Immutable Approval and Revocable Validity

Goal: preserve historical approval immutably while recomputing current validity from subject, policy, time, and status at decision time.

1. The real problem: historical approval is not current validity

Assume event APR-42 records that reviewer R7 approved exactly sha256:A under policy version PUB-3 for public web release at T0. That event is an immutable historical fact. Days later, the effective policy can change, the approval can be suspended or revoked, its validity window can expire, or the requested bytes can differ. The correct question is not “do we have approved=true?” but “is that historical approval still applicable to this exact subject, scope, policy, and decision time?”

2. Separate two layers: Approval Event and Current Validity

The Approval Event records who approved which exact subject, under which policy and scope, at what time, with what evidence. It is append-only. Current Validity is a derived state evaluated at decision time from status events, expiry, supersession, subject applicability, and the effective policy. Current validity is not a permanent field on the event; it is a time-bound computation.

3. Minimum Approval Event schema

Record at least approval_event_id, approved_subject_ref, subject_digest, reviewer_id, reviewer_role, policy_id, policy_version, approval_scope, approval_timestamp, and approval_evidence_ref, plus signature/evidence binding when present. If the exact subject or policy is not bound, downstream systems must not treat the record as general authorization.

4. Append status events; do not rewrite history

Revocation, suspension, supersession, or other status changes must not delete or edit APR-42. Append a new status_event_id with status_purpose, effective_at, reason, and provenance. This preserves both what was approved at T0 and what changed later. Rewriting the original event destroys forensic reconstruction.

5. Subject binding: approval applies to an exact subject

If the approval covers sha256:A but the release gate requests sha256:B, return SUBJECT_MISMATCH even if the filename, URL, content identifier, or approval ID is unchanged. Subject applicability is checked first because an approval for object A proves nothing about object B.

6. Policy binding and supersession

Bind approval to an explicit policy ID/version. If the effective policy is now PUB-4 but the approval only covers PUB-3, the system must evaluate compatibility or supersession explicitly. In this lesson’s fixture, a policy change without compatibility evidence produces POLICY_SUPERSEDED. The historical event remains; its present usability changes.

7. Keep scope and reviewer context independent

reviewer_role and approval_scope are part of the event meaning. An approval for “public web / image A / campaign X” must not silently expand to “paid ads / derivative B / campaign Y.” A request outside scope needs a typed restricted/re-approval state rather than a shortcut based on signature presence.

8. Validity windows: valid_from and valid_until

An approval can expire without being revoked. When decision_time is later than valid_until, the result is EXPIRED. Cryptographic integrity is intentionally separate: the event signature may still verify perfectly while the approval is no longer temporally valid.

9. Revocation and suspension are different

REVOKED means current reliance is disallowed in the fixture model. SUSPENDED means reliance is temporarily paused and can change with a later status event. Both are recorded separately from the historical approval event. The distinction is informed by credential-status standards, while the approval semantics here remain a MAKNOW design rule.

10. A fail-closed decision order

For a request: 1) bind the subject; 2) verify the effective policy relation; 3) check the validity window; 4) order status events effective at decision_time; 5) apply scope/reviewer constraints; 6) emit CURRENT_VALIDITY and validity_reason. If required evidence is UNKNOWN or stale, do not manufacture success. The release gate consumes the current derived state.

11. Why cached approved=true is dangerous

Caching approved=true without a status epoch or recheck trigger can miss a later revocation or policy change. Any downstream cache must at least bind approval ID, subject digest, policy version, effective status epoch, and decision time. The safer pattern in this lesson is to recompute validity at each release-gate decision.

12. Integration with the Release Gate

This lesson does not assemble the release manifest; it produces Approval Event & Current Validity Ledger v1. CON-005 can consume an approval_validity_ref from this ledger. Therefore the output is typed: VALID or a precise state such as SUBJECT_MISMATCH, POLICY_SUPERSEDED, SUSPENDED, REVOKED, or EXPIRED, with a reason and recheck trigger.

13. Audit trail and provenance

For every decision, retain the effective events, chronology, decision timestamp, subject digest, effective policy, and reason. An auditor must be able to explain, without hidden reasoning, why the state was VALID at T1 and REVOKED at T4. Append-only history preserves evidence; it does not make every historical approval permanently authoritative.

14. Transfer: change one dimension and recompute

Keep APR-42 unchanged. First change only the subject from sha256:A to sha256:B and derive SUBJECT_MISMATCH. Restore the subject, change the effective policy from PUB-3 to PUB-4, and derive POLICY_SUPERSEDED. Restore policy, append an effective revocation, and derive REVOKED. Never rewrite or delete APR-42.

15. Output checklist and non-claims

The final artifact contains the immutable event, status chronology, subject/policy/scope bindings, validity window, CURRENT_VALIDITY, validity_reason, and recheck_trigger. This lesson does not establish source authority, claim confidence, rights/embargo permission, or exact release asset composition. A signed or cryptographically valid approval alone does not prove current validity in the requested context.