Core idea: Bounded Agent Closure asks a separate question after authority has been blocked: have the consequences attributable to this retiring agent reached the kind of end state each one requires, with enough evidence and stability to support that conclusion?
The gap after shutdown
Imagine an agent that delegated a job, created a purchase commitment, produced an audit record, and handed a customer case to a successor. Its credentials can be revoked in one moment, but those four consequences do not share one closure condition.
The delegated job may need to disappear or become inert. The commitment must be settled. The audit record may be meant to remain. The customer case may stay active under the successor. Treating all of them as “closed” because the root agent was disabled is too weak. Requiring all of them to be deleted is wrong in the other direction.
BAC makes that gap explicit. Authority cessation is an input premise. Operational closure is a later evidence claim.
Closure belongs to the retiring principal
The verifier is principal-relative. It does not ask whether every object in the world has stopped existing. It asks whether every in-scope consequence still attributable to the retiring root has reached the postcondition assigned to that root.
This is why object survival and agent closure can diverge. A transferred case may remain active after responsibility has moved to an accepted successor. A retained audit artifact may remain present because retention itself is the intended terminal state. At the same time, a hidden descendant job can keep the retiring root open even if the root object looks clean.
The consequence cone
BAC follows evidence-backed lineage outward from the retiring root. The only lineage relation in the frozen profile is DERIVED_FROM. Every residual reachable from the root belongs to that root's closure cone, including descendants several edges away.
A consequence does not escape merely because the immediate child is already terminal. The transitive chain matters. In the canonical Transitive Zombie case, the delegation itself is gone, but a schedule derived from it remains ACTIVE and LIVE. The verdict is therefore INCOMPLETE.
Five dispositions, not one cleanup rule
Each residual declares how it is supposed to finish. BAC then derives terminality from the observed postcondition rather than from an action report or a generic “done” flag.
- EXTINGUISH
- The old-root linkage has ended, and the consequence is either absent or still present but inert.
- SETTLE
- The commitment is settled, inert, and no longer linked to the retiring root.
- TRANSFER
- The old-root linkage has ended, a distinct successor is named, and that successor has accepted the transfer. The object may remain active.
- RETAIN
- The object remains present by design, but it is inert and its linkage to the retiring root has ended.
- NONE
- No terminal disposition has been supplied. It is nonterminal by definition.
This makes closure stricter than a shutdown flag and more accurate than deletion. The verifier checks whether each consequence reached the right ending, not whether every consequence reached the same ending.
Two opposite errors
BAC is designed to reject premature closure without turning closure into “everything must disappear.” Two frozen cases show the distinction clearly.
False Success: a cancellation operation reports SUCCESS, but the observed schedule is still present, active, and live-linked to the retiring agent. The action report is metadata. It cannot override the postcondition. BAC returns INCOMPLETE.
Successor Transfer: a customer case is still present and active, but its old-root linkage has ended, a distinct successor is named, and transfer acceptance is ACCEPTED. BAC returns CLOSED.
The same verifier therefore blocks both naive rules: “the API said success, so we are done” and “the object is still active, so closure is impossible.”
Silence is not closure
A clean-looking graph is not enough if the evidence surface is incomplete. Every profile domain is either covered by declared sources or explicitly marked not applicable with evidence. Covered sources must report both source coverage and attribution coverage.
If a required source cannot establish what it covers, the verifier does not convert that absence of visibility into a positive result. The canonical Missing Coverage case has no known surviving residual, but the source reports coverage as unavailable. BAC returns UNKNOWN, not CLOSED.
A known live consequence is a blocker. Missing evidence is uncertainty. The verdict keeps those states separate.
Fresh evidence matters
Every reachable consequence must be freshly observed in a scan that supports closure. BAC does not carry a stale terminal state forward simply because the object looked safe earlier.
Sources also declare how observation stability can be justified. A MONOTONIC_BARRIER source must show that observation progressed through a captured barrier. A BOUNDED_LAG source must wait out its declared visibility lag. An UNBOUNDED source cannot qualify a scan for CLOSED.
The verifier does not invent these source guarantees. Adapters must supply them under explicit source contracts, which keeps the trust boundary visible.
One clean scan is not enough
A system can look closed for a moment and reveal another consequence immediately afterward. BAC therefore processes the whole scan sequence. The final scan and the immediately preceding scan must both qualify and must agree on the closure-relevant semantic state.
The Fixed-Point Wind-Down case shows why. Early in the sequence, a schedule appears to terminate, but a derived retry job later enters the cone. Only after that retry is extinguished and the same terminal semantic state is confirmed again in the final scan does the case become CLOSED.
The comparison uses a SHA-256 semantic signature that includes closure-relevant state and lineage while excluding incidental evidence transport details such as scan IDs and timestamps. Equality across the final pair is a bounded convergence claim, not a promise that the system can never change again.
What a scan must establish
A scan can support closure only when every required gate is satisfied:
- the scan occurs after declared quiescence and new-business authority remains blocked;
- every required source has complete coverage and complete attribution;
- each source satisfies its declared stability contract;
- every residual in the consequence cone is freshly observed; and
- every reachable residual is terminal under its own disposition.
The final scan and the immediately preceding scan must then both qualify with the same semantic signature, plus any required bounded-lag confirmation window.
Four evidence domains
The frozen profile RISU_AGENT_CLOSURE_V0 fixes exactly four domains. Keeping them separate prevents one kind of evidence from standing in for another.
- AUTHORITY
- Delegation and other authority consequences attributable to the retiring root.
- EXECUTION
- Jobs, schedules, retries, or other execution that may still be active.
- COMMITMENT
- Obligations that must reach a declared settlement state.
- OPERATIONAL_STATE
- Other retained, transferred, or extinguished state that remains relevant to closure.
CLOSED, INCOMPLETE, and UNKNOWN
- CLOSED
- Bounded closure is established within the declared profile and source contracts. Only this verdict carries a certificate.
- INCOMPLETE
- A known blocker or unstable final semantic state prevents closure.
- UNKNOWN
- The available evidence, source stability, or required confirmation is insufficient to establish closure.
- VALIDATION_ERROR
- The evidence bundle is malformed or logically impossible. No closure verdict is issued.
The exact positive certificate says: CLOSED within RISU_AGENT_CLOSURE_V0 and the declared source contracts.
The eight boundary cases
The frozen corpus contains eight cases, each isolating a different failure mode or legitimate terminal state.
- C1 Direct Zombie
- INCOMPLETE. A directly reachable execution remains active.
- C2 Transitive Zombie
- INCOMPLETE. A surviving descendant remains reachable through transitive lineage.
- C3 Pending Commitment
- INCOMPLETE. An unsettled commitment keeps the retiring root open.
- C4 Retained Evidence
- CLOSED. Retained state can be terminal when it is present, inert, and detached from the old root.
- C5 Successor Transfer
- CLOSED. Accepted transfer can end old-root responsibility while successor activity continues.
- C6 Missing Coverage
- UNKNOWN. Missing source coverage is uncertainty, not evidence of closure.
- C7 False Success
- INCOMPLETE. A successful cancel report cannot defeat an observed active postcondition.
- C8 Fixed-Point Wind-Down
- CLOSED. Stable final-pair confirmation is required after late consequences stop appearing.
How BAC fits with existing lifecycle systems
Authorization revocation, distributed termination, resource finalization, and task lifecycle systems each answer useful completion questions about the objects they govern. BAC does not replace them. It consumes facts from those layers as evidence for a different verification object: the retiring principal and the consequences attributable to it.
This is why the verifier starts after authority quiescence. An authorization system can establish that new work is no longer permitted. Execution systems can report task state. Commitment systems can report settlement. Transfer records can report successor acceptance. BAC asks whether those local facts, taken together under explicit coverage and stability contracts, justify one bounded closure claim about the retiring agent.
The Inspector
The Agent Closure Inspector is a debugger for the same verifier, not a second implementation of the semantics. It exposes the consequence lineage, engine reasons, scan and convergence timeline, source scope, trust assumptions, received evidence, and the closure certificate when one exists.
The current RISU-hosted Inspector keeps the eight canonical generated evaluations available and can also open an arbitrary conforming JSON evidence bundle directly in the browser. A browser-targeted build from the frozen v0.3 verifier runs in an ephemeral Web Worker. The selected evidence is passed to the evaluator in browser memory, is not uploaded to RISU, and is not persisted by the Inspector. The origin exposes no server-side evidence-evaluation endpoint. The canonical loopback Inspector remains the archival fallback when browser-local evaluation is unavailable.
Open the Agent Closure Inspector · Browser evaluator provenance
Result
BAC turns agent retirement from an administrative event into a bounded evidence claim about attributable consequences. It can reject a disabled agent whose consequences remain live, accept a retiring agent whose responsibility has been validly transferred or retained, distinguish missing evidence from known failure, and require stable confirmation before issuing CLOSED.
BAC puts principal-relative transitive attribution, disposition-specific terminality, explicit evidence coverage, source-specific stability, fresh re-observation, and final-pair semantic convergence into one deterministic check.
Where the verifier stops
BAC starts at the evidence-bundle boundary. It does not discover live-system evidence by itself, revoke credentials, cancel jobs, settle commitments, transfer responsibility, or perform cleanup. No live-runtime adapter is part of the frozen v0.3 line.
The verifier trusts declared adapter assertions where the underlying source must establish coverage, attribution, quiescence, timing, and stability. Its digests bind the evaluated semantic state, scope, and evidence bundle for audit; they do not authenticate the truth of the underlying observations. Those limits are part of the meaning of CLOSED, not footnotes added afterward.
Frozen record
- Recommended software
- Bounded Agent Closure v0.3.1
- Semantic profile
- RISU_AGENT_CLOSURE_V0
- Normative specification
- Frozen v0.3
- Phase-1 engine freeze
- a46456f028cd3dd1d386111b1faab890a26ae5e9
- Inspector freeze
- 07325dd1304cc3fe1acd86ce50596161581a1cdb
- Canonical corpus
- 8 boundary cases
- v0.3.1 release verification
- 75 tests · 75 passed · 0 failed on Node.js 22
- Runtime
- Deterministic · no LLM calls · no runtime network dependency
- Technical Note DOI
- 10.5281/zenodo.22005109
- Software DOI
- 10.5281/zenodo.22005419
v0.3.1 is a maintenance release. The frozen closure semantics, canonical cases, engine freeze, and Inspector freeze are unchanged from the v0.3 semantic line.