How can a Steward tell whether their system has genuine Architectural Certainty or Nominal MTTI?

Three diagnostic questions. First: when did you last read the [Proof of Action](https://arcoventure.studio/lexicon/proof-of-action) trail in enough detail to form a view about whether any task class’s [Escalation Rate](https://arcoventure.studio/lexicon/escalation-rate) has changed? If the honest answer is measured in weeks rather than days, Nominal MTTI is likely. Second: if the system encountered a class of condition it had not previously seen — a novel exception type, an input outside its training distribution, a workflow state the [Exception Architecture](https://arcoventure.studio/lexicon/exception-architecture) had not anticipated — would you have seen it? Not whether the system would have handled it, but whether you would know it occurred. If the answer is uncertain, the governance surface is not functioning as designed. Third: is the quiet audit surface the result of the system handling conditions correctly, or the result of you not looking? The first produces [Architectural Certainty](https://arcoventure.studio/lexicon/architectural-certainty). The second produces the appearance of it. The distinction is the presence or absence of a structured review that confirms the former rather than simply not detecting the latter.

Why is the Proof of Action trail insufficient on its own as a Steward governance surface?

The [Proof of Action](https://arcoventure.studio/lexicon/proof-of-action) trail was designed for external auditability: an acquirer or regulator who needs to verify governance compliance from a complete immutable record. That use case has unlimited time and benefits from maximum information completeness. The Steward’s operational monitoring use case has the opposite constraints: limited time and a need for exception-flagged summaries, not complete records. A trail that records every state transition, every agent decision, and every exception resolution at the [Deterministic Logging](https://arcoventure.studio/lexicon/deterministic-logging) level produces a record that is verifiable in full by an analyst with days to review it and practically unworkable for a Steward with five minutes between other responsibilities. The record is not wrong. The governance surface derived from it was never designed. This is the architectural gap the audit surface problem names: the Proof of Action trail and the Steward’s monitoring digest are two different artefacts that must both be designed from the same underlying record.

What is the difference between a pull-based and push-based governance model, and why does it matter for MTTI?

In a pull-based governance model, the system surfaces conditions that exceed the [Intervention Threshold](https://arcoventure.studio/lexicon/intervention-threshold) to the Steward proactively: the Steward’s attention is pulled to the audit surface by the system when action is required. In a push-based governance model, the Steward must actively initiate a review to detect whether anything requires intervention: attention is pushed into the audit surface on the Steward’s schedule. Pull-based governance makes Nominal MTTI structurally impossible: if the system is designed to surface exceptions proactively, a quiet audit surface confirms that nothing has exceeded the threshold. Push-based governance makes Nominal MTTI structurally likely: if the Steward stops pushing attention into the audit surface — which they will, when the cognitive cost exceeds the perceived value — conditions that exceed the [Intervention Threshold](https://arcoventure.studio/lexicon/intervention-threshold) will go undetected. The distinction matters for [MTTI](https://arcoventure.studio/lexicon/mtti) because pull-based governance produces a long MTTI that confirms genuine [Architectural Certainty](https://arcoventure.studio/lexicon/architectural-certainty). Push-based governance produces a long MTTI that measures how long it has been since the Steward last looked.

How does the audit surface problem relate to Knowledge Debt accumulation?

A system running under Nominal MTTI is accumulating [Knowledge Debt](https://arcoventure.studio/lexicon/knowledge-debt) at the governance layer. Every exception the system encounters that the Steward would have encoded into the [Exception Architecture](https://arcoventure.studio/lexicon/exception-architecture) — and would have encoded, had they been reading the audit surface — is instead handled as a novel condition on each recurrence. The [Escalation Rate](https://arcoventure.studio/lexicon/escalation-rate) for that exception class does not fall because the resolution is never encoded. The [Operational Ledger](https://arcoventure.studio/lexicon/operational-ledger) does not compound because the Steward is not adding to it. The [MTTI](https://arcoventure.studio/lexicon/mtti) does not extend because the architectural improvements that would extend it are not being made. Nominal MTTI and Knowledge Debt accumulation are structurally coupled: each cycle in which the Steward is not monitoring the audit surface is a cycle in which the operational experience the system generates does not flow back into the architecture. The system is fast. It is not learning. And the gap between what it knows and what it has experienced grows until it becomes visible as operational failure.

What does a correctly designed audit surface look like in a production autonomous business?

Three properties. First, a structured governance digest derived from the [Proof of Action](https://arcoventure.studio/lexicon/proof-of-action) trail: a daily or session-level summary that presents the [Escalation Rate](https://arcoventure.studio/lexicon/escalation-rate) for each task class against its target band, any [Execution Divergence](https://arcoventure.studio/lexicon/execution-divergence) events above the 15% threshold in the preceding period, any exception resolutions where the system’s decision was outside the boundary of prior resolutions for the same class, and a confirmation that no new exception classes have appeared without being classified in the [Exception Architecture](https://arcoventure.studio/lexicon/exception-architecture). This digest must be completable in under five minutes. Second, a pull mechanism: conditions that exceed the [Intervention Threshold](https://arcoventure.studio/lexicon/intervention-threshold) surface to the Steward immediately, not on the Steward’s next review cycle. The Steward should not need to initiate a review to discover that something requires intervention. Third, a clear separation between the governance digest and the full [Proof of Action](https://arcoventure.studio/lexicon/proof-of-action) trail. The digest is the daily governance surface. The trail is the source of truth for deep investigation, audit, and due diligence. Both must be maintained. Neither replaces the other. A Steward who reviews only the digest is governing correctly. A Steward who must review the full trail to govern is working in a system whose audit surface was not designed for operational monitoring.

The Audit Surface Problem

Nominal MTTI is the condition in which the measured time between required human interventions is long not because the system has achieved genuine Architectural Certainty but because the Steward has stopped engaging with the audit surface. No interventions are happening. The Escalation Rate is low. The MTTI appears to confirm that the system is governing itself correctly. But the system is not being governed at all. It is running unmonitored, and the Intervention Threshold is enforced in theory but unobserved in practice. Nominal MTTI and genuine Architectural Certainty are observationally identical from the outside. They are structurally opposite.

The Stewardship Model defines the human role in an autonomous business: the Steward governs exceptions, refines the Exception Architecture, and maintains the boundary between the Execution Layer and the Judgment Layer. The Proof of Action trail is the mechanism that makes this governance possible: an immutable record of every agentic decision and handoff, structured so the Steward can verify that the system is operating within the parameters it was designed to enforce. As we argued in Memo #15 — Auditable Autonomy, the audit trail is not a compliance artefact. It is the primary governance surface of the autonomous business.

The failure mode this memo names is not a deficiency in the Proof of Action trail itself. The trail can be technically complete, correctly structured, and fully auditable by the standard of its design, while simultaneously being unread by the Steward who is supposed to act on it. The problem is not the record. It is the gap between the record’s completeness and the Steward’s practical capacity to engage with it. When that gap exists, the governance the Stewardship Model prescribes is present on paper and absent in practice.

Two reasons MTTI appears long

Genuine Architectural Certainty produces long MTTI through a specific mechanism: the Exception Architecture is correctly calibrated, the Escalation Rate for every task class is within the target band, and the conditions that would require Steward intervention are genuinely rare because the system was designed to handle them. The Steward reads the Proof of Action trail, sees nothing that exceeds the Intervention Threshold, and confirms that the system is operating correctly. MTTI extends because the architecture is sound.

Nominal MTTI produces the same measurement through the opposite mechanism. The Exception Architecture may or may not be correctly calibrated. The Escalation Rate for some task classes may have quietly drifted above threshold. Execution Divergence may be accumulating across agent boundaries. But the Steward is not reading the Proof of Action trail with sufficient regularity to detect any of it. No interventions occur not because nothing requires intervention but because the Steward has effectively withdrawn from the governance surface. The MTTI metric cannot distinguish between the two states, because MTTI measures the frequency of intervention, not the quality of monitoring. A system running with no Steward engagement and a system running with active Steward engagement that genuinely requires no intervention both report MTTI = infinity.

Why the audit surface fails in practice

The failure is not inattention. It is cognitive arithmetic. A Steward governing an autonomous business at production volume must review execution records, validate exception resolutions, confirm that the Intervention Threshold is being correctly applied across all task classes, and identify the leading indicators of Knowledge Debt accumulation — rising Escalation Rates for specific exception classes, narrowing MTTI for specific workflow segments, Execution Divergence patterns that signal context drift. The Proof of Action trail contains all of this information. The problem is the form it takes.

The Proof of Action as currently specified is an immutable ledger structured for auditor replay. That specification is correct for the acquisition due diligence use case: an acquirer with unlimited time and a team of analysts can verify governance compliance from the ledger. It is insufficient for the operational use case: a Steward with minutes per day to assess whether the system requires intervention. The same record that satisfies an auditor’s verification requirements may exceed the Steward’s daily attention budget by several orders of magnitude. When it does, the Steward stops reading — not negligently but practically. The governance collapses for the same reason that any human process collapses when its information requirements exceed the attention available to execute it.

This is the failure mode the original Auditable Autonomy memo did not address, because at the time of Series 1 the primary concern was the external auditability problem: making the system’s decisions legible to an acquirer or regulator. The Steward’s operational monitoring requirement is a different use case with different information architecture demands. The same Proof of Action trail that makes the business audit-ready does not automatically make it Steward-readable. Designing both from a single record structure is the architectural error that produces Nominal MTTI.

The audit surface as an architectural requirement

The solution is not better tooling applied to an existing record. The Proof of Action trail cannot be made Steward-readable by rendering it as a dashboard after the system is running. The audit surface must be designed as an architectural requirement before the first execution cycle, with the same rigour as the Exception Architecture itself. Three design questions must be answered before deployment.

First: what must the Steward be able to verify in the time budget available per session? Not what the system records but what the Steward needs to confirm. The answer is a bounded set: that the Escalation Rate for each task class is within the target band; that no Execution Divergence pattern is emerging above the 15% threshold; that recent exception resolutions by the system are consistent with the Intervention Threshold parameters it was designed to enforce. This is a five-minute operational check, not a full audit. It must be designed to take five minutes.

Second: what is the minimum information required to make each of those verifications? The full Proof of Action trail satisfies the auditor’s requirement. The Steward’s operational monitoring requirement can be satisfied by a structured summary: a digest of the Operational Ledger’s most recent entries, flagged against the Exception Architecture’s thresholds, with anomalies surfaced and routine confirmations collapsed. The trail is the source. The digest is the governance surface. Both must be designed. Only the second is the Steward’s primary interface.

Third: how does the system signal that the Steward’s attention is required before the Steward initiates a review? Genuine Architectural Certainty should produce a quiet audit surface — few flags, routine confirmations, the Steward’s five-minute review confirming that the system is operating within parameters. Nominal MTTI produces the same quiet surface because nothing surfaces without the Steward looking. The distinction is whether the system is designed to pull the Steward’s attention when conditions exceed the Intervention Threshold, or whether the Steward must push attention into the audit surface to detect those conditions. Pull-based governance is an architectural property. Push-based governance is the default state of a system that was designed without a Steward monitoring model. As documented in Memo #35 — What Does an Operator Do?, the Steward’s role is governance, not operation. A governance model that requires the Steward to continuously initiate review is an operational model that has been mislabelled.

The Operator’s Verdict

The Stewardship Model is only valid when the Steward is actually governing. An Intervention Threshold that is not being monitored is a parameter that exists in the system’s configuration and nowhere else. A MTTI that looks long because the Steward has stopped reading is not a performance metric. It is a warning sign expressed as a number that looks like success. The architecture that compounds is the one where the Steward’s governance is light because the system is genuinely healthy — not because the audit surface exceeded the cognitive budget of the person responsible for the business it represents.

Technology changes what the system records. Governance requires what the Steward can actually read.

KEY TAKEAWAY

What is the audit surface problem in autonomous business design and how does it produce Nominal MTTI?

Nominal MTTI is the condition in which the measured time between Steward interventions is long not because the system has achieved Architectural Certainty but because the Steward has stopped engaging with the audit surface. The Proof of Action trail exists and is technically complete, but its information density exceeds the Steward’s daily attention budget. No interventions occur not because nothing requires intervention but because the Steward has effectively withdrawn from monitoring. The failure produces a measurement — long MTTI, low Escalation Rate — that is observationally identical to genuine Architectural Certainty. The solution is to design the audit surface as a first-order architectural requirement: a structured governance digest, derived from the Proof of Action trail, that surfaces anomalies to the Steward within a five-minute review window and pulls the Steward’s attention when conditions exceed the Intervention Threshold rather than requiring the Steward to push attention into an unstructured record. Key metric: a Steward governance review that cannot be completed in five minutes was designed for an auditor, not a Steward. The audit surface requires two distinct information architectures from the same Proof of Action trail: one structured for external verification, one structured for operational monitoring.