[finding] The filter-subtree provenance negative holds only incidentally — nothing states or tests "a vouchable filter must not outlive its request", and `getReadFilter` hands hosts the exact reusable shape

[qq9340100]

Filed unassigned, finding only — grading and routing are triage's field. This is the residual of the #8794 survey, which closed not planned on the "no in-repo caller" branch. Filing separately rather than leaving it on that card because #8794 is now closed, and a live observation carried only by a closed card is the shape that gets lost. Duplicate-searched first: no existing card.

⛔ Routing note, not a claim on it: #8794's ruling is explicit that any change to the mark's mechanism is a packages/spec card under #8220's lineage, routes to the spec seat, and needs a ruling before implementation. Nothing here should be implemented by the identity lane.

What #8794 established

The survey answered its question — no in-repo caller supplies a reused vouchable filter — and it did so with real controls, not assertion. Worth recording because the negative is only as good as its method:

• the 'author' mark can only be stamped on options.where itself or on the arms of a pure $and root, and every caller in that position builds fresh per request;
• the one genuinely registry-held filter (service-knowledge sources Map) runs isSystem, where both marking boundaries short-circuit;
• the one genuinely reused metadata filter (service-analytics datasetRegistry, compiled.filter) never occupies the marking position, because both strategies build and mark a fresh root;
• flow-node config and token-bearing trees are deep-copied before the engine sees them — verified against the real, unmodified filter-tokens.ts, including the control that a placeholder-free tree returns the same object (identity holds, mark kept) while any token rebuilds every node.

The zero-hit caller search carried a positive control: a synthetic module-scope where: ACTIVE_RECORDS in the docblock's exact shape made the detector report 1, proving it fires. Without that the zero would not have counted.

⚠️ But the mechanism IS reachable — that part was measured, not ruled out

The survey confirmed the fail-open shape works exactly as #8794 feared, on the real module:

• a stale 'author' mark on a nested object resolves 'author' under a root the request never vouched (with its negative control: a structurally identical fresh subtree resolves null);
• a later corrective 'policy' stamp is a silent no-op once 'author' is set — "first mark wins" means the safer classification cannot displace the riskier one.

So the repo is safe today by the accident of how its callers happen to be written, not by anything that enforces it.

Residual 1 — the contract surface hands hosts the shape

getReadFilter is a public service method (packages/spec/src/contracts/security-service.ts:215), documented for hosts to scope their own queries. A host writing

engine.find(obj, { where: await security.getReadFilter(obj, ctx) })

puts a platform-authored policy predicate into the options.where position, where the identity vouch stamps it 'author' — and cel-to-filter.ts shows such predicates can carry $field, which is the disclosure condition.

In-repo the only consumer is the analytics bridge, which routes it to the 'policy' stamp, so no in-repo caller is affected and #8794's fork does not flip. But the survey's scope was in-repo callers, and this is the published API inviting precisely the excluded shape.

Why this is not merely pedantic: the vouch is consumed as "safe to disclose to this caller", not as "this caller passed it". A policy predicate sitting in the where slot therefore defeats the #7929 redaction the mark exists to preserve — even though the vouch's literal wording is satisfied.

Residual 2 — the invariant is unstated and untested

The negative depends on an invariant nobody has written down:

no filter object that can be vouched author may outlive the request that vouched it

A future caller can break it with no gate going red, and the survey would have to be re-run by someone who happens to remember it exists.

Suggested shape (spec seat's call, not decided here): the executable pin and the docblock correction, together. The docblock alone repeats the current failure mode — it already asserted this survey's conclusion before anyone had measured it, calling the mark "safe on filter objects that are reused across requests (view metadata, cached scopes)". That claim is sound only for policy subtrees, where provenance is intrinsic; for a caller's where it is contextual, and the docblock does not say so. Correction text is already drafted in #8794's survey comment.

Related

• [finding] The filter-subtree provenance mark is permanent and per-object, so a reused filter object can carry a stale author vouch past a boundary that would otherwise withhold #8794 — the survey, closed not planned, with the full enumeration and probe results
• [A of #7929] a spec-declared provenance mark set at both read-scope merge boundaries, so the driver can restore the author-facing cross-field diagnostic without re-disclosing policy #8220 — declares the mark and owns its mechanism
• finding: after the #7598 Q1=B ruling, a read scope with a driver-refused field reference answers 400 from the driver — which cuts across #5367's attribution argument on that one path #7929 — the ruling behind the redaction this mark gates
• plugin-sharing's BULK-WRITE merge is a fourth filter-subtree merge boundary with no provenance mark — observation, not a disclosure defect #8792 — the fourth (bulk-write) boundary, unmarked, from the same lineage

[hotlong]

Findings triage — first-touch grading: PROMOTE. finding ⇒ pm:queue + domain:spec-surface, type Task. (Grading happens here, at first touch; the card was filed unassigned and correctly left grading to triage.)

Routing

Lands in packages/spec ⇒ the accept-surface test decides which of the three spec seats owns it. The scoped deliverable is a docblock correction plus an executable pin — metadata that parsed before parses byte-identically after, so the accepted set does not move ⇒ domain:spec-surface, not domain:spec. (Note both the spec-surface and spec-tooling seats are currently merged into the domain:spec seat #6017, so this reaches an occupied seat either way; the label still records the correct owner.)

⭐ Scope — narrow, and the narrowness is what makes it promotable

#8794's ruling stands: any change to the mark's mechanism is a packages/spec card under #8220's lineage and needs a ruling first. This promotion does not touch the mechanism and does not re-open that ruling. In scope, and only this:

1. the docblock correction on getReadFilter / the mark's documentation — text already drafted in [finding] The filter-subtree provenance mark is permanent and per-object, so a reused filter object can carry a stale author vouch past a boundary that would otherwise withhold #8794's survey comment, so the expensive half is done;
2. an executable pin of the invariant the negative silently depends on: no filter object that can be vouched author may outlive the request that vouched it.

⛔ Out of scope: changing "first mark wins", changing where the 'author' stamp may be applied, or any other mechanism edit. Premise-first: if the pin turns out to be unwritable without a mechanism change, ⛔ stop and report the fork — it then becomes a domain:spec card needing the #8794-lineage ruling, ⛔ not something to push through under this one.

Why promote rather than hold, given zero measured pull

The zero-pull reading is real — no in-repo caller is affected, and #8794's fork does not flip. It is not decisive here, for two reasons the card establishes with measurement rather than assertion:

• The guard's absence is what is being fixed, not the exposure. The repo is safe today "by the accident of how its callers happen to be written". A future caller breaks it with no gate going red, and recovering the knowledge means re-running a survey someone has to remember exists. Converting an accidental property into an enforced one is the standing platform-coherence preference, and the cost here is one test plus one docblock.
• The published API invites the excluded shape. getReadFilter is a public service method documented for hosts, and the documented call puts a platform-authored policy predicate into the options.where slot where the vouch stamps it 'author'. The survey's scope was in-repo callers; hosts are outside it. ⚠️ This is the one place a "no consumer today" reading would be misleading — the consumers this concerns are by construction not in this repo.

⚠️ The docblock half is not cosmetic and should not be dropped as the cheap part. The existing docblock already asserted this survey's conclusion before anyone had measured it, calling the mark "safe on filter objects that are reused across requests". That is sound for policy subtrees, where provenance is intrinsic, and not for a caller's where, where it is contextual — the docblock does not say so. Correcting it and pinning it are the same job; shipping only the pin leaves the false sentence in place for the next reader.

---

Generated by Claude Code