Define the governed-read transaction, coverage and disclosure protocol

[samovers]

Parent: #10.

Required by: #21, required predecessor 5; #32 / PR #35, HSP-BIND03 for historical governed reads; and OFARM2 #353 / PR #359, G2/G3-READ/G3-HANDOFF.

Status: draft PR #37, head 41cd45b90fb8e133f6377d8f389858b89c3dd7ae, now has the task user's Phase A semantic approval for decision version 2, after the no-blocker exact-head re-review. This issue remains open; no actual binding, accepted law, schema, promotion or implementation gate is closed.

Current Phase A approval — 2026-09-14

The task user replied “i approve” to the explicit request for decision OFARM-ISSUE36-GOVERNED-READ-TRANSACTION-COVERAGE-DISCLOSURE-001, version 2, at 41cd45b90fb8e133f6377d8f389858b89c3dd7ae. The approval record names the exact scope and limits. Re-review 5196618462 resolves B1 at the protocol-design level and requests no further corrective patch.

The reviewed candidate and head are unchanged. Its embedded proposed/pending wording and the earlier records below are publication history; this external record supplies the later approval. Version 1 was not approved. Primary trust boundary: governed-read transaction integrity and protected disclosure. Scope stayed inside approval/publication navigation; no candidate, runtime, schema, database/source authority or adjacent-owner semantic change was made.

The actual source-backed guarantee remains unproven: RD-BIND03-W and RD-BIND01–07 remain open, as do HSP/QG/CP2A dependencies and OFARM2 G2/G3/G4. No writer is activated or proved deferrable. The complete two-action/full-rule scope, criteria/cases and eleven delivery stages remain unchanged. PR #37 stays open/draft/unmerged; this approval does not authorize later materialization, acceptance, promotion, extraction, implementation, merge or deployment. No new package, runtime, concurrency, durability, delivery or privacy test ran in this approval-recording turn.

What is next: prepare the bounded next-stage binding plan against the approved owner designs, including the actual source/transaction/egress mapping and RD-BIND03-W. Obtain separate authorization before materialization or implementation; preserve OFARM2 #353 / PR #359 → #178 → bounded #176.

B1 correction — 2026-09-14 (historical preparation)

Review 5194803845 found one blocker at the original head c2c52fa27bec24e72285564057cab198e4654e36: late hidden history could suppress an otherwise permitted sealed WITHHELD reply, revealing a difference through result omission. The user's next “go” authorized the bounded correction.

PR #37 now proposes version 2 of OFARM-ISSUE36-GOVERNED-READ-TRANSACTION-COVERAGE-DISCLOSURE-001 at 41cd45b90fb8e133f6377d8f389858b89c3dd7ae. The response to B1 requests exact-head re-review; it does not claim blocker closure or approval.

The revision selects the review's explicit-guarantee option: every permitted WITHHELD limited historical reply requires source-backed protection before its final observation and through C/L, ordering a competing qualifier's commit before that cut or after disclosure/irrevocable termination. Optimistic conflict suppression, delayed notifications, empty-history shortcuts and hidden-contention-only admission failures are not privacy proofs. Policy-selected exclusion stays uniform; disclosable history retains refresh/suppression. New I13/C20/C21 combine both C38 policy paths with late candidates, unresolved admission and actual commit-order checks.

The required RD-BIND03-W sealing sub-obligation remains open within RD-BIND03. No existing provider is certified. If supplying the guarantee needs new source/storage authority or an approved owner semantic change, that must be separately reviewed; PR #31/#35 and all other approved candidates remain unchanged.

The correction changes only the existing candidate file: 96 insertions, 35 deletions; total 525 lines, ten criteria, thirteen invariants and twenty-one symbolic cases. Four static repository checks, exact source pins, structure/traceability/whitespace, seven unaffected-section comparisons and exact remote text read-back passed. No runtime, concurrency, durability, delivery or privacy tests ran.

Primary trust boundary: governed-read transaction integrity and protected disclosure. Scope stayed inside this correction, publication and local navigation. The issue's criteria/case requirements, two-action/full-rule scope and all eleven stages are unchanged. All RD/HSP/QG/CP2A and G2/G3/G4 gates remain open; no merge, implementation, writer activation or proven writer deferral follows.

What is next: exact-head re-review of version 2, particularly the sealing guarantee and combined cases, then explicit semantic direction.

Original Phase A handoff — 2026-09-14 (historical)

The amended issue received re-review 5659896617, with no blocking findings in the issue framing. The user then authorized drafting with “no blockers, go.” That review and direction do not approve the newly written protocol.

PR #37 adds only package_meta/history/clean_baseline_migration/phase_reports/governed_read_transaction_coverage_and_disclosure_protocol_rfc_candidate_v0_1.md, from canonical main 71ca724a8b6ec23f1655b086a6f549496d10a47f. Its exact head is c2c52fa27bec24e72285564057cab198e4654e36; the published file was read back and matched the committed local text exactly. It is open, draft and unmerged.

Proposed decision: OFARM-ISSUE36-GOVERNED-READ-TRANSACTION-COVERAGE-DISCLOSURE-001, version 1, not approved. The proposal covers complete direct/query and direct/delegated/sharing coverage; a positive artifact-content example without independent raw-origin access; genuine pre-evaluation qualification; one governed observation; atomic prepared evidence before a guarded disclosure handoff; separately truthful outcome evidence; crash/uncertain-commit/no-protected-replay behavior; history refresh; privacy; and retention stops. Ten issue criteria map to twelve invariants and nineteen symbolic cases.

All seven source PRs and both main refs matched the recorded pins. Repository hygiene, generated-currentness, cross-reference and steward-guardrail checks passed, alongside structure/traceability/whitespace and one-file diff checks. These are static document checks, not independent protocol review or executed database, concurrency, delivery, privacy or runtime conformance.

Primary trust boundary: governed-read transaction integrity and protected disclosure. Scope stayed inside that one-file proposal, its publication and local navigation. Approved adjacent candidate bytes and the dirty primary OFARM2 checkout were preserved. The two-action/full-rule scope and all eleven stages remain unchanged. RD-BIND01–07, HSP/QG/CP2A obligations and G2/G3/G4 remain open; no qualifying writer is activated or proved deferrable.

The criteria and case requirements below are unchanged. What is next: exact-head review of PR #37, then explicit semantic approval or a bounded revision. Do not start materialization or runtime work from draft publication alone.

Review-driven clarification — 2026-09-13 (historical)

This bounded issue-body amendment follows review 5655860343 and second review 5656026666, both of the original 19,215-character issue body. It responds to the second review's reported Blocker 1, Follow-ups 2–5 and Preference 6, and preserves the first review's unresolved-candidate refresh clarification. Those reviews do not review this amended body.

The changes make direct/delegated/SharingGrant coverage, direct-versus-query inputs, pre-disclosure retention stops, read-versus-transport ordering, truthful persistence failures, current source-pin compatibility and safe preflight behavior explicit. The sharing-coverage clause requires a source-backed explanation and a positive path; it does not decide that an artifact grant creates new access rights to underlying records, or establish that sharing-based reads are impossible. A needed new permission rule must return to its separate authorization owner.

Primary trust boundary and selected scope are unchanged. All seven source pins, approved candidate bytes, owner fences and binding/implementation gates remain unchanged. This is an issue clarification, not protocol semantic approval, closure of the reported finding by its reviewer, or permission to start materialization/runtime work.

Outcome and primary trust boundary

Define the complete owner protocol for the selected RECEIVE_READ_DATA action: one protected read connects authorization, retrieval, redaction, qualification, result coverage and exact buffered bytes to durable evidence before disclosure.

Primary trust boundary: governed-read transaction integrity and protected disclosure. This is a canonical contract prerequisite, not an OFARM2 implementation issue or another history-classifier design.

The selected release remains exactly ASSERT_OPERATION_CLAIM and RECEIVE_READ_DATA, with both complete unchanged rules and every required transitive dependency. This issue covers the read owner's protocol for all selected read targets and authority paths, including a separately authorized AUTHORIZATION_TRACE read. It does not narrow reads to operation-claim records, add a third action, activate qualifying-record authoring or change the twenty-action catalogue.

