RFC: authorization evidence retention and proof strength (Phase A)

[samovers]

Outcome and status

Phase A design candidate for #14, under #10: define what approval-display and governed-read evidence can prove while original bytes are retained, digest-only, deleted, redacted or unavailable.

Phase A semantic approval is recorded for exact head 8e0994cae5610ac9c0d2652e02c8a8a2dd7b45c5, following the no-blocking review. The non-blocking schedule-evidence clarification is carried into later contract materialization. This draft does not close #14, accept law, promote a schema, authorize a merge, or unblock OFARM2 implementation.

Primary trust boundary and exact PR boundary

Authorization evidence retention and custody / proof strength. Scope stayed inside that boundary.

One new file only:
package_meta/history/clean_baseline_migration/phase_reports/authorization_evidence_retention_and_proof_strength_rfc_candidate_v0_1.md

Head: 8e0994cae5610ac9c0d2652e02c8a8a2dd7b45c5

Base: 71ca724a8b6ec23f1655b086a6f549496d10a47f

No active baseline, accepted RFC, companion policy, schema, index, existing candidate PR, storage/key operation, database authority or OFARM2 runtime change is included. No cross-boundary exception was used.

Proposed decisions

• One separately governed immutable retention-policy family; preserve the current agent-trace, redaction and sovereignty schemas.
• Mandatory exact retained display bytes and complete renderer/display-policy/media/locale/timezone bindings for fresh human approval; no digest-only fallback or synthetic approval for other modes.
• Preserve RETAINED_BYTES and DIGEST_ONLY in original read receipts. Current byte availability, integrity and verification time are separate evidence.
• Require explicit compatible retention clocks, minimum/maximum constraints, privacy treatment and governed encryption/custody profiles. No universal duration or provider is selected.
• Permit governed bulk-byte disposition only without rewriting immutable receipts, original digests, disclosure history, policy bindings or required retry/reconciliation/tombstone evidence.
• Propose one append-only disposition support profile inside the already proposed authorization evidence package, subject to exact carrier/classification review. No new authority, event family or operation ledger.

The document includes a current-contract inventory with exact schema hashes, ownership and dependency tables, issue-criterion traceability, 28 positive/hostile case specifications, future materialization gates and a version-1 steward approval card.

Exact planning dependencies

These remain draft/unmerged candidates, not active accepted law:

• PR RFC candidate: executable authorization evidence v0.2 #11: 03a21f669ee04f96d444e14f00ae7212cab04803 — exact display/read bindings, immutable receipts and staged delivery.
• PR RFC candidate: governed human-finalization transaction protocol #20: 98f8c4fafbae42c8f7fd931f43f53adcb4733713 — human-finalization lifecycle and retained operation evidence.
• PR Define the NOT_REQUIRED transaction and consumption protocol v0.1 #26: e042efa2911b2ef0a61603b8e0adaa6911c03ac0 — NOT_REQUIRED retry/reconciliation and no-unsafe-forgetting obligations.

Their heads were checked live. None is edited here. Policy/evidence materialization, accepted law, hostile conformance, current/default promotion, extraction and separately authorized runtime work remain necessary under PR #11 section 24 and #21.

Checks performed

• git diff --cached --check — passed before commit.
• package_meta/tools/validate_repo_hygiene.py — passed.
• package_meta/tools/check_generated_currentness.py — passed.
• package_meta/tools/check_repository_cross_references.py — passed.
• package_meta/tools/check_repository_steward_guardrails.py — passed.
• One-file scope, current-schema SHA-256 values, referenced active source paths, Markdown table column counts and 28 unique case IDs — checked.

The local Python interpreter was the existing review-tools environment in the OFARM2 issue-353 worktree; no environment or dependency was changed. The phase-report lane is excluded from several package/index checks, so these results establish repository hygiene, not semantic correctness. The 28 cases are design specifications, not executed runtime/storage/erasure tests. No expensive OFARM2 baseline or production-readiness claim is made.

Review focus

Please check that proof claims remain honest after byte/key loss; privacy and immutable-history obligations cannot silently override each other; digest-only payload handling cannot waive required trace evidence; deletion claims match actual custody/copy scope; and the proposed support profile can fit the existing evidence package without changing another owner's semantics.

Decision ID: OFARM-ISSUE14-AUTHORIZATION-EVIDENCE-RETENTION-PROOF-STRENGTH-001, version 1. Phase A semantic approval is recorded only for the exact reviewed head above. The candidate bytes remain unchanged; their original approval-pending wording is historical.

What is next: carry the explicit schedule-resolution evidence shape and positive append-only case into separately authorized contract materialization. Reconcile the remaining #21 and OFARM2 implementation prerequisites before selecting the next bounded change. Storage/key/runtime work remains separate.

[samovers]

Verdict

No blocking findings for Phase A at head 8e0994cae5610ac9c0d2652e02c8a8a2dd7b45c5. The draft is ready to be presented for exact-head steward semantic approval. That is not a recommendation to merge, promote contracts, or begin OFARM2 runtime implementation. The PR remains a one-file, non-authoritative design candidate.

This is a review conclusion, not a record of steward approval.

What holds up under review

