Define governed qualifying records for authorization evidence

[samovers]

Current Phase A approval and handoff — 2026-09-13

The user has approved Phase A decision version 2 for PR #34 at exact head c59fdbc75f26ee4694355adedd4df021f64b5131. Re-review 5191266887 covers that head, reports no blockers, resolves the previous dependency-alignment observation and requests no further patch. The head and all six candidate dependency pins were rechecked before recording the user's “i approve”.

Primary trust boundary: admission authority and lifecycle of authorization-evidence qualifying records. Scope stayed within the one-file source-governance design and approval/navigation records. The reviewed document bytes remain unchanged; their embedded proposed/pending status is historical publication state. PR #34 stays draft and unmerged, and this issue remains open for its separately gated later work.

The approved design distinguishes action definition/grants from selected-package admission, rejects a defined-but-excluded action before authorization evaluation, and retains the original package-admission proof for historical verification. Its PR #11 pin is 4494924998183fe3fa7bc1b63b76a85893335044; the other five source pins, lifecycle rules, transaction/digest semantics and proof/completeness limits remain unchanged. The original source anchors below remain opening history; use the approved candidate's section 3 and this approval record for the current Phase A input.

This is design approval only, not AI-granted approval or a formal GitHub APPROVE review. QG-DEP01, QG-BIND02–05, QG-DOWN06, CP2A-DEP01 and downstream G2/G3/G4 remain open. No acceptance criterion, owner candidate, action catalogue/release scope, source/grant authority, active law/schema/currentness, runtime, new issue/PR, merge or deployment is changed. In particular, no third action or executable writer is approved, and PR #11 section 24.1 still leaves open whether historical admission and complete observation can be established while new authoring is non-executable.

What is next: return to #32's historical-admission/complete-observation checkpoint using this approved Phase A source design. Separately authorize the next bounded owner step and any required QG-DEP01/binding work; do not assume a release expansion or jump to runtime implementation.

Original issue scope and opening anchors — retained

The text below is preserved verbatim as issue-opening history and scope. Its old review handoff and PR #11 pin are superseded only by the current navigation above; its acceptance criteria and owner boundaries are unchanged.

Parent: #10. Required by: #32, which must consume these source facts before it can finish its history classifier. This is an input prerequisite of CP2A-DEP01, not a replacement for #32 or closure of that dependency. Preserve the applicable #21 gates and the downstream OFARM2 #353 / PR #359 → #178 → bounded #176 implementation order.

This issue follows the source checkpoint on #32. Creating it records the missing source-governance prerequisite; it does not approve a writer, permission, relationship, lifecycle, schema or implementation.

Outcome and boundary

Define what makes a correction, dispute or supersession of authorization evidence a valid governed record, rather than an ordinary attachment, allegation or later failure report. Identify who or what may establish it, which exact source it qualifies and how its own later history is represented. The original authorization result remains unchanged.

Limit the first contract to the committed authorization-evidence sources needed by #32's fresh and historical refusal consumer, and the qualifying records' own supported histories. Other record families may be referenced as exact supporting basis where required; that does not add them as new authoring targets or authorize a general correction workflow for all farm, domain or finalization evidence.

Primary trust boundary: admission authority and lifecycle of authorization-evidence qualifying records. This is a canonical source-governance prerequisite, not a runtime issue, a second authorization evaluator or the read-side history classifier.

The intended first PR is one non-authoritative Phase A document in package_meta/history/clean_baseline_migration/phase_reports/, on a separate branch from canonical main. Proposed filename: authorization_evidence_qualifying_record_governance_rfc_candidate_v0_1.md. This is a future destination, not an existing contract. Reference exact source heads without editing or copying the approved #11/#20/#26/#29/#31 candidates or appending work to #17.

This issue may propose the missing source-record governance choices for review. It does not silently widen the existing action matrix, grant a new actor permission, add a review target or change an existing result contract. Any required change to those separately owned contracts must be identified precisely and handled in its own owner PR before the source mechanism is claimed usable. An unresolved dependency must not be presented as an already admitted authoring path.

Why the source checkpoint requires this work

