Skip to content

DSL-010 — APTL ParticipantRuntime: live-action conformance for reference emulation backend (RUN-314) #554

Description

@Brad-Edwards

DSL-010 | FUNCTIONAL | MUST | Wave 2 | DRAFT

Statement

APTL shall realize the ACES participant/runtime action surface as a conformant
backend: implement the ParticipantRuntime protocol against realized
infrastructure, promote its published backend manifest to a
participant_runtime-capable conformance profile, and prove a real
emulation-backed participant action — so APTL can serve as the ecosystem's
reference emulation backend fulfilling ACES requirement RUN-314.

Background

APTL already realizes authored ACES SDL scenarios onto real Docker Compose
infrastructure through the ACES runtime path (RuntimeManager /
RuntimeControlPlane), implements the Provisioner / Orchestrator /
Evaluator backend protocols, publishes the canonical backend-manifest-v2,
runtime snapshot/status, conformance, and realization-provenance contracts, and
boots curated TechVault SDL variants with a committed live-boot proof. It
currently declares itself an orchestration-evaluation backend and explicitly
does not implement ParticipantRuntime; the curated live proof stops at
boot/readiness/topology (--skip-seed, no driven action).

The ACES requirement RUN-314 (aces5 OpenRAE/rae#197) was reopened on a scope audit that
requires proof of "a real emulation-backed action surface ... real emulation
behaviour rather than only contract-surface or in-memory state behaviour." This
issue closes that gap in APTL and makes APTL the artifact RUN-314 traces to.

Acceptance criteria

  1. Implement the ParticipantRuntime protocol on the APTL RuntimeTarget
    (aces_backend_protocols): initialize / reset / restart / terminate
    plus status / results / history, operating against the realized
    containers and returning the standard aces_contracts DTOs.

  2. Promote the published manifest. Add the participant_runtime capability
    block to create_aptl_manifest() together with its required evidence
    contracts (PARTICIPANT_RUNTIME_CAPABILITY_REQUIRED_CONTRACTS — the
    participant episode / behavior / observation envelopes), and pass the
    corresponding higher conformance profile via aces conformance backend
    (run_target_conformance) with no conformance.unsupported-capability-claim
    diagnostics.

  3. Live-action proof. Promote the curated TechVault live-boot proof to a
    live-action proof: boot a variant without --skip-seed, drive a
    meaningful participant/agent action against the realized container(s), and
    assert the action result surfaces through the standard operation-status-v1
    / runtime-snapshot-v1 / realization-provenance contracts (not just
    in-memory / contract-surface state). Commit the evidence alongside the
    existing curated live-proof artifacts.

Out of scope

Traceability

CI

Branch UID: DSL-010.


Tracks Ground Control requirement DSL-010

Activity

  1. added this to the milestone on Jun 25, 2026
  2. Brad-Edwards commented on Jun 25, 2026

    @Brad-Edwards
    CollaboratorAuthor

    🛠️ Picked up by /implement - driver Codex, branch 554-participant-runtime, 2026-06-25T05:25:40Z.

  3. Brad-Edwards commented on Jun 25, 2026

    @Brad-Edwards
    CollaboratorAuthor

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

  4. Brad-Edwards commented on Jun 25, 2026

    @Brad-Edwards
    CollaboratorAuthor

    GRC screening record — issue OpenRAE/rae#554

    Schema: gc.implement.grc-screening/v1
    Verdict: no_baseline

    Rationale: The aptl threat-model and risk-scenario workspaces currently have no baseline entries, assets, flows, or scenarios to reconcile against for this participant-runtime change. This is an explicit declination rather than a clean security-relevance finding.

  5. Brad-Edwards commented on Jun 25, 2026

    @Brad-Edwards
    CollaboratorAuthor

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

  6. Brad-Edwards commented on Jun 25, 2026

    @Brad-Edwards
    CollaboratorAuthor

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

    Plan

    Scope is issue-scoped because DSL-010 is referenced by the GitHub issue but is not present as a Ground Control requirement in this project.

    1. Add a real ACES ParticipantRuntime adapter under src/aptl/backends/ and wire it into create_aptl_runtime_target() beside the existing provisioner, orchestrator, and evaluator. The adapter will use ACES participant episode DTOs for initialize/reset/restart/terminate/status/results/history and return ApplyResult snapshots with participant episode state/history.
    2. Add the live-action participant path as a bounded descriptor keyed by participant address. The first descriptor drives Kali against the realized victim container through DeploymentBackend.container_exec() with argv-list command execution, bounded timeout, redacted diagnostics, and participant behavior history that records attempted action, observation, actor provenance (codex-cli), target refs, output digest, and success/failure.
    3. Promote the backend manifest to full remote-control-plane shape by declaring ParticipantRuntimeCapabilities and the required participant, orchestration, evaluation, operation, and runtime-snapshot contracts. Keep claims narrow: red participant role, behavior history, and shared state change only where the emitted contracts support them.
    4. Promote TechVault validation defaults and docs from orchestration-evaluation / live boot proof to full-remote-control-plane / live action proof. Update the curated proof script to boot without --skip-seed, run the participant action for techvault-attacker-target, and persist structured action evidence alongside the existing snapshot/result artifacts.
    5. Add pytest coverage in tests/ for manifest promotion, RuntimeTarget construction, full remote run_target_conformance(), participant lifecycle control-plane operations, and the live-action proof helper using a fake deployment backend. Add or update docs and a changelog.d/554.added.md fragment.
    6. Verification will include targeted pytest first, then the repo completion command where feasible, plus an actual Docker lab proof for techvault-attacker-target using the curated proof driver. The lab proof may bring APTL down/up and must prove participant behavior through the ACES control plane and persisted evidence, not an in-memory-only transition.

    Design Checks

    Security: OS exposure remains behind DeploymentBackend.container_exec() with argv-list commands, bounded timeout, no shell strings, redaction via existing helpers, and ACES Diagnostic error envelopes. The proof records output digests and bounded excerpts only.

    Maintainability: the implementation reuses the existing ACES target factory, manifest factory, curated live proof helper, Docker backend boundary, redaction helper, and validation gate conventions instead of adding new schema or runtime layers.

    Extensibility: future participant actions can add another descriptor keyed by participant address without editing the manifest, target construction, or control-plane plumbing. Multi-agent coordination remains outside this issue.

    Whole-repo view: touched surfaces are src/aptl/backends, src/aptl/validation, src/aptl/cli/lab.py, TechVault live proof docs/scripts, tests, and changelog. No Docker Compose, Dockerfile, or config/ changes are planned, so the fresh-machine compose-start rule is satisfied by the explicit lab proof rather than a topology migration.

  7. Brad-Edwards commented on Jun 25, 2026

    @Brad-Edwards
    CollaboratorAuthor

    gc_codex_review — cycle 1 of 1 (pre-push) on issue OpenRAE/rae#554 (branch 554-participant-runtime)

    Core review

    Verdict: ship-with-fixes

    The change is shaped correctly at the main design seam: APTL promotes participant runtime through the ACES RuntimeTarget/BackendManifest boundary, then proves it through RuntimeControlPlane rather than inventing a side-channel. The cross-cutting updates to default profile, live-gate manifest evidence, curated proof docs, and conformance tests are aligned with that promotion. The scope is intentionally narrow to one TechVault red action, which fits the current proof without forcing a speculative participant-action registry.

    Blocking findings (1):

    1. [one-off] Aggregate result can report PASS when participant proof failed — docs/aces/techvault-curated-live-validation-gate/run-curated-live-proof.sh:155
      The script now has two pass conditions: the reduced-surface comparison (ok) and the participant action proof (participant_ok). It exits non-zero when the participant proof fails, but result.json is written before participant_ok is computed and its top-level verdict is based only on ok. A failed participant action would therefore leave the aggregate evidence declaring PASS while the script fails and participant-action.json says FAIL, which breaks the trustworthiness of the committed proof artifact. Compute participant_ok before writing result.json and make the aggregate verdict depend on both checks.

    Security review

    Verdict: ship

    This change promotes APTL from the narrower orchestration/evaluation ACES profile to the full remote-control-plane profile by wiring the participant runtime into the same RuntimeTarget seam used for provisioner, orchestrator, and evaluator, then adds a live proof that exercises the participant action through the control plane. The shape is coherent: the new security-relevant boundary is the participant runtime's deployment-backend exec path, and this diff keeps the proof on a fixed participant address and fixed Kali-to-victim action rather than introducing user-controlled command construction. I do not see a concrete exploitable security regression in the provided diff.

    No blocking findings.

  8. Brad-Edwards commented on Jun 25, 2026

    @Brad-Edwards
    CollaboratorAuthor

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

  9. Brad-Edwards commented on Jun 25, 2026

    @Brad-Edwards
    CollaboratorAuthor

    Review decision record — codex cycle 1 (issue OpenRAE/rae#554)

    Reviewer: codex
    Cycle: 1

    Architectural read:

    Core reviewer: The change is shaped correctly at the main design seam: APTL promotes participant runtime through the ACES RuntimeTarget/BackendManifest boundary, then proves it through RuntimeControlPlane rather than inventing a side-channel. The cross-cutting updates to default profile, live-gate manifest evidence, curated proof docs, and conformance tests are aligned with that promotion. The scope is intentionally narrow to one TechVault red action, which fits the current proof without forcing a speculative participant-action registry.

    Security reviewer: This change promotes APTL from the narrower orchestration/evaluation ACES profile to the full remote-control-plane profile by wiring the participant runtime into the same RuntimeTarget seam used for provisioner, orchestrator, and evaluator, then adds a live proof that exercises the participant action through the control plane. The shape is coherent: the new security-relevant boundary is the participant runtime's deployment-backend exec path, and this diff keeps the proof on a fixed participant address and fixed Kali-to-victim action rather than introducing user-controlled command construction. I do not see a concrete exploitable security regression in the provided diff.

    Blocking findings: 1

    Finding 1 — one-off

    • ID: F1
    • Title: [core] Aggregate result can report PASS when participant proof failed
    • Location: docs/aces/techvault-curated-live-validation-gate/run-curated-live-proof.sh:155
    • Decision: fix
    • Rationale: The script now has two pass conditions: the reduced-surface comparison (ok) and the participant action proof (participant_ok). It exits non-zero when the participant proof fails, but result.json is written before participant_ok is …
  10. Brad-Edwards commented on Jun 25, 2026

    @Brad-Edwards
    CollaboratorAuthor

    gc_test_quality_review cycle 1 of 1 — issue OpenRAE/rae#554

    Reviewer: test-quality (claude-sonnet-4-6 via gc_test_quality_review)
    Branch: 554-participant-runtime
    Cycle: 1 / 1
    Findings: 0 (clean run)

  11. Brad-Edwards commented on Jun 25, 2026

    @Brad-Edwards
    CollaboratorAuthor

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

  12. Brad-Edwards commented on Jun 25, 2026

    @Brad-Edwards
    CollaboratorAuthor

    Review decision record — test-quality cycle 1 (issue OpenRAE/rae#554)

    Reviewer: test-quality
    Cycle: 1

    Architectural read:

    This change adds the AptlParticipantRuntime adapter as a new ACES integration surface and wires it into the conformance, live-gate, and curated-proof layers. The test files accurately track that addition: test_aces_backend.py extends the existing provisioner/orchestration pyramid with lifecycle and action-behavior tests routed through the real ACES RuntimeControlPlane; test_curated_live_proof.py adds a monkeypatched unit proof for the participant action path that exercises the same control plane without Docker; test_techvault_live_gate.py adds thorough per-check unit coverage for the new probes module split and the check_boot_inputs_match_public_path / check_scenario_variation checks; test_techvault_static_gate.py is largely additive, extending gate-helper coverage to match the refactored check decomposition. The tests are scenario-generic (not TechVault-preset-locked), exercise real ACES contract violation checkers (iter_participant_episode_snapshot_violations, iter_participant_behavior_snapshot_violations) as the primary correctness oracle, and use a consistent monkeypatching discipline that targets named leaf-dependency boundaries (lgp, lgc) rather than framework internals. Each positive test has paired negative paths. No false-assurance patterns found; verdict is ship.

    Blocking findings: 0 (clean run)

  13. 5 remaining items

  14. modified the milestones: , Backlog: APTL Core Platform, Backlog: APTL Backend Capabilities on Jun 27, 2026
  15. removed
    in-progressAn agent is actively working this issue via /implement
    on Jul 6, 2026
  16. Brad-Edwards commented on Jul 15, 2026

    @Brad-Edwards
    CollaboratorAuthor

    🛠️ Picked up by /implement - driver Claude Code, branch 554-participant-runtime, 2026-07-15T05:31:58Z.

  17. Brad-Edwards commented on Jul 15, 2026

    @Brad-Edwards
    CollaboratorAuthor

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

    • DSL-010: status=ACTIVE, IMPLEMENTS=18, TESTS=4
  18. Brad-Edwards commented on Jul 15, 2026

    @Brad-Edwards
    CollaboratorAuthor

    Final report — issue OpenRAE/rae#554 complete

    PR: OpenRAE/rae#555
    Plan: #554 (comment)

    Outcome

    APTL now serves as a conformant ACES reference emulation backend: it implements the ParticipantRuntime protocol against real Docker infrastructure and drives a real participant action (a Kali-to-victim probe) through the ACES control plane, surfacing the result through the standard operation-status, runtime-snapshot, and realization-provenance contracts rather than only in-memory state. The published backend manifest now advertises the participant_runtime capability, and the curated TechVault live proof was promoted from a boot-only proof to a real live-action proof.

    In-scope requirements

    • DSL-010 (APTL ParticipantRuntime: live-action conformance for reference emulation backend) — ACTIVE

    Files changed

    Added:

    • changelog.d/554.added.md
    • docs/aces/dsl-010-participant-runtime-preflight.md
    • docs/aces/techvault-curated-live-validation-gate/techvault-attacker-target/participant-action.json
    • src/aptl/backends/aces_participant_actions.py
    • src/aptl/backends/aces_participant_runtime.py
    • src/aptl/validation/participant_live_proof.py
    • src/aptl/validation/range_snapshot_summary.py

    Modified:

    • docs/aces/techvault-curated-live-validation-gate.md
    • docs/aces/techvault-curated-live-validation-gate/run-curated-live-proof.sh
    • docs/aces/techvault-curated-live-validation-gate/techvault-attacker-target/result.json
    • docs/aces/techvault-curated-live-validation-gate/techvault-attacker-target/snapshot.json
    • src/aptl/backends/aces.py
    • src/aptl/backends/aces_manifest.py
    • src/aptl/cli/lab.py
    • src/aptl/validation/_live_gate_checks.py
    • src/aptl/validation/curated_live_proof.py
    • src/aptl/validation/techvault_gate.py
    • src/aptl/validation/techvault_live_gate.py
    • tests/test_aces_backend.py
    • tests/test_curated_live_proof.py
    • tests/test_techvault_live_gate.py
    • tests/test_techvault_static_gate.py

    Reviews

    • codex: Core verdict ship-with-fixes; security verdict ship. Fixed blocking finding: curated-proof script could write aggregate PASS before computing participant_ok. Confirms participant runtime promoted via the ACES RuntimeControlPlane seam.
    • test-quality: 0 findings, clean run, verdict ship. Tests exercise the real RuntimeControlPlane and contract-violation checkers as oracle; scenario-generic with paired positive/negative paths.

    Traceability reconciliation

    • IMPLEMENTS / TESTS / DOCUMENTS added: 3
    • Links updated: 1
    • Stale links removed: 1

    changelog.d/554.added.md left unlinked as housekeeping. Pre-existing links from shared files (aces.py, aces_manifest.py, cli/lab.py, _live_gate_checks.py, techvault_gate.py, techvault_live_gate.py and tests) to other requirements were preserved.

    Status

    • CI: ✅ green
    • SonarCloud: ✅ passed
    • PR ready for user review and merge.
  19. removed
    in-progressAn agent is actively working this issue via /implement
    on Jul 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    requirementGround Control requirementscope:aptl-backend-capabilityGeneric backend capability to realize scenario-declared tools/services.scope:aptl-coreAPTL platform/range capability independent of one scenario.

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions