Integrate RUN-311 initialization as the SEM-220 order-zero projection anchor

[Brad-Edwards]

Problem

RAES already defines the required semantic state:

• SEM-210 view_rules define the initial participant view relation V_p,0;
• SEM-220 defines a participant decision surface D(p,e,o) over that relation at a participant-, episode-, and order-scoped observation point; and
• RUN-311 records truthful participant episode initialization and running lifecycle events.

The released public runtime does not integrate those existing authorities for the first participant decision.

project_participant_decision_surface() accepts a Sequence[ParticipantBehaviorHistoryEvent], rejects an empty sequence, and requires observation_order to identify an event in that sequence. That is correct for later time-indexed projection and correctly prevents a final snapshot from substituting for history. However, immediately after normal RUN-311 initialization the only truthful anchors are participant-episode lifecycle events. Every valid participant-behavior history event is action-linked:

• action_attempted requires a compiled action-contract address and actor provenance;
• state_transition_recorded requires a compiled action-contract address, transition kind, and post-state digest; and
• observation_emitted requires a compiled action-contract address, observation-boundary address, and observation status.

A conformant backend therefore has no typed public path to project V_p,0 and the first SEM-220 decision surface before a participant action occurs. The underlying projection algorithm can select the initial relation when supplied an episode-initialization event as an order anchor, but that event is outside the projector's declared input contract. Depending on Python duck typing is not a portable or conformant solution and leaves ordering and evidence relationships underspecified.

This was encountered while implementing a multi-turn bounded-participant evaluation in Brad-Edwards/aptl#557, but the gap is backend-neutral and must not be designed around APTL or one scenario.

Required outcome

Integrate RUN-311 episode initialization with SEM-210/SEM-220 projection so a newly initialized participant episode has a portable, typed, truthful order-zero anchor for its initial participant-visible context and first decision surface.

The solution should reuse the existing semantic authorities rather than introduce a parallel participant, visibility, or history model. It may admit a typed episode-lifecycle anchor to the projector, introduce a small common projection-anchor contract/protocol, or use another representation consistent with ADR-013, ADR-022, and ADR-083. The representation is not prescribed here.

The integration must preserve these properties:

• V_p,0 remains the authority for initial visibility;
• participant episode lifecycle history and participant behavior history remain semantically distinct;
• no action attempt, state transition, observation result, or participant choice is implied before one occurs;
• the initial surface remains participant- and episode-scoped and carries an explicit order/event/evidence anchor;
• observation-boundary, context-view, exposure-policy, marking, provenance, evidence, and apparatus-selection checks remain governed;
• the first selection binds through the same SEM-220 action, argument-shape, apparatus, and admission checks as later selections;
• subsequent surfaces continue to use time-indexed participant behavior history and the existing visibility-transition anchor discipline;
• final snapshots, arbitrary empty history, and backend-private bootstrap records remain insufficient.

Ordering questions to resolve

Specify the portable ordering relationship among:

1. episode_initialized and episode_running;
2. the initial participant-visible context projection;
3. the order-zero decision surface;
4. the first proposal and selection;
5. the first admitted action attempt;
6. its state transition and terminal observation; and
7. the next decision surface.

In particular, define which RUN-311 lifecycle event is the authoritative readiness anchor and how later participant-behavior event order relates to the order-zero surface without overloading episode sequence_number as behavior-step order.

Acceptance criteria

• A reference test initializes a participant through the public RUN-311 control-plane path and projects V_p,0, its initial context view, and the first SEM-220 decision surface without recording or implying a participant action.
• The projector consumes a documented public type rather than relying on an object outside its declared input contract.
• The projected surface is derived from the compiled participant, behavior specification, observation boundary, action contracts, implementation selection, and exposure policy.
• A first valid selection binds and admits through the public RAES decision-surface control-plane path.
• Subsequent action-result observations and decision surfaces retain the existing time-indexed behavior-history semantics.
• Empty, forged, stale, replayed, cross-episode, cross-participant, and unauthorized-reference inputs fail closed.
• Tests distinguish episode lifecycle order, decision-surface order, and behavior-history order and cover resets/restarts as new episode scopes.
• Documentation states the ordering and evidence relationship described above.

