Repository navigation
DSL-010 — APTL ParticipantRuntime: live-action conformance for reference emulation backend (RUN-314) #554
Description
Activity
- addedrequirementGround Control requirementGround Control requirementin-progressAn agent is actively working this issue via /implementAn agent is actively working this issue via /implement
on Jun 25, 2026 🛠️ Picked up by /implement - driver Codex, branch
554-participant-runtime, 2026-06-25T05:25:40Z.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.GRC screening record — issue OpenRAE/rae#554
Schema:
gc.implement.grc-screening/v1
Verdict:no_baselineRationale: 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.
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.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-010is referenced by the GitHub issue but is not present as a Ground Control requirement in this project.- Add a real ACES
ParticipantRuntimeadapter undersrc/aptl/backends/and wire it intocreate_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 returnApplyResultsnapshots with participant episode state/history. - 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. - Promote the backend manifest to full remote-control-plane shape by declaring
ParticipantRuntimeCapabilitiesand 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. - Promote TechVault validation defaults and docs from
orchestration-evaluation/ live boot proof tofull-remote-control-plane/ live action proof. Update the curated proof script to boot without--skip-seed, run the participant action fortechvault-attacker-target, and persist structured action evidence alongside the existing snapshot/result artifacts. - Add pytest coverage in
tests/for manifest promotion,RuntimeTargetconstruction, full remoterun_target_conformance(), participant lifecycle control-plane operations, and the live-action proof helper using a fake deployment backend. Add or update docs and achangelog.d/554.added.mdfragment. - Verification will include targeted pytest first, then the repo completion command where feasible, plus an actual Docker lab proof for
techvault-attacker-targetusing 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 ACESDiagnosticerror 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, orconfig/changes are planned, so the fresh-machine compose-start rule is satisfied by the explicit lab proof rather than a topology migration.- Add a real ACES
gc_codex_review — cycle 1 of 1 (pre-push) on issue OpenRAE/rae#554 (branch
554-participant-runtime)Core review
Verdict:
ship-with-fixesThe 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):
- [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, butresult.jsonis written beforeparticipant_okis computed and its top-level verdict is based only onok. A failed participant action would therefore leave the aggregate evidence declaring PASS while the script fails andparticipant-action.jsonsays FAIL, which breaks the trustworthiness of the committed proof artifact. Computeparticipant_okbefore writingresult.jsonand make the aggregate verdict depend on both checks.
Security review
Verdict:
shipThis 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.
- [one-off] Aggregate result can report PASS when participant proof failed —
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.Review decision record — codex cycle 1 (issue OpenRAE/rae#554)
Reviewer: codex
Cycle: 1Architectural 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, butresult.jsonis written beforeparticipant_okis …
- ID:
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)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_reviewinvocation to count cycles.Review decision record — test-quality cycle 1 (issue OpenRAE/rae#554)
Reviewer: test-quality
Cycle: 1Architectural 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)
5 remaining items
- addedscope:aptl-backend-capabilityGeneric backend capability to realize scenario-declared tools/services.Generic backend capability to realize scenario-declared tools/services.
on Jun 27, 2026 - modified the milestones: This milestone has been deleted, Backlog: APTL Core Platform, Backlog: APTL Backend Capabilities
on Jun 27, 2026 - modified the milestones: Backlog: APTL Backend Capabilities, M1 — ACES Conformance Truth-up
on Jul 3, 2026 - removedin-progressAn agent is actively working this issue via /implementAn agent is actively working this issue via /implement
on Jul 6, 2026 - addedin-progressAn agent is actively working this issue via /implementAn agent is actively working this issue via /implement
on Jul 15, 2026 🛠️ Picked up by /implement - driver Claude Code, branch
554-participant-runtime, 2026-07-15T05:31:58Z.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
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.mddocs/aces/dsl-010-participant-runtime-preflight.mddocs/aces/techvault-curated-live-validation-gate/techvault-attacker-target/participant-action.jsonsrc/aptl/backends/aces_participant_actions.pysrc/aptl/backends/aces_participant_runtime.pysrc/aptl/validation/participant_live_proof.pysrc/aptl/validation/range_snapshot_summary.py
Modified:
docs/aces/techvault-curated-live-validation-gate.mddocs/aces/techvault-curated-live-validation-gate/run-curated-live-proof.shdocs/aces/techvault-curated-live-validation-gate/techvault-attacker-target/result.jsondocs/aces/techvault-curated-live-validation-gate/techvault-attacker-target/snapshot.jsonsrc/aptl/backends/aces.pysrc/aptl/backends/aces_manifest.pysrc/aptl/cli/lab.pysrc/aptl/validation/_live_gate_checks.pysrc/aptl/validation/curated_live_proof.pysrc/aptl/validation/techvault_gate.pysrc/aptl/validation/techvault_live_gate.pytests/test_aces_backend.pytests/test_curated_live_proof.pytests/test_techvault_live_gate.pytests/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.
- removedin-progressAn agent is actively working this issue via /implementAn agent is actively working this issue via /implement
on Jul 15, 2026
Statement
APTL shall realize the ACES participant/runtime action surface as a conformant
backend: implement the
ParticipantRuntimeprotocol against realizedinfrastructure, 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 theProvisioner/Orchestrator/Evaluatorbackend protocols, publishes the canonicalbackend-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 atboot/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
Implement the
ParticipantRuntimeprotocol on the APTLRuntimeTarget(
aces_backend_protocols):initialize/reset/restart/terminateplus
status/results/history, operating against the realizedcontainers and returning the standard
aces_contractsDTOs.Promote the published manifest. Add the
participant_runtimecapabilityblock to
create_aptl_manifest()together with its required evidencecontracts (
PARTICIPANT_RUNTIME_CAPABILITY_REQUIRED_CONTRACTS— theparticipant episode / behavior / observation envelopes), and pass the
corresponding higher conformance profile via
aces conformance backend(
run_target_conformance) with noconformance.unsupported-capability-claimdiagnostics.
Live-action proof. Promote the curated TechVault live-boot proof to a
live-action proof: boot a variant without
--skip-seed, drive ameaningful 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 justin-memory / contract-surface state). Commit the evidence alongside the
existing curated live-proof artifacts.
Out of scope
top of this action surface.
Traceability
Define the reference-backend contract and conformance evidence (RUN-314) rae#197 — reopened scope audit).
participant/runtime surface.
CI
Branch UID:
DSL-010.Tracks Ground Control requirement DSL-010