You publish the first half of the contract.
We can give you the second.
Australian agencies publish planning, tender and award data as open contracting data. Then the project is delivered, and what actually happened - cost, time, scope, performance - comes back as PDFs, or not at all.
A contractor running delivery on Demiton can hand that half back as a schema-valid OC4IDS v0.9.5 dataset, linked by ocid to the contracting process you already published. No integration for you to build, and no system for you to buy.
Planning, tender, award
Every Australian jurisdiction publishes some of this, and the Commonwealth publishes it well. It is the front half of the contracting process: what was sought, who bid, who won, for how much. This is yours to author and we do not re-publish it - we read it, normalise it, and link to it.
Delivery, cost, completion
What was actually built, what it cost, how long it took, how it performed. Today this returns to the agency as PDF reports, spreadsheets and monthly claims - if it returns in a structured form at all. It is the half that tells you whether the procurement worked.
The award is the seam. It is where a public contracting process becomes a private delivery project - and the only join needed to make the two halves one record is the identifier you already publish.
What we are actually asking for.
None of this requires a procurement, a platform, or a budget line.
Keep publishing tender and award as OCDS
You are mostly doing this already. It is the anchor the rest depends on, because the ocid is what lets a contractor's delivery record point back at your contracting process without either side building an integration.
Prefer contractors who can emit open delivery data
Not a mandate - a preference, expressed the way local content and Indigenous participation preferences already are. A contractor who can hand back structured delivery data costs you nothing extra and saves your team the reporting cycle.
Accept it as data, not as a portal
The contractor emits; you ingest. There is no Demiton system for an agency to procure, log into, or maintain. If you can consume OCDS you can consume OC4IDS - it is the same publishing model, one stage further down the lifecycle.
Because it was never typed into a form.
The usual objection to contractor self-reporting is that it is self-reported. Demiton data is not authored for the report - it is read from the contractor's own finance, payroll and field systems as the job runs, and the disclosure is a projection of that record.
Identity-bound
Every figure in a Demiton record was fetched by a named connector under a named user through Microsoft Entra ID, never a shared service account.
Traceable to source
A fact without a source cannot enter the record. Each figure carries the system it came from, the date it was learned, and the connector version that fetched it.
Contractor-initiated and consented
Tenant operational data never flows to a public hub on its own. Disclosure is an explicit, consented, audited act by the contractor - not a background sync.
Demiton stages delivery data against OC4IDS v0.9.5 today - the preparation, consent and audit path is built. The emission step is scoped per engagement, because no agency has yet told us what shape they want it in. That is the conversation we are trying to start.
Schema-valid is not comprehensive. A partial OC4IDS dataset is still a conformant one. We would rather emit a narrow, accurate record than a wide, padded one.
OC4IDS is pre-1.0. Version 0.9.5, published by the Open Contracting Partnership and CoST. We cite the version because it matters, and because it will change.
Completion data is project-level. It is cleanest on single-prime projects. A project with several head contractors needs a convention nobody has settled yet.
If your agency would accept it, we will build to your shape.
We are looking for one agency willing to receive a delivery dataset for one project and tell us whether it is useful. That is the whole ask.
Open source pipeline - github.com/demitonapp/opencontractau