Why this work is already required

Approved PR #11 section 18.5 requires one governed snapshot, full result coverage and atomic decision/consumption/receipt/payload evidence before the single disclosure linearization point. Section 24 and #21 require a separately governed read protocol. PR #26 section 7.1 excludes RECEIVE_READ_DATA from its NOT_REQUIRED state-effect protocol; the human-finalization protocol in PR #20 does not fill this gap either.

PR #35's approved history producer consumes the actual source/governed-read/transaction owners' observation and reply guarantees under HSP-BIND03. Its approval supplies neither those bindings nor the missing read protocol. The original refusal, qualifying-record lifecycle, six-label history fold and PR #31 public rules remain unchanged.

The pinned OFARM2 implementation provides useful tenant binding and write-order primitives, but not this read contract:

• The production UoW starts READ COMMITTED and supplies write-batch and command-selection facilities, not a complete governed-read attempt/observation/coverage/release interface.
• The knowledge-position allocator requires READ COMMITTED and serializes tenant write-batch positions. That alone does not prove membership or exhaustive visibility across every eligible historical source.
• Existing record reads are tenant-scoped and deliberately not limited to the current bundle, but are not already a v0.2 historical-admission/complete-observation provider.
• Production governed routes remain blocked. This is an unfinished capability, not a demonstrated defect in an enabled reader.

These findings do not choose a new isolation level, lock, transaction owner, reader permission, storage mechanism or history service. A different database mode or nominal snapshot label cannot stand in for a reviewed owner guarantee.

Exact source anchors

Rechecked at issue creation on 2026-09-13. Canonical main is 71ca724a8b6ec23f1655b086a6f549496d10a47f. All seven canonical PRs below remain open, draft and unmerged. Semantic approval does not make a candidate active law.

Owner	Exact head	Boundary retained
PR #11	4494924998183fe3fa7bc1b63b76a85893335044	Authorization rules, full selected scope, read obligations and eleven stages
PR #20	98f8c4fafbae42c8f7fd931f43f53adcb4733713	Human-finalization transaction; compatibility input only
PR #26	e042efa2911b2ef0a61603b8e0adaa6911c03ac0	NOT_REQUIRED state-effect transaction; not governed reads
PR #29	8e0994cae5610ac9c0d2652e02c8a8a2dd7b45c5	Retention, byte access and proof-strength postures
PR #31	092be94f3a67497ba619295932cd0b2b1e9443f3	CP2 public qualification, withholding and safe disclosure
PR #34	c59fdbc75f26ee4694355adedd4df021f64b5131	Qualifying-record admission/lifecycle and original historical proof
PR #35	b9ccdc96c5b3961eb672290cd32019364b56f8e6	History classification, complete observation and trusted producer I/O

PR #11's renewed scope has exact-head approval. PR #34 version 2 has exact-head approval. PR #35 version 1 has exact-head approval, following no-blocker review 5191762787. Preserve reviewed bytes and their historical publication labels.

OFARM2 main is 9d7541d96bc708e9270b986927d7f4b8a035454f. Its PR #359 remains open/draft at 7de8a2c4cf6eb1f293560af67e69565122c42f25, with G2/G3/G4 open. Read canonical baseline/accepted authority first; these candidate pins do not override it.

Intended first PR

One non-authoritative Phase A document on a separate branch from canonical main:

package_meta/history/clean_baseline_migration/phase_reports/governed_read_transaction_coverage_and_disclosure_protocol_rfc_candidate_v0_1.md

This is a proposed future path, not an existing contract. Do not append the work to PR #35, #26, #11 or OFARM2 #359. Reference their exact sources without copying or editing their approved candidates.

The candidate must choose the smallest coherent protocol and state its trust model, authority map, attempt/state ordering, stable invariants, production-reachable negative cases, compatibility/dependency ledger and later binding ownership. It is not a provisional permission to ship a reduced reader. Exact-head review and explicit semantic approval precede later materialization or implementation.

Acceptance criteria

1. Trusted read attempt. Define the owner-issued tenant/principal/session-bound attempt, transaction identity, trusted time/deadline, independently selected policy and required validity/guard inputs. Reject forged, mixed or caller-selected authoritative frames. Consume existing identity and selection authorities; no new authentication or selector power is granted.

2. One protected observation. Specify how authorization facts, immutable origin revisions, query/plan, redaction, CP2 qualification, relevant history, result coverage and payload construction share the governed snapshot. Define the currentness/guard obligations and their validity through the owner-defined release boundary. Identify exact source/external guarantees still owed; a SQL isolation name, cache, context-basis object or nominal watermark is not the proof.

3. Real qualification evidence before evaluation. Identify the rule-selected CP2 read-qualification policy and the source/producer/order by which its required evidence is available to authorization in the same context. Preserve #359 F4: the exact policy may derive required references from effectIntentDigest; do not create an extra carrier merely to populate a provisional frame. Derived references still require genuine eligible evidence. Do not confuse rule-bound pre-evaluation evidence with the public-result projection or invent a dependency cycle.

4. Complete result coverage. Bind every returned row, field, aggregate, count, metadata item, lineage item and payload location to its immutable origins and authority/redaction disposition, including tenant, purpose and sovereignty. Establish coverage under one independently sufficient selected access basis for the exact read target: a direct or delegated RECEIVE_USE AuthorityGrant/DelegationGrant path, or a sufficient SharingGrant, under PR RFC candidate: executable authorization evidence v0.2 #11 sections 5.4/13. Do not combine incomplete authority, purpose or evidence coverage across access bases or use the resource-control layer to supply missing authority. For a shared aggregate artifact revision, explain from the governing contracts which returned constituent/origin information the selected artifact-scoped basis covers, and which information must be withheld, redacted or denied. Origin provenance alone is not authority. Do not assume that permission to read an artifact creates independent access rights to every underlying record, or that all shared-artifact reads must therefore fail. If resolving coverage requires a new or widened permission rule, stop for a separately reviewed authorization-owner decision; this read protocol cannot create that rule. Bind the exact immutable RP_READ_TARGET_ONE target and applicable policy, serializer identifier/version/digest, media type and buffered-payload digest. Preserve both read forms: direct-read form requires neither QUERY_SPECIFICATION nor QUERY_PLAN; query form requires both, exactly one each, as integrity inputs, with their exact revisions and query/plan digest bound where applicable. Apply approved withholding/redaction or deny an incompletely coverable payload. Protected streaming is unsupported. Preflight/dry-run may return only non-protected planning or qualification information and must never disclose protected bytes.

5. Atomic evidence before release. Define the exact success set, state/order and owner of the single disclosure linearization point. Decision evidence, one single-use consumption, governed-read receipt, coverage manifest, payload digest and required retained payload ref/bytes must persist atomically before protected release. Provide an evidence-ownership table naming each profile's semantic owner, proposed package, truth claim, success-set placement and failure/retry posture. Prefer the already proposed AuthorizationDecisionEvidence/AuthorizationFinalizationEvidence v0.2 families; no new top-level evidence family is presumed.

6. Failure, uncertainty and retry. Define cancellation, deadline/guard invalidation, failure before/after persistence, commit acknowledgement loss, partial success evidence, crash/disconnect around disclosure, and retry/reconciliation. The read row selects NO_EXTERNAL_DISPATCH: “release” in this issue means the buffered-read disclosure boundary in PR RFC candidate: executable authorization evidence v0.2 #11 section 18.5, not section 18.6's filing transport-release gate under Define transport-release eligibility after filing outbox commitment #13. Distinguish committed evidence, eligibility for that read disclosure, attempted disclosure and provable delivery; a server receipt does not prove human/network receipt. No protected bytes on pre-disclosure failure, no duplicate consumption, no reuse of an old decision as new disclosure authority and no invented complete-success claim. Place READ_EVIDENCE_PERSISTENCE_FAILED and the applicable decision-bundle persistence/projection failures in their runtime/integrity-gate dispositions: they are not authorization outcomes, have no authorization reason rank, and must not fabricate or rewrite the authorization result as DENY. Adopt PR RFC candidate: governed human-finalization transaction protocol #20/Define the NOT_REQUIRED transaction and consumption protocol v0.1 #26 concepts only through explicit compatibility analysis; their write outcomes and retry rules are not automatically read semantics.

