SCN-010D: route APTL public start path through ACES RuntimeManager handoff

[Brad-Edwards]

ACES Methodology And Capture Tooling

Before starting inventory or encoding work on this issue, use the ACES asset inventory methodology and capture tooling:

• Methodology: https://github.com/Brad-Edwards/aces/blob/dev/docs/aces/inventory/asset-inventory-methodology.md
• Assurance report: https://github.com/Brad-Edwards/aces/blob/dev/docs/aces/inventory/methodology-assurance-report.md
• Codex capture skill: https://github.com/Brad-Edwards/aces/tree/dev/.codex-skills/aces-asset-inventory-capture
• Claude capture skill: https://github.com/Brad-Edwards/aces/tree/dev/.claude/skills/aces-asset-inventory-capture
• Container capture template: https://github.com/Brad-Edwards/aces/blob/dev/.codex-skills/aces-asset-inventory-capture/scripts/capture-container-evidence-template.sh
• Syft normalizer: https://github.com/Brad-Edwards/aces/blob/dev/.codex-skills/aces-asset-inventory-capture/scripts/normalize-syft-cyclonedx.jq

Summary

Make APTL's public scenario/lab start path interpret ACES SDL and instantiate scenarios through the ACES runtime/backend contract as intended. TechVault is the proving case, but this issue is specifically about preventing a shortcut back to the old APTL SDL path or a hardcoded scenario preset.

Parent tracker: #317
Depends on: SCN-010B, SCN-010C
Related blocker: #324 generic equivalent-expressivity interpretation
Requirement: SCN-010

Scope

Wire the public APTL entrypoints so TechVault startup flows through:

1. ACES reference parser for scenarios/techvault.sdl.yaml.
2. ACES semantic validation and dependency/import resolution as applicable.
3. ACES compilation to RuntimeModel / execution plan.
4. APTL ACES backend target interpretation of that model/plan.
5. APTL backend instantiation of Docker Compose profiles, rendered configs, volumes, services, health checks, and runtime bookkeeping from the interpreted model.

Public surfaces include the relevant aptl lab and scenario CLI/API paths that users or automation invoke to start/list/stop scenarios.

Non-negotiable constraints

• No implementation branch may parse techvault.sdl.yaml with aptl.core.sdl.
• No public TechVault start path may materialize legacy ScenarioDefinition models as the source of truth.
• No public scenario start path may treat ACES as if scenario == techvault: start existing preset.
• The backend must inspect declared ACES model/plan content and map it to APTL realization artifacts: services, profiles, networks, volumes, rendered configs, health checks, telemetry, objectives, and run evidence.
• The same interpreter path must be capable of expressing non-TechVault scenarios within APTL's supported expressivity class; SCN-010G: generalize ACES-to-APTL backend interpretation for equivalent scenario expressivity #324 captures that generality gate.
• Legacy paths may remain available only for archived/reference scenarios until the final cutover issue removes them.
• If an APTL-specific realization detail is needed, it must live behind the ACES backend target boundary or a documented ACES extension, not in an out-of-band shortcut.

Acceptance

• Tests prove the public TechVault start path calls ACES parser/runtime handoff before APTL backend instantiation.
• Regression tests fail if techvault.sdl.yaml is routed through aptl.core.sdl or legacy ScenarioDefinition models.
• Regression tests fail if the ACES path only dispatches on scenario name/preset instead of interpreting RuntimeModel / execution-plan content.
• Scenario list/start/stop CLI/API tests cover the ACES path.
• aces conformance backend --profile provisioning-only remains passing for APTL's manifest.
• SCN-010G: generalize ACES-to-APTL backend interpretation for equivalent scenario expressivity #324 is satisfied before this is considered cutover-ready.
• pytest and pre-commit run --all-files pass.

Absolute Observable-Parity Gate

This issue is not complete until the TechVault ACES SDL expresses every fact that a participant, adversary, defender, autonomous agent, tool, evaluator, or harness could observe from inside the realized range for this issue's in-scope surface.

Parity means full observable parity. It is not relevance-filtered. It is not limited to facts needed by APTL's current implementation, not limited to load-bearing behavior, and not satisfied by storing evidence outside the SDL.

Evidence bundles, checksums, source trees, Docker/Compose files, screenshots, logs, inventories, comments, and mapping ledgers are proof inputs only. They are not substitutes for SDL expression. If an observable file, config, package, version, environment value, route, user, permission, process, service, vulnerability, relationship, log path, filesystem entry, credential fixture, or scanner finding is within this issue's scope, then the SDL-backed spec must encode it directly using ACES.

If ACES can express it, encode it in scenarios/techvault.sdl.yaml and add validation that proves it is present. If ACES cannot express it, file one or more blocking issues in Brad-Edwards/aces, link them here, and do not mark this issue complete. A filed ACES issue is a blocker, not a waiver. After ACES merges/releases the needed expressivity, this issue remains incomplete until the SDL is updated to use the new ACES surface and validation passes.

APTL runtime consumption is separate. Lack of APTL support for consuming an SDL field may require a linked APTL issue, but it never excuses missing SDL parity and must not be used to close this issue.

Forbidden completion claims:

• "Captured in evidence" unless also encoded in SDL or blocked by a specific ACES expressivity issue.
• "Representative subset" for packages, files, vulnerabilities, processes, configs, env, services, routes, users, permissions, logs, filesystem state, or scanner findings.
• "Relevant fields encoded", "load-bearing fields encoded", or "implementation-important fields encoded".
• "APTL cannot consume it yet" as a reason to omit SDL content.
• "Out of scope" for any in-scope fact observable from inside the range unless a separate linked issue owns that observable surface and blocks final SCN-010 parity.

Completion checklist:

• Enumerated every participant/agent-observable fact for this issue's surface.
• Encoded every ACES-expressible fact in scenarios/techvault.sdl.yaml.
• Filed and linked ACES blocker issue(s) for every observable fact ACES cannot express.
• Verified no evidence-only observable facts remain without SDL encoding or an ACES blocker.
• Updated the mapping ledger so every row is encoded or blocked by a specific ACES issue.
• Did not mark this issue complete based on evidence capture, representative samples, summaries, relevance judgments, or APTL consumption status.

For already-closed predecessor issues, this gate controls whether their artifacts may be credited toward final SCN-010 cutover; closure does not waive observable parity.

[Brad-Edwards]

🛠️ Picked up by /implement — driver Codex, branch 321-aces-runtime-handoff, 2026-06-13T06:18:54Z.

[Brad-Edwards]

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

GRC screening record — issue #321

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

Rationale: The diff routes APTL lab startup through the ACES SDL parser/runtime handoff and adds regression coverage. It does not create, modify, or claim coverage for Ground Control threat-model, control, risk-scenario, audit, evidence, or risk-register entities.

[Brad-Edwards]

gc workflow phase recorded: grc_screening (issue #321). 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: traceability_reconciled (issue #321). 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.

• SCN-010: status=ACTIVE, IMPLEMENTS=91, TESTS=43

[Brad-Edwards]

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

GRC verdict: not_security_relevant — no entity or code-link verification required.