Does an old permission still work after the system changes?
An approval is issued, but not used. The system enters a new activation. Does that outstanding permission still authorize an action? This software-only test checks whether the gate rejects the stale permission while fresh authority still works.
The scenario
The test changes synthetic configuration bytes from policy-v1 to policy-v2 and activates a new generation. The bundled autonomy-code bytes stay the same. This is not a deployment of a changed executable.
Observed result
# unused permission from an earlier activation verdict DENIED reason AUTHORITY_CONTINUITY_BROKEN simulated pose unchanged operation count unchanged consumed-authority ledger unchanged attempt log rejection recorded # fresh permission for the current activation verdict ALLOWED simulated action succeeds
The stale permission causes no simulated action. The gate does write a rejection record, so this is not a claim that every part of the system state stayed unchanged.
The binding
Per-activation, not just per-version
The binding incorporates the supplied code, configuration and platform identity together with an activation counter. Re-activating the earlier v1 bundle does not revive the old permission. That is a deliberately strict policy: outstanding permissions must be re-issued after activation.
The positive control matters. A fresh permission for the new activation succeeds; the gate is not simply blocking every action.
Verification — break the check
One activation-binding guard was removed from a separate source copy. All seven Authority After Change tests then failed on assertions, with no import, collection or syntax errors. The imported module path was checked to ensure the tests exercised the mutated copy.
| Run | Observed result | Exit |
|---|---|---|
| Selected five-file suite | 148 passed · 47 subtests passed | 0 |
| Authority After Change | 7 passed | 0 |
| One binding guard removed | 7 assertion failures | 1 |
Fresh environment
The supplied source archive was re-run in a new virtual environment using Python 3.12.14 and pytest 9.1.1. All 602 baseline source files retained their pre-run SHA-256 hashes.
Bounded conclusion
Seven tests inspect a shared scenario around one removed check. They are not seven independent mutations. The 148 tests are a selected five-file suite, not the entire repository.
The repeat run was performed by the ChatGPT coding assistant on 3 November 2026. It was archive-based, not a fresh Git clone or an independent audit. Remote commit provenance and the original working-tree status were not verified.
What this does not prove
Synthetic, software-only. No physical robot or aircraft was operated or validated. Tests that touch a hardware interface use injected fake hardware.
Supplied identity, not attestation. The gate enforces the binding it is given. This does not prove that the supplied version identity cannot be forged. No hardware or remote attestation was tested.
Strict policy, bounded coverage. Per-activation invalidation is a policy choice. Production workflows need their own requirements for outstanding approvals and in-flight actions. Passing these cases does not establish safety against untested inputs.
Checksums are not authentication. The public summary below is unsigned. Hashes support byte comparison; they do not authenticate the author. Any separate signed capsule needs a trusted binding between its verification key and claimed signer. Neither proves a physical event occurred.
Reviewed public evidence
Download the review report, selected log excerpts, environment inventory and checksums. This is an evidence summary, not a runnable source release. Excerpts are labelled; they are not full raw transcripts.
The package excludes source archives, mutant copies, private tooling, attack corpora and keys. Its publication boundary is an explicit file allowlist; it is not a claim that the full private repository passed an exhaustive secret audit.
Download evidence summary · ZIP
ZIP SHA-256
77b1097c54204181dd7c4d526bfc22fdd4c093a88985436d2427834185734e97
For a separate runnable educational example, see the Authority Replay Lab. It is not the source of this assessment.
In this synthetic test, an unused permission from the previous activation was rejected after a configuration change and new activation. Simulated action state stayed unchanged; the rejection was logged. Fresh authority still worked. Removing one binding guard caused all seven AAC tests to fail on assertions. A fresh-venv rerun passed the selected 148-test suite, including 47 subtests.
Does authority survive your next change?
Check the stale permission. Check legitimate control. Check that the test catches a broken gate.
Request an assessment →