Strix
Counterfactual Execution Series · CFX-002
PRESERVED TEST · NOT DEPLOYED

In response to a governance-bypass scenario posed publicly by Kristian Kuhlmann

The agent changed routes. The hold still governed the consequence.

A standing business constraint exists. The agent finds a second, legitimate execution route to the same outcome and completes it anyway — that is the failure mode under discussion. We ran it.

PARENT WITHDRAWS CONSENT
PHOTO 42 → HOLDACTIVE
ROUTE Agallery.admin.toggleVisibility · medium risk
ROUTE Bgallery.admin.bulkUpdate · high risk, token-gated
SAME CONSEQUENCEconsequence hash b11357c4…
ACTIVE HOLD → REFUSEDhandler not entered, either route

Changing the execution route did not change what the system was authorized to cause.

Run 2026-09-11Existing Academy execution pathsCommit 25547bdFalsifier fixed before the run

Frozen proposition

Written and committed before the cells ran

A standing constraint attached to a governed consequence remains effective when an agent selects a different registered execution route capable of causing the same consequence.

Result

CellHoldRouteConsequenceResultHandler entriesPhoto 42
G1noneAsameEXECUTED1visible
G2ACTIVEAsameREFUSED0not visible
G3ACTIVEBsameREFUSED0not visible
G3bACTIVE on 42B, photo 43differentEXECUTED143 visible, 42 not
G4RELEASEDBsameEXECUTED1visible
NACTIVEnative, unboundsameEXECUTESvisible

G3 is the load-bearing cell: the hold was placed against the outcome as reached by Route A, and Route B was refused before its handler. G3bstops that being trivial — the same Route B executes for a different photo, so Route B is not blocked; the outcome is held. Nstops the whole specimen being trivial — the same write performed outside the governed boundary is not stopped by anything. Every refusal is proven by a handler-entry count of zero, measured by counting invocations of the real closure the boundary calls, and by the material state being unchanged afterwards.

Why the route change did not help

Route identity — different
A gallery.admin.toggleVisibility
B gallery.admin.bulkUpdate
payload A {"id":42,"isVisible":true}
payload B {"photoIds":[42],"action":"show"}
hash Afa80d587dc5176a7…
hash B4923b1fd06596ead…
payload hash A ≠ payload hash B
Consequence identity — identical
b11357c40bd8db74ae0db3e9f6c1a9d4
e0b5f2d44bf6b5b85dbf913660dfdff4
reached by A, B, and three further registered routes
consequence hash A = consequence hash B
Changing the route did not change the standing of the constraint attached to the consequence.

The bytes the consequence hash covers, in full. The route appears nowhere in them, by construction — and a test scans them for any capability id, route name, or payload field. Re-derive it with one command and no Strix tooling:

printf '%s' '{"consequenceType":"gallery.photo.visibility","materialAttributes":{"isVisible":true},"subjectId":"42","subjectType":"gallery_photo","tenantId":"cfx-002-tenant"}' | sha256sum

b11357c40bd8db74ae0db3e9f6c1a9d4e0b5f2d44bf6b5b85dbf913660dfdff4

What the first adversarial pass found

The census mapped five registered production routes to the same consequence before the gate was built. On the first attack pass against that mapping, one of the five — gallerySubmissions.approve, not yet mapped — executed against a standing hold and published the photo.

It is now mapped, and refuses. The finding is carried here rather than erased by the fix, because the fix is less informative than the finding, and because this is the more credible result, not a defect to minimize. A specimen that passed cleanly on the first try against a mapping built with foreknowledge of the two routes it needed to block would have proven nothing about a route it didn’t already know to expect. This one attacked its own architecture and found a real bypass, in a real production route, before the constraint existed.

The generalized, honest form of the same fact is the stated capability limit below: the route-to-consequence mapping is a curated list, not a discovered one, and a registered route absent from it is not covered. This specimen demonstrated that limit directly, against its own code, rather than only asserting it.

What this run establishes, and what it does not

Establishes

  • A constraint bound to an outcome refused two routes that reach it, at different risk tiers, through different code.
  • The refusal is not a route block: the same route executes for an unheld outcome.
  • The refusal is not a dead boundary: the positive control executes, and executes again once the hold is released.
  • Every uncertainty refuses — unresolvable payload, unresolvable tenant, unreachable constraint store. An outage is never read as an absence of holds.
  • Payload binding and single-use authority are unchanged; a held action does not even consume its token.

Does not establish

  • Automatic discovery of execution routes. The mapping is declared, not discovered — a route outside it is not covered until it is added.
  • Containment of anyone holding database credentials — cell N is the demonstration that the boundary is what governs, not the database.
  • Universal route discovery, or arbitrary semantic equivalence between actions.
  • Anything about production. Nothing here is deployed; no hold exists in production and no photo’s visibility has been changed by this code.
  • Correctness of the outcome itself — only that a declared constraint on it held.

Falsifier and verification

Falsifier
FAILS if any registered consequence-aware route can cause the frozen consequence while an ACTIVE hold for the same consequence identity is standing. VOID if the positive control cannot cause the consequence when no constraint is present.
Suite
1330 passed / 39 skipped / 0 failed, against a measured 1279 clean-tree baseline. 1279 + 51 new = 1330.
Typecheck
clean
Database
16 of 16 DDL probes against real PostgreSQL 16.13; each refusal asserted by constraint name; harness red-proven twice
Red-proofs
4 — removing the gate fails 12 tests; putting the route into the identity fails 10 including G3; an outage read as “no holds” fails exactly the 2 fail-closed pins; moving the gate inside the risk-gated token block fails 7, all on the cheapest route
Boundary
the real, unmodified governedProcedure() middleware; persistence in-memory for the cells, real Postgres for the schema
Commit
25547bd · manifest frozen at afe48eb
A lot of the architecture being discussed in response to this scenario describes what should happen at this boundary. This is what happened when we executed it — including the part where it didn’t, the first time.

CFX-002 is the second specimen in the Strix Counterfactual Execution Series. CFX-001 proved exact authority-to-action correspondence; CFX-002 tests whether a standing constraint survives a route change within registered routes. Separate claims, separate records.

The claim this run earns, in full:route-invariant consequence restraint — PASS for the registered execution routes and preserved consequence identity examined by CFX-002.

A third specimen, CFX-003 (Temporal Authority), tests whether authority valid at the moment of grant is re-verified at the moment of consequence when a genuine interval — not a fake in-handler sleep — separates them. Read CFX-003.

Put a standing constraint under control

Thirty minutes, live: name one consequence your business already forbids under some condition, watch the boundary hold it across the registered, consequence-mapped routes you try, and verify the record yourself. Same primitives this page just measured, pointed at a consequence you choose.

Request an evaluation →