7. History and reply validity. Bind PR Define authorization-evidence source-history qualification (Phase A) #35's authoritative observation to historical RECORDED_RESULT reads in that same read context. Preserve complete candidate enumeration, original historical-admission verification, and established/proved-invalid/unresolved distinctions. Carry forward PR Define authorization-evidence source-history qualification (Phase A) #35 section 6's exact trigger: learning of a potentially material committed candidate after the observation cut but before reply finalization requires a new complete owner-governed observation and whole-read rebuild/revalidation, or the permitted unavailable/withheld path, even when that candidate's admission or classification is unresolved. Do not wait for a confirmed changed history label. Never splice refreshed history into an old governed-read payload. If payload/evidence is already finalized, the classifier cannot rewrite it or add an explanation commit; the owner must suppress/restart disclosure or use its permitted failure path. This creates neither a new retry permission nor a lock through network delivery. Separate the fresh-refusal command/reply path: this read protocol alone does not close that owner's HSP-BIND03 obligations or prove NONE at a fresh refusal's later reply.

8. Unchanged privacy and retention owners. Preserve PR Define CP2 authorization-result qualification and public reasons (Phase A) #31's WITHHELD precedence, null rules, safe messages, protected-detail limits and hidden-history-independent fallbacks, including C38. A missing/unadmitted producer is a readiness failure, distinct from an admitted producer's temporary inability to establish history. Apply the trusted immutable retention policy and preserve RETAINED_BYTES versus DIGEST_ONLY without caller weakening or overclaiming reconstruction. Before disclosure, the read cannot proceed if no applicable policy resolves at its governed snapshot, if a DIGEST_ONLY policy forbids the transient buffer processing needed to hash and execute the read, or if compatible minimization cannot preserve required immutable receipt/coverage/decision/trace evidence without prohibited retention. Release zero protected bytes; record truthful failure under criterion 6 and report any policy conflict to Define authorization evidence retention and proof-strength postures #14/PR RFC: authorization evidence retention and proof strength (Phase A) #29, without inventing a weaker posture or unobservable payload. A receipt, digest or history proof never grants trace access. Retention duration, encryption, deletion/redaction and custody policy remain owned by Define authorization evidence retention and proof-strength postures #14/PR RFC: authorization evidence retention and proof strength (Phase A) #29.

9. Falsifiable positive and hostile cases. Map each criterion to named invariants and case specifications, including the cases below. Show a satisfiable positive protocol for all selected read targets/paths, not a permanently unavailable service. Distinguish Phase A reasoning, schema/semantic fixtures and later production-path, concurrency/privacy and durability tests. No fixture is reported as executed evidence merely because it appears in the document.

10. Real bindings and staged completion. Name later non-default protocol/evidence profiles, source/attempt/observation bindings, producer-consumer interfaces, fixtures, conformance manifest/checker and accountable owners. Bind real reviewed bytes/digests at the authorized stage; no placeholder provider or self-asserted proof closes a dependency. The compatibility/dependency ledger must explicitly distinguish PR RFC candidate: executable authorization evidence v0.2 #11 section 24.1's historical description of PR RFC candidate: authorization-evidence qualifying-record governance #34 at 69682c2f918ef18756261a1186294cc3a5ebe44d as unapproved from this issue's current PR RFC candidate: authorization-evidence qualifying-record governance #34 input at c59fdbc75f26ee4694355adedd4df021f64b5131, with version-2 approval in comment 5654388700. Identify which head each consumed statement rests on, assess the dependency update, and preserve PR RFC candidate: executable authorization evidence v0.2 #11's approved bytes; do not inherit its old approval-state wording as the status of the newer input or mistake that input's approval for source-binding closure. Record every missing source/storage/access/transaction guarantee and split any separate owner change before editing it. Follow all eleven stages of PR RFC candidate: executable authorization evidence v0.2 #11 section 24 and Promote executable authorization constraints and decision evidence RFC v0.2 #21; semantic approval alone closes no materialization, admission, currentness, extraction or runtime gate.

Required cases

These are design and later conformance obligations, not approved protocol choices or executed tests.

Case	Required distinction
Eligible direct read, including separately authorized AUTHORIZATION_TRACE, without query specification/plan	The exact immutable read target, full same-context coverage and buffered evidence support lawful disclosure; query inputs are not required, and the trace target has its own decision and disclosure checks
Eligible query-form read over the exact RP_READ_TARGET_ONE target	Exactly one QUERY_SPECIFICATION and one QUERY_PLAN are bound as integrity inputs, not extra authority targets; every returned item and contributing origin has the required coverage
SharingGrant read of an exact shared aggregate artifact revision, such as EVIDENCE_BUNDLE, DOSSIER_ASSEMBLY or PASSPORT_VIEW	Show a satisfiable positive payload under an independently sufficient SharingGrant and the cited owner coverage rules for returned constituent information. Uncovered information is withheld/redacted or denied; no cross-basis union, ungranted independent origin-record access or silent blanket refusal of this basis
Delegated RECEIVE_USE path versus direct path for the same read target, including attempted combination of incomplete paths or a SharingGrant	Each sufficient path works independently in one final policy decision and trace under PR #11 section 13. An insufficient path cannot borrow action, purpose or evidence coverage from another path or the resource-control layer
Historical refusal with complete empty history	NONE requires an actual complete, reply-valid observation
Older valid qualifier while today's package excludes new qualifying writes	Verify original admission without granting current writing; complete historical source coverage is still required
Mixed snapshots, missing page/partition, hidden qualifying row, stale index or unresolved candidate identity	No fabricated complete observation or clean-history status
Newly learned potentially material committed candidate after the cut and before reply finalization, including unresolved historical admission or classification	New complete observation and whole-read rebuild/revalidation, or permitted unavailable/withheld handling; do not wait for a confirmed label change, splice history into an old payload, or rewrite already-finalized evidence
Authority or relevant guard invalidates before release, or a cutoff is reached	No stale release; define truthful attempt/evidence consequences
Uncovered aggregate, count, field, metadata or lineage item	No leak through payload, cache, denial body, preflight, trace or retry
Forged/mixed attempt, caller-selected policy, fabricated proof or missing real qualification input	No successful authoritative frame, evidence or release claim
Read-evidence persistence failure, uncertain commit or partial success set	Zero protected bytes on pre-disclosure failure; READ_EVIDENCE_PERSISTENCE_FAILED is a runtime failure, not an authorization outcome or ranked reason. Preserve the authorization result and explicit uncertainty/reconciliation; no guessed success, delivery or replay
Crash or disconnect immediately before/after the release boundary, followed by retry	No duplicate consumption or inferred delivery; later disclosure needs its governed authorization
No resolvable retention policy, or DIGEST_ONLY whose necessary transient processing or required immutable receipt/coverage/decision/trace retention is forbidden	The read is ineligible before disclosure; zero protected bytes. Record truthful failure and report a policy conflict to #14/PR #29 without weakening the posture
RETAINED_BYTES versus DIGEST_ONLY; required evidence later unavailable	Selected retention/proof limits remain truthful, without access or reconstruction being invented
Paired hidden-history inputs under PR #31 C38	Public fallback/disclosure behavior preserves the approved privacy rule

Scope fences and owner stops

This protocol may define the read transaction's own semantics for review. It may not quietly amend another owner's authority to make those semantics executable.

• Authorization/evaluator owner: no change to selected rules, outcomes, targets, evidence eligibility or authority paths; no second evaluator.
• Source and history owners: no new qualifier kind, writer admission, lifecycle transition, classification rule or persistent status truth. QG-DEP01 and historical writer-deferral proof remain open.
• Public owner: no new public reason codes, envelope fields, endpoint activation, weaker withholding or trace disclosure.
• Existing transaction owners: no change to PR RFC candidate: governed human-finalization transaction protocol #20 human-finalization or PR Define the NOT_REQUIRED transaction and consumption protocol v0.1 #26 state-effect atomicity, idempotency or reconciliation.
• Storage, identity, selection and custody owners: no database roles/migrations, isolation/locking implementation, source-access grants, hidden truth store, new signing authority, authentication/session policy, audit changes or key/deletion controls.
• Governance/runtime owners: no accepted-law edit, schema materialization, current/default promotion, extraction, deployment, runtime factory or merge.

If a workable read protocol needs a new guarantee from one of those owners, name the exact gap and propose a separate prerequisite or stacked/follow-up PR before changing that boundary. Do not create speculative services or treat a broad “go” as a cross-boundary exception.

Delivery and honest completion

1. Review this issue's bounded scope, then prepare the one-file Phase A when authorized.
2. Obtain exact-head review and explicit semantic approval of the read protocol; do not modify approved adjacent candidates merely to record progress.
3. Complete required adjacent owner contracts and the separately authorized policy-bundle, source-bundle and bounded decision/finalization-evidence drafts with real bindings, in PR RFC candidate: executable authorization evidence v0.2 #11's order.
4. Complete exact binding/selected-closure review and scoped accepted law, hostile conformance, explicit scoped promotion and byte-identical OFARM2 extraction.
5. Undertake separately authorized runtime work. Actual live-provider, concurrency and disclosure evidence belongs at that stage; do not make runtime execution a prerequisite to its own canonical acceptance or claim static fixtures prove production behavior.

This issue records the missing read owner; it does not create a binding or close CP2A-DEP01. Completion requires the applicable governed contract, exact source/observation/producer/consumer bindings and evidence at the appropriate stage. HSP-BIND01–04, applicable QG dependencies, #21 and OFARM2 G2/G3/G4 remain open until their own obligations are met. New qualifying-record authoring is neither activated nor proved deferrable.

The implementation destination remains OFARM2 #353 / PR #359, then #178, then the bounded #176 child. Indispensable read/write input producers must precede their consumers; this capability order cannot justify fake frames or an unresolved dependency cycle.

Verification and limits

At issue creation, checked canonical open/closed issue inventory for a duplicate and refreshed the exact owner heads and OFARM2 #359. The existing local binding investigation used immutable OFARM2 main objects and preserved its dirty primary checkout. No canonical/runtime file, approved candidate, branch/worktree, schema, permission, merge, promotion or deployment is changed by this issue.

The future Phase A must check exact source pins, compatibility/ownership, criterion-to-invariant-to-case traceability, Markdown structure and whitespace. Cheap package checks show document/repository hygiene only; they do not prove snapshot completeness, atomic durability, privacy or production readiness. No package, database, concurrency or hosted runtime test was run to create this issue.

Scope stayed within recording the governed-read transaction integrity and protected disclosure prerequisite.

What is next: re-review PR #37 at 41cd45b90fb8e133f6377d8f389858b89c3dd7ae, proposed decision version 2, then record explicit Phase A semantic direction. Keep approved PR #35 and the other owner candidates unchanged, with all actual binding and implementation gates open.

[samovers]

Review: no blocking findings

Reviewed the current issue body (updated_at: 2026-09-13T19:53:12Z) and comments, with the pinned owner contracts and the preceding source review. The issue is unchanged since creation. The no-blocker verdict stands: it is ready to guide the separately authorized, one-file Phase A proposal. This is clearance of the issue's framing, not approval of the unwritten protocol or closure of its dependencies.

What holds up

The missing contract is real. PR #11 §18.5 at 4494924 already requires same-snapshot authorization, retrieval, redaction, qualification, coverage and payload construction, followed by atomic evidence persistence before disclosure. Its §24 and #21 predecessor 5 require the separately owned read protocol. This issue assigns that existing obligation rather than introducing another history service or borrowing a write-only protocol.

The selected scope remains complete. The issue retains both unchanged selected actions, every selected read target and authority path, and separately authorized AUTHORIZATION_TRACE retrieval. Positive-path obligations prevent a permanently unavailable reader from being presented as completed scope.

The evidence-ordering requirement preserves #359 F4. Criterion 3 distinguishes rule-bound evidence needed before authorization from the eventual public-result projection. The actual selected policy must decide whether references are derived from effectIntentDigest or supplied by a real owner. Neither a new carrier nor derived references can substitute for genuine eligible evidence. This preserves the #359 revision-9 F4 dependency rather than prescribing an unnecessary provisional interface.

History, privacy and retention ownership remain separate. The issue preserves complete historical observation, original admission verification, whole-read refresh, withholding precedence, hidden-history-independent fallbacks, and retained-bytes versus digest-only proof limits. Historical governed reads do not silently close the fresh-refusal owner's reply obligations.

The runtime characterization is appropriately bounded. At the pinned OFARM2 revision, the inspected UoW and allocator provide READ COMMITTED tenant/write-order primitives; tenant-scoped record reads do not themselves establish complete historical observation. The production governed routes are blocked. This is unfinished capability, not evidence of a leak from an enabled reader.

Non-blocking drafting clarification: preserve the unresolved-candidate refresh trigger

Criterion 7 and its matching case say “known material change.” The Phase A document should carry forward the more precise trigger in PR #35 §6 at b9ccdc9: learning of a potentially material committed candidate before reply finalization also requires refresh or the permitted unavailable/withheld path, even when that candidate's admission or classification is unresolved.

Do not wait for a confirmed changed history label before invalidating the old reply. Include the hostile case where the observer learns of a committed candidate but cannot yet verify its historical admission. This is a clarification of the explicitly imported owner rule, not a new semantic requirement or a blocker to drafting.

Main acceptance risks for the eventual candidate

Persistence-to-release ordering: distinguish committed evidence, current release eligibility, attempted disclosure and provable delivery. Define expiry, guard invalidation, cancellation, uncertain commit and crash behavior on both sides of the release boundary. A pre-release receipt must not automatically prove disclosure, and uncertainty must not authorize reuse of a consumed decision.

A satisfiable positive observation path: identify the actual source universe, original admission proof, complete snapshot/predicate/exhaustion evidence and lawful verifier access. Where a required guarantee is absent, name the precise owner dependency; an isolation label, write position, empty query or self-consistent digest does not close it.

These risks are already covered by the issue's acceptance criteria. No broad rewrite or additional architectural layer is requested. Proceed to the bounded Phase A document when separately authorized, keeping semantic review, executable bindings, acceptance/promotion, extraction and runtime evidence as distinct stages.

Static issue-and-source review only; no runtime, concurrency or durability tests were executed. This comment supplies no semantic, merge, materialization or implementation approval.

[samovers]

Review — samovers/OFARM issue #36, "Define the governed-read transaction, coverage and disclosure protocol"

Second pass on the issue. Reviewed the body as created 2026-09-13T19:53:12Z (19,215 characters, unchanged
since creation) against all seven pinned canonical candidates read from their exact pinned commits, against
OFARM2 main and PR #359 at their pinned heads, and against the one existing review comment on the issue.

Position of this pass. Comment 5655860343 (2026-09-13T20:19:39Z) cleared the issue with "no blocking
findings" and one non-blocking drafting clarification. I began extracting before it was posted and read it
only after my own findings were written. I agree with most of it, including its clarification, and I say so
below. I disagree with exactly one of its load-bearing claims — "The selected scope remains complete… every
selected read target and authority path… Positive-path obligations prevent a permanently unavailable reader
from being presented as completed scope" — and that disagreement is Blocker 1.

One finding is a Blocker, four are Follow-ups, one is a Preference. OFARM's AGENTS.md has no review-
classification section, so I use the OFARM2 repo's three: Blocker / Follow-up / Preference.

---

Extraction

$ git rev-parse origin/main                      # samovers/OFARM
71ca724a8b6ec23f1655b086a6f549496d10a47f          # matches the issue's "Canonical main"

$ git log -1 --format='%H %ad %s' --date=iso refs/remotes/pr/<N>
4494924998183fe3fa7bc1b63b76a85893335044 2026-09-11 12:42:42 +0200 Define closed claim/read release scope in Phase A candidate
98f8c4fafbae42c8f7fd931f43f53adcb4733713 2026-09-03 10:28:09 +0200 Bind prospective approval validity window
e042efa2911b2ef0a61603b8e0adaa6911c03ac0 2026-09-06 16:52:08 +0200 Close NOT_REQUIRED digest and reconciliation review gaps
8e0994cae5610ac9c0d2652e02c8a8a2dd7b45c5 2026-09-07 16:39:00 +0200 docs: propose authorization evidence retention Phase A
092be94f3a67497ba619295932cd0b2b1e9443f3 2026-09-08 11:18:33 +0200 docs: tighten CP2 qualification and fallback boundaries
c59fdbc75f26ee4694355adedd4df021f64b5131 2026-09-13 12:10:49 +0200 docs: align qualifying-record design with release admission
b9ccdc96c5b3961eb672290cd32019364b56f8e6 2026-09-13 19:30:49 +0200 docs: propose authorization evidence history qualification

$ git cat-file -p <head>:<the one changed file> | sha256sum
4fb5fb1b035e858d5e0993417e7dcf3ec09d5d9d46376e429a690cc4be7564e7  PR#11  2064 lines  221197 bytes
08ad9d8d768c60e43520f0d431d930d865da44756abf7178bc65e52945bd37dc  PR#20   854 lines   79642 bytes
1198a63ead39aab87b44c78e9bca53f9166baf74ce62e7ae48bfdaf0dd37ac65  PR#26  1256 lines  119415 bytes
c409619b1c886ec8da57390209c744e958aff6a63bd46e774b918ce730c388f6  PR#29   345 lines   45104 bytes
400bc0fd1e06fc15ceac92810fcfcba2d39185cc22c33e14603f43d04df3d8c4  PR#31   466 lines   74400 bytes
581acada1e23da9b0a29a0afd14f38858e75a24c3e1dd171a09d7d5c569a02c7  PR#34   404 lines   64224 bytes
114f3ad6dcaa32fd2110eb2133da15d468e0207c720f36057a65bdb769568301  PR#35   448 lines   71049 bytes

All seven pinned commits exist; each PR's live head equals its pin; all seven are open, draft,
merged: false. Each PR touches exactly one file against its merge base. OFARM2 origin/main is
9d7541d96bc708e9270b986927d7f4b8a035454f and OFARM2 PR #359 is open, draft, head
7de8a2c4cf6eb1f293560af67e69565122c42f25 — both exactly as pinned.

Pin-versus-last-review check (the thing that produced the Blocker on issue #25). For every one of the
seven PRs there is at least one review bound to the exact pinned commit, so no pin sits ahead of its newest
review:

PR	Pinned head	Newest review at that head
#11	4494924	5186503521, 2026-09-12T13:13:29Z
#20	98f8c4f	5099749737, 2026-09-03T08:44:21Z
#26	e042efa	5125732836, 2026-09-06T15:01:21Z
#29	8e0994c	5134001116, 2026-09-07T16:31:47Z
#31	092be94	5168786135, 2026-09-10T15:03:35Z
#34	c59fdbc	5191266887, 2026-09-13T15:54:03Z
#35	b9ccdc9	5191762787, 2026-09-13T18:34:28Z

The three "exact-head approval" claims resolve and are accurate: 5634389303 approves PR #11 at 4494924;
5654388700 approves PR #34 version 2 at c59fdbc; 5655268051 approves PR #35 version 1 at b9ccdc9,
citing review 5191762787. All nineteen URLs in the body return 200. Both Markdown tables are structurally
sound — two table blocks, no blank line inside either, uniform pipe counts (9-column owner table, 3-column
case table).

---

Blocker 1 — the SharingGrant access basis has no acceptance criterion and no required case, and the one question that decides whether it is usable at all is never asked

Entry point. The acceptance criteria and the "Required cases" table of this issue, which together are the
contract the future Phase A candidate will be reviewed and semantically approved against.

Actor. The author of the Phase A candidate, and every later reviewer who checks that candidate against
this issue.

Path. PR #11 §13 at 4494924 (line 907) defines two access bases for the only selected read action:

For RECEIVE_READ_DATA, the evaluator performs one final authority-gate decision with two layers:

1. an access basis: a sufficient RECEIVE_USE AuthorityGrant/DelegationGrant path or a sufficient
   SharingGrant for the exact grantee and artifact; and
2. a resource-control layer …

Each candidate access basis must be independently sufficient. … constraints from separate access bases are
never unioned.

§5.4 (line 183) repeats it: "Each direct, delegated, or SharingGrant access path must be sufficient by
itself." §22 line 1792 makes cross-basis union a hostile case. §22 line 1825 is explicit about what a partial
implementation costs:

| A claim-only RP_READ_TARGET_ONE implementation is presented as complete RECEIVE_READ_DATA coverage |
conformance failure; all unchanged selected resource alternatives and authority paths remain required |

And §23 line 1855 records that "RECEIVE_READ_DATA omits SharingGrant composition" was a triggering review
finding against PR #11 itself. This axis has already been missed once in this programme and had to be
repaired in the authorization candidate.

Now grep this issue. SharingGrant, sharing, delegation, delegated, grant, RECEIVE_USE,
RP_READ_TARGET_ONE appear zero times in any acceptance criterion and zero times in the Required
cases table. The word "grant" appears twice in the whole body, both times in the negative — criterion 1's "no
new … selector power is granted" and the scope fence's "no … source-access grants". The only concrete read
target named anywhere is AUTHORIZATION_TRACE; the only concrete authority path named anywhere is none.

Preconditions. The candidate is drafted to the ten criteria and twelve cases as written, and is reviewed
against them.

Consequence — two parts.

First, the falsifiability gap. Criterion 9 does say "Show a satisfiable positive protocol for all selected
read targets/paths, not a permanently unavailable service", and the Outcome section says the issue "covers
the read owner's protocol for all selected read targets and authority paths". Both are correct as scope
statements, and this is exactly what comment 5655860343 relies on. But criterion 9's own title is
"Falsifiable positive and hostile cases", and the mechanism it provides for falsifiability is the case
table — every other criterion gets at least one row that a reviewer can check a candidate against. The
sharing basis gets none. A candidate that exhibits one positive case over a direct RECEIVE_USE grant
satisfies every listed criterion and every listed case while saying nothing about the second basis. The
clearance's claim that "positive-path obligations prevent a permanently unavailable reader from being
presented as completed scope" is true only for the paths the case table names, and it names one.

Second, and this is why I rate it Blocker rather than Follow-up, there is a live question about whether the
sharing basis can produce a lawful release at all, and this issue is the owner that should require it be
settled. A SharingGrant's covered artifact is fixed by RP_SHARE_ARTIFACT_ONE (§7.5 line 483) to exactly one
of six kinds — PASSPORT_VIEW, DOCUMENT_ASSEMBLY, DOSSIER_ASSEMBLY, SUBMISSION_ASSEMBLY,
EVIDENCE_BUNDLE, CURRENT_STATE_MATERIALIZATION. Every one of those is an aggregate that by construction
draws returned information from more than one origin revision. §13 lines 917–918 then bind the grant to a
single sharedArtifactRef and immutable revision. Meanwhile §18.5 line 1374 requires the coverage manifest to
bind "the immutable read-target revision and every immutable origin revision contributing returned
information", line 1393 requires that "Every unredacted result item must be covered by the selected
authority path for the exact read target …", and closes "if the final payload cannot be completely covered,
the read is denied". §5.4 forbids topping the grant up from anywhere else.

So: does a SharingGrant over an EVIDENCE_BUNDLE revision carry coverage of that bundle's constituent origin
revisions, or must each origin be separately covered by the same selected path? Canonical supports both
readings — line 1393's predicate is over "the exact read target", which favours yes; §18.5's per-origin
manifest and §5.4's no-union rule favour no. If it resolves the strict way, every sharing-based read denies
with READ_RESULT_COVERAGE_NOT_PROVEN (§22 line 1728) and one of the two access bases canonical defines is
permanently unavailable — precisely the outcome criterion 9 says must not be presented as completed scope.

The read-transaction owner is the right owner to settle this, because it is a coverage question, not an
authority question: resolving it does not change any selected rule, outcome, target, evidence eligibility or
authority path, so it does not touch the "Authorization/evaluator owner" fence. If the candidate never asks
it, the question surfaces at stage 8 of eleven (hostile conformance) under §22 line 1825, after semantic
approval, the policy/source/evidence bundle drafts and binding review have all been built on it.

Reproduction. Read the acceptance criteria and the Required cases table; grep for the second access
basis; find nothing. Then read PR #11 §13 + §5.4 + §7.5 line 483 + §18.5 lines 1374/1393 together at
4494924 and try to construct a completely covered payload for a shared EVIDENCE_BUNDLE read without
unioning paths.

Minimal patch. Two case rows and one clause, all inside the existing structure:

• Criterion 4, after "Bind every returned row, field, …": add that coverage must be established under the
  one selected access basis for the exact read target, and that the candidate must state whether coverage
  of a shared aggregate artifact revision extends to its constituent origin revisions, or deny.
• Case table, add: "Read authorized by a SharingGrant over a shared aggregate artifact (EVIDENCE_BUNDLE,
  DOSSIER_ASSEMBLY, PASSPORT_VIEW, …) | A satisfiable positive path exists, or the incoverable payload is
  denied; no cross-basis union under §5.4; the basis is not silently unusable".
