A Receipt Is Not Current Permission

Ari entered at tick 2. The workshop then revokes the session. Ari still has a record of the earlier visit; that record does not authorize another one.

Item	What It Says	What It Does Not Say
Historical visit receipt	That visit was admitted.	Every future visit is allowed.
Session reference	Which session to check.	The session is currently valid.
Current admission result	This operation passed its owning checks.	An unrelated operation has the same permission.

A browser can display a receipt or a previously enabled button. The service that owns the work still decides whether a new request may proceed using current facts.

Engineering Depth

This model excerpt uses known-valid fixtures:

let earlier = shop.visit(&session).enter().unwrap();
shop.revoke(&session).unwrap();
let later = shop.visit(&session).enter();
assert_eq!(later, Err(EntryFailure::Revoked));

earlier remains a historical value. later is refused. The new visit does not inherit authority from the old result.

Compare two kinds of cloning:

Value	Why Cloning May or May Not Fit
A session reference	Repeated visits are allowed, but each visit rechecks validity.
A single-use execution permit	Cloning could allow a caller to repeat work that was meant to consume the permit.

The reference's session is cloneable because it is a model handle, not a perpetual entry capability. A serialized receipt likewise carries data under its contract; decoding JSON must not create fresh authority.

Your Reflection

An export lists an approval made yesterday. The approver lost membership today. Should the export erase yesterday's decision? Should a new operation accept it without current checks?

Worked Discussion

Keep the historical decision as a fact. Re-evaluate whatever current authority the new operation requires. Revocation can block subsequent work without rewriting history. The exact policy belongs to the owning product, not to a receipt's format.