PR #11 section 17.2 permits immutable authorization evidence with new linked corrections or failures, but does not close the qualifying records' admission, typed relationships or lifecycle. Its closed target sets and PR #17's review-target mapping do not make authorization evidence an eligible direct review target. The current ReviewDecision v0.1 schema does not provide that family either.

For example, a later EvidenceEvent naming refusal D and describing itself as a correction is not sufficient proof of authority to correct D. Another record naming that event does not, by itself, prove resolution, reopening or supersession. Generic references, record integrity and a new timestamp cannot settle those meanings. #32 cannot fill this gap by inventing the rules under which its own source records become authoritative.

The existing transaction candidates already require complete positive, negative and set-valued guards. They are real design inputs. The first problem is identifying the actual admissible records and writer/visibility semantics to which a history observation could be bound—not inventing another history service or declaring the transaction protocols inadequate in advance.

Exact source anchors

Rechecked on 2026-09-11: all six PRs remained open, draft and unmerged at the heads below; their base was canonical main 71ca724a8b6ec23f1655b086a6f549496d10a47f. An approved candidate is not active law. PR #17's approval status was not re-audited; it is used here only to check its exact scope.

Source	Exact head	Role preserved
PR #11	03a21f669ee04f96d444e14f00ae7212cab04803	Authorization law, closed targets, append-only evidence packages and staged delivery
PR #17	9ef08030b25eb3db1c2da14d6595300198384ff2	Separate final ReviewDecision result mapping and target scope
PR #20	98f8c4fafbae42c8f7fd931f43f53adcb4733713	Human-finalization transaction and commit guards
PR #26	e042efa2911b2ef0a61603b8e0adaa6911c03ac0	NOT_REQUIRED transaction, durable evidence and reconciliation
PR #29	8e0994cae5610ac9c0d2652e02c8a8a2dd7b45c5	Retention, byte access and proof-strength limits
PR #31	092be94f3a67497ba619295932cd0b2b1e9443f3	Approved public qualification and open CP2A-DEP01

Higher authority remains the canonical baseline, including Constitution AAI-C.1–1.1 and Platform AAI-P.6–6.1. Read the accepted source-truth, event-ingress, authority and CP2 rules with their current/default schema selections. Generic EvidenceEvent, ReviewDecision or materialization-freshness vocabulary is not authority to infer an authorization-specific lifecycle.

Acceptance criteria

