Primer
Why a core?
This example proposes a small shared project record. It illustrates how explicit fields and checks can expose inconsistencies; it is not an official Project Data Standard, a full JSON Schema validator or evidence of reliable forecasting.
What’s validated?
Required fields, ID and codelist formats, real dates, start/finish order, finite non-negative amounts, same-currency CAPEX budgets, provenance age and duplicate IDs. Actuals mean spend to date; forecast means total expected spend. Early completion and forecasts below baseline are allowed.
How to use
Try this: set a milestone actual date before its planned date, then change a CAPEX funding currency. The first is allowed; the second blocks the comparison. Tune tolerance/SLA, validate, then download the results with the assessed settings. A check report is not certification or approval.
Playground
Payload (JSON)
Example-rule results
Scores are the percentage of these illustrative checks that pass, not a measure of project health or readiness. — means no applicable checks. Unknown fields and many domain rules are not assessed.
Rule violations
| Rule | Severity | Message |
|---|
Parsed header
Visuals
Milestone timeline
Funding vs Baseline/Forecast/Actual
Codelists
DeliveryPhase
ApprovalStage
RAG
Declared provenance
project.provenance and the was_derived_from link. These are assertions in the payload, not independently verified lineage.Export report
(validate to populate)