Insurance framing
Governance chain depth and variance history provide measurable operational risk signals for underwriting autonomous systems. An insurer scanning the log can compute mean time between governance breaches, variance trend over time, and omega_breach frequency — without accessing the operator's systems.
What AGTS proves
Each authorized governance decision produces a canonical leaf that cryptographically binds:
The proof bundle
What evidence justified the decision — five gate results with supporting data, four evidence hashes, system state snapshots, replay seed.
The validator signatures
Who evaluated it — three or more of four independent validators voted ACCEPT with ECDSA P-256 signatures over a canonical representation of the proof bundle.
The authority signature
Who bears accountability — the Sovereign Authority key (hardware-backed, biometric-gated) signed the Governance Envelope. The operator who pressed the fingerprint is on record.
The log binding
Where the record lives — the canonical leaf hash, Merkle inclusion proof, and Signed Tree Head, independently verifiable by any party with the log_id.
Six-claim regulatory mapping
The AGTS compliance report covers six claims (RTR-C001 through RTR-C006). Each claim maps to specific regulatory articles and is satisfied by specific gate evidence.
Statistical Capability Confidence
Gate: G1 — confidence interval on system performance metric
Regulatory articles: EU AI Act Art. 15 (accuracy and robustness); ISO/IEC 42001 §6.1.2 (AI risk assessment)
What the gate proves: The system's performance is measured with a bounded confidence interval. The lower CI bound meets a declared threshold — the system is not operating on anecdote.
How an auditor verifies it: Retrieve the proof bundle from the governance API using the leaf's payload_uri. Check gate_results.G1.confidence_interval_lower against the declared threshold in the Verification Policy Bundle.
Financial Validity — Compliance Threshold
Gate: G2 — C (compliance) ≥ 0.40
Regulatory articles: EU AI Act Art. 13 (transparency and provision of information); DORA Art. 8 (ICT risk management framework)
What the gate proves: The compliance observable meets the declared threshold. The IEED observable framework captures entropy (H), compliance (C), and energy (E) — three orthogonal measures of system governance posture.
How an auditor verifies it: Check gate_results.G2.compliance ≥ 0.40 and ablation_delta within declared bounds.
Byzantine Fault Tolerance
Gate: G6 (Byzantine kernel) — validator quorum with 3-of-4 threshold
Regulatory articles: EU AI Act Art. 14 (human oversight); DORA Art. 11 (ICT business continuity)
What the gate proves: No single validator can authorize a governance action. The quorum requires ≥3 of 4 validators to ACCEPT, with at least one regulator-role and one auditor-role validator. A single Byzantine node cannot forge a quorum certificate.
How an auditor verifies it: Inspect the Governance Envelope's quorum_certificate. Count valid AGTS_VOTE_V1 signatures. Verify each against the validator registry. Count regulator and auditor roles.
ℹ Trial tier: this claim shows amber — single local validator (genesis mode) does not satisfy Byzantine fault tolerance. Resolves at L2 Certified.
Operational Validity — Energy Bound
Gate: G3 — E (energy) ≤ 0.60
Regulatory articles: EU AI Act Art. 9 (risk management system); ISO/IEC 42001 §8.4 (AI system operation)
What the gate proves: Execution energy stays within the declared bound. Operational Validity enforces that no protected metric degraded beyond its threshold — safety score, VaR limit, toxicity rate — by bounding the energy observable mathematically.
How an auditor verifies it: Check gate_results.G3.energy ≤ 0.60 and inspect protected_metrics against the Verification Policy Bundle's declared thresholds.
Bounded Recovery
Gate: G7 (lifecycle controller) — ACTIVE / QUARANTINE / LOCKBOX state management
Regulatory articles: EU AI Act Art. 15 (robustness and fail-safe operation); DORA Art. 25 (testing of ICT tools)
What the gate proves: The system has a bounded recovery mechanism. Three consecutive BREACH classifications trigger QUARANTINE — autonomous authorization is suspended until remediation. The log records the state transition.
How an auditor verifies it: Scan the log for AGTS_VARIANCE_RECORD_V1 with classification: BREACH. Count consecutive breaches. Verify lifecycle state matches.
ℹ Trial tier: this claim shows amber — bounded recovery requires operational monitoring infrastructure. Resolves at L2 Certified.
Aggregate Gate — Evidence Integrity
Gate: G4 — aggregate gate with evidence classification and four-hash integrity proof
Regulatory articles: EU AI Act Art. 12 (record-keeping); Basel III Pillar 2 (governance of model risk)
What the gate proves: The evidence used to justify the decision was produced by an independent harness (HOOKED), an attested enclave (ATTESTED), or instrumented internal audit (INSTRUMENTED) — not self-reported. The four evidence hashes commit to the evaluation dataset, execution trace, ablation log, and capability certificate.
How an auditor verifies it: Check gate_results.G4.evidence_class is not UNCLASSIFIED. Request the raw evidence artifacts and verify SHA256(canonical_json(artifact)) === recorded_hash.
Continuous compliance through replay
Each claim summary includes a link to a representative leaf. Auditors can replay any decision from any period — not a sample, but any specific decision — to see the exact gate evidence that led to the outcome.
This transforms audits from periodic document reviews into continuous, on-demand verification. Exported compliance reports include references to all proof bundles, enabling offline replay without contacting the operator.
Try the replay demo →Closed-loop accountability (L2+ tiers)
For governed actions using the Triple-Leaf Ledger, the audit path expands from "was this action permitted?" to "did the execution match the permission?"
| Leaf | What the auditor sees | What it proves |
|---|---|---|
| Authorization (Leaf 1) | Gate evidence, validator votes, authority signature | The action was permitted under these conditions |
| Execution (Leaf 2) | Execution-time H/C/E state, domain metrics hash, outcome classification | This is what actually happened |
| Variance (Leaf 3) | Per-observable deltas, L2 distance, omega breach status | The measured gap between intent and reality |
An auditor can request the triple-leaf chain for any action by its authorization leaf hash. Governance breaches (BREACH classification or omega_breach = true) are visible to monitors scanning the log in real time — no access to the operator's systems required.
Conformance levels
| Level | What it requires | Regulatory purpose | Pricing tier |
|---|---|---|---|
| L1 | Clearinghouse running, proof bundles generated | Internal record — EU AI Act Art. 12 basic record-keeping | Free trial |
| L2 | Validator network (AGTS_VOTE_V1 quorum), Sovereign Authority signature | Insurance-relevant — RTR-C003 and RTR-C005 satisfied | Pay-as-you-govern / Certified |
| L3 | Transparency log, STH, inclusion proofs, external verifiability | Counterparty-verifiable — regulators can run their own monitor | Transparent |
| L4 | Witness quorum, external monitor network, cross-institution mesh | Regulatory-grade — no trust assumption on operator systems required | Networked |
ENISA standardisation gap analysis
ENISA's "Cybersecurity of AI and Standardisation" (2021) identifies five gaps that existing frameworks cannot close. AGTS closes all five.
Gap 1: Traceability of data and AI components
"The traceability of data and AI components throughout their life cycles remains an issue that cuts across most threats and remains largely unaddressed."
AGTS response: Every governance cycle commits dataset_provenance_hash and parent_bundle_hash. The hash chain is structural — the Merkle tree enforces it. Any history rewrite breaks the consistency proof. Traceability is a cryptographic property of the log, not a process claim.
Gap 2: Record-keeping to a recognised standard
"Logging capabilities shall conform to recognised standards or common specifications" — but no AI-specific standard defines what a governance log must contain.
AGTS response: The transparency log is an append-only Merkle tree with a defined leaf format (AGTS_GOVERNANCE_ENVELOPE_V1), a Signed Tree Head (STH) signed with ECDSA P-256, witness countersignatures, and publicly verifiable consistency proofs. The format is fully specified at /docs/terms.
Gap 3: Conformity assessment without technical requirements and metrics
"Existing standards on trustworthiness lack conformity assessment methods, sometimes including technical requirements and metrics."
AGTS response: The six-claim compliance report is a unified conformity assessment evidence format. The metrics are explicit and machine-readable: G1 entropy threshold (semantic firewall), G2 compliance score (finance gate), G3 energy bound (ACO observer), G4 aggregate evidence classification, G5 log anchor. No separate standards for separate characteristics — one compliance report covers all seven EU AI Act trustworthiness dimensions.
Gap 4: Transparency requirements without a technical replay mechanism
"Technical documentation is a key element in system transparency and in high-level explainability — but documentation alone doesn't make a decision replayable."
AGTS response: Every governance envelope contains a payload_uri — a durable reference to the evidence used at decision time. Replaying that evidence through the same G1–G5 gate logic produces the same verdicts. The replay is deterministic and independent: any party with the payload_uri and the AGTS validation engine can reconstruct the governance decision context without access to the operator's systems.
Gap 5: Human oversight with a verifiable accountability record
"Where human oversight is required, no existing standard specifies how the human oversight event itself is recorded and made verifiable."
AGTS response: G5 is a gate, not a process recommendation. It is structurally mandatory — no canonical leaf can be admitted without a passing G5 record. The operator_id and the ECDSA signature over the gate verdict are committed into the proof bundle and hashed into the canonical leaf. The oversight event is cryptographically recorded, not self-reported.
For national competent authority staff
If your organisation is standing up an EU AI Act regulatory sandbox under Articles 57–63, the AGTS clearinghouse provides the evidence layer that sandbox participants use to demonstrate governance during the sandbox period.
- Sandbox participants can enrol their AI system with ObligationSign and begin producing canonical leaves immediately
- The governance chain produced during the sandbox period is cryptographically continuous with the chain after the sandbox concludes
- Regulators running a monitor node can verify any leaf independently, without accessing the participant's systems
- The compliance report generated during the sandbox period is the same format as the production report — no translation required
AGTS is not a sandbox. It is the evidence infrastructure that makes governance claims inside a sandbox verifiable.
Contact for sandbox pilot engagements: regulatory@obligationsign.com
Cryptographic audit trail reference
| Audit question | Where to look | Verification method |
|---|---|---|
| Was this governance decision made? | Canonical leaf in transparency log | Inclusion proof from /agts/v1/log/proof/{leaf_index} |
| Was the log root honest at the time? | STH covering the leaf | Consistency proof from /agts/v1/log/sth/consistency |
| Did witnesses agree? | witness_signatures on the STH | ECDSA P-256 / Ed25519 verification against published witness public keys |
| What evidence was used? | payload_uri in governance envelope | Fetch payload, replay through G1–G5 gate logic |
| Who authorised it? | gate_g5_authorization.operator_id | Identity committed in proof bundle, signed by Sovereign Authority |
| What was the model's health state? | gate_g2_drift.{h_score, c_score, e_score} | Compare against admission thresholds in Verification Policy Bundle |
| Was the training data clean? | gate_g4_evidence.classification | HOOKED or ATTESTED = passing; UNCLASSIFIED blocks admission |
| Was execution within bounds? | Leaf 3 variance record | omega_breach field; delta.{h,c,e} per observable |
All verification operations use SHA-256 and standard ECDSA/Ed25519 — no proprietary cryptographic libraries required.