1. One concrete source mechanism. Identify the exact qualifying-record kinds, their governing sources and their minimum carrier. Prefer a bounded tagged profile within PR RFC candidate: executable authorization evidence v0.2 #11's existing proposed evidence packages if it fits. Explain any necessary new carrier; do not invent a registry, universal history graph or durable status receipt merely to hold a label. Distinguish an ordinary allegation, attachment and later failure observation from an admitted qualifying act.
2. Verifiable admission authority. Define the governed basis, eligible actor or trusted runtime role, target scope and validation evidence for each supported qualifying act. Explain how that basis is verified at admission; an authenticated identity, free-text rationale, caller flag, public projector or classifier is not sufficient. Where an existing authoring path fits, name its exact rule and target binding. Where none fits, identify the exact missing authority/target decision and separate owner amendment; do not claim it already exists or silently add it to PR RFC candidate: executable authorization evidence v0.2 #11.
3. Exact immutable source binding. Define whether the target is an individual evidence profile or its containing bundle, and bind its kind, immutable identity/content, tenant and scope unambiguously. Bind any supporting basis to the exact history used by that authorization record, not a newly selected current record. Preserve the original request, outcome, evaluation time and bytes; a different request, tenant, source revision or later authorization decision cannot substitute for the target.
4. Closed relationship meanings. Define the supported correction, record-dispute, disputed-basis and supersession relationships as source-governance facts, including their admission preconditions and evidence. Distinguish questioning the original record from questioning its supporting basis and from merely recording a later event. Specify what each relationship does and does not establish. Do not map these facts to the six public CP2 labels here; that remains Define authorization-evidence source-history qualification and producer contract #32's classifier decision. Do not re-evaluate or rewrite the original authorization result.
5. Qualifying-record lifecycle. For supported operations, define corrections to corrections, dispute resolution/reopening and supersession chains, including competing successors and inconsistent or cyclic links. Identify what remains historically true and what changes in the later qualification. No timestamp-only winner, silent deletion or assumption that the newest record clears every prior qualification. Unsupported transitions must be explicit and cannot be made valid by the classifier.
6. Admission, ordering and visibility. Identify the existing authoritative commit/visibility mechanism and the point at which a proposed record becomes an admitted source fact. Explicitly decide whether the exact target must already be committed and observable, how duplicate/replayed records are recognized, and which trusted ordering facts distinguish concurrent or late-arriving records. Separate event/effective time from admission/record time; do not backdate observation knowledge. Name the applicable transaction-owner guarantees rather than choosing locks, isolation, a new commit or a fictional watermark here. An unmet required guarantee becomes a precise separate dependency, not an assumed input.
7. Failure and proof limits. Define source-side handling for unresolved authority, invalid relationships, missing or altered bytes, unknown versions, incomplete admission evidence and uncertain persistence. Integrity alone is not admission, an uncertain write is not a proven qualifying record, and failure to verify is not proof of clean history. Preserve PR RFC: authorization evidence retention and proof strength (Phase A) #29's retained-byte/digest-only and missing-byte limits. Do not create access, retention, deletion, redaction or key-custody powers.
8. Usable handoff to Define authorization-evidence source-history qualification and producer contract #32. Specify the exact facts and verification procedure by which the classifier can identify the eligible root and related admitted records, their relationship/lifecycle state and the authoritative visibility facts. Keep actual source evidence distinct from a producer's derived history status. Identify the real source bindings that Define authorization-evidence source-history qualification and producer contract #32 can use to define its observation/completeness proof; this issue does not assert that a complete cut already exists or that a fresh refusal implies NONE. Keep classification authority and permission to disclose separate from record-writing authority.
9. Falsifiable cases and traceability. Map every criterion to named invariants and case specifications. Distinguish invalid bytes, failed authority/admission, unsupported relationships, insufficient observation inputs and later runtime race/replay tests. Explain which cases this source owner closes and which are handed to Define authorization-evidence source-history qualification and producer contract #32 or a transaction owner. Phase A examples are specifications, not executed conformance evidence.
10. Exact later units and honest completion. Identify the future non-default record profiles/schema, authoring and rule bindings, examples, source-validation fixtures and conformance ownership. Require actual reviewed bytes/digests and explicit resolution of any authority/result/transaction dependency before claiming a usable source mechanism. Follow PR RFC candidate: executable authorization evidence v0.2 #11 section 24 and Promote executable authorization constraints and decision evidence RFC v0.2 #21's controlling stage order. Phase A approval does not materialize, admit, promote, extract or implement a contract, and completion of this source prerequisite alone does not close Define authorization-evidence source-history qualification and producer contract #32 or CP2A-DEP01.

Required cases

These are questions the future design must answer, not approved lifecycle semantics or test results.

Situation	Distinction the source contract must establish
Valid qualifying act for one exact committed authorization-evidence source	Admitted actor/act, target and immutable relationship are verifiable without rewriting the original
Ordinary attachment, allegation or later failure calls itself a correction	Naming or describing a correction does not grant its governing effect
Correct record bytes but wrong writer, rule, tenant, scope, target kind or revision	Integrity cannot substitute for admission authority or exact binding
Dispute about the record versus its original supporting basis	Exact relationship and historical basis are distinguishable without a new authorization evaluation
Correction of a correction, or resolution then reopening of a dispute	Supported transitions and their authority are explicit; prior history remains available under its governing proof limits
Supersession chain, competing successors, cycle or unsupported link type	No invented winner, implicit transition or fabricated clean-history conclusion
Later ALLOW/DENY, permission revocation or ordinary failure report	No automatic correction or supersession of an earlier authorization result
Qualifying record targets an uncommitted, missing or unresolved source	Explicit admission/visibility rule; no assumed already-committed target proof
Exact replay, repeated reference or same identity with changed content	Duplicate identity and conflicting content are distinguished without inventing a second qualifying act
Concurrent links, out-of-order delivery or late arrival with an earlier effective time	Trusted admission/ordering facts remain distinct from event time and later observation completeness
Missing retained bytes, digest-only proof or uncertain evidence commit	Proof limits and unresolved state remain explicit; neither qualifying effect nor absence is fabricated
Reader cannot see some or all qualifying history	Source governance does not override retention/access rules or #31's history-independent disclosure/fallback behavior

