Define executable mixed-backend mapping and time contracts

[Brad-Edwards]

Mixed execution records bridge and time references without executing their obligations. A backend success boolean can also create unsupported delivery and observation records.

Acceptance criteria

• Define executable action/subject mappings, operation ownership, bridge invocation, time-domain coordination, ordering, readback, and handoff for the supported mixed and staged arrangements.
• Specify capability admission, declared losses, and contextual refusal. Require evidence for supported mapping and timing obligations; metadata and timestamps alone are insufficient.
• Distinguish request acceptance, backend execution, delivery, and participant observation. Define partial/unknown outcomes and stale or failed handoffs using the shared operation lifecycle.
• Publish the accepted decision, SEM-234/API-407 and ADR-102 amendments where needed, compatibility rules, and executable examples. Retain shared time semantics without imposing one clock or physical-OT timing guarantees.

References: Diagnosis, Mixed runtime dispatch.

Requirements

• SEM-234 — Mixed Cross-Backend Participant-Control Composition
• API-407 — Participant Feature Support And Constraint Declaration

[Brad-Edwards]

🛠️ Picked up by /implement - driver codex, branch 1355-mixed-backend-time-contracts, 2026-09-24T01:09:37.621Z.

[Brad-Edwards]

gc workflow phase recorded: preflight (issue #1355). Posted by the MCP server to enforce ordering between workflow steps (issue #794 MVP-2). Do not edit or delete — used by downstream tools to gate phase prerequisites.

[Brad-Edwards]

gc workflow phase recorded: preflight (issue #1355). Posted by the MCP server to enforce ordering between workflow steps (issue #794 MVP-2). Do not edit or delete — used by downstream tools to gate phase prerequisites.

[Brad-Edwards]

gc workflow phase recorded: preflight (issue #1355). Posted by the MCP server to enforce ordering between workflow steps (issue #794 MVP-2). Do not edit or delete — used by downstream tools to gate phase prerequisites.

[Brad-Edwards]

gc workflow phase recorded: plan (issue #1355). Posted by the MCP server to enforce ordering between workflow steps (issue #794 MVP-2). Do not edit or delete — used by downstream tools to gate phase prerequisites.

Issue #1355 implementation plan

Decision and scope. Keep the published sem-234/rev1 composition profile as sealed, backend-neutral intent. Add a trusted executable edge binding at MixedRuntimeBinding/the selected RuntimeTarget, keyed by the admitted edge and exact source/destination subjects, bridge identity, time mapping, loss and evidence obligations. The binding invokes the selected destination through an admitted bridge and obtains correlated time, backend, delivery and observation readback. A reference, timestamp, callable method or backend success flag alone proves none of those stages. Pure and historical reference-only carriers remain readable; unsupported mixed edges refuse before external effect. Do not add a schema field or reinterpret old v1 history. Record this compatibility rule in ADR-102 and the reference explanation. No published schema change is planned, so the schema publication ledger and generator should remain identical.

Clause paths and coverage.

• SEM-234(1) alternative/simultaneous modes and (5) linked trials/finite stages — Path A: preserve existing admitted mode and identity, add executable positive/negative witnesses for pure, simultaneous and staged paths; transition/handoff evidence must precede switching provider.
• SEM-234(2) stable refs/backend-neutral SDL and (3) edge authority/mapping/time/loss/evidence — Path A: bind exact compiled action/subject and edge refs to trusted mapping, bridge, time/order service and readback; reject missing, ambiguous, incompatible or stale bindings before invocation.
• SEM-234(4) separate controller, authority, owner, routing and disclosure — Path A: reuse RUN-310/API-423 authorization and final sinks; bridge/native owner cannot confer action or observation authority.
• SEM-234(6) open/closed loop, world and membership axes — Path A: retain admitted phase/profile axes and refuse effects not admitted by the active phase; no implicit backend fallback.
• SEM-234(7) missing/stale/unsupported/contradictory authority, capability, clock/order or evidence — Path A: contextual fail-closed checks and typed correlated proof; explicit declared weakening only where policy allows.
• API-407 participant support declaration — Path A: join provider-local effective feature support and installed bridge/time/readback capability; preserve constraints, downgrade and evidence rather than pooling manifests or inferring support from method presence.
• Issue acceptance on stage outcomes — Path B: first write a regression test showing backend success=True currently fabricates delivery and observation, then emit execution, delivery and observation only from their distinct correlated evidence; map partial/unknown work to the shared INDETERMINATE lifecycle where cessation is unproved.
• Issue acceptance on handoff — Path A: add stale/failed/pending handoff cases; retain the prior phase and owner unless the admitted transition's responsibility handoff is evidenced and committed.
• Issue publication — Path D within this source-bearing change: amend SEM-234/API-407 and ADR-102, publish the accepted bounded decision, compatibility limits and runnable control-plane examples. The source-bearing diff uses TDD; no documentation-only carve-out.

Implementation sequence. (1) Add failing targeted cases in implementations/python/tests/test_issue_1355_mixed_mapping_time.py and update #1016 witnesses where the old unsupported claims are asserted. (2) Introduce a small typed trusted edge execution contract in raes_runtime/mixed_runtime.py and validation/dispatch in mixed_runtime_dispatch.py; reuse participant_crossing_boundary.py, backend_calls.py, time_coordinator.py/TimeRuntime, Diagnostic, OperationState and store CAS. (3) Commit stage-specific facts and terminal state through the existing operation and composition histories; never retry a committed external effect on replay. (4) Strengthen mixed_runtime_phase.py evaluation and quiescence for responsibility changes. (5) Update requirements traceability and publish the decision and examples in docs/decisions/adrs/adr-102-mixed-cross-backend-participant-control.md, specs/formal/participant-semantics/cross-backend-participant-control.md and docs/explain/reference/mixed-participant-composition.md.

Repository-wide design check. Security: closed profile/plan parsing and exact context joins, component manifest/registry validation, authenticated target and participant/controller subjects, RUN-310/API-423 policy/final sinks, secret/env validators, redacted diagnostics and store path/lease rules remain the gates; no request field, environment value, URL or subprocess selects a bridge. Maintainability: extend the incumbent runtime binding, shared time state/readback, operation lifecycle, backend result validation and one control-plane store; add no policy, clock or persistence engine. Extensibility: another conforming bridge is supplied through the admitted-edge binding with pinned identity, mapping, time service and bounds, without changing portable SDL or dispatch policy. Whole-repo surfaces: specs/, docs/, raes_contracts, raes_backend_protocols, raes_runtime, component stubs, targeted tests, policy and documentation coverage checks. The change adds no host/OS execution authority, no physical-OT timing guarantee and no claim of federation interoperability or backend equivalence.

Verification. Set RAES_REQUIREMENT_UID=SEM-234 (or API-407 for its focused check) because the issue branch has no UID. Run only the changed pytest module/cases plus the relevant #1016/#1200, shared-time and operation-lifecycle cases needed for observed risks. Run relevant generated-schema parity/policy checks if their inputs change. Preserve the mandatory pre-publish hook, review, CI, SonarCloud and readiness gates; full, integration, fuzz and completion suites run in CI/CD. Use a Conventional Commit PR title (feat: or fix:) for the consumer-visible behavior.

[Brad-Edwards]

gc_codex_review — sanitized deferred publication for issue #1355, cycle 1 of 1
Reviewed revision: 733f5599b31d0ae7d74a3d496d0ad694a41143185114edb35a6dd3fcc8f86478

Architectural read

The trusted mixed edge and handoff bindings retain control-plane operation ownership. The action path needs three repairs before delivery: preserve execution evidence across later readback failure, keep declared loss separate from unexecuted results, and authorize a translated destination action before effect.

Verdict: don't-ship

Findings

core-F1 — Retain validated execution evidence when later readback fails

• Classification: one-off
• Decision: fix
• Location: implementations/python/packages/raes_runtime/mixed_runtime_edge_execution.py:92
• Rationale: Preserve validated execution separately from confirmed delivery and observation, with a regression for failed later readback.

core-F2 — Do not attach mapping loss to an unexecuted result

• Classification: one-off
• Decision: fix
• Location: implementations/python/packages/raes_runtime/mixed_runtime_result.py:44
• Rationale: Record declared loss on the attempt; add it to result facts only after correlated execution, with a pre-effect refusal regression.

security-F1 — Authorize the translated action before calling the destination provider

• Classification: one-off
• Decision: fix
• Location: implementations/python/packages/raes_runtime/mixed_runtime_edge_execution.py:49
• Rationale: Require the destination action to be admitted to the selected provider and policy cut before invocation, with an unauthorized translation regression.

[Brad-Edwards]

gc_codex_review pre-push cycle 1 of 1 complete for issue #1355 on branch '1355-mixed-backend-time-contracts'. Posted by the MCP server to enforce the pre-push hard-cap-1 contract (issues #796, #804, #906). Do not edit or delete — used by the next gc_codex_review (uncommitted) invocation to count cycles.

[Brad-Edwards]

Review decision record — codex cycle 1 (issue #1355)

Reviewer: codex
Cycle: 1
Verdict: don't-ship

Architectural read:

The trusted mixed edge and handoff bindings retain control-plane operation ownership. The action path needs three repairs before delivery: preserve execution evidence across later readback failure, keep declared loss separate from unexecuted results, and authorize a translated destination action before effect.

Blocking findings: 3

Finding 1 — one-off

• ID: core-F1
• Title: Retain validated execution evidence when later readback fails
• Location: implementations/python/packages/raes_runtime/mixed_runtime_edge_execution.py:92
• Decision: fix
• Rationale: Preserve validated execution separately from confirmed delivery and observation, with a regression for failed later readback.

Finding 2 — one-off

• ID: core-F2
• Title: Do not attach mapping loss to an unexecuted result
• Location: implementations/python/packages/raes_runtime/mixed_runtime_result.py:44
• Decision: fix
• Rationale: Record declared loss on the attempt; add it to result facts only after correlated execution, with a pre-effect refusal regression.

Finding 3 — one-off

• ID: security-F1
• Title: Authorize the translated action before calling the destination provider
• Location: implementations/python/packages/raes_runtime/mixed_runtime_edge_execution.py:49
• Decision: fix
• Rationale: Require the destination action to be admitted to the selected provider and policy cut before invocation, with an unauthorized translation regression.

[Brad-Edwards]

gc_codex_review — sanitized deferred publication for issue #1355, cycle 2 of 1
Reviewed revision: 17bd3318c48c34b0f46b30aa86948ef9a61923984172060e56c480b6329ff8bc

Architectural read

The mixed runtime bindings preserve control-plane ownership, but recovery must retain uncertainty across external bridge and handoff stages. Handoff time evidence must join the operation snapshot, and mapper or bridge callbacks must not mutate the governed request before provider effect.

Verdict: don't-ship

Findings

core-F1 — Reconcile mixed external stages before releasing a running claim

• Classification: class
• Decision: fix
• Location: implementations/python/packages/raes_runtime/mixed_runtime_phase.py:206
• Rationale: Persist or recover unresolved mixed external stages under the owning operation and keep uncertain effects indeterminate, with restart regressions.

core-F2 — Bind handoff time readback to the operation snapshot

• Classification: one-off
• Decision: fix
• Location: implementations/python/packages/raes_runtime/mixed_runtime_phase.py:194
• Rationale: Require pre-transfer and post-transfer time states to match the operation snapshot cut, with stale-cut regression coverage.

security-F1 — Mutable request aliases let callbacks change the authorized action

• Classification: class
• Decision: fix
• Location: implementations/python/packages/raes_runtime/mixed_runtime_edge_execution.py:49
• Rationale: Keep an independent governed request copy or commitment and revalidate full request value immediately before provider invocation, with mapper and bridge mutation regressions.

[Brad-Edwards]

gc_codex_review pre-push cycle 2 of 1 complete for issue #1355 on branch '1355-mixed-backend-time-contracts'. Posted by the MCP server to enforce the pre-push hard-cap-1 contract (issues #796, #804, #906). Do not edit or delete — used by the next gc_codex_review (uncommitted) invocation to count cycles.