RFC-0002 revision: deterministic invalidation and bounded audit retention

[FNB2026]

Proposal

This prepares RFC-0002 for its required second public review without changing its status to Accepted.

• define one-target append-only InvalidationRecord transitions
• define deterministic direct/transitive traversal and a reproducible SHA-256 idempotency key
• define a data-minimized AuditTombstone as the maximum retained shape when a valid bounded basis exists
• explicitly prohibit direct identifiers, source/evidence/content fields, free-text reasons, and reversible subject keys in tombstones
• add positive, schema-negative, semantic-negative, and invalidation-chain fixtures
• update the public correction/audit documentation so append-only retention does not override valid deletion

Validation

• python tools/validate-public-artifacts.py
  • 12 schemas
  • full valid-instance coverage
  • positive and negative object/chain semantics
• python -m py_compile tools/validate-public-artifacts.py
• jq empty across schemas and fixtures
• git diff --check

Review questions

1. Is invalidating existing downstream identities on reject/replace/redact the correct portable default?
2. Is the canonical idempotency tuple sufficient for independent implementations?
3. Is the AuditTombstone shape still too identifying, or too weak for a justified audit purpose?
4. Should any retention basis be removed or narrowed before acceptance?

Governance

Per RFC-0000, this PR begins a minimum 7-day public comment period. Passing CI does not make RFC-0002 Accepted. A separate Steward decision is required after review.

Implementation feasibility was exercised separately in FNB2026/FNB#48; that product implementation is non-normative.

[FNB2026]

Hello @jdesrosiers, @coolharsh55, and @besteves4 — apologies for the unsolicited mention; there is no obligation to review.

We are seeking independent feedback on a small, implementation-neutral protocol revision for correction propagation and deletion-safe audit retention. The repository contains only public schemas, synthetic fixtures, and a reference validator.

• @jdesrosiers: your JSON Schema specification and implementation work would be especially helpful for the boundary between schema constraints and cross-object semantic validation, including the canonical idempotency tuple.
• @coolharsh55 / @besteves4: your work on data protection, consent/DPV, access control, and decentralised data would be especially helpful on whether AuditTombstone is genuinely data-minimized, whether its retention bases are too broad, and whether deletion/redaction semantics are stated safely.

A scoped review of only the relevant schema or RFC section is completely welcome; formal approval is not expected. Critical feedback, a pointer to a better standard, or a brief decline are all useful. We will not merge this RFC revision solely because the comment window elapsed.

Thank you for considering it.