• Case table, add: "Delegated RECEIVE_USE path versus direct path for the same read target | Each basis
  independently sufficient; one decision and one trace under §13; no union of action, purpose or evidence
  coverage".

Counter-argument, stated plainly. Criterion 9's quantifier and the Outcome sentence already say "all
selected read targets/paths", and the case table's preamble says it is non-exhaustive ("including the cases
below"). A reviewer could reasonably hold that the obligation is therefore already written and this is a
drafting Follow-up. I do not, for two reasons: the case table is where this issue puts everything it wants a
reviewer to be able to check, and the specific satisfiability question above is not merely unlisted — it is
unasked, and it is decisive for one of exactly two access bases. A scope sentence that is true but
unfalsifiable is how "omits SharingGrant composition" got into PR #11's own traceability ledger the first
time.

---

Follow-up 2 — criterion 4 makes query/plan binding unconditional; canonical has two mutually exclusive read forms, and the direct-read form requires neither

Criterion 4 says, without qualification: "Bind exact query/plan, policy, serializer identifier/version/digest,
media type and buffered-payload digest."

Canonical says the opposite in three places at 4494924:

• §7.5 line 485, RP_READ_TARGET_ONE: "optional query form requires both QUERY_SPECIFICATION and
  QUERY_PLAN (INTEGRITY_INPUT), exactly 1 each, while direct-read form requires neither";
• §7.6 line 549, EI_DATA_READ_V0_2: "immutable read-target revision or QuerySpecification/plan
  revisions, …";
• §18.5 line 1375: "the exact QuerySpecification and executable query/plan digest, where applicable".

A candidate drafted to criterion 4 literally either mandates a query specification for direct reads — which
narrows RP_READ_TARGET_ONE, a quiet amendment of the authorization owner's resource policy and a breach of
this issue's own first scope fence — or silently ignores the criterion. Neither is what the issue wants.

The "Eligible ordinary read" case row does not distinguish the two forms either, so the omission is not
repaired downstream.

Patch. Add "where applicable" to criterion 4 and name both forms; add the direct-read form to the first
case row, or split it into two rows.

---

Follow-up 3 — the three pre-disclosure retention stops that canonical already mandates are absent from criterion 8 and from the case table

Criterion 8 requires the candidate to "Apply the trusted immutable retention policy and preserve
RETAINED_BYTES versus DIGEST_ONLY without caller weakening or overclaiming reconstruction." The single
matching case row is "RETAINED_BYTES versus DIGEST_ONLY; required evidence later unavailable".

Canonical defines three distinct pre-disclosure conditions under which the read must not proceed, none of
which is about later unavailability:

1. PR RFC candidate: executable authorization evidence v0.2 #11 §18.5 line 1389 — "If no applicable policy can be resolved, the read cannot claim v0.2 governed-read
   evidence and no protected bytes are disclosed."
2. PR RFC: authorization evidence retention and proof strength (Phase A) #29 line 172 — under DIGEST_ONLY, "The exact buffer must still exist long enough to hash and execute
   the owning read protocol. … If privacy prohibits even that processing, the read is ineligible, not an
   excuse to invent unobservable bytes."
3. PR RFC: authorization evidence retention and proof strength (Phase A) #29 line 174 — "If compatible minimization cannot preserve the required proof without prohibited
   retention, the operation cannot proceed under this profile; report the policy conflict to its owner."

All three land squarely inside criterion 5's "exact success set, state/order" and criterion 9's
"production-reachable negative cases", and all three are decisions the read-transaction owner must place in
its attempt ordering — nobody else can. As written, a candidate can satisfy criterion 8 by describing how the
two postures are honoured once a policy resolves, and never define what happens when one does not.

Patch. One clause in criterion 8 and one case row: "No resolvable retention policy at the snapshot, or
DIGEST_ONLY whose required transient processing or required receipt/coverage/trace retention the policy
forbids | The read is ineligible before disclosure; zero protected bytes; report the policy conflict to
#14/PR #29 rather than weakening the posture".

Counter-argument. "Apply the trusted immutable retention policy" arguably includes applying its
ineligibility rules, and criterion 9 asks for production-reachable negative cases generally. I still file it,
because the consequence class is release of protected bytes where canonical requires ineligibility, and the
issue's own primary trust boundary is "governed-read transaction integrity and protected disclosure".

---

Follow-up 4 — criterion 6 borrows "release eligibility", which is §18.6's transport-gate term of art and cannot apply to this row; and it omits the rule that a persistence failure is not an authorization outcome

Two small things in the same criterion.

(a) Term collision. Criterion 6 asks the candidate to "Distinguish committed evidence, release
eligibility, attempted disclosure and provable delivery". In canonical, "release eligibility" is the name of
the §18.6 transport-release gate tracked by samovers/OFARM#13 (line 1415: "the separate transport-release
gate tracked by samovers/OFARM#13 must establish current release eligibility for the exact envelope,
destination, and endpoint"). That gate belongs to the OUTBOX_COMMIT_IS_FINAL_FILING_ACT posture. The read
row selects external posture N = NO_EXTERNAL_DISPATCH (§7.8 line 595), so §18.6's gate cannot apply to it
and #13 is correctly absent from this issue's scope fences. The collision is live, not hypothetical: comment
5655860343's "Main acceptance risks" already reuses the phrase as "current release eligibility". A candidate
that follows the term will import a transport-release stage into a protocol canonical says cannot dispatch
externally.

Patch. Say in criterion 6 that the read row is NO_EXTERNAL_DISPATCH, and that "release" here means the
single disclosure linearization point in §18.5, not §18.6's transport-release gate under #13.

(b) A missing disposition. PR #11 line 1622 fixes where a read persistence failure goes:
"DECISION_BUNDLE_PERSISTENCE_FAILED, DECISION_BUNDLE_PROJECTION_INVALID, READ_EVIDENCE_PERSISTENCE_FAILED
… are runtime/integrity/domain-gate results, not authorization outcomes, and therefore have no reason
rank. A runtime must not fabricate or rewrite an authorization result to place them in this table."
Criterion 6 and the "Persistence failure, uncertain commit or partial success set" case row both stop at "no
guessed success or replay" and never carry this. Mapping a persistence failure onto a DENY is the obvious
wrong turn and canonical has already closed it; the criterion should name READ_EVIDENCE_PERSISTENCE_FAILED
(§22 line 1724) and the no-reason-rank rule.

---

Follow-up 5 — the dependency ledger and PR #11's own §24.1 now describe PR #34 differently, and the compatibility ledger must reconcile it

This issue pins PR #34 at c59fdbc and cites its version-2 exact-head approval. PR #11, at the head this
issue pins (4494924), says in §24.1:

Issue #33 / PR #34 at 69682c2f918ef18756261a1186294cc3a5ebe44d
is an unapproved qualifying-record governance proposal with QG-DEP01 …

