RFC-0003 revision: portable provenance and source-state semantics

[FNB2026]

Proposal

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

• add implementation-neutral PermissionSnapshot and SourceStateChange schemas
• keep credentials, ACLs, sessions, identity graphs, storage topology, and product APIs outside the protocol
• map redaction, deletion, staleness, and withdrawn permission into RFC-0002 invalidation rather than creating a parallel cascade
• add positive, object-semantic negative, and source-state-to-invalidation conformance fixtures

Validation

• uv run --python 3.12 --with jsonschema==4.26.0 python tools/validate-public-artifacts.py
  • 14 schemas
  • full valid-instance coverage
  • negative object, chain, invalidation, and source-state fixtures
• python3 -m py_compile tools/validate-public-artifacts.py
• jq empty across changed schemas and fixtures
• git diff --check

Review questions

1. Is the PermissionSnapshot boundary portable without leaking authentication or ACL mechanics?
2. Are the source states and their constrained reason codes sufficient and mutually clear?
3. Is reusing RFC-0002 for all downstream execution the correct division of responsibilities?
4. Is stale → invalidated | review_required the appropriate portable flexibility?

Governance

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

The artifacts are implementation-neutral; private product behavior is non-normative.