Repository navigation
Admit mixed and staged participant trial realizations #1015
Description
Parent: #813
Bounded outcome
Extend deterministic trial compilation and admission to pin multiple apparatus
components, stable allocation scopes, composition topology, cross-clock and
policy mappings, and finite phase schedules under SEM-234. Preserve
backend-neutral SDL, immutable plan/run identity, schedule-independent bytes,
and fail-closed admission.
Negative cases
- Runtime or scheduler selection of an undeclared backend or allocation.
- Partial plan sealing, silent fallback, resampling, or dropped components.
- Phase membership that is not finite and admitted before execution.
- Apparatus, capability, authority, clock, or policy drift after sealing.
- Inter-trial realization changes that reuse a run identity.
Evidence required
- Red-green compiler/admission tests for pure, mixed, and staged entries.
- Worker/schedule permutation determinism and digest integrity.
- Rejection evidence for unresolved scopes, incompatible apparatus, cycles,
missing mappings, and exceeded bounds. - Trial/run lineage and cleanup/isolation evidence.
Explicit nonclaims
- No live mixed-runtime execution or backend realization.
- No scheduler authority over semantic selection.
- No exact replay, equivalence, or transfer claim.
Dependencies
- Parent design: Design cross-backend participant control against simulation and cyber-range precedents #813.
- Depends on Publish portable mixed-composition contracts #1014.
Requirements
- SEM-234
- SCE-002
- API-407
Activity
Brad-Edwards commentedon Sep 18, 2026
🛠️ Picked up by /implement - driver codex, branch
1015-admit-mixed-staged-trials, 2026-09-18T06:35:33.670Z.Brad-Edwards commentedon Sep 18, 2026
gc workflow phase recorded:
preflight(issue #1015). 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 commentedon Sep 18, 2026
gc workflow phase recorded:
preflight(issue #1015). 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 commentedon Sep 18, 2026
gc workflow phase recorded:
preflight(issue #1015). 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 commentedon Sep 18, 2026
gc workflow phase recorded:
plan(issue #1015). 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.Implementation plan
All issue clauses are Path A (new feature) except the architecture/documentation and traceability updates, which are Path D and ride with the executable tests. The existing pure compiler path remains byte-for-byte compatible.
Extend the existing admitted-plan contract, not its lifecycle.
AdmittedApparatusBindingModel, carrying an exact digest-pinned profile reference and an optional exact immediate-source plan/entry/run tuple.AdmittedTrialPlanInputRefsModelwith the exact mixed-profile input set while omitting the empty field from legacy serialization, and add governed composition-aware compiler/entry/run identity-profile literals.AdmittedTrialPlanModel, entry sealing, cleanup, isolation, JCS digests, and ingress as the only plan lifecycle. Update the hand-governed admitted-plan schema, generated bundle parity, fixtures, and schema-publication hash/change summary together.Add explicit, total coordinate-to-realization admission to the incumbent compiler.
TrialCompilationRequestwith immutable maps for coordinate assignments, sealed mixed profiles, contextual resolution inputs, exact per-component envelopes, and optional already-sealed source plans.Reuse and tighten the Publish portable mixed-composition contracts #1014 contextual gate.
validate_mixed_composition_context().MixedCompositionResolutionContextonly for missing trusted relationships: canonical allocation-to-semantic-effect coverage and all-phase cleanup/isolation resource coverage. Reject cross-kind overlapping active providers, unresolved targets, missing mappings, cycles, bounds, authority/policy/clock/evidence drift, or omitted later-phase resources.trial-compiler.*diagnostics that do not expose raw resolver/Pydantic/backend content.Keep phase schedules sealed and runtime behavior fail closed.
plan_batch_schedule()continues to schedule whole entries only.realize_admitted_trial_entry()explicitly reject mixed-bound entries before backend selection until Coordinate mixed participant runtimes fail-closed #1016 supplies coordination; add no live dispatch, phase state, persistence, endpoint, or scheduler authority.Verify, publish, and reconcile authority.
verify_all.pychecks through the workflow gates; do not editCHANGELOG.md, add a changelog fragment, or hand-edit the product version.Requirement and acceptance coverage
Whole-repository design checks
Brad-Edwards commentedon Sep 18, 2026
gc_codex_review — cycle 1 of 1 (pre-push) on issue #1015 (branch
1015-admit-mixed-staged-trials)Diff mode: inline — the complete diff was supplied in one prompt
Core review
Verdict:
don't-shipThe change chooses the correct top-level seam: mixed realization remains inside the admitted-plan lifecycle, uses governed identity profiles, reuses contextual composition validation, and rejects unsupported runtime realization before backend selection. However, the implementation is not yet production-shaped because replacing the apparatus carrier drops participant-manifest authority, recursive profiles do not receive the complete admission gate, and failure selection is order-dependent. These are boundary-contract defects in the core admission path, not localized polish.
Blocking findings (3):
implementations/python/packages/raes_contracts/contracts/admitted_trial_plan_components.py:231The mixed binding contains only the profile and optional source tuple, while the incumbent digest-pinned participant-manifest references remain on AdmittedApparatusBindingModel. The compiler then emits the mixed binding instead of request.apparatus, copies participant manifest payloads without calling validate_selected_participant_manifests, and excludes the apparatus from mixed plan intent. Consequently, participant references or payloads can be stale—or change without changing the sealed plan identity when no binding descriptor happens to consume them. This contradicts the declared separate AdmittedParticipantManifestReferenceModel join. Preserve those references in a shared entry-level carrier or the mixed binding, validate each exact payload/digest, and include them in the identity projection.
implementations/python/packages/raes_contracts/contracts/mixed_composition_resolution.py:378The contextual visitor recursively walks nested profiles, but require_trial_admission applies projection/effect/resource checks only once to the root after traversal. The processor similarly validates concrete apparatus and cleanup resources only for profile.components on the root, while the aggregate-work calculation counts only request.mixed_profiles and not reachable nested payloads. A nested profile can therefore bypass concrete manifest/envelope admission, projection membership, overlap detection, all-phase resource coverage, and its own per-profile limits while its parent is admitted. Apply reconstruction, profile limits, trial-specific context checks, concrete apparatus/resource admission, and aggregate accounting to every reachable profile in the bounded traversal.
implementations/python/packages/raes_processor/trial_compiler/compiler.py:366Pre-entry apparatus admission fails fast while iterating mixed_profiles in caller insertion order, and validate_composition_components likewise iterates component mappings without canonical ordering. Because these sites can raise different diagnostics—such as missing manifest, envelope mismatch, or compatibility rejection—reversing logically equivalent maps can change the single emitted failure. The new permutation test covers only successful compilation, so it does not pin the required failure stability. Sort these traversals and canonically select failures, as _compile_entries already does.
Security review
Verdict:
don't-shipThe change uses the right overall seam: mixed realization remains a closed admitted-entry variant, identities are domain-separated, and unsupported runtime realization fails closed. However, the implementation does not preserve the same exact-authority boundary throughout admission: raw manifest collections can authorize bindings, one concrete apparatus can masquerade as multiple providers, and trial-specific validation stops at the root of a nested profile graph. Those are structural authorization gaps in the newly sealed intent, so this should not ship yet.
Blocking findings (3):
implementations/python/packages/raes_processor/trial_compiler/compiler.py:363Attacker model: a caller may supply mixed-compilation artifacts but may not authorize arbitrary apparatus or participant configuration targets. The mixed branch copies the complete caller-owned apparatus_manifests and participant_manifests maps and passes them to _admitted_descriptors(), whose target resolver treats every map entry as selected authority. Unlike the legacy branch, these maps are not reduced through validate_selected_apparatus() and validate_selected_participant_manifests(). A caller can therefore add an otherwise valid but unreferenced manifest with a configuration registry, target it from an experiment binding descriptor, and have that descriptor sealed into every matching entry even though the manifest is neither selected by the composition profile nor digest-pinned by the mixed entry. This turns possession of an arbitrary manifest payload into configuration-binding authority. Construct the resolver maps exclusively from the exact validated component set, and resolve participant manifests through digest-pinned references carried by the sealed mixed authority.
implementations/python/packages/raes_processor/trial_compiler/apparatus.py:383A profile author possessing one allowed backend manifest can reference that same manifest and envelope from multiple component IDs while assigning each a distinct apparatus_identity_ref and realization_form. This loop validates each reference but silently overwrites duplicate manifest keys rather than rejecting them, then returns the manifest once per component. The composition-mode check only observes the declared realization_form strings, so one backend can be admitted as multiple supposedly distinct simulation/emulation providers and receive authority allocations intended to be separated between providers. The new positive-test builder reinforces the bypass by assigning the same manifest and envelope to every component. Reject duplicate concrete manifest bindings across components and require each component's governed apparatus identity to resolve uniquely to its concrete manifest/envelope authority.
implementations/python/packages/raes_contracts/contracts/mixed_composition_resolution.py:378The recursive _ContextValidator.visit() applies the baseline contextual checks to nested profiles, but require_trial_admission invokes _validate_trial_admission_context() only once for the root. Consequently, a digest-referenced child profile is never checked for component projection membership, cross-provider semantic-effect overlap, or all-phase resource coverage. A malicious nested composition can therefore introduce providers outside their admitted envelope projection, overlapping authority, or resources omitted from cleanup/isolation while the root plan is still sealed. Apply the trial-admission checks to every profile reached by the bounded recursive traversal, not only the root.
Brad-Edwards commentedon Sep 18, 2026
gc_codex_review pre-push cycle 1 of 1 complete for issue #1015 on branch '1015-admit-mixed-staged-trials'. 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 commentedon Sep 18, 2026
Review decision record — codex cycle 1 (issue #1015)
Reviewer: codex
Cycle: 1
Architectural read:
Blocking findings: 6
Finding 1 —
class(5 instances)F1implementations/python/packages/raes_contracts/contracts/admitted_trial_plan_components.py:231implementations/python/packages/raes_contracts/contracts/admitted_trial_plan_components.py:231contracts/schemas/plans/admitted-trial-plan-v1.json:140implementations/python/packages/raes_processor/trial_compiler/compiler.py:266implementations/python/packages/raes_processor/trial_compiler/compiler.py:364implementations/python/packages/raes_processor/trial_compiler/inputs.py:287Finding 2 —
class(6 instances)F2implementations/python/packages/raes_contracts/contracts/mixed_composition_resolution.py:378implementations/python/packages/raes_contracts/contracts/mixed_composition_resolution.py:375implementations/python/packages/raes_contracts/contracts/mixed_composition_resolution.py:378implementations/python/packages/raes_processor/trial_compiler/inputs.py:206implementations/python/packages/raes_processor/trial_compiler/compiler.py:366implementations/python/packages/raes_processor/trial_compiler/realization_admission.py:173implementations/python/packages/raes_processor/trial_compiler/realization_admission.py:185Finding 3 —
class(2 instances)F3implementations/python/packages/raes_processor/trial_compiler/compiler.py:366implementations/python/packages/raes_processor/trial_compiler/compiler.py:366implementations/python/packages/raes_processor/trial_compiler/apparatus.py:359Finding 4 —
class(2 instances)F4implementations/python/packages/raes_processor/trial_compiler/compiler.py:363implementations/python/packages/raes_processor/trial_compiler/compiler.py:363implementations/python/packages/raes_processor/trial_compiler/compiler.py:364Finding 5 —
one-offF5implementations/python/packages/raes_processor/trial_compiler/apparatus.py:383Finding 6 —
one-offF6implementations/python/packages/raes_contracts/contracts/mixed_composition_resolution.py:378Brad-Edwards commentedon Sep 18, 2026
gc_codex_review — cycle 2 of 1 (pre-push) on issue #1015 (branch
1015-admit-mixed-staged-trials)Diff mode: inline — the complete diff was supplied in one prompt
Core review
Verdict:
don't-shipThe change chooses the right high-level seam: it extends the incumbent admitted-plan union, reuses contextual composition validation and domain-separated identities, and explicitly rejects mixed entries at the unsupported runtime boundary. However, the implementation weakens per-coordinate apparatus authority into a plan-wide union, changes legacy v1 serialization under the existing identity profile, and over-constrains valid manifest reuse. Those are structural contract errors that also foreclose the obvious next variation—multiple realization profiles using the same governed implementation manifest—so this is not production-ready.
Blocking findings (5):
implementations/python/packages/raes_processor/trial_compiler/compiler.py:364For mixed plans,
authority.apparatus_manifestsis the union of every root profile and is passed once to_admitted_descriptors. A descriptor targeting a manifest present only in profile B can therefore be admitted and later sealed into an entry assigned profile A;_entry_bindingsfilters by selection and condition but never rechecks the assigned profile's component authority. Mixed descriptor admission must use the exact profile closure selected for that coordinate, not another entry's manifests.implementations/python/packages/raes_contracts/contracts/admitted_trial_plan_components.py:217participant_manifest_refswas already a defaulted field onAdmittedApparatusBindingModel; this new serializer now removes it when empty. Bothplan_intent()and the entry/plan sealing helpers use ordinarymodel_dump(mode="json"), so pure legacy requests now produce different plan identities, entry digests, plan digests, and serialized bytes while still declaringtrial-compiler-v1. Preserve the established v1 projection or introduce a governed profile/version change and compatibility vectors.implementations/python/packages/raes_processor/trial_compiler/apparatus.py:361A manifest identifies a governed processor/backend implementation, while component and apparatus identities identify its use in a composition. Rejecting solely because the same
ApparatusManifestKeyappears twice prevents distinct component instances from using the same implementation and, through the second occurrence, prevents independent root profiles from sharing it. The latter is especially common for alternative profiles across coordinates. Enforce profile-local component/apparatus identity uniqueness and exact payload equality; do not require globally unique implementation manifests.implementations/python/packages/raes_contracts/contracts/admitted_trial_plan.py:279The validator checks mixed entry/run profiles only when
compiler_profileis mixed. A plan containing only legacy apparatus entries can therefore usetrial-compiler-v1together with either mixed entry or run identity profile and still pass this join validation. Validate the complete governed profile tuple in both directions so externally supplied plans cannot claim identity derivations that do not match their compiler branch.implementations/python/packages/raes_processor/trial_compiler/realization_admission.py:254The source map is looked up by
source_ref.plan_id, but the validated payload'sadmitted.plan_idis never compared with that value. A caller can place a valid sealed plan under an alias key and produce a target whose identity-bearing source tuple names a nonexistent or different plan while its digest, entry, and run checks pass. Includeadmitted.plan_id == source_ref.plan_idin the exact tuple validation.Security review
Verdict:
shipThis change is shaped correctly: mixed and staged realization extends the existing admitted-plan/compiler seam through a closed binding union, digest-pinned profiles, bounded trusted-context validation, and domain-separated identities. Manifest, envelope, participant-authority, source-plan, cleanup, and semantic-effect joins remain explicit, while the existing single-backend realization path rejects mixed entries before backend selection. The coordinate-to-realization seam supports future governed profile revisions without introducing dynamic loading, host-path access, or a parallel execution lifecycle. I found no concrete exploitable security issue in the supplied diff.
No blocking findings.
Brad-Edwards commentedon Sep 18, 2026
gc_codex_review pre-push cycle 2 (USER-AUTHORIZED OVERRIDE past cap 1) complete for issue #1015 on branch '1015-admit-mixed-staged-trials'. 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.Override reason: user said: "overcap authroized"
Brad-Edwards commentedon Sep 18, 2026
Review decision record — codex cycle 2 (issue #1015)
Reviewer: codex
Cycle: 2
Architectural read:
Blocking findings: 5
Finding 1 —
one-offF1implementations/python/packages/raes_processor/trial_compiler/compiler.py:364authority.apparatus_manifestsis the union of every root profile and is passed once to_admitted_descriptors. A descriptor targeting a manifest present only in profile B can therefore be admitted and later sealed into …Finding 2 —
one-offF2implementations/python/packages/raes_contracts/contracts/admitted_trial_plan_components.py:217participant_manifest_refswas already a defaulted field onAdmittedApparatusBindingModel; this new serializer now removes it when empty. Bothplan_intent()and the entry/plan sealing helpers use ordinarymodel_dump(mode="json"), so…Finding 3 —
class(2 instances)F3implementations/python/packages/raes_processor/trial_compiler/apparatus.py:361ApparatusManifestKeyappears twice prevents distinct compone…implementations/python/packages/raes_processor/trial_compiler/apparatus.py:361implementations/python/packages/raes_processor/trial_compiler/realization_admission.py:211Finding 4 —
one-offF4implementations/python/packages/raes_contracts/contracts/admitted_trial_plan.py:279compiler_profileis mixed. A plan containing only legacy apparatus entries can therefore usetrial-compiler-v1together with either mixed entry or run identity profile and still p…Finding 5 —
one-offF5implementations/python/packages/raes_processor/trial_compiler/realization_admission.py:254source_ref.plan_id, but the validated payload'sadmitted.plan_idis never compared with that value. A caller can place a valid sealed plan under an alias key and produce a target whose identity-bearing so…Brad-Edwards commentedon Sep 18, 2026
gc_codex_review — cycle 3 of 1 (pre-push) on issue #1015 (branch
1015-admit-mixed-staged-trials)Diff mode: manifest — the complete diff exceeded one prompt and was reviewed as 2/2 inline slice(s) (file-slices) covering 41/41 file(s)
Core review
Verdict:
shipSlice 1/2: This is shaped correctly: mixed realization extends the existing admitted-plan entry seam as a closed binding variant, preserves the legacy apparatus path and identity domain, and keeps compilation, contextual validation, apparatus admission, cleanup/isolation, and runtime realization at their established boundaries. The new realization-assignment projection is identity-bearing and canonicalized, while the single-backend runtime explicitly rejects the unsupported mixed branch; that leaves the obvious next variation—runtime coordination—at the intended downstream seam rather than smuggling it into admission.
Slice 2/2: This slice updates the formal-validation release gate coherently: 33.0.0 is already the selected current release and baseline successor, and the retest snapshot validator now applies the same shape and retained-fixture rules to it. The policy ownership additions keep the mixed-participant-composition seam explicit across its contracts, compiler, evidence, and tests without introducing a competing mechanism. This is shaped correctly.
No blocking findings.
Security review
Verdict:
shipSlice 1/2: This change extends the existing sealed trial-plan seam with a closed mixed-composition realization branch, keeping identity derivation, plan validation, apparatus admission, cleanup/isolation checks, and the single-backend runtime boundary aligned. The new trusted-context admission layer is the appropriate cross-cutting seam: it validates profile closure, manifest/envelope authority, component-local constraints, resources, and lineage before sealing, while runtime explicitly rejects unsupported mixed execution. I found no concrete exploitable security regression in this slice.
Slice 2/2: This slice consistently extends the formal-evidence release allowlist to revision 33.0.0 and maps the new mixed/staged admission surfaces into the existing requirement-ownership policy. The seam remains the validation/policy boundary: release selection still compares the exact expected artifact set, while the ownership file only declares allowed paths. I found no concrete, exploitable security issue introduced by these changes.
No blocking findings.
Brad-Edwards commentedon Sep 18, 2026
gc_codex_review pre-push cycle 3 (USER-AUTHORIZED OVERRIDE past cap 1) complete for issue #1015 on branch '1015-admit-mixed-staged-trials'. 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.Override reason: user said: "overcap authorized"
Brad-Edwards commentedon Sep 18, 2026
Review decision record — codex cycle 3 (issue #1015)
Reviewer: codex
Cycle: 3
Architectural read:
Blocking findings: 0 (clean run)
Brad-Edwards commentedon Sep 18, 2026
Pre-PR base synchronization
refs/remotes/origin/devatc745080657e4dcdbb14f7bd243a394a1d7ac16bfmerged_clean983f402f2fadd28b8ed8f2545f62f522196735ef046385e10f2385225659f587cc3a6461ae7c0d20Brad-Edwards commentedon Sep 18, 2026
Pre-PR base synchronization
refs/remotes/origin/devatc745080657e4dcdbb14f7bd243a394a1d7ac16bfalready_currentbacd83cf689e79166668ed86e5368901e794b677eb77506493cb3cdaaee11bd16f731d32c6d11fb9Brad-Edwards commentedon Sep 18, 2026
Pre-PR base synchronization
refs/remotes/origin/devatc745080657e4dcdbb14f7bd243a394a1d7ac16bfalready_currente176428da0508e270305ec7410691994e42350e14152bc330ef5f367790200b34a10619d016f4a5fBrad-Edwards commentedon Sep 18, 2026
Pre-PR base synchronization
refs/remotes/origin/devatc745080657e4dcdbb14f7bd243a394a1d7ac16bfalready_current91e2b38a047b6f5378271c361c572ebbb4ed8a8e5134a9b8ed2b2ea82d9f994fc4e6914270dd20eeBrad-Edwards commentedon Sep 18, 2026
Ready for review — issue #1015
PR: #1322
Plan: #1015 (comment)
Outcome
Trial compilation now admits mixed participant compositions across backend boundaries, including staged realizations linked to sealed source trials. Exact manifests, identities, cleanup resources, and deterministic plan sealing remain enforced.
Implemented mixed and staged trial realization admission, exact per-coordinate authority binding, source-plan validation, deterministic identity profiles, schema/publication updates, evidence releases, and focused regression coverage. CI is green and SonarCloud reports quality gate OK with zero issues and zero hotspots.
In-scope requirements
Proposed state in this PR — authoritative only after merge.
SEM-234(Mixed Cross-Backend Participant-Control Composition) — ACTIVE (proposed)SCE-002(Scenario Composition, Parameterization, and Randomization) — ACTIVE (proposed)API-407(Participant Feature Support And Constraint Declaration) — ACTIVE (proposed)Files changed
Added:
contracts/fixtures/plans/trial-compiler-mixed-composition-v1/identity-vectors.jsondocs/decisions/issue-1015-mixed-staged-trial-admission-preflight.mddocs/research/formal-semantic-validation/analysis-v32.jsondocs/research/formal-semantic-validation/bundles/retest-v32.jsondocs/research/formal-semantic-validation/execution-snapshot-v32.jsondocs/research/specification-coverage/analysis-v32.jsondocs/research/specification-coverage/bundles/raes-standardized-specification-coverage-issue-1015-v32.jsondocs/research/specification-coverage/execution-snapshot-v32.jsonimplementations/python/packages/raes_contracts/contracts/_mixed_composition_exports.pyimplementations/python/packages/raes_processor/trial_compiler/realization_admission.pyimplementations/python/tests/test_issue_1015_mixed_staged_trial_admission.pyModified:
contracts/schema-publication/entries/admitted-trial-plan-v1.jsoncontracts/schemas/plans/admitted-trial-plan-v1.jsondocs/explain/reference/scenario-variation-and-trial-realization.mddocs/requirements/API-407/requirement.mddocs/requirements/SCE-002/requirement.mddocs/requirements/SEM-234/requirement.mddocs/research/formal-semantic-validation/index.mddocs/research/specification-coverage/index.mdimplementations/python/packages/raes_contracts/contracts/__init__.pyimplementations/python/packages/raes_contracts/contracts/_exports.pyimplementations/python/packages/raes_contracts/contracts/admitted_trial_plan.pyimplementations/python/packages/raes_contracts/contracts/admitted_trial_plan_components.pyimplementations/python/packages/raes_contracts/contracts/mixed_composition_resolution.pyimplementations/python/packages/raes_contracts/contracts/trial_compilation.pyimplementations/python/packages/raes_processor/trial_compiler/__init__.pyimplementations/python/packages/raes_processor/trial_compiler/apparatus.pyimplementations/python/packages/raes_processor/trial_compiler/compiler.pyimplementations/python/packages/raes_processor/trial_compiler/inputs.pyimplementations/python/packages/raes_processor/trial_compiler/models.pyimplementations/python/packages/raes_processor/trial_compiler/profiles.pyimplementations/python/packages/raes_processor/trial_realization.pyimplementations/python/tests/test_formal_semantic_validation.pyimplementations/python/tests/test_issue_1014_mixed_composition_contracts.pyimplementations/python/tests/test_issue_989_versioned_evidence.pyimplementations/python/tests/test_specification_coverage.pyimplementations/python/uv.lockimplementations/tooling/python/smoke/linux-arm64-cp314.txtimplementations/tooling/python/smoke/linux-arm64-cp314.wheelhouse-manifest.jsonimplementations/tooling/python/smoke/linux-x86_64-cp311.txtimplementations/tooling/python/smoke/linux-x86_64-cp311.wheelhouse-manifest.jsonimplementations/tooling/python/smoke/linux-x86_64-cp312.txtimplementations/tooling/python/smoke/linux-x86_64-cp312.wheelhouse-manifest.jsonimplementations/tooling/python/smoke/linux-x86_64-cp313.txtimplementations/tooling/python/smoke/linux-x86_64-cp313.wheelhouse-manifest.jsonimplementations/tooling/python/smoke/linux-x86_64-cp314.txtimplementations/tooling/python/smoke/linux-x86_64-cp314.wheelhouse-manifest.jsonimplementations/tooling/python/smoke/macos-arm64-cp314.txtimplementations/tooling/python/smoke/macos-arm64-cp314.wheelhouse-manifest.jsontools/check_specification_coverage.pytools/formal_semantic_validation/_baseline.pytools/formal_semantic_validation/_loading.pytools/formal_semantic_validation/_releases.pytools/formal_semantic_validation/_retest.pytools/policy/requirement_order.yamlReviews
Traceability reconciliation
Status
Brad-Edwards commentedon Sep 18, 2026
Final report — issue #1015 complete
PR: #1322
Plan: #1015 (comment)
Outcome
Trial compilation now admits mixed participant compositions across backend boundaries, including staged realizations linked to sealed source trials. Exact manifests, identities, cleanup resources, and deterministic plan sealing remain enforced.
Implemented mixed and staged trial realization admission, exact per-coordinate authority binding, source-plan validation, deterministic identity profiles, schema/publication updates, evidence releases, focused regression coverage, an AnyIO security update, and regenerated Python closure projections.
In-scope requirements
Verified at merge revision
fe3b31860e2a.SEM-234(Mixed Cross-Backend Participant-Control Composition) — ACTIVESCE-002(Scenario Composition, Parameterization, and Randomization) — ACTIVEAPI-407(Participant Feature Support And Constraint Declaration) — ACTIVEFiles changed
Added:
contracts/fixtures/plans/trial-compiler-mixed-composition-v1/identity-vectors.jsondocs/decisions/issue-1015-mixed-staged-trial-admission-preflight.mddocs/research/formal-semantic-validation/analysis-v32.jsondocs/research/formal-semantic-validation/bundles/retest-v32.jsondocs/research/formal-semantic-validation/execution-snapshot-v32.jsondocs/research/specification-coverage/analysis-v32.jsondocs/research/specification-coverage/bundles/raes-standardized-specification-coverage-issue-1015-v32.jsondocs/research/specification-coverage/execution-snapshot-v32.jsonimplementations/python/packages/raes_contracts/contracts/_mixed_composition_exports.pyimplementations/python/packages/raes_processor/trial_compiler/realization_admission.pyimplementations/python/tests/test_issue_1015_mixed_staged_trial_admission.pyModified:
contracts/schema-publication/entries/admitted-trial-plan-v1.jsoncontracts/schemas/plans/admitted-trial-plan-v1.jsondocs/explain/reference/scenario-variation-and-trial-realization.mddocs/requirements/API-407/requirement.mddocs/requirements/SCE-002/requirement.mddocs/requirements/SEM-234/requirement.mddocs/research/formal-semantic-validation/index.mddocs/research/specification-coverage/index.mdimplementations/python/packages/raes_contracts/contracts/__init__.pyimplementations/python/packages/raes_contracts/contracts/_exports.pyimplementations/python/packages/raes_contracts/contracts/admitted_trial_plan.pyimplementations/python/packages/raes_contracts/contracts/admitted_trial_plan_components.pyimplementations/python/packages/raes_contracts/contracts/mixed_composition_resolution.pyimplementations/python/packages/raes_contracts/contracts/trial_compilation.pyimplementations/python/packages/raes_processor/trial_compiler/__init__.pyimplementations/python/packages/raes_processor/trial_compiler/apparatus.pyimplementations/python/packages/raes_processor/trial_compiler/compiler.pyimplementations/python/packages/raes_processor/trial_compiler/inputs.pyimplementations/python/packages/raes_processor/trial_compiler/models.pyimplementations/python/packages/raes_processor/trial_compiler/profiles.pyimplementations/python/packages/raes_processor/trial_realization.pyimplementations/python/tests/test_formal_semantic_validation.pyimplementations/python/tests/test_issue_1014_mixed_composition_contracts.pyimplementations/python/tests/test_issue_989_versioned_evidence.pyimplementations/python/tests/test_specification_coverage.pyimplementations/python/uv.lockimplementations/tooling/python/smoke/linux-arm64-cp314.txtimplementations/tooling/python/smoke/linux-arm64-cp314.wheelhouse-manifest.jsonimplementations/tooling/python/smoke/linux-x86_64-cp311.txtimplementations/tooling/python/smoke/linux-x86_64-cp311.wheelhouse-manifest.jsonimplementations/tooling/python/smoke/linux-x86_64-cp312.txtimplementations/tooling/python/smoke/linux-x86_64-cp312.wheelhouse-manifest.jsonimplementations/tooling/python/smoke/linux-x86_64-cp313.txtimplementations/tooling/python/smoke/linux-x86_64-cp313.wheelhouse-manifest.jsonimplementations/tooling/python/smoke/linux-x86_64-cp314.txtimplementations/tooling/python/smoke/linux-x86_64-cp314.wheelhouse-manifest.jsonimplementations/tooling/python/smoke/macos-arm64-cp314.txtimplementations/tooling/python/smoke/macos-arm64-cp314.wheelhouse-manifest.jsontools/check_specification_coverage.pytools/formal_semantic_validation/_baseline.pytools/formal_semantic_validation/_loading.pytools/formal_semantic_validation/_releases.pytools/formal_semantic_validation/_retest.pytools/policy/requirement_order.yamlReviews
Traceability reconciliation
All three in-scope requirements are ACTIVE with IMPLEMENTS and TESTS links reconciled in the merged delivery diff.
Status