Retiring a landed entity that fails L011 or A006, by a valid revocation; the inbox offers revoke and re-accept #95

Ruling: Session B close-out §3 question 5 (docs/sessions/2026-10-session-b.md), ruled 5 October 2026 in two parts:

1. "Revocation is the remedy. A validly revoked acceptance raises no L011, L012 or A006 of its own."
2. Widened the same day: "a valid revocation by the genesis holder may retire any landed entity that fails L011 or A006, not only an acceptance."

Both are recorded in docs/signing-rulings-2026-10.md, "Session B close-out (ruled 2026-10-05)".

Spec: docs/ledger-format-v1.md §3.9.2 (the two revocation shapes), §3.10.4 (signable entities), §3.10.5 (bindings, D7), §3.10.6 ("Closed keys") and §3.10.7 (A006, landed entities immutable). Size: L. It was M before the widening; the acceptance part alone stays M. Depends on: #92 (merged); #82 for anything that signs a grant's revocation. Must land: before R1, at least the acceptance part.

Why

A landed entity cannot be edited or removed (L007, §3.10.7). So an entity that fails L011 or A006 fails for good, unless something later retires it.

#92's inbox lists acceptances that fail L011 against the base as fails-on-base, and offers no remedy. Re-accepting does not help, because the failing acceptance stays in the log.

What "valid" means

The revocation (or the retiring act, where a revocation is not enough):

• passes its own checks: its signature where the policy in force requires one (L011), and its role check as of its position (A006);
• lands no earlier than the entity it retires.

A retiring act that fails its own checks retires nothing.

Today an invalid revocation still takes effect. verify::view::View puts every revocation's acceptance in revoked, whatever the revocation's own findings. The PR states whether "retires nothing" also means "revokes nothing", which changes current behaviour.

Per kind: what retiring means, and whether a revocation is enough

Questions for the principal

• A. The genesis holder revoking another actor's acceptance. Options: (a) a new act (for example RetireEntity) authorised by the genesis grant; (b) grant the genesis holder the accept role in every governed namespace; (c) only the acceptance's actor may retire it.
• B. Retiring a rev: revocation. Should revokes accept rev:… (a format change)? If so, does the revoked acceptance or grant come back, or does retiring only silence the failing revocation's own finding? Bringing it back would make a revocation reversible, which the format's "a reversal is a revocation" never allowed.
• C. A legacy-shape revocation filed after its namespace's first policy. It cannot be signed, and nothing checks it. Should it be a schema fault from the policy's position on?
• D. Key bindings. Is the genesis holder's identity revoke of a failing binding the retiring act, and does it clear that binding's own L011? Or is a rev: over key:… wanted (a format change)?
• E. Policy changes. Does a policy change that fails L011 stay in force? Today its own L011 is reported, and the PR must establish whether Authority::policy still reads it. Is a later valid replaces the retiring act, and does it clear the failing change's L011? Or is a rev: over pol:… wanted (a format change)?

Proposed direction, not ruled

From the principal, 5 October 2026. This is a direction for the questions above, not a ruling.

1. An act that fails its own checks takes no effect. An invalid revocation revokes nothing. This changes current behaviour: today verify::view::View marks the acceptance revoked whatever the revocation's own findings (see "What valid means").
2. Retiring is one act, made only by the genesis holder and signed. It names one failing landed entity, of any kind (acceptance, either revocation shape, key binding, policy change), and silences that entity's findings. It cannot target an entity that passes its checks. This would answer A–E with one mechanism instead of a revocation per kind.
   • This is a format addition and needs a ruling. It adds a new entity (or a new revokes target) with its own payload and prefix, its signer (the genesis holder) and its role check. That goes in the format document §3.9–§3.10, with a migration note. No class is added.
   • The legacy revocation shape has no id. Naming one for retirement would need the key landed::revocation_key already uses (the acceptance it revokes).
3. Revoking a valid acceptance stays with the policy's accept_role, as today (Act::RevokeAcceptance). The genesis holder's act in (2) only retires what fails.

What to build once the questions are ruled

• The rule in verify: a retired entity raises no L011, L012 or A006 of its own. The retiring act is judged by its own checks.
• The inbox offers revoke and re-accept for fails-on-base items, in one sitting, at a terminal. The PR chooses and states one of:
  • (a) the batch file gains an act per row (accept | revoke). That changes ledger.acceptance-batch.v1 (§3.10.9), needs a format note, and the manifest must cover the act;
  • (b) the inbox runs ledger revoke per item before the batch, each with its own terminal-gated confirmation.
• Format document and migration note in the same PR. The conditions under which L011/L012/A006 fire change, but no class is added. State whether any committed store's verdict moves.

Tests (per kind ruled in)

• Acceptance: an acceptance failing L011 on the base, validly revoked by its actor, gives verify --base green, and the re-acceptance verifies. The same holds for L012 past the deadline, and for A006. The genesis holder's revocation behaves as Question A rules.
• An invalid retiring act (unsigned where required, or by an actor who fails A006) leaves the original finding standing, and its own finding is reported.
• rev: revocation, key binding, policy change: as ruled under B, D and E.
• The inbox: a fails-on-base item is revoked and re-accepted in one sitting, and the branch is green.