1. Ecosystem Actor Types
AGTS defines six distinct actor types. Each has a specific role, a specific key, and a specific relationship to the governance record:
| Actor | Identified by | Role in governance |
|---|---|---|
| Operators | node_id = SHA256(client SPKI) |
Run AI systems and submit governance evidence. Produce proof bundles. Hold the Sovereign Authority key. Bear accountability. |
| Validators | validator_id = SHA256(validator SPKI) |
Independently evaluate proof bundles against policy rules. Vote ACCEPT or REJECT. 3-of-4 quorum required for authorization. |
| Sovereign Authority | authority_node_id = SHA256(authority SPKI) |
Hardware-backed (Pixel Titan M2, StrongBox). Signs the final Governance Envelope after quorum. Makes the authorization binding and non-repudiable. |
| Log Operators | log_id = SHA256(log operator SPKI) |
Maintain the append-only Merkle transparency log. Sign the Signed Tree Head (STH). Cannot alter admitted leaves. |
| Witnesses | witness_id = SHA256(witness SPKI) |
Countersign STHs and gossip with other witnesses. Detect log forks and equivocation. Required at L4. |
| Monitors | monitor_id = SHA256(monitor SPKI) |
Scan the log for governance gaps, consistency violations, BREACH variance records. Regulators, insurers, and counterparties run monitors. |
No actor is trusted unconditionally. The operator submits evidence but cannot vote. The validator votes but cannot sign. The authority signs but cannot admit. The log admits but cannot alter. The witness countersigns but cannot forge. Every power is separated.
2. AGTS Protocol Stack
| TCP/IP Layer | AGTS Layer |
|---|---|
| Application (HTTP, SMTP) | Governance Layer (RTR measurement, validation) |
| Transport (TCP, UDP) | Envelope Layer (Governance Envelope assembly) |
| Internet (IP) | Transparency Layer (Merkle log, STH) |
| Link (Ethernet, Wi-Fi) | Verification Layer (witnesses, monitors) |
| (Physical) | Trust Policy Layer (client trust decisions) |
3. The AGTS Governance Mesh
| Property | Value | Why |
|---|---|---|
| Byzantine fault tolerance | f = 1 (4 validators, 3-of-4 quorum) | No single validator can forge a quorum certificate |
| Log operator collusion resistance | Merkle tree + witnesses | Log operator cannot alter or remove leaves without breaking consistency proof; witnesses detect forks |
| Operator non-repudiation | Sovereign Authority signature | Hardware-backed key; biometric gated; cannot be exported |
| Monitor independence | log_id only required | Monitors verify the log with only the log operator's public key — no access to operator systems required |
4. AGTS as Air Traffic Control
Air traffic control (ATC) is the most apt operational analogy for AGTS. ATC does not fly aircraft; it governs them. Pilots decide where to fly; ATC determines when, where, and how safely. No aircraft may enter controlled airspace without ATC authorization. The authorization is based on verifiable criteria (position, altitude, weather, traffic) that are independent of the pilot's claim. ATC keeps a complete record of every authorization — the flight log. Any incident investigation begins with this record, not the pilot's account.
| ATC element | AGTS equivalent |
|---|---|
| Controlled airspace | Any governance-critical decision domain (trading, drug release, model deployment) |
| ATC authorization | Governance Envelope: five-gate proof + validator quorum + authority signature |
| Flight plan | Proof Bundle: stated intent, evidence, operator identity |
| Transponder signal | Governance evidence: verifiable, independent, continuous |
| Flight recorder | Transparency log: append-only, tamper-evident, independently verifiable |
| Incident investigation | Replay: gate-by-gate reconstruction from canonical leaf |
| ICAO standards | AGTS specification suite (AGTS-0 through AGTS-12) |
The pilot (operator) cannot simply say "I am in safe airspace." ATC verifies independently. AGTS: the operator cannot simply say "my AI system was behaving safely." The five-gate validation and the transparency log verify independently.
5. The Obligation Record Primitive
The canonical leaf is the fundamental primitive of the AGTS protocol. It plays the same role in governance infrastructure as packets play in networking — the irreducible unit of the system.
| Infrastructure type | Primitive | Properties |
|---|---|---|
| Networking (TCP/IP) | Packet | Fixed header, variable payload, routing address, checksum |
| PKI (X.509) | Certificate | Signed, expiry-bound, chain-of-trust |
| Finance (payments) | Transaction record | Atomic, ordered, non-repudiable, settled |
| Governance (AGTS) | Canonical leaf (Obligation Record) | Hash-chained, timestamped, signed by multiple parties, permanently verifiable, replayable |
Like TCP/IP packets, canonical leaves can be inspected by any party with access to the log. Like X.509 certificates, they carry multiple signatures and are chain-of-trust bound. Like financial transactions, they are atomic and permanently settled. Unlike all three, they are replayable — the exact decision context can be reconstructed from the proof bundle referenced by the leaf.
This replayability property is new. No prior infrastructure primitive — not packets, not certificates, not transactions — allows you to reconstruct the exact reasoning that led to a specific record. AGTS canonical leaves do.