Publish portable mixed-composition contracts

Parent: #813

Bounded outcome

Publish closed portable contracts for SEM-234 composition profiles,
allocation entries, topology edges, admitted phase schedules, cross-clock
mappings, mapping loss, and realization evidence bindings. Reuse the admitted
trial plan, apparatus, participant-control, crossing, time, and associated
artifact families. Update schema publication, fixtures, generators, and
compatibility records together.

Negative cases

HLA FOM/handle fields or backend-local commands on universal carriers.
Open metadata maps, duplicate apparatus identities, or a second trial/run
identity.
Multiple canonical values for authority, order, loss, or phase membership.
A schema-valid composition whose referenced manifests, scopes, mappings, or
policy cuts do not resolve.

Evidence required

Red-green model and contextual-validator tests.
Positive and negative fixtures for alternative, simultaneous mixed, and
staged profiles.
Generated-schema parity and publication-manifest change records.
Round-trip, reference-resolution, and unknown-revision failures.

Explicit nonclaims

Schema presence does not establish runtime or backend realization.
Contract validity does not establish interoperability, transfer, IFC, or
behavioral equivalence.

Dependencies

Parent design: Design cross-backend participant control against simulation and cyber-range precedents #813.
Depends on Define mixed cross-backend participant-control semantics #1013.

Requirements

SEM-234
SCE-002
API-407
API-423

🛠️ Picked up by /implement - driver codex, branch 1014-mixed-composition-contracts, 2026-09-17T22:00:31.799Z.

