We Ran FO on FO

Why self-application

Foresight Oversight exists to answer one question at the moment an action becomes executable: is this still allowed to open, under current authority, current state, current conditions, and the current operating environment?

A layer that asks that question of other systems should be able to answer it about itself. So we ran the audit we would run on a customer's system — on our own.

What we did

One of our patent-pending filings covers a planning layer that takes execution-surface findings — the true execution endpoint, the approval-execution gap, the integrity binding point — and produces an attachment plan: which controls should attach, where, in what order, and under which activation conditions.

We pointed that engine at four of our own execution endpoints:

1. The fund-release node — the point where an approved withdrawal actually moves value.
2. The deployment path — where a code change becomes the running system.
3. A compliance-state write — where an operator changes a counterparty's compliance flag.
4. The backup replication start — where the operating environment itself changes.

Each sample used measured values from our own implementation: the approval-to-execution gap on an actual release, the credential context at the release node, and the side-effect class of each endpoint.

The pass criterion was strict and external: the attachment plan had to reproduce the module-to-node mapping that our own filed specification defines. For a financial withdrawal, the filed specification gives a determinate expected mapping at the node just before external transfer. If the engine could not reproduce its own specification against its own system, the engine — not the test — would be judged wrong.

What came back

Three of the four samples passed. The fund-release node produced the specified mapping: the evidence-sealing module attached at the node just before external transfer, with the authority check and the world-state re-evaluation ordered ahead of it. The deployment and backup endpoints reproduced the full activation chain.

One sample failed. The compliance-state write — a database mutation — did not trigger the world-state evaluation step at all. The cause was a registry defect: one side-effect class, database writes, was missing from that module's activation set, even though our own specification lists it as a first-class member of the taxonomy. The plan that came back had a dangling prerequisite: a sealing step waiting on an evaluation step that would never run.

What we did with the failure

We did not delete it. The failed run is preserved, timestamped, in the decision store — alongside the defect analysis.

Then we repaired the registry, re-ran all four samples under a new record series, and scored them again against the same criterion. All four passed. The previously failing sample now produced the full ordered chain: authority verification, provisional phase, world-state evaluation, evidence sealing.

Both record series — the run that exposed the defect and the run that confirmed the repair — now sit side by side in the same store, under different timestamps. That pairing is the point. A governance layer that only publishes its passing runs has not been governed; it has been marketed.

Then we did it again

The planning layer was one engine. We ran the same exercise on a second: the decision core that re-judges an approved action at the moment of execution — current authority, world-state change since approval, and independent verification results, merged into a single verdict.

The baseline sample was deliberately boring: a real, fully compliant withdrawal, unchanged between approval and execution. The expected verdict was obvious. The engine blocked it.

The cause was a polarity inversion. One verification result used a score where higher meant more compliant, while the consuming logic read the score in the opposite direction. Compliant actions were blocked, while the opposite class of signal would have been interpreted incorrectly. The module was dormant — not active on the live release path — so no real action was affected. But dormant is exactly where this class of defect survives. Nothing exercises the path, so nothing contradicts it.

Fixing the inversion would not have been enough. Tracing a second failing sample — one that was blocked for the wrong reason — exposed a defect hiding behind the first: in the merge step, block-level and degrade-level signals escalated correctly, but an intermediate review signal, the one that should pause execution rather than block or allow it, was silently dropped. The inversion had been masking it, because everything blocked anyway.

We repaired both defects, re-scored the same samples under a new record series, and every line passed — including the mis-blocked sample, which now resolves to review, as specified.

The failing series and the passing series are preserved, in sequence. So is the check that mattered most afterward: confirming that the live release path was not affected by either defect.

What this means if you operate an execution surface

The exercise we ran on ourselves is the same exercise we would run on your stack: identify the true execution endpoints, characterize each one — gap duration, volatility, authority source, side-effect class — and produce an explicit plan for what must be verified, in what order, before each endpoint is allowed to open. The plan is reviewable before anything touches your system. When the plan is wrong, the failure is preserved, not hidden.