[jonahgabriel]

What

On the deployed bus path, every escalation attempt's backend_id was routing_decision_id, uuid5(NAMESPACE_DNS, "omninode.ai/backends/{model_id}"). Two backends serving the same model id (local-coder/local-heavy-reasoning on .201, local-omnipc2-chat on .202, all serving Qwen3.8-27B) therefore all recorded the identical hash, and no bus-path receipt could say which host actually answered. The routing decision already carries the backend key as selected_backend_ref (OMN-14402); it was dropped between the decision and the terminal.

• ModelDelegationEscalationAttempt gains backend_ref, stamped from workflow.routing_decision.selected_backend_ref at both record helpers (_record_escalation_attempt and the winning-rung append), so every rung in escalation_history names its backend.
• handler_delegate_skill.py::_attempt_records maps a bus-path attempt's backend_id from backend_ref first, falling back to the old backend_id/routing_decision_id fields for a terminal produced by a runtime that predates this change. The CLI receipt's backend_id is the accepted attempt's backend_id, so it now names the backend key, matching the in-process path. Never an endpoint URL (preserves OMN-17013).

Why this also matters for OMN-19124/OMN-19765

This is also why onex delegate --backend-id cloud-glm --bus kafka --lane dev --locus deployed-lane exits 1 as a false pin violation even when the pin is honoured on the deployed lane (comments on OMN-19234, 2026-09-26/27): _backend_pin_defect in omnibase_infra's cli_delegate.py compares the requested slug against the accepted attempt's backend_id, which on the bus path was this uuid5 hash. Once this lands, the bus-path attempt's backend_id carries the real backend key and the existing comparison in omnibase_infra needs no change.

Separate, unrelated-but-adjacent PRs: omnibase_infra#4170 (OMN-19124, the deployed-lane consumer admission guard, unmerged, needs=train) and omnibase_infra#4173 (OMN-19765, the BYOK-substitution case, unmerged). Neither is touched here.

AC coverage (OMN-19234)

