An OpenChainGraph receipt already proves what was computed (the §4 hash), that it was computed correctly (§16 and §18 proofs), and who was authorized to run it (§22 mandates). None of that records the act a bank examiner, an auditor, or a court actually asks for: which named human reviewed the result and signed off on it. Section 27 adds that layer as a signed, machine-checkable artifact type, without moving a single existing hash.
A reporting artifact passes through a closed set of accountability roles. Each role binding ties one identity (a did:key or an LEI) to one role for one subject, and is itself signed.
Assembles the reporting artifact from the underlying calculation.
Checks it and records a human judgment. Satisfies a review_required gate.
Accepts responsibility. This is the legally-effective sign-off, and the only role that can satisfy dual control.
Transmits it. The optional model_owner, compliance_officer, and read-only examiner round out the set.
An approval record is a new artifact about an existing sealed one. It carries the subject artifact's execution_hash as a reference, never a copy of the subject's inputs, so it can be added, revised, or discarded and the subject's hash stays byte-identical. This is the SCITT pattern: a receipt about a receipt. Every approval record carries its own §16 signature bound to the named human, so an unsigned record is not accepted as evidence.
{
"record_type": "approval",
"role": "approver",
"subject_hash": "sha256:9f2c...", // the sealed report being signed off
"identity": { "id": "did:key:zCFO" },
"reason_code": "REVIEWED_OK",
"timestamp": "2026-07-23T14:00:00Z"
// + its own execution_hash and a §16 eddsa-jcs-2022 proof
}A gate can require dual_control(N): it is satisfied only when N distinct identities have each signed an approval record over the same subject. Distinctness is by identity, never by key, so one person who rotates keys or signs twice still counts once. This is exactly the check the FDIC GENIUS rule needs for its CEO and CFO certification.
Two records: did:key:zCEO and did:key:zCFO. Two distinct identities, threshold met.
Two records both from did:key:zCEO. One human cannot self-approve past dual control.
A §21.4 decision gate can carry a policy from a closed vocabulary: auto_pass, review_required, dual_control, escalate, hold, reject, or emergency_override. The policy is a precondition checked before the routing rules, so an unmet requirement holds the step rather than falling through to the gate default. The routing math itself is untouched.
An emergency override is never an unconditional bypass. It is a time-boxed attenuation plus a mandatory evidence bundle (reason, scope, expiry, authorizing identity, and a link to the overridden hash). When the expiry passes, the override lapses and the gate reverts to its underlying policy. A timeout can never resolve to a silent permanent pass.
The evidence bundle aggregates the whole trail for one subject: input lineage, kernel and policy versions, the verification verdict, annotations, the reviewer and approver identities with their signed record hashes, timestamps, and a submission-receipt slot filled only after a real transmission. It exports through §13.12 SD-JWT selective disclosure, so an examiner gets exactly the fields their remit requires. Approver identities and the verdict are always disclosed; input values can be selectively withheld. A redacted bundle is not re-executable; it evidences the human trail, not a recomputation.
role_binding.approval record. A review_required gate is now satisfied.approval over the same subject_hash. dual_control(2) clears because the two identities are distinct.execution_hash. A verifier that predates §27 validates the report unchanged and can ignore the accountability layer entirely.All content on this page is static and processed locally in your browser. No data is transmitted. Do not enter real personal data into any OpenChainGraph tool. Use synthetic or anonymised inputs only.