Let a deployment name its one real Conduit, so the verdict log can populate

[xmap]

Closes the gap the last PR (#757) documented but didn't fix: CORA's authorization decisions were not in the record CORA claims is the artifact.

The gap

TrustAuthorize._emit_verdict writes one Verdict row per decision, but only when the target Conduit exists and has an open verdict logbook. On 2-BM: zero Conduit streams exist, and all ~180 handler call sites pass conduit_id=NIL_SENTINEL_ID, so every write is silently skipped. warn_if_verdict_log_dormant exists solely to say this out loud at boot.

This was a deliberate, named deferral. Watch item 6 of project_authorization_envelope_design.md states the fix precisely: "conduit injection + a seeded verdict logbook, NOT just flipping trust_policy_id", trigger "a compliance/ops need for one queryable cross-layer log." The JSR paper's D5 exhibit is that need.

The choice: resolve, don't sweep

Two ways to close this. Thread conduit_id through the ~180 call sites the way surface_id was swept — a real parameter change for a value that's identical everywhere until multi-zone topology exists, which project_conduit_injection_design.md's WI10 defers on purpose. Or resolve the deployment's one configured Conduit once, in the adapter.

The second is not a shortcut around honesty; it's what the sentinel is for. NIL_SENTINEL_ID is documented as meaning "unspecified," never "none" — so resolving it to a configured default is a default for the unspecified case, not a fabrication. A caller that passes a real, non-nil conduit_id of its own is never overridden. The precedent is exact: get_surface_id is itself a static return that ignores the request.

What ships

A forward-only migration seeds SYSTEM_LOCAL_ZONE_ID / SYSTEM_LOCAL_CONDUIT_ID with an open verdict logbook, named deployment-neutrally ("System Local," not "2-BM") since it ships to every deployment. LogbookSchema matches _TRAVERSALS_SCHEMA byte-for-byte, so a hand-seeded Conduit's logbook declaration is indistinguishable from one opened through the API.

Settings.trust_conduit_id resolves the unspecified case in TrustAuthorize._effective_conduit_id, called exactly once per authorize() call so the same resolved value feeds both the Policy evaluation and the Verdict write:

authorize(conduit_id=nil) ──► _effective_conduit_id ──► ONE resolved value
                                                              │
                                          ┌───────────────────┴───────────────────┐
                                          ▼                                       ▼
                                  decide_authorization                    _emit_verdict
                                  (what was evaluated)                 (what gets written)

The row can never describe a conduit the command wasn't actually evaluated against.

Three boot guards, because this codebase keeps re-learning that asking for a control and silently not getting one is the failure that matters:

• trust_conduit_id set with no trust_policy_id → AllowAllAuthorize is never constructed with a conduit_id, so the setting would be read by nothing.
• trust_conduit_id set but the Conduit is missing or has no open verdict logbook → looks wired, populates nothing.
• trust_conduit_id and trust_policy_id both set but the policy governs a different conduit → Policy.evaluate checks conduit before surface or principal, so this would deny every command, not narrow what's permitted. This is what makes leaving 2-BM's nil-bound policies unmigrated safe rather than an oversight.

warn_if_verdict_log_dormant now checks the effective conduit instead of hardcoding nil, so a correctly-adopting deployment gets no false alarm and a misconfigured one still gets a true one.

What's deliberately not here

• The ~180-call-site sweep (deferred to WI10, same as the design doc).
• A V3 bootstrap policy (guard 3 makes it unnecessary).
• 2-BM's own migration to the real conduit — separate, deliberate step, so the shadow period already accumulating there isn't interrupted by another restart. The runbook records the capability exists and 2-BM hasn't adopted it yet.
• The in-process SurfaceKind work (agent-raised commands are still ungovernable) — next PR.

Verification

Unit + architecture: 49,100 passed. Contract: 3,436 passed. Full integration tier: 1,364 passed, including a new test file that applies the migration against a real Postgres testcontainer (not just unit-level folding) and confirms the Zone/Conduit fold correctly with an open logbook, plus a case driving TrustAuthorize end-to-end through the configured conduit with the caller passing nil. Both boot guards and the conduit-resolution logic are mutation-verified in both directions. Default is unset for every new setting, so every existing deployment and ~2400 AllowAll-based tests are unaffected.

🤖 Generated with Claude Code

[github-actions]

Coverage report

Click to see where and how coverage changed

File	Statements	Missing	Coverage	Coverage (new stmts)	Lines missing
apps/api/src/cora/api
main.py
apps/api/src/cora/infrastructure
config.py
routing.py
schema_version.py
apps/api/src/cora/trust
__init__.py
_bootstrap.py
authorize.py
build_authorize.py
Project Total

This report was generated by python-coverage-comment-action