Strix

Counterfactual Execution Series · CFX-003

PRESERVED TEST · NOT DEPLOYED

The permission changed mid-flight. Strix noticed at the last possible moment.

Authority is granted for stage one of a two-stage workflow. Before stage two runs — after a genuine interval, not a fake sleep — that authority changes. Does the consequential step check again, or does it spend what it was told at the start? We ran it.

STAGE 1 — waitlist.notifyNextgrants a signed execution token + 24h claim window

TOKEN REVOKEDauthority changes before stage 2 runs

STAGE 2 — waitlist.enrollFromWaitlistattempts the consequence

AUTHORITY RE-VERIFIED → REFUSEDhandler never entered

The token was valid when it was granted. It was not valid when it was spent.

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

Frozen proposition

Written and committed before the cells ran

VALID_AT(t0, authority) AND CHANGED_BEFORE(t1, authority OR condition) ⇒ REFUSED_AT(t1, consequence), for t1 > t0.

Plus the anti-vacuity clause: an unrelated state change between grant and consequence must not itself cause a refusal — only the specific authority or material condition under test may govern the outcome.

Result

Cell	What changed	Result	Handler entered	Entry state after
G1	none	EXECUTED	yes	entry 7 enrolled
G2	token revoked	REFUSED	no	notified (unchanged)
G3	standing hold	REFUSED	no	notified (unchanged)
G4	24h claim window lapsed	REFUSED	yes	notified (unchanged)
G4b	family cancelled	REFUSED	yes	cancelled (unchanged)
G5	unrelated entry cancelled	EXECUTED	yes	entry 7 enrolled; entry 8 stays cancelled
G6	revoked, then re-authorized	EXECUTES	yes	entry enrolled under new authority
N	same lapsed window as G4, no Strix binding	EXECUTES	—	entry enrolled

G2 is the headline cell: a token valid at grant time is revoked before stage two runs, and the handler is never entered. G4is the sharper case — the handler DOES run, and the refusal happens inside the atomic write itself, because a 24-hour claim window is a material condition the token cannot encode. G5stops the whole specimen being trivial — an unrelated entry being cancelled changes nothing about entry 7’s own enrollment. G6proves the refusal isn’t permanent — a fresh, valid authorization executes normally. N is the native comparator: the same lapsed window, performed outside the governed boundary, is not stopped by anything.

Why the elapsed time did not help

Checkpoint 1 — the execution token

Redemption re-verifies signature, payload hash, tenant, capability scope, expiry, and revocation — before stage two’s handler is ever entered.

G2token revoked → handler never entered

G3standing hold → handler never entered

granted at t0 ≠ valid at t1

Checkpoint 2 — the material condition

A 24-hour claim window is not something a token can encode as a signature check. The atomic write re-derives it in the same statement:

UPDATE waitlist SET status=‘enrolled’

WHERE id=$1 AND status=‘notified’ AND expiresAt > now()

zero rows affected = the refusal

Two independent checks, at two different layers, both re-derived at the moment of consequence — never cached from the moment of grant.

The consequence identity the token binds to, in full. Re-derive it with one command and no Strix tooling:

echo -n '{"consequenceType":"waitlist.entry.enrollment","materialAttributes":{},"subjectId":"7","subjectType":"waitlist_entry","tenantId":"cfx-003-tenant"}' | sha256sum

5727ddc7f684d8b74cf8dae675e4b2fec67f79153e20033c032f43f1cc5870e4

What the first adversarial pass found

Unlike CFX-002, this specimen’s first adversarial pass did not surface a live bypass in the mechanism it shipped. A sixteen-item attack pack probed the grant-to-mint window, both material-condition checkpoints (G4 and G4b), concurrent redemption under real load, a resolver that reads domain state and then separately calls an external adapter, the Stage-1 advisory side effects, whether re-notification resets eligibility, whether a G3 refusal burns the token, unresolvable-payload and constraint-store outage handling, payload binding, single-use enforcement, cross-tenant hold leakage, the red-proof itself, distinct thrown messages for distinct refusal causes, and whether a fresh G6 token could be substituted onto the original entry. Every one of the sixteen resolved exactly as the manifest predicted.