69682c2 is PR #34's previous head — the one reviewed at 2026-09-13T10:01:39Z, superseded by c59fdbc at
12:10:49 and approved at 16:02:59. This is not a defect in this issue; PR #11's reviewed bytes are correctly
preserved and this issue rightly says "Preserve reviewed bytes and their historical publication labels". But
the Phase A candidate's "compatibility/dependency ledger" (criterion 10) will consume both documents, and they
describe the same dependency at two heads with two different approval states. Criterion 10 should require the
ledger to record which head of PR #34 each consumed statement rests on, so the candidate does not inherit
"unapproved" from PR #11's prose while pinning the approved head.

---

Preference 6 — "preflight disclosure remain unsupported" reads as banning preflight

Criterion 4 ends: "Protected streaming and preflight disclosure remain unsupported." Protected streaming is
unsupported outright (§18.5 line 1395; §22 line 1730). Preflight is not: §18.5 line 1370 says "A
preflight/dry-run may return only non-protected planning or qualification information and must never
disclose protected bytes", and §13 line 930 repeats it. The read row also selects agent posture PC
(AGENT_ALLOWED_WITH_POLICY_CHECK), and §22 line 1722 turns on the distinction: an actual read missing CP2
qualification evidence is DENY, and "PREFLIGHT_ONLY is not used to authorize the read". Parsed as
"[protected streaming] and [preflight disclosure] are unsupported" the sentence is right; parsed as
"[protected streaming and preflight] disclosure is unsupported" it removes a posture canonical preserves.
Reword to "protected streaming is unsupported, and no preflight or dry-run response may disclose protected
bytes."

---

Where I agree with comment 5655860343

I checked its four "What holds up" claims independently and all four reproduce, one of them more strongly
than stated:

• §18.5 and §24/Promote executable authorization constraints and decision evidence RFC v0.2 #21 predecessor 5 really do assign this obligation. §18.5 is at line 1368 exactly as
  linked, and every clause the issue attributes to it is verbatim. Promote executable authorization constraints and decision evidence RFC v0.2 #21's predecessor 5 reads "The separately
  owned governed-read transaction/coverage/receipt/disclosure protocol must also be closed; PR Define the NOT_REQUIRED transaction and consumption protocol v0.1 #26's
  write-only profile is not that read protocol." PR Define the NOT_REQUIRED transaction and consumption protocol v0.1 #26 §7.1 item 4 excludes RECEIVE_READ_DATA and line 16
  states why. PR RFC candidate: governed human-finalization transaction protocol #20 mentions RECEIVE_READ_DATA and "governed read" zero times — a stronger fact than
  "does not fill this gap either".
• #359 F4 is preserved correctly. F4 is real and citable: review 5187679508 at 7de8a2c4, whose own
  "What is next" says "record F4 against G2/G3-READ". G3-READ and G3-HANDOFF are real tokens in #359's
  body. Criterion 3's wording does not commission the redundant carrier.
• The OFARM2 characterization is accurate at the byte level. All four line anchors resolve to what the
  issue claims: tenant_uow.py L466 is _run, which executes BEGIN ISOLATION LEVEL READ COMMITTED at L475;
  0003_tenant_knowledge_position.sql L36 is allocate_tenant_knowledge_position(), which raises 25001
  unless transaction_isolation = 'read committed' (L47–50) and serializes positions via
  take_tenant_write_lock() + max+1 (L66–76); store.py L578 is the comment "Canonical truth is
  tenant-scoped, not bundle-scoped"; api.py L63 is blocked(), raising 503 GOVERNED_SURFACE_BLOCKED.
• Its non-blocking clarification is correct and I would keep it. PR Define authorization-evidence source-history qualification (Phase A) #35 §6 at b9ccdc9 does carry the
  sharper trigger: "If they learn of a potentially material committed candidate after c but before finalizing
  the reply, they must not deliberately keep c to hide it… An unverified new candidate is reason to refresh or
  report a limit, not permission to ignore it because its status is not known yet." Criterion 7's "known
  material … change" is weaker than the imported owner rule. Same section also forbids splicing a refreshed
  history into a finalized payload, which criterion 7 does carry.

Where I part company is only the sentence quoted at the top of this review.

---

Checked, and decided were not findings

So the next pass does not re-spend it.

• Duplicate-issue check. Full open+closed issue inventory for samovers/OFARM: Define governed human-approval transaction and consumption protocol #19 (closed) owns the
  human-approval transaction, Define the NOT_REQUIRED atomic transaction and single-use consumption profile #25 owns the NOT_REQUIRED transaction, Define authorization-evidence source-history qualification and producer contract #32/Define governed qualifying records for authorization evidence #33 own history and qualifying
  records, Define the CP2 authorization-result surface and registered public reason codes #30 owns CP2, Define authorization evidence retention and proof-strength postures #14 owns retention, Define transport-release eligibility after filing outbox commitment #13 owns transport release. Nothing else owns the governed-read
  transaction. The issue's duplicate check reproduces.
• AUTHORIZATION_TRACE recursion. A trace read emits its own decision evidence and governed-read
  receipt, which become trace content. I checked whether that is an unbounded regress or a coverage paradox.
  It is neither: §18.5 line 1374 pins "the immutable read-target revision", so each trace read is taken over a
  fixed revision and its own later evidence is simply a subsequent revision. Monotone growth, not a defect.
  §22 line 1734 already handles the unauthorized case. No criterion needed.
• CURRENT_ONLY historical posture versus historical reads. §7.8 line 595 gives the read row historical
  posture C, and line 572 says "No current row performs a historical authority check." That does not
  conflict with criteria 7 and the historical case rows: PR Define CP2 authorization-result qualification and public reasons (Phase A) #31 line 310 makes RECORDED_RESULT use "the
  current projection time and current disclosure limits" over historical content, and line 316 says a lookup
  denied under current authority cannot reveal the old outcome. Current authority, historical content.
  Consistent throughout.
• Where the governed-read receipt and coverage manifest live. Criterion 5's "no new top-level evidence
  family is presumed" is satisfiable: PR RFC candidate: executable authorization evidence v0.2 #11 §17.2 item 4 already names "governed-read receipt with an
  explicit payload proof-strength posture" inside AuthorizationFinalizationEvidence v0.2, and §18.5 lines
  1372/1379 place the coverage manifest as a binding of the decision bundle and receipt rather than a separate
  family. §17.2 also states "NOT_REQUIRED does not remove single-use evidence, governed-read receipts,
  retention proof, public refusal qualification or source-history obligations". I expected a gap here and
  there is none.
• samovers/OFARM#13 absent from the scope fences. I considered filing this. It is correct: the read row
  is NO_EXTERNAL_DISPATCH, so §18.6's transport-release gate is inapplicable. Only the terminology leaks —
  see Follow-up 4(a).
