Resolve farm scope for legacy result and trace reads with FIELD-only anchors

[samovers]

Parent: #179. Related output-authorization work: #177. Discovered as F1 in PR #393 review 5209450131; separate from Delivery #389's documentation-only reader guide.

Outcome and primary boundary

An authorized legacy farm reader can retrieve a commit result and its promotion trace for a valid FIELD-only submission using a durable, unambiguous farm association. Missing or ambiguous association and insufficient read authority continue to fail closed. Primary boundary: farm resolution for legacy record-read authorization.

Demonstrated problem

At f804beb626c7026f6d25373caa9c427c1c5fc25c, kernel/legacy_m1/api.py::_read_farm_scopes resolves FARM-typed scopes from the record or recursively through semanticEventRef/requestId. Nonempty explicit FIELD-only targetScopes are preserved as the event/request scopes. They provide no FARM entry to that reader, which returns 403 PERMISSION_REDACTED for the result and trace before a normal farm-read authority evaluation, even when the submitting farmer has the needed farm grant. A retained sufficiency case has a FARM anchor and can be readable directly. Omitted/empty raw targetScopes take the normalizer's FARM default and are not this counterexample.

The reviewer measured FIELD-only operation and observation result/trace reads as 403; FARM+FIELD operation reads succeeded. Their environment was PostgreSQL16.13/CPython3.12.3 and is not the repository's pinned runtime evidence. The source path is confirmed locally; independent pinned disposable-fixture verification is in progress for PR #393. No production route is opened by that evidence.

Falsifiable acceptance criteria for future implementation

• Identify the accepted durable source of a result/trace's farm; do not infer authority from a caller-asserted farm or field identifier alone.
• With a valid FIELD-only stored submission and the existing farm-read grant, authorized GET of the result and trace succeeds and returns the original immutable records.
• The same records remain unreadable to an unrelated farm or unauthorized principal. Missing, ambiguous or inconsistent durable association fails closed.
• Existing FARM and FARM+FIELD reads, immutable event anchors, claim/replay semantics and production closure are preserved.
• Prove the allowed and refused paths with fictional fixtures and isolated disposable databases under the required interpreter/database/dependency profile.

Scope and approval posture

This issue records a separate future Delivery, not implementation permission. Read authorization is an authority boundary and requires its own risk-shaped design, review, decision and exact same-task approval before changes. Resolve overlap/dependency with #177 in that design; do not widen #393 or transfer its routine documentation classification.

Non-goals: new grants or sharing rules, weakening failed resolution, broader output-authorization overhaul, acceptance changes, stored-event rewrites, new production endpoints, deployment, or restarting the audit. No implementation PR is open for this issue.

Next: prepare a bounded design for this read-resolution capability when authorized; #393 may describe the existing limitation without implementing this repair.

[samovers]

Review: #394

Verdict: valid follow-up issue, ready for a bounded design—not implementation. No blocker to accepting the issue in its current role.

#394 explicitly defers implementation permission and keeps the repair separate from #393’s documentation work. That separation is appropriate.

The reported defect is correctly described

The normalizer preserves nonempty targetScopes, so a FIELD-only submission produces FIELD-only event and request scopes. _read_farm_scopes() looks for FARM scopes, then follows semanticEventRef and requestId; it does not resolve field containment. Consequently, the record route denies the read before evaluating the principal’s farm-read grant. Omitted or empty targetScopes instead receive the FARM default and are not this counterexample.

Sources at reviewed commit: IngressNormalizer, _read_farm_scopes and record route.

The important remaining work is not another diagnosis. It is deciding which stored relationship is sufficient to authorize these reads without creating a second authorization policy.

1. The design needs a provenance matrix, not just one successful lookup

There is already a candidate durable path worth evaluating before adding records or changing schemas:

commit result → promotion trace → authorization decision result → authorization request → target.scope

The authority stage persists its request, trace and result, and adds authorizationDecisionResultRef to the promotion trace. The authorization request contains the FARM scope evaluated during submission. This establishes an existing source to investigate; it does not, by itself, prove that every such relationship is trustworthy or sufficient for read authorization.

Sources: AuthorityGate, AuthorityEvaluator, PromotionTraceWriter.

That path is also not universal. ReplayWriter creates different request/result/trace records, references the original semantic event, and does not attach a new promotion authority decision. A fallback that works for an ordinary submission can therefore still fail—or choose the wrong association—for replay records. See ReplayWriter.

Required design output: identify the accepted source and expected read outcome separately for ordinary submissions, retained/refused attempts, matching replays and conflicting replays. State whether pre-existing records are covered and which historically unresolvable cases intentionally remain denied.

This should explicitly cover both the operation and observation counterexamples. “Valid FIELD-only stored submission” is adequate for recording the problem, but too broad to serve as the implementation test matrix.

2. Resolve the #177 boundary before implementing the fallback

The issue already requires resolving the overlap with #177. That must become a concrete design decision, not remain a cross-reference: #177 explicitly owns durable tenant/scope/provenance resolution and authority evaluation together with the protected read in one UnitOfWork.

Two implementation traps deserve explicit tests:

Historical authority is not present permission. An old authorization decision might help establish which farm an attempt concerns. Its historical ALLOW must never replace the fresh RECEIVE_READ_DATA evaluation. Test a successful read followed by grant revocation and a denied subsequent read. The existing reader already evaluates access per request; preserve that behavior. See evaluate_read.

Do not expand the generic recursive resolver indiscriminately. The helper serves every non-public record passing through the generic record endpoint, not only commit results and promotion traces. It currently returns the first resolved farm set and prevents only immediate self-reference—not longer cycles. A repair should define allowed record kinds and reference paths, check conflicting associations, and terminate safely rather than introduce unrestricted graph traversal. See _read_farm_scopes and its caller.

My recommendation is to keep #394 narrowly responsible for result/trace farm resolution, with an explicit decision on what it reuses from, depends on, or leaves unresolved under #177. Do not quietly implement a parallel general-purpose authorization resolver.

Minor evidence correction

The issue says pinned disposable-fixture verification is “in progress.” PR #393 now records six focused probes using CPython 3.12.13 and PostgreSQL 17.10, including FIELD-only versus FARM+FIELD reads. Refresh that statement with the recorded evidence, while retaining the qualification that the FIELD-only observation probe was not repeated in that run. This is an evidence-status correction, not an implementation blocker.

Bottom line: keep the issue. Its diagnosis and scope are sound. The next design should settle the provenance matrix and #177 dependency before selecting a repair.

Validation: source review against commit 47610badaf171bee7ac83c3430bad561073c7e14 and the linked issue/PR records. I did not independently run the pinned database tests. This review is not implementation authorization.