# Governance controls

These files turn the reviewed domain profile into testable release controls:

- `requirements.json` states normative product and safety requirements;
- `traceability.json` maps those requirements to evidence, decisions,
  artefacts, risks and validation;
- `risk-register.json` records foreseeable harm, planned controls and release
  disposition;
- `rights-review.json` records which metadata operations are permitted,
  conditional or prohibited for each source layer;
- `ai-model-usage.json` distinguishes measured AI token evidence, unavailable
  pre-tracking usage, subscription allocation and separately billed API spend;
  and
- `artifact-dependency-graph.json` maps changed authored inputs to predicted
  generated artefacts, requirements, risks, tests, validations and release
  gates. Its top-level `build_inputs` role is the smaller causal set hashed into
  the build receipt; stage `inputs` plus `validation_inputs` remain the complete
  candidate-control set bound by the candidate commit and G1–G9 evidence.

They are machine-readable inputs, not validation receipts. Where present, the
v0.1.0 `released-poc` and policy-approval states authorise only the control
design and release intent. They do not prove that generated bytes passed a
gate; only the exact-digest receipts and G9 release record can do that.

## Authority

The domain profile and its evidence register are the discovery authority for
this scaffold. Current legislation, formal notices and publisher-operated HM
Land Registry sources remain authoritative for legal and operational facts.
If a governance file conflicts with a current source, stop the build, record
the conflict and return to Stage 1 review.

## Change control

Every requirement, risk and rights assessment has a stable ID. Do not reuse an
ID for a different meaning. Add a new entry or explicitly supersede the old
one. A change to scope, authority, public fields, acquisition, licence,
restricted-service treatment or release claims requires a fresh rights and
risk review.

Generated validation receipts should refer to these IDs and bind the exact
candidate and policy digests. The v0.1.0 policy approval covers only the
AI-generated metadata proof of concept and does not substitute for a human
legal, licence or accessibility audit. Do not edit receipts or generated
bundle files to make a check pass; fix the source, rule or implementation and
rebuild.

The dependency graph is release-planning policy, not evidence that an affected
gate passed. Unknown paths and generated changes without a matching upstream
edge require manual review and all G1–G9 gates. Update the graph whenever a
governed input, output, validator or gate relationship changes.
