ADR-0095 delta c's carve-out now holds only at the read call site — PR #17115 tightens the compiler past it, and the asymmetry is undocumented

[os-trump]

Filed by the domain:services PM seat (#6021) from PR #17115's out_of_scope_findings (card #17042). ⛔ Routed to the maintainer, not queued for a dev: the remedy is a sentence in docs/adr/**, which is a governed surface — the maintainer's floor. The delivering seat reported it rather than writing it, which is correct.

The asymmetry

PR #17115 closes #17042 by judging undeclared columns at RLSCompiler.compileFilter — the one seam the read layer (using) and the ADR-0058 D4 write gate (check) already share — on the compiled FilterCondition tree, so no spelling of negation can route around it.

The read call site's older, narrower mechanism (extractTargetField, a leading-only == / = / in shape match) stays. ⭐ That is not an oversight: ADR-0095 delta c's carve-out depends on the regex recognising only the leading shape. Widening the regex — the obvious repair, which the PR explicitly rejected — would have broken it.

⇒ After #17115 the carve-out is honoured at the read call site and not replicated in the compiler pass, which denies on every undeclared column, organization_id included.

The observable consequence. On a tenancy-disabled object, a policy naming organization_id in a non-leading or negated position moves from "SQL raises / the in-memory matcher returns 0 rows" to "deny sentinel".

⛔ Why the PR was right not to "fix" this

Replicating the carve-out into the compiler pass would turn a case that denies today into one applying no restriction at all — a relaxation. #17042's dispatch forbids that in terms: ⛔ relaxing a security boundary is the maintainer's floor. So the PR tightened and reported, which is the only correct move available to it.

⚠️ ⇒ This card is not a request to undo anything. The behaviour is deliberate and, this seat believes, right. What is missing is that ADR-0095 does not say so, and a reader comparing the ADR to the code after #17115 will find a carve-out that the code honours in one place and overrides in another, with nothing explaining which is intended.

What the maintainer is being asked for

One decision, then at most a paragraph:

1. Confirm the tightening is intended — an undeclared column denies everywhere, and delta c's carve-out is scoped to the leading-shape read path only.
2. If yes, state the asymmetry in ADR-0095 so the next reader is not left inferring it from a regex. If no, the direction to take instead is the maintainer's, and fix(security)!: an RLS predicate naming an undeclared column denies in every position #17115 (or a follow-up) is where it lands.

⚠️ ⛔ This should be settled while PR #17115 is still in contract review, not after: the reviewer is looking at exactly this seam, and an ADR that disagrees with the code is worse the longer it stands.

Provenance

PR #17115 (card #17042), out_of_scope_findings — "the ADR-0095 delta c carve-out now lives ONLY at the read call site … a maintainer may want the asymmetry stated in ADR-0095 itself. Governed surface, so reported rather than written."

Related: #17042 / PR #17115 · ADR-0095 delta c · ADR-0058 D4.