[jonahgabriel]

OMN-16976

The OMN-16831 tenant-authority fix is released and is deployed. It still writes no rows. This is the reason, and the fix.

What the ticket's premise got wrong

The description says the fix is "merged but UNRELEASED" and that "every runtime resolves omnibase-infra 0.38.11 from PyPI". Both are stale. Read out of the deployed omninode-runtime container on the .201 dev lane this session:

omnibase_core-0.47.1.dist-info
omnibase_infra-0.38.16.dist-info     <- contains 01261b796 (tags v0.38.14, v0.38.15)
omnimarket-0.4.15.dist-info
ONEX_TENANT_DB_URL=postgresql://tenant_projection_writer:***@postgres:5432/omnidash_analytics

AC2 is met. The pre-fix refusal string Tenant projection has no cryptographically verified authority appears 0 times in a 3h log window. And the projection still writes nothing — 40 InsufficientPrivilege in that same window, all on projection_delegation_inference_response_text, the one tenant-classified relation currently taking traffic.

Root cause: the fix removed the Python refusal and left a Postgres one

OMN-16831 severed attribution from authorization, correctly. It also severed the write from the isolation mechanism. With no authority bound — which is every real dispatch — TenantProjectionTableOperation.upsert calls _execute_upsert(tenant_context=None), which issues a bare INSERT and never opens a tenant transaction, so app.tenant_id is never set.

Every tenant-classified relation carries WITH CHECK (tenant_id = current_setting('app.tenant_id', true)) under FORCE ROW LEVEL SECURITY, and the runtime connects as tenant_projection_writer (NOBYPASSRLS). An unset GUC reads NULL, tenant_id = NULL is false, the row is denied.

Proven in-lane, same relation, same role, same statement, for a tenant slug outside the compiled _LEGACY_TENANT_UUID_MAP (['beta-business-proof','beta-gateway-canary-79afa7263852','omninode']):

STEP 3: INSERT with NO app.tenant_id GUC
  RAISES: InsufficientPrivilege | new row violates row-level security policy
          for table "projection_delegation_inference_response_text"
STEP 4: same INSERT with SET LOCAL app.tenant_id = the row's own attribution
  INSERT OK -> the missing GUC is the entire remaining gap

Why the fix is writer-side, not database-side

FORCE RLS here is the deliberate target state, not drift: 10 relations in omnidash_analytics carry it, all tenant-classified, all written by tenant_projection_writer. And the canonical shape enforced by application_database_domain_enforcement is exactly one permissive ALL policy for PUBLIC. OMN-17298's own 0004_capability_scores_policy_atomic_restatement.sql states the consequence outright:

A second permissive policy scoped to the writer role would be rejected there as 'extra permissive policy ... widens access', which is why the fix for a policy-less FORCE-RLS relation is an atomic restatement and never an extra admitting policy.

So a GUC-scoped write is the only sanctioned path. The writer has to open the scope.

The change

When no authority is bound, the statement is scoped to the tenant the row itself records. The scope value IS the row's tenant_id, so this widens nothing — the write is confined to the identity it already declares and cannot reach another tenant's rows. Reads are symmetric: scoped by the caller's own filter; a filter naming no tenant opens no scope and stays blind.

The read half is not cosmetic. _preserve_existing_evidence reads before every upsert; under FORCE RLS an unscoped read returns [] even when the tenant's row exists, so the upsert that follows would overwrite accumulated recent_responses instead of merging it — silently.

What stays enforced

• No capability is minted. The claim is never verified against a dispatch event and authorizes nothing; _optional_tenant_context() still returns None. A bound authority still wins and is still verified against its event.
• A tenant-less or blank row opens NO scope, so the relation's own policy denies it. OMN-16831 ruling item 4 (a tenant-less row is the producer's obligation) is now enforced by the database instead of by a Python raise.
• The scope is transaction-local (set_config(..., is_local => true)), committed on success and rolled back on failure — it cannot leak to the next event on a pooled connection.
• INTERNAL and CATALOG domains supply no scope and open no tenant transaction, unchanged.

The invariant I deliberately sharpened — please read this part

test_red_control_untrusted_tenant_selection previously asserted that an unverified claim "never reaches set_config('app.tenant_id', ...)". That conflated two different things:

• opening a session in order to be entitled to act as a tenant — a capability, still forbidden;
• scoping one statement to the identity that statement is persisting — the isolation mechanism reading attribution it was already handed.

The test now asserts the invariant that actually matters: no authority is minted, nothing is verified against an event, and the only scope opened is the row's own — asserted positionally against the row's tenant_id. This is a judgement call made under Operating Rule 2 and it is the one thing in this PR worth arguing with.

Red-then-green

Tests kept, source reverted to dev tip → 4 of 43 fail: StopIteration on the absent set_config, no scope on the read, DID NOT RAISE on the rollback control. With the fix → 43/43.

Gates

gate	result
adapter module	43/43 pass
tests/unit/runtime + tests/unit/topology + tests/ci	7857 passed, 8 skipped
mypy --strict	clean, 2917 source files
ruff format + check	clean
pre-commit (commit hooks)	all passed

7 wall-clock performance thresholds failed under -n 4 on a loaded host (policy_registry, registry_compute, handler_bootstrap_source — none touched by this diff). Verified independent: they pass 3/3 in isolation with this change applied.

Not in this PR

• OMN-17374 — tenant_projection_writer has zero grants on tenant_registry_mirror, so sync_registry_tenant_uuid raises permission denied before resolution. Confirmed live again this session. Blocks node_projection_delegation; does not block the relation this PR unblocks.
• tenant_registry_mirror holds 0 rows on the dev lane (OMN-17374 adjacent finding 1).
• permission denied for table savings_estimates — same grant class.

Ticket: OMN-16976

Evidence-Ticket: OMN-16976
Evidence-Source: OCC#7890

[github-actions]

⚠️ Hostile Reviewer — DEGRADED (informational)

Blocking findings (critical): 0
Total findings: 0
Models succeeded: none

Note: All reviewer models failed or were unavailable. Degraded results are informational during the pilot phase (OMN-8468/OMN-8524) and do not block merge. Error: all review endpoints [192.168.86.201:8000 192.168.86.201:8000 ] unreachable — preflight short-circuit (no models available)

---

Gate semantics (pilot phase)

Verdict	Meaning	Blocks merge?
passed	No critical findings	No
blocked	CRITICAL findings found	Yes
degraded	All models unavailable (infra)	No (pilot)

Powered by omniintelligence.review_pairing.cli_review — multi-model adversarial review (OMN-8468/OMN-8524)