Scope fences and stop rules

Separate owner	What this prerequisite must not change
Original authorization and PR #11	Existing action algorithm/outcomes, grants, principal/actorship, action/target authority or retry eligibility; expose a necessary authoring-path amendment separately
Final ReviewDecision and PR #17	Existing target eligibility, domain result mapping or accepted-consequence composition; do not coerce authorization evidence into an eligible family
History classifier and #32	Six-label mapping, trusted history determination and reply-valid completeness policy
Public consumer and approved PR #31	Public fields/codes, AVAILABLE/UNAVAILABLE/WITHHELD rules, safe messages or hidden-history-independent fallback
Transactions and PR #20 / PR #26	Isolation, locks, atomic sets, idempotency, commit/reconciliation protocol or a new history service
Retention/custody and PR #29	Byte access, retention periods, deletion/redaction, storage security, keys or reconstruction claims
Acceptance, promotion and runtime owners	Active law/schema selection, extraction, deployment or OFARM2 implementation

If the proposed mechanism cannot work without crossing one of these boundaries, stop before editing it and present the exact missing owner guarantee or semantic delta. Do not open several speculative follow-ups in advance, and do not treat a broad “go” as approval of a cross-boundary exception. An approval for issue creation does not approve any proposed writer, permission, lifecycle or schema.

Delivery and definition of done

When separately authorized, the one-file Phase A candidate must choose and explain the smallest source mechanism, show its authority/relationship/lifecycle semantics and dependency deltas, and obtain exact-head review and semantic approval. Existing candidate bytes remain untouched. Any required owner amendment must keep its own PR boundary and traceable dependency.

Later source materialization, binding review, accepted governance, conformance and current/default promotion/extraction remain separately authorized stages in the existing order. The source handoff is complete only when its applicable governance and exact bindings are valid and every necessary owner dependency is resolved. A schema pass, an example record or approval of a draft does not establish a usable authoring path.

Then resume #32's classifier and observation design against those actual source semantics. Check whether the existing transaction guarantees suffice for the exact incoming-relationship set before proposing any further transaction issue. Keep CP2A-DEP01 open until the required governed producer and consumer bindings are complete. This does not close the other #21 or OFARM2 implementation gates.

Verification and limits

For the initial one-file Phase A candidate, verify exact source pins, the source/admission/relationship contract, criterion-to-invariant-to-case traceability, the unchanged owner boundaries, Markdown structure and whitespace. Existing package checks establish repository hygiene only; several exclude historical candidates. Their success is not semantic approval or proof of admission authority, persistence, concurrency, privacy or runtime readiness.

Later source-contract work requires actual reviewed bytes/digests, exact authoring and rule bindings, applicable conformance evidence and resolution of the identified owner dependencies. Keep accepted governance, current/default selection, extraction and implementation in their separately authorized stages. Do not claim an existing authoring path from unresolved assumptions or a permanently unavailable producer.

Issue creation does not change an existing candidate, active contract/law, authorization or transaction rule, public response, retention/custody control or runtime. It does not close #32, CP2A-DEP01, #21 or the broader OFARM2 implementation gates.

What is next: review this issue's scope, then take up the bounded one-file Phase A design when authorized. Require exact-head review and semantic approval before later contract or runtime work; keep #32's classifier and every other owner boundary separate.

[samovers]

Review — ready for the bounded Phase A design

No blocking issue-level findings. The issue is ready to guide the bounded, one-file Phase A design. It identifies a real missing prerequisite without giving the history classifier permission to invent evidence-writing authority. That is readiness to design and review—not approval of a writer, lifecycle, executable contract, or closure of CP2A-DEP01.

This is an issue-scope and source-contract review, not semantic approval or authorization to undertake later stages. I checked the issue against #32 and its source checkpoint, the relevant pinned candidates, the current ReviewDecision schema, and #21's delivery gates. The six candidate heads matched the issue's pins when checked for this review on 2026-09-11; they remained open, draft and unmerged.

What checks out