• AC1: the routing decision already carries the selected backend key as its own field distinct from the model-id hash (ModelRoutingDecision.selected_backend_ref); covered here by a new test proving two backends serving one model id differ in selected_backend_ref while sharing selected_backend_id.
• AC2 (in-repo half): the bus-path attempt/terminal now names the backend key; TestTheTerminalAttemptNamesTheBackend proves two hosts serving one model id produce two different receipt identities, and a terminal predating this change still maps via the old fallback.
• AC3: test_the_backend_key_is_never_an_endpoint_url asserts the mapped backend_id is never a URL (no ://), preserving OMN-17013.

Test plan

• New test file: tests/unit/delegation/test_backend_identity_on_bus_receipt_omn19234.py -- RED-proven against origin/dev (checked out the 3 pre-fix source files locally, 6 of 8 cases failed with the exact hash-collision symptom, restored, GREEN 8/8 with the fix).
• Focused regression run, no regressions: test_bus_path_provider_identity_omn17013.py, test_omn19004_the_deciding_rung_sets_the_cause.py, test_local_accept_ends_chain_omn16932.py, test_escalation_metered_cost_reaches_projection_omn13535.py (69 passed), test_handler.py under node_delegate_skill_orchestrator (35 passed), and the OMN-19765 substituted-backend tests (5 passed, no interaction with the new field).
• ruff format --check / ruff check clean on all touched files.
• mypy --strict clean on all touched source files.
• Lab proof on the .201 dev lane: pending a concurrent lane's HOLD on the 201-dev-runtime surface clearing (in force until 12:45Z as of this PR); will be appended to this PR and the ledger once run.

OMN-XXXX

Cites OMN-19234 (dod_evidence: this PR plus the lab proof once appended).

[x] Title contains OMN-XXXX
[x] Body cites OMN-XXXX ticket
[x] uv run ruff format and ruff check --fix (touched files)
[x] Focused local tests for changed behavior
[ ] pre-commit run --all-files (pre-push hooks ran clean on push; full --all-files not run, focused scope only)

Evidence-Ticket: OMN-19234
Evidence-Source: OCC#11629

[github-actions]

⚠️ Architectural Review — WARNINGS

Errors: 0
Warnings: 1

What this checks

Rule	Description
ARCH-TOPIC-001	No hardcoded Kafka topic strings in handler code
ARCH-DI-001	No event_bus=None bypass
ARCH-DI-002	No direct Handler instantiation outside workflow_runner/adapters
ARCH-DI-003	No reinvented DI containers
ARCH-TOPIC-002	contract.yaml topics follow `onex.{cmd

---

ARCH-DI-002: Direct Handler instantiation (warning)\n\n```\nsrc/omnimarket/nodes/node_delegation_orchestrator/handlers/handler_delegation_workflow.py:1279: loop = HandlerComplianceLoop()

src/omnimarket/nodes/node_delegation_orchestrator/handlers/handler_delegation_workflow.py:2143: HandlerEscalationDecision()\n```\n\nHandler classes should be wired only in workflow_runner.py or adapter modules. Direct instantiation elsewhere bypasses the contract system.\n\n

Static architectural lint — no model inference (OMN-14176).

[github-actions]

✅ Hostile Reviewer — PASSED

Blocking findings (critical/error): 0
Total findings: 13
Models succeeded: qwen3-review,gpt-oss-review

---

Gate semantics

Verdict	Meaning	Blocks merge?
passed	>=2 models succeeded, no critical/error findings	No
blocked	CRITICAL or ERROR findings found	Yes
degraded	Fewer than 2 models succeeded (infra unavailable/timeout)	Yes (OMN-15110)

Powered by omniintelligence.review_pairing.cli_review — node-based adversarial review via HandlerLlmCliSubprocess (OMN-8524)

[jonahgabriel]

Lab proof, .201 dev lane (rule 24, sanctioned hotpatch, HOLD/RELEASE on ledger:10916/10971)

Hotpatched this PR's head (f905220969, 3 files) into omninode-runtime and omninode-runtime-effects, alongside a read-only reuse of the already-open omnibase_infra#4170 (OMN-19124, 2 files) so the deployed-lane admission gate honours a cloud-glm pin at all. Single-container restarts, no --cold, no rebuild.

Pinned proof -- onex delegate --backend-id cloud-glm --bus kafka --lane dev --locus deployed-lane "...", run twice:

run_id	correlation_id	exit	provider	model	attempts[0].backend_id	escalation_count	receipt backend_pin_honoured
3282e836-7d03-497f-88ec-5e85844ce5c2	390da9ac-3776-4538-8e93-62d2392e1b5a	0	glm	glm-5.3-flash	cloud-glm	0	true
b9fa4149-f18b-429b-98dc-5e50bc02e41f	29704a39-0d70-4ddb-91d5-963d12fff9fe	0	glm	glm-5.3-flash	cloud-glm	0	true

receipt.json for both: {"backend_id": "cloud-glm", "backend_pin_honoured": true, "backend_selection": "pinned", "requested_backend_id": "cloud-glm"} -- the exact false-pin-violation symptom from the OMN-19234 comments (attempt backend_id = a uuid5 hash) is gone; the attempt now names the backend key.

Unpinned control (no regression) -- run ca0dae99-66a7-4258-8ed9-98eb480d5aa2: completed on local-heavy-reasoning, backend_selection: "cheapest_first", backend_pin_honoured: null (no pin requested), as expected.

Restore: all 5 hotpatched files sha256-verified equal to origin/dev on both containers after the run (ae47a2ce... handler_delegation_workflow.py, cbe99275... handler_delegate_skill.py, 4359cead... model_delegation_escalation_attempt.py, d45c5c6a... dogfood_delegation_fault_routes.py, ed5bc64a... service_delegation_dispatch_port.py); both containers healthy (/health 200) with RestartCount: 0 throughout -- no crash loop. An unrelated automated deploy-agent rebuild (triggered by the 12:00Z OMN-19677/OMN-18773 dev merges) recreated all dev-lane containers mid-hotpatch; the hotpatch was reapplied cleanly once that settled.

Ledger: HOLD docs/tracking/ROLLING_WORK_LEDGER.md:10916, RELEASE docs/tracking/ROLLING_WORK_LEDGER.md:10971.