Revocations
Records
Inspect or publish revocation state for records while preserving the prior evidentiary and lifecycle history.
Purpose
One function. Explicit trust boundaries.
Revocation changes present validity without erasing the historical existence of the revoked object or relationship.
Every material state transition should remain attributable to an authenticated actor, an authority context, a timestamp and the evidence required to reconstruct what happened.
Operational flow
Records lifecycle.
01
Identify revocable object
02
Verify revoking authority
03
Capture reason & evidence
04
Set revocation state
05
Preserve prior history
Object model
Minimum verification context.
The exact schema can vary by object class and policy version, but the verification layer should be able to resolve these core dimensions.
- Revocation ID
- Object
- Revoking authority
- Effective time
- Reason class
- Evidence
- Replacement / successor
- History
Operational state
Designed for progressive activation.
InterfacePrepared
BackendIntegration required
Audit trailDesigned
Status modelDefined
Production status must always be sourced from the deployed service and published through System Status; this static package does not claim backend activation.
Related PAR domains