gc workflow phase recorded: preflight (issue #1014). 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.

gc workflow phase recorded: plan (issue #1014). 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

Scope and TDD paths

All executable clauses use Path A (new feature) with a red-green-refactor cycle in implementations/python/tests/test_issue_1014_mixed_composition_contracts.py; the documentation update is part of the same executable diff and does not use the documentation-only carve-out.

SEM-234(1): model distinct alternative, simultaneous-mixed, and staged profiles; alternatives remain separate sealed roots and simultaneous mode requires distinct active realization forms.
SEM-234(2): allocate stable compiled participant, controlled-scope, action-family, observation-source, and crossing targets to admitted components without adding backend choice to SDL.
SEM-234(3): require each directed edge to bind component identities, authority, API-423 subject/policy coordinates, time mapping and governed order, mapping loss, failure disposition, and evidence obligations.
SEM-234(4): keep participant identity, controller, action authority, realization provider, native ownership, routing, and disclosure authority as independent fields and joins.
SEM-234(5): publish only a finite pre-admitted phase schedule; carry no trial/run identity or mutable phase state, and express alternative changes as distinct profile digests.
SEM-234(6): keep control-loop posture, world assumption, and federation membership as independent closed coordinates.
SEM-234(7): fail closed on missing, stale, unsupported, contradictory, unmapped, cyclic, or resource-exhausting references; explicit authorized weakening requires policy and provenance refs.
SCE-002: reuse CompiledAddress and incumbent selection/plan identities; composition validation neither selects scenario variants nor consumes random draws.
API-407: contextual validation invokes resolve_participant_feature_support() per component/phase requirement, never unions declarations across providers, and validates downgrade policy/provenance.
API-423: edges reference incumbent crossing subjects and policy cuts while occurrences, decisions, transformations, disclosure, delivery, and evidence remain owned by API-423.
Issue negatives/evidence: reject backend-local/HLA carriers, open maps, duplicate apparatus identity, duplicate trial identity, contradictory canonical values, unresolved joins, unknown revisions, and bounded-traversal exhaustion; add positive/negative fixtures for all three profile modes plus round-trip, reference-resolution, and generated-schema parity evidence.
Nonclaims: schema/model success is structural only; conformance reports semantic context required and makes no runtime, interoperability, transfer, IFC, or equivalence claim.

Implementation

Add raes_contracts.contracts.mixed_composition with the sealed root, closed component/allocation/edge/mapping/loss/evidence/phase records, canonical digest helpers, bounded JSON ingress, root-local graph checks, and a pure trusted-context validator. Reuse existing base types, canonicalization, addresses, manifest/envelope refs, feature support, crossing refs, time declarations, and evidence identities.
Register mixed-participant-composition-profile-v1 in versions, schema_bundle(), explicit schema-generator routing, and conformance validation as structural-context-required. No backend supported-contract claim changes.
Publish the generated schema under contracts/schemas/plans/, positive and negative fixtures under contracts/fixtures/plans/, and a schema-publication entry with its initial content hash and last_change record. Keep generated schema byte-for-byte equal to the reference model.
Resolve repository governance with an exact issue-bound scope for SEM-234, SCE-002, API-407, and API-423; move the two participant API requirements into the existing mixed-composition phase, assign every delivery path narrowly, and preserve all prerequisite and ownership checks.
Update docs/explain/reference/mixed-participant-composition.md with the published carrier, validation stages, trust boundary, and explicit nonclaims. Reconcile requirement IMPLEMENTS/TESTS traceability to the new schema/model/validator/tests/fixtures before publish.

Repository-wide design checks

Security: bounded duplicate-rejecting object ingress precedes model construction; explicit byte/depth/node/work limits protect graph traversal; no fetches, subprocesses, host paths, environment/secret values, backend commands, raw payload logging, or resolver exception leakage; diagnostics remain bounded and value-independent.
Maintainability: build on ContractModel, parse_bounded_json_object(), canonical_json_digest(), CompiledAddress, incumbent manifest/envelope/crossing/time/evidence types, the existing bundle/generator/publication pipeline, and the current conformance runner. Add no parallel loader, registry, exception family, store, or CI workflow.
Extensibility: the explicit profile revision and typed referenced subprofiles are the seam for another backend, mapping kind, or evidence owner; trusted resolver indexes and caller-supplied limits vary without adding backend-name conditionals or open metadata.
Whole-repo view: update the contract package, versions/bundle, conformance registry, generator routing, checked-in schema, publication ledger, fixtures, issue-scope authority, requirement ownership/traceability, and reference documentation together. Admission-plan binding, runtime coordination, and backend realization remain separate contracts owned by issues 1015–1017.

Verification

Observe focused tests fail before production implementation, then pass after each contract/validator slice.
Run targeted model, contextual-validator, fixture, conformance, generator-parity, and governance tests.
The mandatory publish/CI gates run tools/check_repo_policy.py, tools/check_requirement_governance.py, tools/verify_all.py, generated-schema parity, schema publication, pre-commit, both pre-push reviews, CI, and SonarCloud with RAES_REQUIREMENT_UID=SEM-234 resolved through the issue scope.

gc_codex_review — cycle 1 of 1 (pre-push) on issue #1014 (branch 1014-mixed-composition-contracts)
Diff mode: inline — the complete diff was supplied in one prompt

Core review

Verdict: don't-ship

The change chooses the right overall seam: one closed, digest-sealed composition root reuses incumbent address, manifest, crossing, time, capability, ingress, publication, and conformance vocabulary, while separating root-local graph checks from trusted contextual resolution. However, the contextual boundary is not complete enough to uphold the contract it advertises, and its capability join introduces a reverse package dependency forbidden by the repository's module policy. Those are structural defects in the admission seam, not polish issues.

Blocking findings (2):

[class] Context validation leaves admitted external coordinates unresolved — implementations/python/packages/raes_contracts/contracts/mixed_composition.py:669
The validator states that it resolves all external profile authority, but several admitted coordinates are never represented in MixedCompositionResolutionContext or consulted during validation: apparatus and participant identities, evidence obligation refs, mapping-loss basis/affected/limitation refs, crossing scope and audience, and transition trigger/evaluator refs. The joins that do exist are also partial: manifest and envelope lookup is keyed by component_id and compares only digest tuples, so a different manifest ref_id/subject or envelope_id can pass; nested refs compare only the child digest and never require child.profile_id == child_id. A caller can therefore alter one of these coordinates, reseal the root, supply the unchanged trusted context, and receive successful contextual/conformance validation. SEM-234 requires complete edge/trigger/reference resolution and revision/digest-matched authority, so admission must fail unless every coordinate and its required cross-agreement is resolved.
[one-off] Contract layer imports its downstream backend-protocol layer — implementations/python/packages/raes_contracts/contracts/mixed_composition.py:565
raes_backend_protocols already depends on raes_contracts, while the binding ADR-036 module policy permits raes_contracts to import only raes. Importing the backend capability resolver here reverses that dependency and creates a package cycle; placing the import inside the function does not change the architectural edge. Keep the contract validator dependency-inverted—for example, accept a trusted capability-resolution result or callback—and let a higher owning layer invoke the incumbent backend-protocol resolver.

Security review

Verdict: don't-ship

The change is shaped around the correct seam: a closed, digest-sealed portable profile, bounded structural parsing, and a separate trusted-context validator registered as structural-context-required. That separation preserves incumbent scenario, manifest, policy, time, and evidence owners and leaves room for nested profiles. The contextual seam is incomplete, however: it reports semantic validity without resolving several security-bearing identities and authorization relationships that the profile introduces.

Blocking findings (2):

[class] Context validation accepts unresolved authorization and evidence coordinates — implementations/python/packages/raes_contracts/contracts/mixed_composition.py:699
Attacker model: an untrusted profile author whose sealed profile is evaluated against trusted repository indexes. The validator can return success after checking selected digests and set membership while never resolving the component's apparatus/manifest/envelope identity relationship, allocation participant identity, edge crossing scope and audience, evidence obligation, mapping-loss authorities, or transition trigger/evaluator. For example, an attacker can replace audience_scope_ref or participant_identity_ref while retaining an otherwise trusted crossing policy, controller, and disclosure-authority reference; neither changed value is represented in MixedCompositionResolutionContext, so conformance returns no diagnostic. An admission caller relying on this semantic-valid result can consequently seal a graph that launders authority into another participant/audience or claims evidence for an unrelated obligation. Staged profiles similarly admit untrusted trigger/evaluator names. Add trusted, relationship-aware indexes for these coordinates and require exact joins—including manifest/apparatus/envelope identity, participant/controller/scope/audience-policy agreement, obligation-to-evidence satisfaction, accepted mapping loss, and trigger/evaluator ownership—before returning success.
[one-off] Any known authority references can authorize a feature downgrade — implementations/python/packages/raes_contracts/contracts/mixed_composition.py:571
A profile author can lower an exact feature requirement to a weaker supported level by placing any two unrelated entries from the generic authority_refs set into downgrade_policy_ref and downgrade_provenance_ref. These lines check only membership; resolve_participant_feature_support() subsequently checks that the strings are present and that the backend declares the selected weaker level, but does not establish that the referenced policy authorized this provider, feature, required level, or downgrade. This turns unrelated action or edge authority into downgrade permission and can admit a backend lacking the required participant security guarantee. Supply a trusted structured downgrade authorization keyed by provider, feature, required/allowed levels, policy, and provenance, then compare the complete tuple instead of consulting the generic authority set.

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

Reviewer: codex
Cycle: 1

Architectural read:

Core reviewer: The change chooses the right overall seam: one closed, digest-sealed composition root reuses incumbent address, manifest, crossing, time, capability, ingress, publication, and conformance vocabulary, while separating root-local graph checks from trusted contextual resolution. However, the contextual boundary is not complete enough to uphold the contract it advertises, and its capability join introduces a reverse package dependency forbidden by the repository's module policy. Those are structural defects in the admission seam, not polish issues.

Security reviewer: The change is shaped around the correct seam: a closed, digest-sealed portable profile, bounded structural parsing, and a separate trusted-context validator registered as structural-context-required. That separation preserves incumbent scenario, manifest, policy, time, and evidence owners and leaves room for nested profiles. The contextual seam is incomplete, however: it reports semantic validity without resolving several security-bearing identities and authorization relationships that the profile introduces.

Blocking findings: 4

Finding 1 — `class` (14 instances)

ID: F1
Title: [core] Context validation leaves admitted external coordinates unresolved
Location: implementations/python/packages/raes_contracts/contracts/mixed_composition.py:669
Decision: fix
Rationale: The validator states that it resolves all external profile authority, but several admitted coordinates are never represented in MixedCompositionResolutionContext or consulted during validation: apparatus and participant identities, evidenc…
Instances:
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:669
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:117
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:138
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:155
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:175
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:176
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:177
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:192
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:194
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:245
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:246
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:540
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:543
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:700

Finding 2 — `one-off`

ID: F2
Title: [core] Contract layer imports its downstream backend-protocol layer
Location: implementations/python/packages/raes_contracts/contracts/mixed_composition.py:565
Decision: fix
Rationale: raes_backend_protocols already depends on raes_contracts, while the binding ADR-036 module policy permits raes_contracts to import only raes. Importing the backend capability resolver here reverses that dependency and creates a package cyc…

Finding 3 — `class` (13 instances)

ID: F3
Title: [security] Context validation accepts unresolved authorization and evidence coordinates
Location: implementations/python/packages/raes_contracts/contracts/mixed_composition.py:699
Decision: fix
Rationale: Attacker model: an untrusted profile author whose sealed profile is evaluated against trusted repository indexes. The validator can return success after checking selected digests and set membership while never resolving the component's app…
Instances:
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:117
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:119
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:120
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:138
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:155
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:175
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:176
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:177
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:192
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:194
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:245
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:246
- implementations/python/packages/raes_contracts/contracts/mixed_composition.py:699

Finding 4 — `one-off`

ID: F4
Title: [security] Any known authority references can authorize a feature downgrade
Location: implementations/python/packages/raes_contracts/contracts/mixed_composition.py:571
Decision: fix
Rationale: A profile author can lower an exact feature requirement to a weaker supported level by placing any two unrelated entries from the generic authority_refs set into downgrade_policy_ref and downgrade_provenance_ref. These lines check …

gc_test_quality_review cycle 1 of 1 — issue #1014

Reviewer: test-quality (claude-sonnet-5 via gc_test_quality_review)
Branch: 1014-mixed-composition-contracts
Cycle: 1 / 1
Findings: 0 (clean run)

gc_test_quality_review cycle 1 of 1 complete for issue #1014 on branch '1014-mixed-composition-contracts'. Posted by the MCP server to enforce the gc_test_quality_review hard-cap-1 contract (issue #884 follow-up, default lowered in #906). Do not edit or delete — used by the next gc_test_quality_review invocation to count cycles.

Review decision record — test-quality cycle 1 (issue #1014)

Reviewer: test-quality
Cycle: 1

Architectural read:

This is a closed, sealed contract root (MixedParticipantCompositionProfileModel) plus a separate trusted-context resolver (validate_mixed_composition_context) that performs the "confused deputy" defense — rejecting a self-consistent but re-sealed/attacker-controlled profile whose field values don't match a caller-supplied trusted index. That's the actual security-relevant surface in this diff, and the test suite attacks it correctly: test_context_rejects_resealed_profiles_with_untrusted_external_coordinates parametrizes 23 distinct field-level tamper cases (component identity, allocation authority refs, edge crossing/policy/time/mapping/failure fields, evidence obligation refs) and asserts each one is rejected by validate_mixed_composition_context, using real dataclasses built from a genuinely different "trusted" profile rather than mocks. The feature-support/downgrade-authorization path calls the real resolve_participant_feature_support from raes_backend_protocols rather than stubbing it, so a regression in that real comparison logic would surface as a spurious pass/fail here. Fixture-backed structural tests (mode violations, duplicate identity, unknown schema revision, open/extra metadata) were spot-checked against their JSON bodies and each one perturbs exactly the field the corresponding validator branch checks — nothing is gamed to make a broken implementation look green. The governance test file is a duplicate-source-of-truth consistency check (JSON bindings vs. YAML ownership vs. a hardcoded literal in the test) rather than a behavioral test; it's outside the security-enforcement rubric and is fine as documentation-drift insurance. Overall this is exactly the shape a principal engineer would want for a trust-boundary contract: adversarial re-sealing tests at the seam, real dependency calls instead of mocks, and fixtures that were verified (not merely asserted) to trip the specific rule they're named for.

Blocking findings: 0 (clean run)

Pre-PR base synchronization

Source: refs/remotes/origin/dev at 015ad168f139c48f100b75dd7c85a5b6aaab46b6
Outcome: merged_clean
Published feature head: 05178452ac8d1a0b56e0d1347cc85d1f63aeffcb
Synchronized tree: 3e00268a4e3a3f02d32bd6f9c59af0fefac54966

Pre-PR base synchronization

Source: refs/remotes/origin/dev at 015ad168f139c48f100b75dd7c85a5b6aaab46b6
Outcome: already_current
Published feature head: 7159f5445ebfee54f8ffa796c6074352ac3ceb68
Synchronized tree: 802ae4ec6f1fb99bd8b6da9a96cb5f7aebd1b0b3

Pre-PR base synchronization

Source: refs/remotes/origin/dev at 015ad168f139c48f100b75dd7c85a5b6aaab46b6
Outcome: already_current
Published feature head: 79752c8c1bb4f38fed5e9b1ad3199436a2644f90
Synchronized tree: 610309f55ae0676a904edc5e68670ed24f4235ca

Pre-PR base synchronization

Source: refs/remotes/origin/dev at 3c7d64a0eff5ebb964c7cff1c13351db43baf8b0
Outcome: merged_clean
Published feature head: bfb838af5e79cb886e388fdba4d036ef09606d75
Synchronized tree: ba9df3d407531c093ff6f770e02d8084fd0d176c

Pre-PR base synchronization

Source: refs/remotes/origin/dev at 3c7d64a0eff5ebb964c7cff1c13351db43baf8b0
Outcome: already_current
Published feature head: abc17383aa80d2a8cae5b1671fec64c583f7b8ad
Synchronized tree: 07bbde90636ef73ab83decc98ed83cf73d2165de

Ready for review — issue #1014

PR: #1315
Plan: #1014 (comment)

Outcome

RAES now publishes a portable, digest-sealed mixed-participant composition profile for alternative, simultaneous mixed, and staged realizations. Trusted contextual admission resolves exact scenario, provider, crossing, time, evidence, feature-support, downgrade, and nested-profile relationships without introducing runtime mutation or backend coupling.

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)
API-423 (Participant Crossing Policy And Evidence Contracts) — ACTIVE (proposed)

Files changed

Added:

contracts/fixtures/plans/mixed-participant-composition-profile-v1/invalid/alternative-fallback-pool.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/invalid/duplicate-apparatus-identity.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/invalid/open-metadata.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/invalid/simultaneous-single-form.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/invalid/staged-unadmitted-member.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/invalid/unknown-revision.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/valid/alternative.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/valid/simultaneous-mixed.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/valid/staged.json
contracts/schema-publication/entries/mixed-participant-composition-profile-v1.json
contracts/schemas/plans/mixed-participant-composition-profile-v1.json
docs/decisions/issue-1014-mixed-composition-contracts-preflight.md
docs/governance/requirement-scopes/1014.json
implementations/python/packages/raes_contracts/contracts/mixed_composition.py
implementations/python/packages/raes_contracts/contracts/mixed_composition_resolution.py
implementations/python/packages/raes_contracts/contracts/mixed_composition_validation.py
implementations/python/tests/test_issue_1014_mixed_composition_contracts.py
implementations/python/tests/test_issue_1014_mixed_composition_governance.py

Modified:

docs/explain/reference/mixed-participant-composition.md
docs/requirements/API-407/requirement.md
docs/requirements/API-423/requirement.md
docs/requirements/SCE-002/requirement.md
docs/requirements/SEM-234/requirement.md
docs/research/formal-semantic-validation/bundles/retest-v30.json
docs/research/formal-semantic-validation/execution-snapshot-v30.json
docs/research/specification-coverage/analysis-v30.json
docs/research/specification-coverage/bundles/raes-standardized-specification-coverage-issue-1179-v30.json
docs/research/specification-coverage/execution-snapshot-v30.json
implementations/python/packages/raes_conformance/conformance/validators.py
implementations/python/packages/raes_contracts/contracts/__init__.py
implementations/python/packages/raes_contracts/contracts/_exports.py
implementations/python/packages/raes_contracts/contracts/bundle.py
implementations/python/packages/raes_contracts/json_ingress.py
implementations/python/packages/raes_contracts/versions.py
tools/generate_contract_schemas.py
tools/policy/requirement_order.yaml

Reviews

codex: One capped review cycle found four blocking issues; exact trusted-context joins, dependency inversion, security-reference resolution, and downgrade authorization were fixed. The user authorized advancing without an over-cap review.
test-quality: Test-quality review completed cleanly with no findings; focused contract/governance coverage, mutation-style rejection cases, evidence replay, and the full hosted matrix pass.

Traceability reconciliation

Pending — requirement status transition and IMPLEMENTS/TESTS reconciliation run in Phase E once the PR merges.

Status

CI: ✅ green
SonarCloud: ✅ passed
PR ready for user review and merge. Ground Control reconciliation (requirement status + traceability) runs on merge (Phase E).

Pre-PR base synchronization

Source: refs/remotes/origin/dev at ad15124667b10c510301da5eaeeaaf1c52cb13d5
Outcome: merged_conflicts_resolved
Published feature head: eb5756894b11a1301d0521832cc41898659436dd
Synchronized tree: 507cc5ce405040627e3ef93815bf7d80e6f2fcea

Pre-PR base synchronization

Source: refs/remotes/origin/dev at ad15124667b10c510301da5eaeeaaf1c52cb13d5
Outcome: already_current
Published feature head: 195132d740acd4a63dd0e9fd366545e26e18d693
Synchronized tree: 1174ee018ac7c3e43740c3b3b38d1719536f98af

Final report — issue #1014 complete

PR: #1315
Plan: #1014 (comment)

Outcome

RAES now publishes a portable, digest-sealed mixed-participant composition profile for alternative, simultaneous mixed, and staged realizations. Trusted contextual admission verifies exact scenario, provider, crossing, time, evidence, feature-support, downgrade, and nested-profile relationships without runtime mutation or backend coupling.

In-scope requirements

Verified at merge revision 803257b2d9d3.

SEM-234 (Mixed Cross-Backend Participant-Control Composition) — ACTIVE
SCE-002 (Scenario Composition, Parameterization, and Randomization) — ACTIVE
API-407 (Participant Feature Support And Constraint Declaration) — ACTIVE
API-423 (Participant Crossing Policy And Evidence Contracts) — ACTIVE

Files changed

Added:

contracts/fixtures/plans/mixed-participant-composition-profile-v1/invalid/alternative-fallback-pool.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/invalid/duplicate-apparatus-identity.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/invalid/open-metadata.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/invalid/simultaneous-single-form.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/invalid/staged-unadmitted-member.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/invalid/unknown-revision.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/valid/alternative.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/valid/simultaneous-mixed.json
contracts/fixtures/plans/mixed-participant-composition-profile-v1/valid/staged.json
contracts/schema-publication/entries/mixed-participant-composition-profile-v1.json
contracts/schemas/plans/mixed-participant-composition-profile-v1.json
docs/decisions/issue-1014-mixed-composition-contracts-preflight.md
docs/governance/requirement-scopes/1014.json
implementations/python/packages/raes_contracts/contracts/mixed_composition.py
implementations/python/packages/raes_contracts/contracts/mixed_composition_resolution.py
implementations/python/packages/raes_contracts/contracts/mixed_composition_validation.py
implementations/python/tests/test_issue_1014_mixed_composition_contracts.py
implementations/python/tests/test_issue_1014_mixed_composition_governance.py

Modified:

docs/explain/reference/mixed-participant-composition.md
docs/requirements/API-407/requirement.md
docs/requirements/API-423/requirement.md
docs/requirements/SCE-002/requirement.md
docs/requirements/SEM-234/requirement.md
docs/research/formal-semantic-validation/bundles/retest-v31.json
docs/research/formal-semantic-validation/execution-snapshot-v31.json
docs/research/specification-coverage/analysis-v31.json
docs/research/specification-coverage/bundles/raes-standardized-specification-coverage-issue-1183-v31.json
docs/research/specification-coverage/execution-snapshot-v31.json
implementations/python/packages/raes_conformance/conformance/validators.py
implementations/python/packages/raes_contracts/contracts/__init__.py
implementations/python/packages/raes_contracts/contracts/_exports.py
implementations/python/packages/raes_contracts/contracts/bundle.py
implementations/python/packages/raes_contracts/json_ingress.py
implementations/python/packages/raes_contracts/versions.py
tools/generate_contract_schemas.py
tools/policy/requirement_order.yaml

Reviews

codex: One capped review cycle found four blocking trusted-context and dependency-boundary issues; each was fixed and verified before the clean readiness record.
test-quality: The capped test-quality review completed cleanly with zero findings; it confirmed adversarial trusted-context coverage and fixture-backed rejection behavior.

Traceability reconciliation

IMPLEMENTS / TESTS / DOCUMENTS added: 4
Links updated: 4
Stale links removed: 0

Requirement lifecycle and IMPLEMENTS/TESTS traceability were merged in PR #1315 and are verified at its immutable merge commit.

Status

CI: ✅ green
SonarCloud: ✅ passed
PR ready for user review and merge.

Publish portable mixed-composition contracts #1014

Description

Bounded outcome

Negative cases

Evidence required

Explicit nonclaims

Dependencies

Requirements

Activity

Brad-Edwards commented on Sep 17, 2026

Brad-Edwards commented on Sep 17, 2026

Brad-Edwards commented on Sep 17, 2026

Brad-Edwards commented on Sep 17, 2026

Brad-Edwards commented on Sep 17, 2026

Brad-Edwards commented on Sep 17, 2026

Implementation plan

Scope and TDD paths

Implementation

Repository-wide design checks

Verification

Brad-Edwards commented on Sep 17, 2026

Core review

Security review

1 remaining item

Brad-Edwards commented on Sep 17, 2026

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

Finding 1 — class (14 instances)

Finding 2 — one-off

Finding 3 — class (13 instances)

Finding 4 — one-off

Brad-Edwards commented on Sep 18, 2026

gc_test_quality_review cycle 1 of 1 — issue #1014

Brad-Edwards commented on Sep 18, 2026

Brad-Edwards commented on Sep 18, 2026

Review decision record — test-quality cycle 1 (issue #1014)

Brad-Edwards commented on Sep 18, 2026

Pre-PR base synchronization

Brad-Edwards commented on Sep 18, 2026

Pre-PR base synchronization

Brad-Edwards commented on Sep 18, 2026

Pre-PR base synchronization

Brad-Edwards commented on Sep 18, 2026

Pre-PR base synchronization

Brad-Edwards commented on Sep 18, 2026

Pre-PR base synchronization

Brad-Edwards commented on Sep 18, 2026

Ready for review — issue #1014

Outcome

In-scope requirements

Files changed

Reviews

Traceability reconciliation

Status

Brad-Edwards commented on Sep 18, 2026

Pre-PR base synchronization

Brad-Edwards commented on Sep 18, 2026

Pre-PR base synchronization

Brad-Edwards commented on Sep 18, 2026

Final report — issue #1014 complete

Outcome

In-scope requirements

Files changed

Reviews

Traceability reconciliation

Status

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Finding 1 — `class` (14 instances)

Finding 2 — `one-off`

Finding 3 — `class` (13 instances)

Finding 4 — `one-off`