---
title: "Never reuse prior eligibility after revocation."
description: "Use append-only revisions, expiry, supersession, and replay controls so a former valid state cannot become current authority."
updated: "30 August 2026"
availability: "LOCAL SIMULATION · TEST_ONLY"
candidate_route: "/docs/raiffa/guides/revoke-and-recheck"
---

# Never reuse prior eligibility after revocation.

Use append-only revisions, expiry, supersession, and replay controls so a former valid state cannot become current authority.

**LOCAL SIMULATION · TEST_ONLY:** Local validation surfaces and fixed fixtures only · no real login, organizational authority, operational API, external execution, or authority issuance

## Revocation appends a new revision

Do not delete an ACTIVE record or overwrite its status. Append a new event with revokedAt, reason, and prior-revision binding, then rebuild the projection.

- Preserved prior digest and event
- Monotonic revision
- Hash chain and append-only store
- Projection rebuild after restart

## Revalidate at the point of use

1. **Check expiry** — Confirm current time remains between issuedAt and expiresAt.
2. **Check revocation revision** — Find whether a newer REVOKED event supersedes ACTIVE.
3. **Check nonce and replay** — Prevent a request or gate reference from being consumed twice.
4. **Compare the binding again** — Actor, scope, policy, and DecisionCaseRef must still match the current request.

## Closed is correct when revalidation is unavailable

If the store, validator, or current revocation projection cannot be checked, never reuse a cached ELIGIBLE result as success.

> **FAIL CLOSED:** REVOKED, EXPIRED, replay, or ledger integrity failure must stop before external execution.

---

Published route: /docs/raiffa/guides/revoke-and-recheck