• Every named token resolves verbatim at its pinned head. HSP-BIND01–04 (PR Define authorization-evidence source-history qualification (Phase A) #35 lines 416–419;
  BIND03 is "authoritative observation and reply binding … with actual source/governed-read/transaction
  owners", exactly as the issue characterizes it), QG-DEP01, CP2A-DEP01, C38 (PR Define CP2 authorization-result qualification and public reasons (Phase A) #31 lines 165 and 384),
  WITHHELD precedence (PR Define CP2 authorization-result qualification and public reasons (Phase A) #31 line 161), RETAINED_BYTES/DIGEST_ONLY (PR RFC candidate: executable authorization evidence v0.2 #11 lines 1386–1387, PR RFC: authorization evidence retention and proof strength (Phase A) #29 lines
  20/114/166), RECORDED_RESULT (PR Define CP2 authorization-result qualification and public reasons (Phase A) #31 line 310; PR Define authorization-evidence source-history qualification (Phase A) #35 line 148 binds its cut to the §18.5 governed-read
  snapshot), AuthorizationDecisionEvidence/AuthorizationFinalizationEvidence v0.2 (§17.2), the eleven
  stages of §24, EP_CP2_READ_QUALIFICATION_V0_2 and EI_DATA_READ_V0_2 (§7.8 line 595). Zero invented
  names. This is the cheapest possible Blocker and the issue does not hand it over.
• Markdown mechanics. Both tables are intact; no blank line drops rows. (This was a real finding on issue
  Define the NOT_REQUIRED atomic transaction and single-use consumption profile #25 and is worth the ten seconds every time.)
• The "Verification and limits" process claims. "The existing local binding investigation used immutable
  OFARM2 main objects and preserved its dirty primary checkout" reproduces: the local OFARM2 checkout is at a
  different HEAD with 12 dirty entries, and 9d7541d is reachable as origin/main and readable by
  git cat-file without touching the working tree. "No canonical/runtime file … is changed by this issue"
  holds — the issue creates no commit.
• Positive-path phrasing in criterion 9. "not a permanently unavailable service" is the right requirement
  and it is the requirement Blocker 1 says has no mechanism behind it for one basis. The phrasing itself is
  fine.

---

What my method made easier than production

• Everything here is prose against prose. I read seven pinned candidate documents and one issue body.
  Nothing was executed. No schema exists for any of it, so every token match I report is a string match in a
  draft, not a validated binding. G2 on OFARM2 #359 — no executable canonical bytes — applies to this review
  in full.
• Blocker 1's severity rests on a reading of two clauses that canonical leaves ambiguous. I am confident
  the ambiguity is real and that this issue is its owner; I am not claiming to know which way it resolves.
  If §18.5 line 1393's "covered by the selected authority path for the exact read target" is meant to make
  the target revision the whole coverage predicate, the sharing path is fine and Blocker 1 shrinks to
  "add the case rows" — still worth doing, no longer structural.
• I did not verify the six shareable artifact kinds against any schema, because none exists. The
  aggregate-versus-atomic characterization of EVIDENCE_BUNDLE, DOSSIER_ASSEMBLY and the rest is inferred
  from their names and from §7.5, not from a materialized contract.
• I checked pins against the GitHub API at one instant. PR RFC candidate: authorization-evidence qualifying-record governance #34 and PR Define authorization-evidence source-history qualification (Phase A) #35 both moved earlier today
  (12:10 and 19:30 local); another head could land while this review sits unposted. Re-check the seven heads
  before acting on it.
• The AUTHORIZATION_TRACE recursion dismissal is an argument, not a test. With no runtime there is no
  way to show that trace growth stays bounded in practice.
• I ran no package, database, concurrency or hosted-runtime check, and none would be meaningful against a
  document that does not exist yet.

---

Final assessment

One Blocker, four Follow-ups, one Preference. The issue's mechanics are the best I have seen in this
family: seven pins exact, seven heads open/draft/unmerged, every pin at or behind its newest review, three
approval comments resolving to the heads they claim, nineteen live links, four OFARM2 line anchors accurate to
the line, every named token verbatim, tables structurally clean, and the duplicate check reproducible. The
missing contract it records is real and correctly attributed.

The Blocker is not about what the issue says; it is about what it makes checkable. RECEIVE_READ_DATA has two
access bases, the acceptance criteria and required cases exercise one, and the question that decides whether
the second can ever return a completely covered payload is never asked of the candidate. That omission has
already cost this programme once — PR #11 §23 line 1855 records "RECEIVE_READ_DATA omits SharingGrant
composition" as a triggering review finding against the authorization candidate itself. I would not clear the
issue for Phase A drafting until the sharing and delegated bases have a criterion clause and two case rows.

The four Follow-ups are all one-clause patches that are cheaper now than in a reviewed candidate. None of
them, and not the Blocker either, asks for an architectural change, a new owner, or a wider scope.

This review supplies no semantic, merge, materialization or implementation approval, and it is authored by
samovers, the issue's own author — like every prior review in this family, it does not satisfy an
independent-review gate. HSP-BIND01–04, QG-DEP01, CP2A-DEP01, #21 and OFARM2 G2/G3/G4 remain open.

What is next: patch criteria 4, 6 and 8 and add the three case rows above, then draft the one-file Phase A
candidate when separately authorized. Keep PR #35 and every other approved candidate unchanged.

[samovers]

Re-review: no blocking findings

Reviewed the amended issue body, updated_at: 2026-09-13T20:51:47Z, against review 5655860343, second review 5656026666, and the affected pinned source sections.

The reported SharingGrant omission is addressed at the issue-specification level. The other requested clarifications are also addressed. No further corrective issue-body patch is needed before the separately authorized Phase A draft. This is review clearance of the amended issue, not approval of the unwritten protocol or closure of its dependencies.

1. SharingGrant coverage: the amendment addresses the concern without inventing authority

Criterion 4 now explicitly requires independently sufficient direct, delegated, and SharingGrant access bases. It prohibits completing an insufficient path with authority, purpose, or evidence borrowed from another path or from the resource-control layer. The case table now demands both a positive shared-artifact read and independent direct/delegated paths, including attempted cross-path combination. This removes the omission identified by the second review.

The important improvement is not merely mentioning SharingGrant. The amendment requires a source-backed explanation of which constituent information the artifact-scoped permission covers, while expressly refusing to infer independent access to underlying records. A genuinely new permission rule must return to the authorization owner. That respects PR #11 §13 at 4494924's separation between an independently sufficient access basis, the constraining resource-control layer, and the subsequent §18.5 result-coverage checks.

The drafting omission is resolved; the actual coverage semantics are not yet demonstrated. The second review's stronger possibility—that origin-level coverage could make sharing-based reads unusable—is not an established contradiction. Requiring origin provenance does not, by itself, settle what information an artifact-scoped grant permits disclosing. The amended issue correctly requires that question to be answered from governing contracts rather than assuming either universal permission or universal refusal.

2. Remaining review points

Review point	Re-review disposition
Follow-up 2 — direct versus query reads	Addressed. Direct reads require neither query input; query-form reads require exactly one QUERY_SPECIFICATION and one QUERY_PLAN, as integrity inputs rather than additional authority targets. This matches PR #11's RP_READ_TARGET_ONE.
Follow-up 3 — pre-disclosure retention stops	Addressed. Criterion 8 and a dedicated case cover an unresolved policy, prohibited transient buffering, and incompatible mandatory evidence retention. These stop disclosure rather than justify a weaker posture. The latter two conditions match PR #29 §8 at 8e0994c's explicit ineligibility rules; unresolved policy is covered by PR #11 §18.5.
Follow-up 4(a) — read disclosure versus filing transport	Addressed. Criterion 6 now expressly distinguishes the buffered-read disclosure boundary from the filing transport-release gate. It does not import #13's transport protocol into this read protocol.
Follow-up 4(b) — persistence failures	Addressed. The issue now places read-evidence and applicable decision-bundle failures in runtime/integrity dispositions, without an authorization reason rank or a fabricated DENY. This matches PR #11's explicit classification.
Follow-up 5 — historical versus current dependency status	Addressed. Criterion 10 requires the ledger to distinguish PR #11's historical reference to the unapproved older PR #34 head from the approved version-2 input. The re-review inspected PR #34 at c59fdbc75f26ee4694355adedd4df021f64b5131, with design-only approval and its binding dependencies still open.
Preference 6 — preflight wording	Addressed. Non-protected planning or qualification responses remain permitted; protected-byte disclosure through preflight remains prohibited. That preserves PR #11 §18.5 rather than banning preflight itself.
Earlier clarification — unresolved-candidate refresh	Addressed. Criterion 7 and its case now trigger on a newly learned potentially material committed candidate, even before admission or classification is resolved. Whole-read rebuilding, suppression of finalized payloads, and the prohibition on rewriting evidence match PR #35 §6 at b9ccdc9.

3. What remains open is correctly left to Phase A

The eventual candidate must still demonstrate a coherent positive protocol: lawful shared-artifact coverage, complete same-context observation, genuine pre-evaluation qualification evidence, and precise behavior between evidence commitment and disclosure—including expiry, uncertain commitment, crashes, and retry. Adding those requirements to the issue is not evidence that the protocol satisfies them. The amended issue preserves that distinction and keeps the source-binding, promotion, extraction, and runtime gates open.

Recommendation: proceed with the separate one-file Phase A proposal when authorized. Do not reopen the adjacent approved candidates merely to record these clarifications, and do not treat this review as protocol-semantic or implementation approval.

Static re-review only. No runtime, concurrency, durability, or package tests were run. This comment supplies no semantic, merge, materialization, promotion, extraction, deployment, or implementation approval.