Repository navigation
REP-003 — Author CAGE-2 (Scenario2) as an ACES SDL document #637
Description
REP-003 | FUNCTIONAL | MUST | Wave 4 | DRAFT
Requirements
- REP-003 — Author CAGE-2 (Scenario2) as an ACES SDL document
Statement
ACES shall provide a validated SDL document expressing the TTCP CAGE Challenge 2 (Scenario2) scenario, including its network topology (the three subnets: user hosts, enterprise servers, and the critical operational server subnet), hosts, services, identities, participants/agents (red and blue), and objectives. The document shall resolve, verify imports, and publish cleanly through the ACES reference implementation, and shall live under examples/scenarios in the aces repository.
Rationale
The single authored source of truth that both backends realize; expressing CAGE-2 in ACES SDL is the core of the replication claim.
Created from Ground Control requirement REP-003
Milestone: Paper Slice: CAGE-2 Replication (ACES-Driven Sim) (#58)
Design: REP-001 / #635.
Author the TTCP CAGE Challenge 2 (Scenario2) scenario as an ACES SDL document under examples/scenarios/ in this repo (aces). Cover the three subnets (user hosts / enterprise servers / critical operational server), hosts, services, identities, red+blue participants, and objectives. Must resolve, verify-imports, and publish cleanly.
This SDL document is the single authored source of truth that both backends (CybORG sim adapter, ACES reference backend) realize in REP-005.
Out of scope (deferred): CAGE-2 emulation-backend realization.
Activity
Brad-Edwards commentedon Jul 4, 2026
🛠️ Picked up by /implement — driver Claude Code, branch
637-REP-003-cage2-sdl, 2026-07-04T02:37:45Z.Brad-Edwards commentedon Jul 4, 2026
gc workflow phase recorded:
preflight(issue #637). 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 commentedon Jul 4, 2026
gc workflow phase recorded:
plan(issue #637). 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 — REP-003: Author CAGE-2 (Scenario2) as an ACES SDL document
Scope
Deliver the TTCP CAGE Challenge 2 (Scenario2) scenario as a positive, reusable ACES SDL example under
examples/scenarios/, authored entirely with existing SDL surfaces (ADR-069 /docs/decisions/cage-2-replication-design.md). This is the single authored source of truth both backends realize in REP-005. Emulation-backend realization is out of scope. The CAGE→ACES source-mapping ledger with upstream digests is downstreamaces-adapterswork (per the design layout); REP-003 records source provenance and mapping summary in a companion README, not a new SDL/schema surface.Source of truth (pinned)
Topology authored from the pinned upstream
Scenario2.yaml(cage-challenge/cage-challenge-2@26ce1c1253fa9e2e73f25e6a7f2da32860c11257,CybORG/CybORG/Shared/Scenarios/Scenario2.yaml) and ADR-069 source pins.Files
examples/scenarios/cage-2-scenario2.sdl.yaml— the scenario.examples/scenarios/cage-2-scenario2.README.md— companion doc (topology, participant identities, CAGE→ACES mapping summary + name mapping, source pins, resolve/verify/publish commands, loss disclosures, limitations, downstream links). Mirrors thepaper-agent-loop.README.mdprecedent.changelog.d/637.added.md— describe the new example (currently only mentions preflight guardrails).docs/decisions/issue-637-rep-003-cage-2-sdl-preflight.md(from Step 2.5).Scenario content (existing SDL sections only; no CAGE-specific keys)
nodes: 3 switches (user-net,enterprise-net,operational-net) + 13 VMs preserving CAGE host names (User0–4, Enterprise0–2, Defender, Op_Server0, Op_Host0–2). Every VM carriesresources(required to keepadvisories == []),os, and role-appropriateservices.Op_Server0carries the criticalot-serviceandasset_value(High availability / Medium confidentiality per CAGE).infrastructure: per-subnet CIDR/gateway/internal, host↔switchlinks(Enterprise0 bridges user↔enterprise; Op_Host0 bridges enterprise↔operational), andaclsrestricting inbound User→Operational (CAGE reachability rule).entities: red / blue / green / white (evaluator) teams.accounts: red foothold (SYSTEM privilege on User0) + representative green user accounts.agents: red variants (B-line, Meander, Sleep), blue defender (Monitor/Analyse/Remove/Restore/decoys/Sleep), green user — withinitial_knowledge,allowed_subnets,operating_scope,authority_anchors; red foothold = User0. Identities kept distinct.vulnerabilities: CWE-classified exploitable services along the red discover→exploit→escalate→impact path.relationships: pivot/monitoring edges (gateway reachability, blue monitors hosts).conditions→metrics→evaluations→tlos→goals: OT-service availability + Op_Server0 integrity scoring pipeline.objectives: red (reach/impact Op_Server0) and blue (protect OT service), bound to agents/targets/success.Verify (Step 4.4 loop, from
implementations/python/)uv run aces sdl resolve ../../examples/scenarios/cage-2-scenario2.sdl.yaml(self-contained; writes lockfile with empty imports).uv run aces sdl verify-imports ../../examples/scenarios/cage-2-scenario2.sdl.yaml.uv run aces sdl publish ../../examples/scenarios/cage-2-scenario2.sdl.yaml --output-dir <tmp>(do NOT commitdist/).uv run python -m pytest tests/test_scenarios.py tests/test_example_schema_conformance.py -q— auto-discovers the new file; must load with zero advisories and validate againstcontracts/schemas/sdl/sdl-authoring-input-v1.json.nox -s verify(repo policy, requirement governance, tests, docs). Ensure the generatedaces.lock.jsonnext to the scenario is either committed intentionally or removed; confirm nodist/artifacts are staged.Governance
Out of scope
CybORG adapter,
aces-adapters,sim_adapter_base, backend conformance, replication/equivalence evidence, emulation realization, and the digest-bearing source-mapping ledger (downstream REP-004/REP-005).Brad-Edwards commentedon Jul 4, 2026
gc_codex_review — cycle 1 of 1 (pre-push) on issue #637 (branch
637-REP-003-cage2-sdl)Core review
Verdict:
ship-with-fixesThe change is shaped mostly correctly: it adds CAGE-2 as a positive SDL corpus example, keeps the adapter/replication evidence out of the authored scenario, and uses existing SDL surfaces rather than creating CAGE-specific parser or schema vocabulary. The main design seam is the authored SDL representation of CAGE facts versus downstream realization; that seam is respected. The production-readiness issue is narrower: two red semantics in the SDL do not match the stated source-of-truth contract, so the document would publish as a valid-looking example while misrepresenting red variant execution and red success.
Blocking findings (2):
examples/scenarios/cage-2-scenario2.sdl.yaml:330red-impact-op-serverdeclares red success usingop-server-integrity, but that metric is backed byop-server-integrity-intact, whose condition succeeds when there is no red privileged session onOp_Server0. That inverts the red objective: the authored red-impact objective is satisfied by the blue/defensive state rather than by impact or compromise. Add a red-positive condition/metric or otherwise model the red success criterion without reusing the defensive integrity metric.examples/scenarios/cage-2-scenario2.sdl.yaml:271The README and scenario description state that the red policy variants share the
User0privileged foothold and that exactly one variant runs per episode, but onlyred-blinedeclaresstarting_accounts: [red-foothold].red-meanderandred-sleepare therefore authored with initial knowledge but no foothold account, which changes the CAGE-2 starting state for those variants.Security review
Verdict:
shipThis change is shaped as a data/documentation-only REP-003 addition: a positive SDL scenario, sidecar README, changelog entry, and preflight note. It stays on the existing SDL authoring surfaces and does not add parser behavior, backend execution paths, trust-policy exceptions, repository queries, auth boundaries, or publication code. The main security-relevant seam is the scenario-authoring boundary versus downstream adapter/runtime realization; this diff keeps credentials, hidden truth, evaluator details, and replication evidence described as authored scenario facts rather than operational secrets. I do not see a concrete exploitable issue introduced by the diff.
No blocking findings.
Brad-Edwards commentedon Jul 4, 2026
gc_codex_review pre-push cycle 1 of 1 complete for issue #637 on branch '637-REP-003-cage2-sdl'. 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 commentedon Jul 4, 2026
Review decision record — codex cycle 1 (issue #637)
Reviewer: codex
Cycle: 1
Architectural read:
Blocking findings: 2
Finding 1 —
one-offF1examples/scenarios/cage-2-scenario2.sdl.yaml:330red-impact-op-serverdeclares red success usingop-server-integrity, but that metric is backed byop-server-integrity-intact, whose condition succeeds when there is no red privileged session onOp_Server0. That inverts the red obje…Finding 2 —
class(2 instances)F2examples/scenarios/cage-2-scenario2.sdl.yaml:271User0privileged foothold and that exactly one variant runs per episode, but onlyred-blinedeclaresstarting_accounts: [red-foothold].red-meanderan…examples/scenarios/cage-2-scenario2.sdl.yaml:271examples/scenarios/cage-2-scenario2.sdl.yaml:282Brad-Edwards commentedon Jul 4, 2026
gc_review_cap_disposition — issue #637 (codex, cycle 1 of 1)
Disposition: proceed
Auto-override grant #: n/a
Rationale: Doc/unclassified surface only, purely additive diff, no security finding, and a small known finding shape (1 one-off + 1 class) — low risk enough to proceed without spending an over-cap cycle.
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 commentedon Jul 4, 2026
gc_test_quality_review cycle 1 of 1 — issue #637
Reviewer: test-quality (claude-sonnet-5 via gc_test_quality_review)
Branch:
637-REP-003-cage2-sdlCycle: 1 / 1
Findings: 0 (clean run)
Brad-Edwards commentedon Jul 4, 2026
gc_test_quality_review cycle 1 of 1 complete for issue #637 on branch '637-REP-003-cage2-sdl'. 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_reviewinvocation to count cycles.Brad-Edwards commentedon Jul 4, 2026
Review decision record — test-quality cycle 1 (issue #637)
Reviewer: test-quality
Cycle: 1
Blocking findings: 0 (clean run)
Brad-Edwards commentedon Jul 4, 2026
GRC screening record — issue #637
Schema:
gc.implement.grc-screening/v2Derived verdict:
security_relevant(computed from derived facts + the GRC coverage graph — not agent-asserted)Rationale: Docs/examples-only change: adds a positive ACES SDL example scenario (examples/scenarios/cage-2-scenario2.sdl.yaml, data consumed by the SDL parser via existing tests), a companion README, a changelog fragment, and a preflight note. No executable source, backend/runtime code, auth surface, trust policy, parser behavior, or secret handling is added or changed; the SDL is authored data validated by existing test suites and the published schema.
Provenance:
b61eb024a37be7114d3c5cce645ae9ce3c7ef1fb→ head52f9abfc7c3e2d1fa158cd1248d718ac27b3eb63none· architecture snapshot:noneCapture limits:
no_derivation_run: no derivation run for project; touched surface unclassified by adaptersImpact set (existing coverage the change touches) — 0:
Gap set (touched security-relevant surface with no coverage — must be modeled, controlled, or dispositioned before completion) — 1:
examples/scenarios/cage-2-scenario2.sdl.yaml— no_derivation_coverageStale set (linked entities whose underlying code changed) — 0:
Candidate threats (GC-GRC-007, deterministic) — 0:
Candidate controls (GC-GRC-008, deterministic) — 0:
Brad-Edwards commentedon Jul 4, 2026
gc workflow phase recorded:
grc_screening(issue #637). 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 commentedon Jul 4, 2026
Ready for review — REP-003 (Phase D complete)
PR #666 is ready to merge. All automated gates are green:
OK, 0 open issues, 0 hotspotsship-with-fixes→ 2 blocking findings fixed (red objective was scored by the defensive integrity metric;red-meander/red-sleeplacked the sharedred-foothold); security reviewship; cap dispositionproceednox -s verifypasses;aces sdl resolve/verify-imports/publishall succeed on the scenarioOne blocker to the automated readiness/completion record: the Step 3.5 GRC screening derived
security_relevantwith a single gap —examples/scenarios/cage-2-scenario2.sdl.yaml → no_derivation_coverage— whose capture limit isno_derivation_run("no derivation run for project; touched surface unclassified by adapters"). Impact set 0, stale set 0, candidate threats/controls 0. This is the known no-derivation-baseline false positive for a docs/examples-only change; Ground Control derivation is not wired for this repo.gc_assert_completion (pre_merge)therefore refused withgrc_not_reconciled. Clearing it cleanly needs a maintainer decision (audited GRC override vs. standing up a derivation baseline). Awaiting authorization — the workflow is paused at the merge touchpoint and no override has been self-applied.Next (Phase E, after merge + authorization): transition REP-003 DRAFT→ACTIVE, reconcile traceability (IMPLEMENTS:
examples/scenarios/cage-2-scenario2.sdl.yaml), and post the reconciled final report (with the authorized GRC disposition), then close the issue.1 remaining item
Brad-Edwards commentedon Jul 4, 2026
Progress note — REP-003 re-scoped and paused (blocked)
Scope correction. REP-003 was written narrowly ("author CAGE-2 as an ACES SDL document"). It is re-scoped to a full specification of the CAGE-2 environment AND experiment. (Issue wording should be updated to match.)
PR #666 closed as a premature partial. The initial
examples/scenarios/cage-2-scenario2.sdl.yamlpassed every gate (nox verify, CI, SonarCloud, codex + test-quality reviews) but was an under-specified first cut: three-subnet topology / hosts / identities / objectives skeleton only, with corners a full spec must not cut — placeholder service ports and invented CWEs instead of the real data in the pinned CybORG image files; participant actions named but not modeled (no action-contracts / observation-boundaries / behavior-specs); execution controls omitted. Branch637-REP-003-cage2-sdlretained for reference; do not merge.Semantics audit — what a full spec needs vs. what ACES implements today.
Authorable now: subnets / hosts / services / processes / listeners; OS family; local accounts (uid/gid/groups);
action-contracts;observation-boundaries(partial observability + discovery transitions);behavior-specifications;outcome-interpretation-rules; run count / allocation; seeds / stochastic controls; factors / conditions; red-variant selection; scenario-snapshot binding.Correction: plaintext credentials ARE representable via the
secret_fixtureclassification (#471 / ADR-057; used in TechVault). CAGE'spi/raspberryis expressible today — in a runtime field, not on theaccountsentry (see #673).Genuine blockers (facts a full CAGE-2 spec cannot express today) — #637 is
blocked_by:Node(CAGE hosts are x64; no field exists).Related open design questions (NOT blockers — the scenario doesn't depend on their outcome):
accountssurface should carry a plaintext credential value directly.Design through-line. ACES models ground truth (configuration, participants, actions, observations, execution); relational/perspectival claims (vulnerability, reward, score, "success") are prior/posterior to the system and belong in interpretation layers or as participant-informing content — not first-class environment/experiment semantics. Domain-neutrality corollary: ACES is an autonomous-organization-engineering foundation; cyber is one use case, so cyber-specific taxonomies (CWE) shouldn't be baked into the core.
Next. When #122 / #674 / #675 land, re-author the full spec from the pinned CybORG sources (all ten image files): real services / ports / OS / accounts / credentials; action-contracts + observation-boundaries + behavior-specs for the full action set; and the experiment (turn order, step count, termination, runs, seeds, red-variant) via the new authoring surface. Treat #671 / #676 / #673 as inputs to how objectives and weaknesses are expressed.
Brad-Edwards commentedon Aug 8, 2026
Closing won't-do: scope moved to the adapters repo. Per OpenRAE/hub#3, RAES owns semantics/contracts/conformance; scenario content belongs beside its adapter (as nasim/cyberbattlesim/primaite scenarios already do). REP-003's location clause (SDL under examples/scenarios in aces) violates that boundary. Authoring the full CAGE-2 (Scenario2) SDL now tracked in adapters milestone 'CybORG CAGE-2 Research Demonstrator': OpenRAE/adapters#77.