Closed-Loop Specification

Triple-Leaf Ledger

Normative specification for the execution witness, variance record, and closed-loop cross-leaf linkage. Authorization → execution trace → variance record.

Normativev0.1-Draft

Extends: AGTS_CLEARINGHOUSE_SPEC.md §11, §14 · Implements: RTR Regulated Collapse Architecture Stages 6–7

§1 Overview

The base AGTS protocol produces a single canonical leaf per governance decision: the authorization record. This extension closes the accountability loop by adding two additional leaf types, creating a Triple-Leaf Ledger per governed action:

LeafArtifact typeWhat it recordsWhen it fires
Leaf 1: AuthorizationAGTS_GOVERNANCE_ENVELOPE_V1Action was permitted under these conditionsAfter validator quorum + sovereign authority signing
Leaf 2: ExecutionAGTS_EXECUTION_TRACE_V1This is what actually happenedAfter the authorized action executes
Leaf 3: VarianceAGTS_VARIANCE_RECORD_V1This is the measured gap between intent and realityAfter execution trace is admitted

The three leaves form a cryptographic chain: Leaf 2 references Leaf 1 by parent_auth_leaf_hash. Leaf 3 references both by parent_auth_leaf_hash and parent_exec_leaf_hash. An auditor can reconstruct the complete chain using only the transparency log and standard SHA-256 operations.

§2 Why the Base Protocol Is Incomplete

The base AGTS protocol satisfies the RTR "Decision Firewall" (Stage 5): collapse gating ensures that only states satisfying H ≤ H_max ∩ C ≥ C_min can produce a commitment. This is necessary but not sufficient.

The gap: After the gate passes and the action is authorized, the base protocol has no mechanism to verify that the physical execution matched the authorized intent.

ScenarioAuthorization leaf saysWhat actually happensDetection without closed loop
NominalPermitted: deploy model v2.1Model v2.1 deployed, metrics stable
Silent driftPermitted: maintain temperature 2–8°CTemperature drifted to 9°C for 3 minutes
Governance gapPermitted: trade within VaR limitsTrading algorithm exceeded VaR during execution

§3 Execution Witness (L6 — Stage 6)

§3.1 Artifact: AGTS_EXECUTION_TRACE_V1

{ "type": "AGTS_EXECUTION_TRACE_V1", "version": "AGTS-1", "subject_id": "supply-chain:batch-4401", "parent_auth_leaf_hash": "<64-char hex — leaf_hash of the authorization envelope>", "node_id": "<64-char hex>", "auth_state": { "H": 0.90, "C": 0.85, "E": 0.10 }, "exec_state": { "H": 0.88, "C": 0.83, "E": 0.12 }, "execution_metrics_hash": "<64-char hex — SHA256 of domain-specific execution data>", "outcome": "NOMINAL", "outcome_detail": "L2 distance: 0.0300 (nominal ≤ 0.05, drift ≤ 0.20)", "generated_at": "2026-03-12T14:30:00Z", "spec_ref": "RTR Regulated Collapse Stage 6 — Execution Witness" }

§3.2 Who produces the execution trace

The execution trace is produced by the same clearinghouse node that produced the authorization. The node_id in the trace matches the node_id of the authorization proof bundle — non-repudiation by construction.

§3.3 Domain metrics commitment

The execution_metrics_hash commits to domain-specific data without storing it in the log:

DomainExample execution metricsHash input
Supply chain{ temperature_max: 7.2, handling_events: 3 }SHA256(canonical_json(metrics))
Financial{ realized_pnl: 42300, var_utilization: 0.78 }SHA256(canonical_json(metrics))
Cybersecurity{ action: "block_ip", endpoints_affected: 3 }SHA256(canonical_json(metrics))

§3.4 Outcome pre-classification

ClassificationL2 distanceMeaning
NOMINAL≤ 0.05Execution matched authorized intent
DEVIATED≤ 0.20Measurable drift, within operational tolerance
BREACHED> 0.20Execution exceeded authorized bounds

§4 Variance Reconciliation Engine (L7 — Stage 7)

§4.1 Artifact: AGTS_VARIANCE_RECORD_V1

{ "type": "AGTS_VARIANCE_RECORD_V1", "version": "AGTS-1", "subject_id": "supply-chain:batch-4401", "node_id": "<64-char hex>", "parent_auth_leaf_hash": "<64-char hex>", "parent_exec_leaf_hash": "<64-char hex>", "auth_state": { "H": 0.90, "C": 0.85, "E": 0.10 }, "exec_state": { "H": 0.88, "C": 0.83, "E": 0.12 }, "delta": { "H": -0.02, "C": -0.02, "E": 0.02 }, "l2_distance": 0.0346, "classification": "NOMINAL", "drift_direction": { "H": "degraded", "C": "degraded", "E": "degraded" }, "thresholds_applied": { "NOMINAL_MAX": 0.05, "DRIFT_MAX": 0.20 }, "auth_in_omega": true, "exec_in_omega": true, "omega_breach": false, "generated_at": "2026-03-12T14:30:01Z", "spec_ref": "RTR Regulated Collapse Stage 7 — Variance Reconciliation" }

§4.2 Omega breach detection

auth_in_omega = true (system was in safe region Ω when authorized) exec_in_omega = false (system exited Ω during execution) omega_breach = true (governance gap — authorized safe, executed unsafe)

This is the most critical scenario: the five-gate validation correctly permitted the action, but the execution drove the state outside the admissible region. Without the closed loop, this breach is invisible.

§5 Cross-Leaf Linkage — Log Worker Enforcement

Rule 1: Execution traces MUST have a valid parent authorization. If parent_auth_leaf_hash does not correspond to an existing leaf, the trace MUST be rejected with HTTP 422 and error code PARENT_AUTH_NOT_FOUND.

Rule 2: Variance records MUST have valid parent authorization AND execution. Both parent_auth_leaf_hash and parent_exec_leaf_hash must correspond to existing leaves.

Rule 3: No orphaned execution traces. An execution trace referencing a non-existent authorization MUST be rejected.

§6 HCE Feedback Loop

Measurement typeTriggerH nudgeC nudgeE nudge
execution_nominalNOMINAL variance+0.015+0.015−0.010
execution_driftDRIFT variance−0.025−0.020+0.025
execution_breachBREACH variance−0.070−0.050+0.070

The feedback is one-directional and forward-only: variance from cycle N affects observables for cycle N+1. The append-only log guarantees no retroactive modification.

§7 Audit Path

An auditor investigating a specific action retrieves three leaves: Authorization (replay the five-gate evidence, validator votes, authority signature), Execution trace (actual execution state, domain metrics hash, outcome classification), and Variance record (computed gap, per-observable deltas, omega breach status).

All three are linked by parent_auth_leaf_hash and parent_exec_leaf_hash. The chain is self-contained — no external data required for the basic audit.

§8 What This Does Not Change

The closed-loop extension does not modify: the five-gate validation predicate, the proof bundle format, the governance envelope format, the validator network, the sovereign authority signing ceremony, the existing canonical leaf format, or the STH, witness, and consistency proof protocols.

It adds two new leaf types to the same log, using the same Merkle tree, the same signing primitives, and the same verification infrastructure. The base protocol is a strict subset of the closed-loop protocol.

Non-technical overview → Base spec → Normative vocabulary →