The proof-strength distinction is sound (§§5, 8). The original receipt records the historical retention posture; later evidence describes what can actually be retrieved and verified. Deleting retained bytes does not retroactively turn the original receipt into DIGEST_ONLY. Conversely, matching independently supplied bytes against a digest does not prove OFARM retained the original disclosure. Permission denial, missing bytes, integrity failure, and redacted derivatives are kept distinct.

Fresh approval cannot bypass its evidence requirements (§7). Exact display bytes must exist before challenge persistence and remain available through the applicable approval and transaction obligations. Missing or changed bytes cannot be replaced by a digest-only approval or a newly rendered substitute. This is consistent with the pinned PR #11 lifecycle, rather than a new approval protocol. Direct-human and NOT_REQUIRED modes do not acquire synthetic challenges.

Privacy constraints do not become an evidence-retention escape hatch (§§8–9). The draft checks compatibility before capture, including transient processing, immutable metadata, and independent trace requirements. It explicitly rejects embedding prohibited bulk content in immutable receipts and later trying to redact those receipts. Its DIGEST_ONLY option does not waive the accepted reconstruction and forensic-trace obligations.

Deletion does not reset transaction history (§9.2). The no-unsafe-forgetting rules preserve retry/reconciliation inputs, consumption bindings, and necessary tombstones. This matches PR #26 §14.2's requirement that byte expiry must not make an operation tuple reusable, and PR #20 §17.3's separation between coordination cleanup and immutable operation evidence.

Custody evidence is not mistaken for authority or guaranteed erasure (§§10–11). Storage possession and policy authorship do not grant deletion authority. Completion claims require evidence for the declared copy and recovery scope; an API acknowledgement, missing object, or deleted key handle is insufficient. Recipient-controlled copies are not silently included in an erasure claim. The proposed support record remains evidentiary, not a new governance decision or operation ledger.

One non-blocking clarification: give resolved retention schedules an explicit carrier

Location: package_meta/history/clean_baseline_migration/phase_reports/authorization_evidence_retention_and_proof_strength_rfc_candidate_v0_1.md, §§9.1, 11.3, and 12.

Section 9.1 requires append-only evidence when a later authoritative terminal event resolves a retention schedule. However, §11.3 currently describes the support profile in terms of availability/integrity, redaction, and deletion; it does not explicitly assign the schedule-resolution evidence to a particular shape. Exact schema design is deferred, so this is not a blocking contradiction in the Phase A proposal, but it should not remain implicit during materialization.

The smallest clarification would identify where that evidence lives—preferably as a conditionally validated payload within the proposed support profile—and require it to bind the original policy/rule, authoritative terminal event and time, resolved cutoffs, and original evidence reference. Add a positive case proving that schedule resolution appends evidence without changing the original receipt; the existing unknown-terminal-event case covers the refusal side.

Classification: RFC materialization/conformance implication. No active-baseline change or additional top-level contract family is needed.

Validation and limits

All four reported GitHub check runs passed for the reviewed SHA, covering repository-validation and generated-currentness. I independently checked those results; I did not rerun the repository suite locally.

The 28 hostile/positive cases remain design specifications, not executed custody, storage, key-loss, or erasure tests. The draft states that limitation and preserves later schema, cross-binding, conformance, acceptance, and promotion gates.

Recommendation: proceed to exact-head Phase A steward approval, carrying the schedule-evidence clarification into materialization. No request-changes finding from this review.

[samovers]

Phase A semantic approval recorded

Recorded by the AI from the user's go in task 01a070c9-7ea9-7081-85ed-147d12568fa9, immediately after presenting the no-blocking review and requesting Phase A semantic approval of this exact head.

• Decision: OFARM-ISSUE14-AUTHORIZATION-EVIDENCE-RETENTION-PROOF-STRENGTH-001
• Version: 1
• Approved candidate head: 8e0994cae5610ac9c0d2652e02c8a8a2dd7b45c5
• Review: RFC: authorization evidence retention and proof strength (Phase A) #29 (review) — no blocking Phase A findings at that same head.
• Primary trust boundary: canonical authorization evidence retention and custody / proof strength. Scope stays inside it; no cross-boundary exception is granted.

Non-blocking clarification carried forward

During later contract materialization, explicitly assign retention-schedule resolution evidence to a conditionally validated payload in the proposed support profile, subject to the existing carrier/classification gate. It must bind the original policy and schedule rule, the authoritative terminal event and time, resolved cutoffs, and the original evidence reference. Add a positive case showing that resolution appends evidence without changing the original receipt. The unknown-terminal-event refusal case remains required.

This is an outstanding materialization/conformance requirement, not a claim that a schema or executed test already exists. It requires no new top-level family or active-baseline amendment.

Limits

This records Phase A semantic approval only. It does not authorize merge, issue closure, schema acceptance, current/default promotion, canonical extraction, storage/encryption/key operations, or OFARM2 runtime implementation. The PR remains draft and unmerged. Existing #21 and downstream G2/G3/implementation-approval gates remain in force.

The reviewed candidate bytes are unchanged so the approval stays bound to the exact reviewed commit. This comment records the later approval; approval-pending wording inside that historical candidate describes its pre-approval state.

What is next: carry the schedule-evidence requirement into the separately authorized contract stage, while reconciling the remaining #21 and OFARM2 implementation prerequisites before selecting the next bounded change.