Based on the open-source reference implementation evidence_gated_state_machine.py and its independent reruns (verified 2026-09-29 and 2026-10-03; fresh rerun 2026-10-16)

Registry entry - new FG-TIDA contribution
- Document type: new contribution - executable reference implementation for evidence-gated agent lifecycle governance
- Date: 2026-10-16
- Author: Steven Zhao / Independent Researcher

Evidence-Gated Governance for Agent Lifecycles: From Theory to Executable Code

Abstract

Governance of autonomous agents is usually specified as prose: a change "should be justified", expansion "should be approved", postmarket drift "should be monitored". Prose governance leaves the gate itself undefined, so implementations diverge and audits cannot distinguish a denied transition from an ignored one. This contribution presents a small, runnable reference implementation that turns four lifecycle-governance constructs into executable state-machine semantics: an entity registration spine with a hash-chained audit trail, evidence-gated transitions that are denied rather than merely discouraged when declared evidence is unmet, named silent-failure detectors, and a bright-line rule that capability expansion requires distinct human authorization. The script is Apache-2.0, uses only the Python standard library, and ships with seven self-checks that all pass and return exit code 0.

Problem

Agentic systems change themselves in production: a model is updated, a tool is swapped, a dataset is refreshed, an agent's authority expands. Two weaknesses recur in current governance thinking. First, obligations are written as recommendations rather than as machine-checkable predicates, so a transition can be quietly skipped without any inspectable record. Second, authority and capability are conflated: an agent that is permitted to act is often allowed to enlarge its own envelope. Auditors then face a narrative rather than a ledger. What is missing is the smallest executable core that a standards body could point to and say: this is what a gate means; this is what a denial looks like; this is what must be re-shown before a returned-to-service agent acts again.

Solution

The reference script implements four constructs.

1. Entity registration spine. Every agent, model, tool and dataset is registered as a versioned entity; each registration materializes a SHA-256 link over the previous link, forming a hash-chained audit trail (evidence_gated_state_machine.py, lines 59-66 and 77-81). A verify_chain() method re-walks the chain and returns false on any inconsistency (lines 86-94).

2. Evidence-gated state transitions. Six transition types are pre-declared, each with a fixed list of required evidence items (lines 97-114). A gate attempts a transition; if any required evidence is absent, it raises a denial, records a receipt, and the transition does not occur (lines 126-140). This is invalidity, not discouragement: the failed transition is a binary, inspectable event, not a soft warning.

3. Human-authorized capability expansion. A bright-line rule: even when evidence is present, a capability-expansion transition is denied unless a distinct human authorization flag is set (lines 142-149). Authority is not capability; crossing a capability tier requires a human receipt.

4. Named silent-failure detectors and re-entry. Three postmarket monitoring predicates are provided: population drift (headline accuracy stable but subgroup degraded beyond a threshold), expired input (a tool or dataset used outside its declared validity window), and path deviation (an agent completing work through workflows outside its declared envelope) (lines 159-172). Return-to-service is itself a gated transition requiring fresh reverification evidence (lines 236-241), so re-entry is non-monotonic and must be re-earned rather than assumed.

Evidence

Every claim below is verifiable against the script source or its rerun output.

• Seven self-checks. The demonstration path contains seven PASS assertions, printed at lines 188, 196, 208, 219, 226, 234 and 241: a registration spine with four entities and a verifiable chain; a model-update transition granted; a tool-change transition denied with a recorded receipt; capability expansion denied without human authorization; the same expansion granted once human authorization is supplied; all three silent-failure detectors firing; and return-to-service granted only through a fresh evidence-carrying transition.
• Exit code 0. The wrapper exits 0 only when every self-check passes and 1 on any assertion failure or unexpected denial (lines 247-256). A fresh rerun on 2026-10-16 reproduced the seven PASS lines and exit code 0; an independent verification rerun on 2026-09-29 confirmed the same, including the denial path.
• Audit-trail facts. The rerun prints five receipts and a chain depth of five (line 243), matching the script's own audit output.
• Hash chain verified. Each link is SHA-256 over the previous link and a canonical JSON payload (line 65); verify_chain recomputes every link on demand (lines 86-94).
• Zero dependencies. The script imports only hashlib, json, sys, dataclasses, enum and typing (lines 30-35), and is released under Apache-2.0 (line 20).

Reproduction Path

1. Obtain evidence_gated_state_machine.py (Apache-2.0, standard-library only, no network access required).
2. Run it with Python 3: python3 evidence_gated_state_machine.py.
3. Observe seven [PASS] lines, ending with the result line that all self-checks passed; observe the printed receipt count and chain depth.
4. Expect exit code 0. To confirm the denial semantics directly, read the gate.attempt source, remove one required evidence key from a call, and rerun: the script exits 1 and names the missing evidence. No installation, account or external service is required.

Contribution to FG-TIDA

This contribution complements the organizational deployment-tiers submission, which describes how existing institutions map onto governance roles across organization, company and state scales. That submission answers who staffs the gate; this one answers what the gate literally does when code runs. It gives the Focus Group a machine-checkable anchor for three work items: lifecycle and trust models, where a transition is invalid rather than discouraged when evidence is unmet; security criteria and benchmarks, where the seven self-checks form a minimal, repeatable harness an evaluator can clone and rerun; and reference architecture, where the registration spine, hash chain, denial receipt and human-authorization bright line are small enough to embed in any member's existing change-management tooling. The design goal is not novelty but falsifiability: every governance sentence above reduces to a line of code that either runs or does not.