Conformance & the disclosure gate
Standards conformance in Demiton is a property declared at the edges of the system, not a claim about internal storage. This page is the concrete “how it’s enforced” companion to OCDS and OC4IDS.
Conformance is declared per adapter
Every adapter that touches procurement or delivery-reporting data declares its own conformance level:
| Adapter kind | Declares |
|---|---|
| Procurement adapters (AusTender, state portals) | ocds-1.1 |
| The delivery-reporting emission service | oc4ids-0.9.5 |
| Native operational adapters (ERP, field ops, payroll) | none |
Nothing in the platform stores OCDS or OC4IDS as its native format. Internal facts keep their own typed structure; conformant output is projected wherever a boundary is crossed - on ingest from a government portal, or on emission to one. See OCDS for what that projection looks like on the way in.
The One-Way Valve
Your tenant’s operational memory - site diaries, allocations, payroll reconciliations, anything produced by running your own business - never flows to Demiton’s public platform hub as a side effect of being in the system. It reaches the public side only through a delivery report you explicitly choose to send to a government client: a contractor-initiated, consented, audited emission.
That’s the One-Way Valve: data can flow from the public hub into your tenant freely (that’s how Market works), but it only flows back out through one deliberate, logged action - never silently, never automatically.
The disclosure gate is the single guard
Every crossing - public data landing in your tenant, or your delivery data leaving it - passes through one enforcement point: the disclosure gate. Centralising it there means there’s exactly one place in the platform where “is this allowed to cross” is decided, and exactly one place to audit if you need to know why something did or didn’t.