The missing source-governance contract is real.

PR #11 §17.2 at the pinned head establishes that authorization evidence is immutable and that corrections or later failures are new linked evidence records. It also identifies EvidenceEvent / evidence record as their event and commit classification. Neither classification establishes who may author a correction or what gives that link a governing effect.

The issue also correctly rejects borrowing generic review authority. PR #11's closed attachment/review target sets and PR #17's exact target mapping do not provide authorization evidence as a direct target; the current ReviewDecision v0.1 family enum does not supply that missing branch either. Consequently, adding a reference or calling something a correction cannot make it an authorized qualifying act.

The separation from #32 is coherent, including lifecycle ownership.

Issue #33 owns whether a qualifying act is admissible, what exact record it targets, and what its relationships and subsequent lifecycle mean. Issue #32 then determines the resulting history qualification at a defensible observation point. That is a useful separation: the classifier consumes governed facts rather than deciding retrospectively which writers and relationships deserve authority.

Requiring histories of the qualifying records themselves is appropriate here. A correction to a correction or a resolved dispute is a source-lifecycle question before it becomes a public-label question. The issue also keeps that work bounded to the initial authorization-evidence sources and explicitly supported transitions—not a general correction system for every farm record.

The transaction requirements avoid both an assumed guarantee and an unnecessary redesign.

PR #20 §10.3 already requires complete read/write guards, including negative and set-valued facts; locking only positive records is explicitly insufficient. PR #26 §6.1 distinguishes actual durable admission from staged objects, logs, caches, and ambiguous commit responses. Those are substantive inputs, not missing concepts that automatically justify another history service.

However, those general guarantees do not automatically prove that the eventual incoming-correction set is covered. The candidate still needs to identify the actual writer, admitted record set, visibility boundary, and applicable guards. Issue #33 correctly requires that concrete assessment before declaring either completeness or a new transaction dependency.

Proof limits and completion gates remain honest.

The issue preserves the distinction between an intact record, proven admission, and complete observed history. That matches PR #29's separation of historical evidence from present verification, especially §5, and PR #31 §5.4, which explicitly says that an intact digest, empty visible search, or fresh refusal commit cannot establish NONE.

It also preserves #21's requirement for actual materialized bytes and binding review before accepted-RFC promotion. A design approval or permanently unavailable producer cannot stand in for the missing source mechanism.

One non-blocking addition: historical admission versus current writer authority

I would make this an explicit hostile case in the candidate:

A qualifying record is inspected after its writer loses authority or its admission policy changes. Verify the original admission against its exact historical authority and rule bindings. Distinguish an ordinary later permission change, a new governed challenge to the original admission, and an inability to verify the retained admission proof. Do not silently erase, re-admit, or reinterpret the historical act using current policy. Leave the resulting public qualification to #32.

The failure mode is concrete: a future verifier could check today's permissions, conclude that yesterday's valid correction was unauthorized, discard it, and produce a false clean-history result. The reverse is equally problematic: a grant issued today must not retroactively legitimize an earlier unauthorized record.

The issue's existing admission, lifecycle, proof-limit, and exact-binding criteria broadly cover this, so this is not a blocker or a reason for another prerequisite issue. It is a useful explicit test of those requirements.

Main risk in the forthcoming candidate

The document must demonstrate one workable admission path, not merely describe what every possible path is forbidden to do.

Its first substantive checkpoint should trace one positive example from an exact committed refusal, through the proposed qualifying act and its independently verifiable authority, to authoritative admission and the facts handed to #32. Pair it with an otherwise identical record from an unauthorized writer.

At that checkpoint, keep these distinctions explicit: a proven invalid act is not an admitted qualification; an act whose admission cannot be established is not thereby proven invalid or absent; and a valid admitted act does not by itself prove that all applicable history has been observed. The issue already requires these distinctions—the candidate needs to make them operationally precise.

Disposition: proceed to the separately authorized one-file Phase A candidate. No issue rewrite is required. Any necessary authorization, target, result-contract, or transaction amendment should emerge from that concrete design as an exact dependency—not from speculative expansion in advance.

No runtime tests were run. This review changes no candidate, active law, schema, authorization, promotion, extraction or implementation gate.