Skip to main content
The Compliance File is the evidence pack behind a decision. This page covers what it holds, the document it is written as, where each piece comes from and who may read it. Read it if you answer audit questions or build reporting on top of composerID. It is what a reviewer asks for when the question is not “does a requisition exist” but “this decision, made at this time on these answers, produced this record in this system, and here is what happened afterwards”.

​
What it holds

  • The scored assessment: the answers, the section scores and the ranked outcomes the decision was made from.
  • The publish receipts: which destination records were created, under which idempotency keys, with deep links.
  • The reconciliation history: what drifted, when, and when it resolved.
  • The signed PDF of the approval workflow, where one exists.

​
The document

The Compliance File is a JSON-LD document that references its evidence rather than copying it: every artifact is a URI, never an embedded binary.
​
string
required
https://composer.id/schemas/defence-file.jsonld. Self-referencing for now; it will move to a dedicated vocabulary URI.
​
string
required
Always DefenceFile.
​
string
required
The Intent ID the file covers. Matches ^[A-Za-z0-9_-]{10,64}$.
​
integer
The intent version the evidence was assembled for. Minimum 1.
​
array
The ordered evidence chain. Each entry carries a type, a timestamp at, an optional ref URI to the source record and a one-line summary. Types: assessment_scored, override_applied, routing_decided, publish_confirmed, reconciliation_passed, pdf_signed.
​
string
URI of the WorkAuthor signed PDF, served by GET /workflows/{Id}/signed-pdf. The authoritative evidence artifact, referenced and never embedded.
​
string
URI of the DiagnosticsBundle that drove the decision.
​
array
The destination records the file covers: provider, external_id, whether the Intent ID was stamped into the record, and a deep_link.
​
string
required
ISO 8601 timestamp. updated_at is set when the file is reassembled.
The intent record points at its Compliance File through defence_file_ref, a URI on the IntentRecord.

​
Where each piece comes from

The Compliance File joins them under the one Intent ID. Lifecycle bookkeeping on the timeline, such as intent.created and intent.version_bumped, is not evidence and is left out.
The reconciliation row is not wired up yet. The reference assembler (adapter/defence_file.py) maps an intent.reconciled event to reconciliation_passed, but that type is not in the TimelineEvent enum: the sandbox emits reconciliation.detected and reconciliation.resolved, which the assembler does not map. Until the two are brought into line, an assembled file carries the assessment, the publish receipts and the signed PDF, and no reconciliation evidence.

​
Who may read it

Nobody downstream. A destination receives the Intent ID and a valid request, never the Compliance File or any link that would expose it without authentication.
Anyone entitled to the evidence follows the reference back to it, behind the programme’s own access controls: the Manuscript API is served with per-customer API keys, with access granted per programme, and the Intent API timeline needs a token with the intents:read scope.
The schema file keeps an older name: defence-file.jsonld, with the field defence_file_ref. The prose was renamed to Compliance File in August 2026; the schema and field keep the old name until a versioned schema rename, so expect that mismatch in the schemas and the reference code.

​
Next steps

Score and manuscript

Why the evidence never travels with the request.

Events and the timeline

The append-only events the evidence chain is built from.

Published schemas

defence-file.jsonld and every other schema at its canonical URL.