A pre-execution governance layer for AI-mediated actions, approvals, and workflows.
Foresight Oversight is a pre-execution governance architecture for AI-mediated actions. It does not ask only whether a decision was acceptable when it was made. It asks whether the specific action attempting to execute now remains eligible under current authority, current state, current conditions, and the current operating environment.
This note defines the architecture at the level intended for external reference: the problem it addresses, where it sits, what unit it judges, what it evaluates, what it outputs, and what it records. It is a reference architecture, not an implementation specification.
Most AI governance effort concentrates on models, policies, review processes, and audit. All of these are necessary. None of them sits at the point where risk actually materializes: the moment a decision or approval becomes an executable action — a withdrawal that releases, a deployment that goes live, an access grant that takes effect.
Between approval and execution there is always a gap. Sometimes seconds, sometimes days. In that gap, authority can lapse, state can shift, conditions can change, and the operating environment can degrade. Systems that treat the approval record as a durable permission execute anyway — correctly, by their own logic — and the cost is discovered after the fact, as incident response, dispute, or audit failure.
The architectural gap is not a missing policy or a missing review. It is a missing evaluation at a specific moment.
A decision is not an approval. An approval is not execution eligibility.
An approval captures a past decision context: who held authority, what the state was, which policy applied — at the moment of signing. Execution eligibility is a present-tense property of a specific action at the moment it attempts to run. The two can diverge, and everything in this architecture follows from taking that divergence seriously.
FO's unit is not the model, and not the decision. It is the execution event: a specific action, attempting to run at a specific moment, against a specific current world.
The exposure FO governs is executable exposure — the set of actions a system is currently in a position to make real. This unit has a governance consequence worth stating plainly: FO judges the execution event, not the person. The question is never whether an actor was trustworthy when they approved something. The question is whether this specific action still carries valid grounds to execute at the moment it opens.
FO sits at the execution boundary: the last point at which an action can be evaluated before it changes real system state.
AI / Workflow / Approval System
│
▼
Execution Surface
│
▼
FO Pre-Execution Governance Layer
│
▼
Executable Action
│
▼
Evidence Record
Typical boundaries where this layer attaches:
FO inserts at these boundaries as a thin layer in front of existing systems. It does not require replacing the approval system, the workflow engine, or the execution stack.
At the execution boundary, FO re-verifies four things — all in the present tense:
An action is eligible only when all four bindings hold at the moment of execution. A binding that held at approval time and lapsed afterward is a lapsed binding.
For each execution event, the layer produces one of three outcomes:
The intermediate outcome exists deliberately. Not every change since approval is disqualifying, and not every change is ignorable. A governance layer that can only allow or deny converts every mid-severity signal into either noise or an outage; the review outcome is where those signals are held instead of lost.
Every decision produces a record at the moment the decision is made — not reconstructed afterward. The record carries, at minimum:
The purpose is reconstructability: when a regulator or an internal review asks why an action did or did not open, the answer exists as a first-class artifact generated at the boundary, not as an inference assembled from surrounding logs. Evidence reconstructed after an incident inherits every ambiguity the incident created; evidence sealed at decision time does not.
The layer is designed to run inside a customer-controlled environment:
This matters most in the environments where the architecture matters most: regulated financial operators, public-sector systems, and infrastructure where an execution-governance layer that itself depends on external connectivity would be a new risk rather than a reduced one.
Reference architectures are defined as much by what they exclude:
Model evaluation, policy authorship, screening, and post-hoc audit are adjacent layers. Each can be present in the same stack; none of them performs the evaluation described in sections 5–7.
FO determines whether a specific action remains eligible to execute, now — and leaves behind the evidence of how that determination was made.
We apply this architecture to our own system first. The practice record of doing so — including the findings it surfaced and how those findings were preserved — is published separately as a Practice Note: We Ran FO on FO.