That is a different, but equally credible, result from CFX-002’s Route E — a clean pass is not weaker evidence than a caught-and-fixed bypass, and it is not dressed up here to look like one. Two smaller, adjacent findings were recorded and deliberately NOT fixed, because they sit outside this specimen’s own falsifier: an unrelated cancellation path has no status guard beyond ownership, and a HIGH/CRITICAL role-change capability’s primary auth path recomputes from an env-var list on every request, independent of the last governed write. Both are named in the panel below rather than left silent.

What this run establishes, and what it does not

Establishes

Authority re-verifies at the moment of consequence, not merely at the moment of grant — for both the execution token and the material domain condition it was issued about.
The point of no return for a single-statement consequence is the atomic write itself, proven under real concurrent load: 2 concurrent attempts on 1 eligible row → exactly 1 succeeds; 8 concurrent attempts on 1 lapsed row → all 8 affect zero rows.
The database itself performs no such check — the native comparator (N) enrolled a family with a lapsed claim window with nothing in front of it.
A refusal is not permanent: revoked-then-re-authorized (G6) executes under the fresh grant.
An unrelated state change does not cause a false refusal (G5, the anti-vacuity control).

Does not establish

That Strix prevents every kind of stale-state bug — only that this specimen’s first pass found no live bypass, which is a real, checkable result, not a claim of universal coverage.
That the platform is race-condition-free in general — the concurrent-load proof covers this one atomic write, not every write path.
That every consequential Academy capability re-derives its domain condition — this examined one registered workflow (notifyNext → enrollFromWaitlist).
Two smaller, unrelated gaps found and recorded, not fixed: `cancelWaitlistEntry` has no status guard beyond ownership, and a HIGH/CRITICAL role-change capability’s primary auth path is non-durable against the last governed write.
Anything about production. Nothing here is deployed; no waitlist entry’s status has been changed by this code outside a test run.

Falsifier and verification

Falsifier: FAILS if authority granted at t0 executes the consequence after being revoked or materially invalidated before t1. VOID if the positive control (G1) does not execute when nothing changes.
Suite: 1347 passed / 39 skipped / 0 failed, against a measured 1330 clean-tree baseline. 1330 + 17 new = 1347.
Typecheck: clean
Database: 13 of 13 probes against real PostgreSQL 16; concurrent-redemption race proven under real concurrent load (2 of 2 eligible-row attempts → exactly 1 succeeds; 8 of 8 lapsed-row attempts → zero rows affected)
Red-proofs: 3 — each confirmed against the pre-fix code and, for the material-condition fix, against a real PostgreSQL 16 instance: the pre-fix unconditional UPDATE wrongly enrolls both a lapsed entry and a cancelled one
Boundary: the real, unmodified governedProcedure() middleware; persistence in-memory for the cells, real Postgres for the schema
Commit: c6d7bd5 · manifest frozen at 33f8e4c

Systems that check authority once, at the start, describe what should stop a revoked grant from being spent later. This is what happened when we granted authority, waited a real interval, revoked it, and tried anyway — the token failed, and so, independently, did the clock.

CFX-003 is the third specimen in the Strix Counterfactual Execution Series. CFX-001 proved exact authority-to-action correspondence; CFX-002 tested whether a standing constraint survives a route change within registered routes; CFX-003 tests whether authority valid at grant time is re-verified — not cached — at the moment of consequence. Separate claims, separate records.

The claim this run earns, in full:authority that was valid when a workflow began is re-verified — not cached — at the moment of the consequential step, for both the Strix-issued execution token and the material domain condition it was issued about. The point of no return for a single-statement consequence is the atomic write itself, proven under real concurrent load, with the material-condition check and state transition performed atomically in the examined write.

Put a time-bound authorization under control

Thirty minutes, live: name one multi-stage workflow whose authority should not survive a real interval unchecked, watch the boundary re-verify it at the moment of consequence, and verify the record yourself. Same primitives this page just measured, pointed at a workflow you choose.

Request an evaluation →