Non-goals

• Creating a second visibility relation or participant-history model.
• Weakening time-indexed projection to accept an arbitrary final snapshot.
• Treating a backend-selected setup action as participant behavior.
• Merging RUN-311 lifecycle history and participant behavior history into one ambiguous carrier.
• Tailoring initial context to APTL, TechVault, coding agents, or one backend.
• Exposing evaluator-only or hidden state as participant-visible initialization data.

[Brad-Edwards]

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

1. Keep the preflight guidance as the binding design record and update ADR-083 plus the participant-semantics specification with the portable ordering: lifecycle creation/reset/restart → episode_running → initial context/D0 → proposal/selection → admitted behavior → terminal observation → next surface. Document lifecycle generation, decision-surface order, and behavior-history order as independent coordinates.
2. Add a closed tagged projection-anchor shape to the public decision-surface contract. The episode-readiness variant will carry the resolved episode_running event, its lifecycle-history order, per-episode decision-surface order, stable event reference, evidence, and provenance. The behavior-event variant will carry the corresponding behavior-history event/order/prefix facts. Add it to decision-surface v1 as a backwards-compatible optional field without changing existing v1 field meaning; classify and record the additive schema change, regenerate the published schema, and add positive/negative fixtures.
3. Add trusted anchor resolvers in the reference processor. They will derive anchors from the current RuntimeSnapshot, reuse RUN-311 snapshot invariants and existing behavior-history normalization, require the current running participant/episode, derive stable event references rather than trusting caller strings, and reject incomplete, forged, stale, replayed, cross-participant, cross-episode, or unauthorized evidence/provenance relationships.
4. Update project_participant_decision_surface() to accept the trusted snapshot and tagged anchor while keeping lifecycle and behavior histories separate. A current episode_running anchor plus empty current-episode behavior history will select compiled V_p,0; behavior anchors will continue through the existing behavior-anchor indexes and effective-relation selector. Empty history without a valid readiness anchor and final-snapshot substitution remain rejected.
5. Strengthen the existing selection/admission control-plane path so an anchored surface is revalidated against the live snapshot immediately before binding/admission. Reset, restart, termination, or later behavior will invalidate a stale surface before any behavior event is written. Existing action-shape, apparatus, exposure-policy, SEM-211, and backend admission checks remain unchanged.
6. Drive the change with failing tests first. The principal integration test will initialize through the public RUN-311 RuntimeControlPlane, prove no participant behavior exists, resolve and project the initial anchor/context/D0, validate the context envelope, bind a valid selection through the public decision-surface path, and then prove admission creates the first action_attempted → state_transition_recorded → observation_emitted sequence. Negative tests will cover missing/isolated anchors, wrong readiness event/status, incomplete history, evidence/provenance mismatch, cross-scope inputs, stale/replayed surfaces, resets/restarts as fresh D0 scopes, and unchanged later behavior-history projection.
7. Verify with targeted SEM-220/RUN-311/control-plane tests, then run ACES_REQUIREMENT_UID=SEM-220 with tools/check_repo_policy.py, tools/check_requirement_governance.py, tools/verify_all.py, and the repository’s canonical nox lint/hygiene/verify gates. Run generated-schema and schema-publication checks as part of those gates.

Security and whole-repo constraints: reuse closed ContractModel validation, current snapshot/store authority, existing visibility/exposure/apparatus/admission resolvers, diagnostics, audit, and error handling. Add no endpoint, secret/config surface, subprocess, backend-private bootstrap record, alternate history, visibility algorithm, persistence path, or APTL-specific semantics.

[Brad-Edwards]

gc_codex_review — cycle 1 of 1 (pre-push) on issue #909 (branch 909-initial-projection-anchor)

Core review

Verdict: don't-ship

The tagged-anchor seam is directionally correct: it preserves separate lifecycle and behavior histories, reuses the trusted snapshot and incumbent visibility validators, and adds admission-time freshness checks. However, the implementation does not preserve its defining boundary contract—the independent decision-surface and owning-history order domains are collapsed at projection and surface validation. That makes the new decision_surface_order descriptive rather than authoritative and breaks the stated D(p,e,o) progression, so the change is not yet shaped for production.

