consider(authoring): CACAO/Attack Flow translation into SDL

[Brad-Edwards]

Question

Should env-packs provide design, authoring, or translation support that helps users turn CACAO playbooks or Attack Flow models into some useful part of a RAES SDL?

This is intentionally exploratory. It should not assume one-to-one semantic equivalence, a particular implementation shape, or that RAES core must own support for these external formats.

Areas to consider

• Whether the useful surface is guided authoring, import/translation, an intermediate projection, examples/templates, scenario kits, or documentation.
• Which CACAO and Attack Flow concepts can usefully inform SDL structure without overstating equivalence.
• Whether agents, targets, actors, assets, and related concepts could contribute to participant semantics or participant-oriented scaffolding.
• Whether ordering, branching, conditions, ATT&CK references, variables, provenance, and source-version information can be retained usefully.
• How ambiguous, unsupported, and lossy translations should remain visible to an author.
• Where mapping profiles, version compatibility, and translation-loss records would belong in the ecosystem.

Boundaries worth preserving

• The result should be ordinary SDL that RAES can validate; external artifacts should not become an alternate SDL authority.
• Translation support should not imply direct execution of CACAO or Attack Flow.
• Similar names should not be treated as proof of semantic equivalence.
• Generated output should not claim stronger semantics than the source supports.
• This should not require a RAES core extension unless exploration identifies a genuinely general SDL semantic gap.

Background

This question was previously framed as a core RAES SDL mapping contract in RAESystem/rae#660. With the ecosystem ownership boundaries now in place, it appears better treated as an env-packs authoring/design question first.