Incident and revocation policy · v0.1
A revocation is never silent. An incident is never quiet.
When a credential is revoked, how supersession works, what happens on a key compromise or an engine defect, how disputes are recorded, and the bounty.
Version 0.1, 21 October 2026.
1. Revocation
- A credential is revoked when its proof is found unsound, its inputs are found misrepresented, its subject is found to be a test identity, or a court or regulator requires it.
- Every revocation is a public log leaf with a reason and a timestamp. A revocation is never silent.
- Revoked credentials stay on the registry marked revoked; the page and the status endpoint say so; subscribers are pushed within a minute (best effort).
2. Supersession
- A longer or corrected record supersedes the previous link in the chain; the old credential stays valid as history and its status reads superseded.
3. Incidents
- Classes: key compromise; engine soundness defect; data-source defect; registry or log integrity defect; availability.
- Response: within 24 hours a public note on /standard/incident-policy/ with scope, affected credentials, and action; log leaf; webhook push; a dated post-mortem within 14 days.
- Soundness defects: the affected era is marked; credentials under it are not revoked wholesale but flagged "era under review" until re-verified or revoked individually.
4. Disputes
- A subject or relying party may dispute a verdict or a revocation by email to [email protected]; the dispute and its resolution are recorded as log leaves. No appeal changes the rule; it may change a verdict if the rule was misapplied.
5. Bounty
- A standing public challenge pays for a demonstrated break; submissions are logged before they are read. Amount: set by the founder; until set, the programme page says so.