AUTHORITY OBSERVATORY
Player eligibility, governed
The same shape as a payer policy review: multiple sources of authority, a recommendation, an action, and a question someone asks later — “why was this allowed?” Admissibility is re-evaluated at the moment of execution, so an ineligible roster change is refused at the boundary, not assumed from the submission.
ADMISSIBILITY RE-EVALUATED AT EXECUTION
Player Eligibility
Why was this player allowed to play?
A tournament director’s approved run authorizes an Eligibility Office, which delegates bounded check authority to age, grade, and waiver verifiers plus a roster agent. Each check runs under governance; the eligible player is approved onto the roster. An ineligible player’s approval is denied at the boundary — admissibility is re-checked at the moment of execution, not assumed from the submission.
Watch for: Three checks and one roster approval execute. The ineligible approval is refused with a real SWARM_POLICY_DENIED verdict — the roster is never modified.
Replay proof — rewind & verify
The same run as an authority graph. Click a side effect to rewind its lineage to the human authority; hit Verify to re-derive every edge from the signed receipts. Delegation edges are drawn at a width proportional to their signed budget; blocked branches sit red, off to the side — governance working, not a failure.
Loading graph…
Real boundary, ephemeral key (never the production key), no database, feature dormant. Re-derive any executed action offline: npx @strixgov/verifier swarm swarm_academy_eligibility
See all three scenarios together in the Authority Observatory.