Blocking findings (1):

1. [class] Projection conflates decision-surface order with anchor-history order — implementations/python/packages/raes_processor/models/decision_surface_anchor.py:183
   The contract and ADR declare decision_surface_order and anchor_order to be independent coordinates, but this validator requires projection.observation_order to equal anchor.anchor_order, and ParticipantDecisionSurfaceModel repeats the same coupling. Meanwhile, both resolvers merely echo the caller-provided decision_surface_order without deriving or checking it. Consequently, the initial readiness anchor at lifecycle index 1 produces a surface/selection order of 1 instead of D(p,e,0), while the behavior head after one three-event action produces order 2 instead of D(p,e,1). Admission re-resolves using the same unchecked decision_surface_order, so arbitrary or duplicate decision orders remain valid. Carry the per-episode decision order through the canonical projection/surface identity and validate it against authoritative progression; reserve anchor_order solely for indexing the owning lifecycle or behavior history.

Security review

Verdict: ship

This is shaped correctly: the change introduces a closed, tagged projection-anchor contract, resolves it against the trusted RuntimeSnapshot and complete lifecycle or behavior history during projection, and revalidates freshness at the admission boundary. It preserves the separation between lifecycle and behavior histories while touching the necessary contract-publication, runtime-authority, admission, fixture, and documentation surfaces. The discriminated anchor seam accommodates future governed anchor variants without weakening existing exposure or action-admission checks.

No blocking findings.

[Brad-Edwards]

gc_codex_review pre-push cycle 1 of 1 complete for issue #909 on branch '909-initial-projection-anchor'. 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 #909)

Reviewer: codex
Cycle: 1

Architectural read:

Core reviewer: The tagged-anchor seam is directionally correct: it preserves separate lifecycle and behavior histories, reuses the trusted snapshot and incumbent visibility validators, and adds admission-time freshness checks. However, the implementation does not preserve its defining boundary contract—the independent decision-surface and owning-history order domains are collapsed at projection and surface validation. That makes the new decision_surface_order descriptive rather than authoritative and breaks the stated D(p,e,o) progression, so the change is not yet shaped for production.

Security reviewer: This is shaped correctly: the change introduces a closed, tagged projection-anchor contract, resolves it against the trusted RuntimeSnapshot and complete lifecycle or behavior history during projection, and revalidates freshness at the admission boundary. It preserves the separation between lifecycle and behavior histories while touching the necessary contract-publication, runtime-authority, admission, fixture, and documentation surfaces. The discriminated anchor seam accommodates future governed anchor variants without weakening existing exposure or action-admission checks.

Blocking findings: 1

Finding 1 — class (5 instances)

• ID: F1
• Title: [core] Projection conflates decision-surface order with anchor-history order
• Location: implementations/python/packages/raes_processor/models/decision_surface_anchor.py:183
• Decision: fix
• Rationale: The contract and ADR declare decision_surface_order and anchor_order to be independent coordinates, but this validator requires projection.observation_order to equal anchor.anchor_order, and ParticipantDecisionSurfaceModel repeats the same…
• Instances:
  • implementations/python/packages/raes_processor/models/decision_surface_anchor.py:109
  • implementations/python/packages/raes_processor/models/decision_surface_anchor.py:162
  • implementations/python/packages/raes_processor/models/decision_surface_anchor.py:183
  • implementations/python/packages/raes_contracts/contracts/participant_decision_surface.py:383
  • implementations/python/tests/test_sem_220_participant_decision_surface.py:1232

[Brad-Edwards]

gc_review_cap_disposition — issue #909 (codex, cycle 1 of 1)

Disposition: proceed
Auto-override grant #: n/a
Rationale: No security finding, one consolidated known finding class with zero one-off findings, and zero prior auto-overrides on this issue — signals converge cleanly enough that the unclassified surface tag doesn't warrant burning another cycle or escalating.

Posted by the MCP server to record the review-cap auto-disposition. Do not edit or delete — the cycle wrappers read this marker to verify an over-cap auto-grant before running a cycle.

