Audit Surface

The structured governance digest derived from the Proof of Action trail and designed for Steward comprehensibility at operational tempo — the architectural layer between the complete immutable record and the Steward's daily monitoring requirement, specifying what must be verified, in what time budget, and at what level of abstraction for the Intervention Threshold to be actively rather than nominally enforced.

The Audit Surface and the Proof of Action trail are two different artefacts that must both be designed from the same underlying record. The Proof of Action trail is structured for external auditability: every agentic decision and handoff recorded at the Deterministic Logging level, immutable, structured for auditor replay, complete enough that an analyst with unlimited time can verify governance compliance from the record alone. The Audit Surface is structured for operational monitoring: exception-flagged, anomaly-surfacing, completable in minutes, designed for a Steward with a five-minute daily review window rather than an auditor with a due diligence timeline.

The distinction exists because the two use cases have structurally opposite information requirements. External auditability benefits from maximum completeness: the more the record contains, the more verifiable the governance claim. Operational monitoring benefits from maximum compression: the more the digest collapses routine confirmations and surfaces only anomalies, the more likely the Steward is to actually read it. A system that provides only the Proof of Action trail has satisfied the external governance requirement while leaving the Steward without a governance surface that is practical to use. When the Steward stops using the trail — which they will, when its information density exceeds the attention available to review it — the system enters Nominal MTTI.

The minimum specification for a functioning Audit Surface has four components. First, a daily Escalation Rate summary by task class, displayed against the target band defined in the Exception Architecture, flagging any class whose rate has moved outside the band since the last review. Second, an Execution Divergence alert layer, surfacing any workflow that deviated more than 15% from its predicted path in the preceding period. Third, an exception novelty signal: any exception class encountered in the period that the Exception Architecture does not yet contain a canonical resolution for. Fourth, a pull mechanism: conditions that exceed the Intervention Threshold surface to the Steward proactively, not on the Steward's next scheduled review — the Steward should not need to initiate a review to discover that something requires intervention.

First used: May 2026