Permission History — Access Rights Need a Timeline Too

A Project being private today does not mean it was never shared. Without history, important context disappears.

Who granted access, to whom, when, through which mechanism, and for what purpose?

Grant — when and by whom was access created?

Scope — which entities, fields, or actions did it cover?

Change — how was permission expanded, narrowed, or extended?

Revoke — when was access withdrawn and from what point did it stop applying?

Auditability — can the access history be reconstructed later?

If a shared link first exposes only a Project Summary and later includes Evidence, those should not be treated as the same permission state.

Permission to view does not mean someone viewed. Permission to edit does not mean someone changed anything.

Permission history and activity history are related but distinct layers.

Revoking access should stop future use, while records that the permission once existed may still need to remain under the applicable policy.

Client reviews, recruiter access, or partner reviews often have natural end dates. Expiring permissions reduce forgotten access.

AI agents, integrations, and third-party crawlers with scoped access should also have grant time, scope, expiry, and revocation state.

A useful model: Permission Event Log → Subject → Resource → Scope → Effective Time → Expiry → Revocation → Access/Action References.

Do not only ask, “Who has access now?”

Ask: “Who had which access, during what period, under what scope, and can we reconstruct that history when needed?”

Grant → Scope → Change → Revoke → Auditability.