Pillar 4 - Governed Intervention

The Question

What do you do about it?

Coverage shows you the population. Timing tells you when something changes. Explainability tells you why a finding matters. Together, they tell you what happened. Governed Intervention determines whether anything changes because of it.

Each of the first three pillars is necessary. None, by itself, is governance. Governance happens when a finding produces action: a routed escalation, an investigated transaction, a corrected process, a closed risk.

A platform that surfaces findings without driving consequences is producing reports. A platform that produces consequences is producing oversight.

This pillar is the action argument.

The Loop

Governed Intervention is built on a closed control loop: Detect, Explain, Act, Monitor.

Detect. The platform identifies anomalies, exceptions, and risk patterns across the transaction population.

Explain. The finding includes the reasoning needed for a human or system to evaluate it.

Act. The finding is routed to the appropriate owner, exposed through workflows and interfaces, and tracked through investigation and resolution.

Monitor. The platform verifies that the response worked and feeds the result back into detection.

The loop is the operational architecture of governance. Each step requires the previous step and feeds the next. The loop is not a checklist or a workflow diagram; it is the structural property that makes the platform produce consequences instead of reports.

Detection Without Action Is Observation

A platform that detects risk and doesn’t drive action is not performing governance. It is performing observation.

Observation has value. Dashboards, periodic exception reports, and analyst notebooks all support investigation by humans who choose to investigate. The operating model is straightforward: a human reviews the information, decides what matters, and determines what to do next. The platform informs; the human governs.

This model works when execution moves at human speed and the volume of findings remains manageable. It breaks down when execution accelerates and reviewer queues become overwhelmed. Findings accumulate faster than they can be evaluated. Ownership becomes unclear. Backlogs grow. The organization has evidence of risk but no reliable mechanism for producing a response.

In Some Simple Economics of AGI (February 2026), economists Christian Catalini, Xiang Hui, and Jane Wu describe this failure mode in formal terms. Detection without action is what produces what they call the “counterfeit utility” of unverified AI output: outputs that satisfy automated metrics (the platform did its job, look at all the flagged transactions) but silently violate human intent (the flagged transactions weren’t actually addressed). The platform’s report shows the detection happened; the underlying risk continues to accumulate because no governed action followed. Detection without intervention is verification without consequence. 

Governance closes this gap. A finding is assigned to a specific owner. The owner has a defined window to investigate and disposition it. If no action is taken, the finding escalates. Actions are recorded. Outcomes are verified. The architecture produces the consequence rather than relying on someone to remember to check a dashboard.

Article 14: Override, Disregard, Reverse, Or Stop

The EU AI Act formalizes the governance requirement directly. Article 14 (human oversight) requires that high-risk AI systems be designed so that natural persons can effectively oversee them. The Article specifies four mandated capabilities:

• Override. Take a different decision than the AI recommends.
• Disregard. Choose not to act on an AI output.
• Reverse. Undo an action initiated by the AI.
• Stop. Halt operation of the AI system.

The list is revealing. The requirement is not visibility. It is intervention.

The Act does not say the overseer must be able to view reports. It says the overseer must be able to change outcomes. Oversight is defined by action, not observation.

The Article uses a phrase that matters: meaningful oversight. The overseer’s capability has to be real, not theoretical. A platform that nominally allows the overseer to override but routes the override through a fifteen-step approval workflow that nobody completes has not provided meaningful oversight. A platform that nominally allows the overseer to stop the AI but the stop function takes 24 hours to take effect has not provided meaningful oversight in a workflow where AI execution propagates in minutes.

Governed Intervention captures the same architectural principle. Oversight must produce consequences at the speed consequences need to be produced. Anything else is ceremonial governance.

The Accountability Chain

Governed Intervention requires four properties at the operational layer.

Routing by role and workflow. When a finding emerges, the platform knows who owns the response. The owner is identified by their role (controller for journal entry anomalies, AP manager for vendor payment exceptions, treasurer for cash position anomalies) and by the workflow the finding emerged from (the accounts payable cycle, the close cycle, the treasury cycle). Generic routing to a shared queue does not satisfy the requirement; the finding has to land with the specific person whose job is to address it.

Tracking from finding to closure. Each finding has a state: open, under investigation, action taken, verified resolved, closed. The state transitions are timestamped. The state history is part of the audit trail. The auditor reviewing the platform six months later can see not just what was flagged but what was done about it.

Escalation by SLA. If the owner doesn’t respond within the defined window, the finding escalates. The escalation goes to the next responsible role. The escalation is logged. Unaddressed risk does not sit forever in a queue; the architecture forces attention or surfaces the gap.

Post-action verification. After action is taken, the platform verifies the result. Did the underlying transaction get corrected? Did the control change actually prevent recurrence? Did the next cycle show the pattern resolved? Verification feeds back into detection: an unresolved issue surfaces again in the next pass. A resolved issue stays closed unless the pattern returns.

Together, these four properties make the platform’s output operationally consequential. Not informationally consequential, where the user is informed of risk. Operationally consequential, where the platform’s architecture drives the resolution.

What Failure Looks Like

Five adjacent categories fail the action pillar in different ways:

Alert-only systems. The platform detects anomalies and sends alerts (email, Slack, dashboard notification). The alert lists the finding; the response is whatever the recipient decides to do. No routing, no tracking, no closure. This is the dominant pattern in first-generation finance analytics. The platform’s responsibility ends at notification; the human’s responsibility starts there. The architecture relies on the human to do everything the platform should have helped with.

Dashboards with no workflow integration. The platform produces a dashboard of flagged transactions. The user logs in, reviews the dashboard, decides what to investigate. The platform doesn’t know what was reviewed, what was decided, or what was done. The dashboard is a snapshot; the response is invisible to the platform. From the platform’s perspective, all findings stay open forever.

Manual routing by email or messaging. The platform sends findings to a designated person who is expected to email or message the right colleague to address it. The routing happens outside the platform. The tracking happens outside the platform. The audit trail is reconstructed from email archives if anyone bothers to reconstruct it. The platform contributed detection; the organization had to build the entire response infrastructure.

Fire-and-forget detection. The platform identifies anomalies, logs them, moves on. There is no expectation that anything will be done about most of them. The deployment is justified as “completeness” or “audit support.” The actual operational impact is small because the findings don’t translate to action. This is the failure mode anomaly detection tools fell into in the late 2010s and that the AFO category was named to prevent.

First-line-only defense from the execution platform. ERP and automation vendors are increasingly adding strong error detection and AI agent monitoring features inside their execution platforms. This is good and necessary; execution platforms should detect their own anomalies as a first line of defense, and the work makes their products materially stronger. But strong first-line defense is not the same as independent verification. The action remains internal to the system that produced the anomaly, which means the system is acting as both line worker and validator. AFO is the independent verification layer that operates above and across these execution platforms; the first line and the independent line are complementary, not redundant. Pillar 5 develops this architectural point in full.

Each of these has a useful scope in specific contex