[Brad-Edwards]

gc_test_quality_review cycle 1 of 1 — issue #909

Reviewer: test-quality (claude-sonnet-5 via gc_test_quality_review)
Branch: 909-initial-projection-anchor
Cycle: 1 / 1
Findings: 1

Finding 1 — [critical] implementations/python/tests/test_sem_220_participant_decision_surface.py:944

Problem: test_realization_kind_preserves_surface_semantic_refs is parametrized over (implementation_selection_ref, decision_control_mode) — the two fields the test name says it verifies — but none of its three assertions touch surface.decision_control_mode or surface.implementation_selection_ref. All four parametrize cases assert the identical fixed values (SCAN, SCAN_SHAPE, 'selection-meaning.candidate.v1'), none of which vary with the parametrized inputs.
Why it matters: decision_surface.py:351-352 passes projection.implementation_selection_ref and projection.decision_control_mode straight through into the surface payload with no cross-field validation elsewhere (participant_decision_surface.py declares decision_control_mode as a plain NonEmptyString, no invariant ties it back). The one internal check that touches decision_control_mode (participant_exposure_policy.py:76) compares the resolver-built selection against projection.decision_control_mode — the same test-local variable used to construct that selection — so it's tautologically satisfied regardless of what ends up in the surface. If _surface_payload ever hardcoded or dropped these two fields (e.g. during a refactor of _surface_payload), this test — parametrized specifically to catch exactly that — would keep passing across all four cases, and no other test in the file asserts surface.decision_control_mode or surface.implementation_selection_ref against a varying expected value.
Fix: Add assert surface.decision_control_mode == decision_control_mode and assert surface.implementation_selection_ref == implementation_selection_ref to the test body so each parametrized case actually checks the field it's supposed to be exercising.

[Brad-Edwards]

gc_test_quality_review cycle 1 of 1 complete for issue #909 on branch '909-initial-projection-anchor'. 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.

[Brad-Edwards]

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

Reviewer: test-quality
Cycle: 1

Architectural read:

This PR wires the RUN-311/SEM-220 order-zero anchor design from ADR-083/issue-909: a closed, discriminated ParticipantDecisionSurfaceProjectionAnchorModel (episode_readiness | behavior_event), a trusted resolver that re-derives the anchor from the live RuntimeSnapshot rather than trusting a caller-supplied event, and control-plane admission that revalidates the anchor at submission time. The test suite matches this shape well: it treats the anchor as an anti-replay/anti-forgery gate and tests it as one — forging event_ref, submitting a stale surface after reset/restart, submitting a prefix-truncated history, and a decision_surface_order that doesn't match the resolved count of observations — and in each case asserts the real control-plane/projection boundary rejects it with a concrete effect (unchanged history length, accepted is False), not just that an exception type was raised or a mock fired. That's the correct altitude for this kind of invariant. The one weak spot is a single test whose parametrization promises coverage it doesn't deliver.

Blocking findings: 1

Finding 1 — one-off

• ID: F1
• Title: (no title)
• Decision: fix
• Rationale: Addressed by next cycle

[Brad-Edwards]

gc_review_cap_disposition — issue #909 (test-quality, cycle 1 of 1)

Disposition: one_more_cycle
Auto-override grant #: 1
Rationale: Single known, non-security one-off finding (no class-level pattern), zero prior auto-overrides, and doc/unclassified surfaces — low-risk enough for one automated fix cycle rather than human escalation.

Posted by the MCP server to record the review-cap auto-disposition. Do not edit or delete — the cycle wrappers read this marker to verify an over-cap auto-grant before running a cycle.

[Brad-Edwards]

gc_test_quality_review cycle 2 of 1 — issue #909

Reviewer: test-quality (claude-sonnet-5 via gc_test_quality_review)
Branch: 909-initial-projection-anchor
Cycle: 2 / 1
Findings: 1

Finding 1 — [critical] implementations/python/tests/test_sem_220_participant_decision_surface.py::test_decision_surface_schema_is_closed_discriminated_and_published

Problem: The new decision-surface-projection-anchor-agreement invariant — enforced by ParticipantDecisionSurfaceModel._validate_projection_anchor in participant_decision_surface.py:377-395, which rejects a surface whose projection_anchor.participant_address/episode_id/decision_surface_order/evidence_refs/provenance_refs disagree with the surface's own fields — is only checked for existence as a string in schema['x-aces-invariants']. No test in the file constructs a ParticipantDecisionSurfaceModel payload with a mismatched anchor to prove the validator actually rejects it.
Why it matters: This is the sole enforcement point that ties an anchor's claimed participant/episode/order to the surface payload it is attached to — validate_participant_decision_surface_projection_anchor (decision_surface_anchor.py:260-306), which runs at admission time, only re-resolves the anchor against the current snapshot using the anchor's own fields; it never cross-checks the anchor against the surface's participant_address/episode_id/observation_order. If _validate_projection_anchor were deleted or turned into a no-op, a surface could carry a validly-resolvable anchor for one participant/episode/order while its own payload (entries, observation_order, episode_id) describes a different one, and nothing else in the pipeline would catch it — yet every test in this file would still pass. The one new fixture that exercises the anchor field (human-candidate.json) only covers the self-consistent, valid case; there is no invalid fixture for a mismatched anchor either.
Fix: Add a test that builds a valid surface payload (e.g. via _surface_payload()), sets projection_anchor to an otherwise-valid anchor whose participant_address (or episode_id, or decision_surface_order) deliberately differs from the surface's own value, and asserts ParticipantDecisionSurfaceModel.model_validate(payload) raises ValidationError matching "projection anchor disagrees with the decision surface". Add companion cases for the evidence_refs/provenance_refs subset branches (anchor ref not present in the surface's own evidence_refs/provenance_refs). Consider also adding a corresponding invalid fixture under contracts/fixtures/.../invalid/ so the fixture-driven schema test exercises it too.

[Brad-Edwards]

gc_test_quality_review cycle 2 (USER-AUTHORIZED OVERRIDE past cap 1) complete for issue #909 on branch '909-initial-projection-anchor'. 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.
Override reason: auto-disposition grant #1 (gc_review_cap_disposition one_more_cycle for test-quality)

[Brad-Edwards]

Review decision record — test-quality cycle 2 (issue #909)

Reviewer: test-quality
Cycle: 2

Architectural read:

This PR adds the RUN-311/SEM-220 order-zero/behavior projection-anchor mechanism: typed, discriminated (episode_readiness vs behavior_event), sha256-bound event anchors that pin a decision surface to an exact, current, non-replayable point in a participant's lifecycle/behavior history. The seam is split correctly into three layers matching the repo's existing resolve/validate pattern: (1) a contracts-level self-consistency invariant on ParticipantDecisionSurfaceModel itself (anchor must agree with the surface's own participant/episode/order/evidence/provenance), (2) processor-level resolve_*/validate_* functions that re-derive the anchor against the current RuntimeSnapshot at admission time, and (3) a runtime-level admission gate (admit_participant_decision_surface_selection) that refuses to proceed without a present, freshly-revalidated anchor. Layers (2) and (3) are exercised thoroughly and honestly: the tests drive real staleness (post-reset), real forgery (tampered event_ref, forged decision_surface_order), real cross-episode/cross-participant mismatches, and real unanchored-surface rejection through the full RuntimeControlPlane admission path, asserting on rejection outcomes and unchanged history length rather than on mock calls. That is the hard, security-relevant part of this feature and it is well covered. Layer (1), however — the model's own _validate_projection_anchor invariant, which is the only place that checks the anchor's declared participant/episode/order/evidence/provenance actually agree with the surface's own declared fields (the admission-time re-validation only checks the anchor against the snapshot, never against the surface it's attached to) — has no behavioral test anywhere in this file or the wider tree. It is shippable in shape, but the one new invariant this PR both introduces and prominently advertises in the schema is currently backed only by a string-presence assertion.

Blocking findings: 1

Finding 1 — one-off

• ID: F1
• Title: (no title)
• Decision: fix
• Rationale: Addressed by next cycle