Simulate a JWCC Multi-Cloud Authorization

Onboard a DoD logistics pipeline across 4 clouds with a 44-agent AI swarm.

Introduction

30 Second Summary

Government organizations need to run mission workloads across multiple cloud providers, but the authorization process involves hundreds of security controls, architecture diagrams, and compliance evidence packages. Teams spend months preparing what an authorizing official needs to see before a single workload goes live.

In this project, you will architect a multi-cloud onboarding simulation that mirrors the JWCC pattern, using 44 AI agents in Cursor Composer to build Terraform modules, structure OSCAL evidence, and produce a presentation-ready authorization briefing in under an hour.

What You'll Build

A multi-cloud onboarding simulation covering engineering baseline through authorization package, with a 44-agent organization in Cursor Composer building provider modules, security controls, and compliance evidence in parallel while you make the architectural decisions.

By the end of this project, you'll have:

  • A cloud-agnostic Terraform baseline with provider-specific modules for AWS, Azure, Google Cloud, and OCI, validated by policy-as-code gates and proven portable across providers.
  • A tailored NIST 800-53 Rev 5 control set for an IL5-equivalent baseline with inheritance documented, evidence structured in OSCAL using compliance-trestle, and a capability-mapping layer that routes around provider gaps.
  • Presentation-ready artifacts including rendered boundary diagrams, an ATO-style briefing deck, an interactive compliance dashboard, and the full authorization package ready for a mock authorizing official.
  • Secret Mission: Test a provider failover against your mission's RPO and RTO, proving the capability-mapping layer absorbs an outage and updating the boundary for the failover state.

Are there any prerequisites?

This project assumes Terraform fluency (modules, workspaces, provider blocks), commercial accounts on AWS, Azure, Google Cloud, and OCI (free tiers sufficient), and familiarity with NIST RMF concepts at an architectural level. You also need Cursor with Composer access and Python 3.11+ with pip.

Set Up the Workspace, Agent Roster, and Mission Framing

Your toolchain is verified and ready. Before a single line of Terraform gets written, you need to draw the authorization boundary, define who builds what, and frame the mission.

This is the "boundary first" principle in action. The RMF authorization boundary is the anchor for every diagram, every control, and every architectural decision that follows. Nothing gets built until the boundary is drawn.

In this step, get ready to:
  • Define the 44-agent organization and encode standing rules for the swarm.
  • Frame the mission, draw the authorization boundary, and produce C4 diagrams and ADRs.
  • Scaffold the repository and initialize the capability parity matrix.
Define the agent roster and standing rules

The 44-agent swarm needs a rules file that encodes how every agent operates. The .cursorrules file tells Cursor Composer what constraints apply to every agent output.

  • Move to your Desktop by running this command:
cd ~\Desktop
  • Create the project folder, initialize a Git repository, and move into it by running these commands:
mkdir jwcc-simulation
cd jwcc-simulation
git init

What does this do?

This creates a jwcc-simulation folder on your Desktop and initializes it as a Git repository. All project artifacts live here.

  • Confirm the folder exists and Git initialized by running:
git status

You should see a message indicating you are on a new branch with no commits yet.

  • In Cursor, open the jwcc-simulation folder by clicking File in the top menu bar, then Open Folder, and selecting the jwcc-simulation folder on your Desktop.
  • Create a new file called .cursorrules in the root of the project by pressing Ctrl+N and saving immediately as .cursorrules.
  • Paste the following content into .cursorrules:
# JWCC Simulation Standing Rules

## Boundary-First Principle
- Every diagram references the RMF and FISMA authorization boundary
- Inherited controls marked explicitly (cite provider FedRAMP PA)
- CAP-equivalent boundary separate from provider FedRAMP authorization
- No fabricated control numbers (cite NIST 800-53 Rev 5 only)

## Evidence Discipline
- Evidence captured as you go (during build, not reconstructed)
- All controls reference implementation evidence (Terraform resource or Rego policy)
- OSCAL structured with compliance-trestle

## Artifact Standards
- All diagrams rendered as SVG (not raw markdown)
- Briefing artifacts are presentation-ready
- Parity matrix dated on every update
- ADRs follow Status/Context/Decision/Consequences format

What does this file do?

The .cursorrules file acts as the constitution for the agent swarm. Every agent output is checked against these rules. If a diagram does not reference the authorization boundary, it fails. If a control number is fabricated, it fails.

This is what lets 44 agents produce consistent, auditable work without constant operator correction.

  • Save .cursorrules.
  • Create a new file at agents/roster.yaml by creating the agents folder first, then creating roster.yaml inside it.
  • Paste the following content into agents/roster.yaml:
# 44-Agent Organization for JWCC Simulation
teams:
  mission_and_requirements:
    count: 4
    responsibilities:
      - Mission statement and scope
      - RPO/RTO targets
      - IL5-equivalent compliance requirements
      - Architectural principles

  reference_architecture:
    count: 6
    responsibilities:
      - C4 Context diagram
      - C4 Container diagram
      - System and security-boundary diagram
      - ADRs (architectural decisions)
      - Authorization boundary documentation
      - Deployment view diagrams

  terraform:
    count: 8
    responsibilities:
      - Cloud-agnostic interface (variables, outputs)
      - AWS provider module (2 agents)
      - Azure provider module (2 agents)
      - Google Cloud provider module (2 agents)
      - OCI provider module (2 agents)

  connectivity:
    count: 4
    responsibilities:
      - CAP-equivalent boundary (all providers)
      - Inspection egress routing
      - FIPS-validated crypto configuration
      - Network topology documentation

  control_set_and_rmf:
    count: 6
    responsibilities:
      - 800-53 Rev 5 family tailoring
      - Inheritance documentation
      - OSCAL structure and evidence linking
      - SSP drafting
      - POA&M management
      - Control-to-resource mapping

  capability_mapping:
    count: 4
    responsibilities:
      - Parity matrix maintenance
      - Gap detection and documentation
      - Fallback routing logic
      - Provider capability research

  validation_and_evidence:
    count: 6
    responsibilities:
      - Conftest Rego policy authoring
      - Checkov scanning configuration
      - Plan validation across providers
      - Evidence collection and linking
      - Compliance dashboard generation
      - Cross-provider parity checks

  authorization_readout:
    count: 6
    responsibilities:
      - ATO-style briefing deck (Marp)
      - SSP assembly and review
      - POA&M summary
      - Rendered diagram assembly
      - Compliance dashboard finalization
      - Lessons learned documentation

total_agents: 44

Why 44 agents across 8 teams?

Each team owns one domain of the authorization package. The Terraform team (8 agents) writes four provider modules in parallel. The Control Set team (6 agents) tailors 800-53 families while the engineering is happening. The Authorization-Readout team (6 agents) assembles the briefing while evidence is still being generated.

The parallelization is the point. Serial execution of this work would take a team days. The operator makes the architectural calls. The agents produce the artifacts.

  • Save agents/roster.yaml.
  • In Cursor Composer, verify the rules file is accepted by opening Composer and typing a test prompt such as: @agents list all teams and their agent counts.

Composer should respond referencing all 8 teams and 44 agents. If it does not pick up the roster, confirm that the jwcc-simulation folder is your active workspace in Cursor.

Composer not picking up the rules?

Make sure the .cursorrules file is saved at the root of jwcc-simulation (not inside a subfolder). Cursor reads rules from the workspace root.

If you opened a parent folder by mistake, close it and re-open specifically the jwcc-simulation folder.

Why isn't Cursor Composer picking up my .cursorrules file?

Frame the mission and draw the authorization boundary

With the swarm defined, you now direct the Mission and Requirements team (4 agents) and Reference Architecture team (6 agents) in parallel. They produce the mission statement, recovery targets, C4 diagrams, the signature boundary diagram, and the ADRs.

  • Open Cursor Composer and issue the following prompt to direct both teams simultaneously:
Using the Mission and Requirements team (4 agents) and Reference Architecture team (6 agents) simultaneously, produce the following artifacts:

## Mission and Requirements team output:
1. docs/mission/mission-statement.md containing:
   - Mission: fictional DoD mission partner onboarding a logistics data pipeline onto JWCC-equivalent commercial cloud
   - RPO: 15 minutes
   - RTO: 30 minutes
   - IL5-equivalent baseline: FedRAMP High ~410 controls plus IL5 delta families SC, PS, IA, IR, SR
   - Architectural principles: defense-in-depth, least privilege, boundary-explicit, provider portability where mission-justified

## Reference Architecture team output:
2. docs/diagrams/c4-context.mmd - Mermaid C4Context diagram showing: mission workload, four CSPs (AWS, Azure, Google Cloud, OCI), CAP-equivalent boundary, authorizing official, mission owner
3. docs/diagrams/c4-container.mmd - Mermaid C4Container diagram showing: Terraform control plane, provider modules, capability-mapping layer, boundary inspection, OpenBao secrets management
4. docs/diagrams/system-security-boundary.mmd - Mermaid diagram showing: RMF/FISMA authorization boundary drawn, inherited vs system-owned controls labeled, CAP-equivalent boundary distinct from provider FedRAMP boundary
5. docs/adr/ADR-001.md - Cloud-agnostic modules (Status: Accepted, Context/Decision/Consequences)
6. docs/adr/ADR-002.md - CAP-equivalent boundary (Status: Accepted)
7. docs/adr/ADR-003.md - Capability-mapping over abstraction (Status: Accepted)
8. docs/adr/ADR-004.md - OpenBao over Vault (Status: Accepted)
9. docs/adr/ADR-005.md - Conftest+Checkov over Trivy (Status: Accepted)

All diagrams must reference the RMF and FISMA authorization boundary per .cursorrules.
All ADRs must follow Status/Context/Decision/Consequences format.
Create the directory structure as needed.

What are these artifacts?

The C4 diagrams show the system at different zoom levels. The Context diagram is the 30,000-foot view. The Container diagram zooms into the technical building blocks. The system-security-boundary diagram is the signature artifact that defines what crosses the authorization boundary.

The ADRs (Architecture Decision Records) capture the five key decisions. Each records why the team chose this approach over the alternative, with consequences documented.

  • Review the Composer output. Confirm the mission statement includes RPO 15 min and RTO 30 min.
  • Confirm each ADR has all four sections: Status, Context, Decision, Consequences.
  • Render the Mermaid diagrams to SVG by running these commands in your terminal:
npx -y @mermaid-js/mermaid-cli mmdc -i docs/diagrams/c4-context.mmd -o docs/diagrams/c4-context.svg
npx -y @mermaid-js/mermaid-cli mmdc -i docs/diagrams/c4-container.mmd -o docs/diagrams/c4-container.svg
npx -y @mermaid-js/mermaid-cli mmdc -i docs/diagrams/system-security-boundary.mmd -o docs/diagrams/system-security-boundary.svg

Why render to SVG?

Raw Mermaid markdown is not presentation-ready. The standing rules require all diagrams rendered as SVG. These SVG files go directly into the ATO-style briefing deck later.

  • Open one of the rendered SVG files in your browser to confirm the diagram renders correctly with the authorization boundary visible.

You should see the authorization boundary drawn as a distinct region enclosing the system components, with inherited controls on the outside and system-owned controls labeled inside.

Mermaid CLI not rendering?

The npx command downloads the Mermaid CLI on first run. If it fails, check that Node.js is installed and your network can reach npm.

If the C4 diagram syntax produces an error, Mermaid's C4 support uses C4Context and C4Container as diagram type declarations. Confirm your .mmd files start with the correct type.

Help me debug why my Mermaid C4 diagrams are not rendering to SVG.

Scaffold the repository and initialize the capability map

The engineering directories need to exist before the Terraform team starts writing modules. You also need the initial parity matrix that maps mission capabilities to each JWCC provider BEFORE a line of infrastructure code is written.

  • Create the full directory scaffold by running this PowerShell command in your terminal:
# Create all project directories in one command
$dirs = @(
    "modules/interface",
    "modules/aws",
    "modules/azure",
    "modules/gcp",
    "modules/oci",
    "modules/shared",
    "boundary/cap-equivalent",
    "boundary/inspection",
    "capability-map",
    "policies/rego",
    "policies/checkov",
    "evidence/oscal",
    "evidence/ssp",
    "evidence/poam",
    "evidence/dashboard",
    "outputs/slides",
    "outputs/rendered"
)
$dirs | ForEach-Object { New-Item -Path $_ -ItemType Directory -Force | Out-Null }
Write-Host "Scaffold complete."

What does this create?

Each directory maps to a team's output domain. modules/ holds the Terraform team's work. boundary/ holds the Connectivity team's CAP-equivalent boundary. policies/ holds the Validation team's Rego and Checkov rules. evidence/ holds the OSCAL artifacts, SSP, and POA&M.

  • Confirm the directories exist by running:
Get-ChildItem -Recurse -Directory | Select-Object FullName

You should see all 17 directories listed under jwcc-simulation, plus the agents, docs/adr, docs/diagrams, and docs/mission directories created by Composer.

  • Create the placeholder Terraform root files by running:
New-Item -Path "terraform.tf" -ItemType File -Force | Out-Null
New-Item -Path "providers.tf" -ItemType File -Force | Out-Null
  • Now create the parity matrix. Create a new file at capability-map/parity-matrix.yaml and paste the following content:
# Capability Parity Matrix - JWCC Simulation
# Maps mission-required capabilities to each JWCC provider
# Last updated: 2026-07-03

mission_capabilities:
  identity:
    description: "Identity and access management with MFA, least privilege"
    aws:
      service: "IAM + AWS SSO"
      status: "available"
    azure:
      service: "Entra ID + Conditional Access"
      status: "available"
    gcp:
      service: "Cloud IAM + Identity Platform"
      status: "available"
    oci:
      service: "IAM with Identity Domains"
      status: "available"

  networking:
    description: "Virtual network with segmentation and inspection"
    aws:
      service: "VPC + Network Firewall"
      status: "available"
    azure:
      service: "VNet + Azure Firewall Premium"
      status: "available"
    gcp:
      service: "VPC + Cloud IDS"
      status: "available"
    oci:
      service: "VCN + Network Firewall"
      status: "available"

  data_classification:
    description: "Managed data discovery and classification for CUI"
    aws:
      service: "Macie"
      status: "available"
    azure:
      service: "Purview"
      status: "available"
    gcp:
      service: "DLP API"
      status: "limited"
      notes: "Different integration pattern, API-based not managed service"
    oci:
      service: "none"
      status: "unavailable"
      notes: "No equivalent managed service"

  state_storage:
    description: "Encrypted object and block storage"
    aws:
      service: "S3 + EBS (SSE-KMS)"
      status: "available"
    azure:
      service: "Blob Storage + Managed Disks (CMK)"
      status: "available"
    gcp:
      service: "Cloud Storage + Persistent Disk (CMEK)"
      status: "available"
    oci:
      service: "Object Storage + Block Volume (Vault)"
      status: "available"

  crypto:
    description: "FIPS-validated key management and encryption"
    aws:
      service: "KMS (FIPS 140-2 Level 3)"
      status: "available"
    azure:
      service: "Key Vault (FIPS 140-2 Level 2, HSM Level 3)"
      status: "available"
    gcp:
      service: "Cloud KMS (FIPS 140-2 Level 3)"
      status: "available"
    oci:
      service: "Vault (FIPS 140-2 Level 3)"
      status: "available"

  monitoring:
    description: "Centralized logging and audit trail"
    aws:
      service: "CloudTrail + CloudWatch"
      status: "available"
    azure:
      service: "Monitor + Log Analytics"
      status: "available"
    gcp:
      service: "Cloud Logging + Cloud Audit Logs"
      status: "available"
    oci:
      service: "Logging + Audit"
      status: "available"

Why map capabilities before writing Terraform?

This is "map capabilities, do not assume parity" in action. Four clouds do not have parity. OCI has no managed data classification service. Google Cloud's DLP API is a different integration pattern. If you wrote modules first, you would discover these gaps mid-build and need to refactor.

The parity matrix tells the capability-mapping layer where the gap is before the first resource block is written. In Step 3, this gap will break the baseline and force a fallback.

  • Save capability-map/parity-matrix.yaml.
  • Commit all work by running:
git add -A
git commit -m "Initial scaffold: agent roster, mission framing, boundary diagrams, parity matrix"
  • Confirm the commit by running:
git log --oneline

You should see a single commit with the message you just wrote.

Git commit fails?

If Git asks for your name and email, configure them first with git config user.name and git config user.email. These are required for commits.

If the commit is empty, confirm you ran git add -A from the jwcc-simulation root. Files must be staged before committing.

Help me fix my Git commit in the jwcc-simulation project.

✔️ Awesome, I've got everything!

Great. Double check that your initial commit includes .cursorrules, agents/roster.yaml, the docs/ directory with diagrams and ADRs, capability-map/parity-matrix.yaml, and the empty terraform.tf and providers.tf files.

ⓧ I'd like to double check the full code

Here are the key files in full for comparison.

# JWCC Simulation Standing Rules

## Boundary-First Principle
- Every diagram references the RMF and FISMA authorization boundary
- Inherited controls marked explicitly (cite provider FedRAMP PA)
- CAP-equivalent boundary separate from provider FedRAMP authorization
- No fabricated control numbers (cite NIST 800-53 Rev 5 only)

## Evidence Discipline
- Evidence captured as you go (during build, not reconstructed)
- All controls reference implementation evidence (Terraform resource or Rego policy)
- OSCAL structured with compliance-trestle

## Artifact Standards
- All diagrams rendered as SVG (not raw markdown)
- Briefing artifacts are presentation-ready
- Parity matrix dated on every update
- ADRs follow Status/Context/Decision/Consequences format
# 44-Agent Organization for JWCC Simulation
teams:
  mission_and_requirements:
    count: 4
    responsibilities:
      - Mission statement and scope
      - RPO/RTO targets
      - IL5-equivalent compliance requirements
      - Architectural principles

  reference_architecture:
    count: 6
    responsibilities:
      - C4 Context diagram
      - C4 Container diagram
      - System and security-boundary diagram
      - ADRs (architectural decisions)
      - Authorization boundary documentation
      - Deployment view diagrams

  terraform:
    count: 8
    responsibilities:
      - Cloud-agnostic interface (variables, outputs)
      - AWS provider module (2 agents)
      - Azure provider module (2 agents)
      - Google Cloud provider module (2 agents)
      - OCI provider module (2 agents)

  connectivity:
    count: 4
    responsibilities:
      - CAP-equivalent boundary (all providers)
      - Inspection egress routing
      - FIPS-validated crypto configuration
      - Network topology documentation

  control_set_and_rmf:
    count: 6
    responsibilities:
      - 800-53 Rev 5 family tailoring
      - Inheritance documentation
      - OSCAL structure and evidence linking
      - SSP drafting
      - POA&M management
      - Control-to-resource mapping

  capability_mapping:
    count: 4
    responsibilities:
      - Parity matrix maintenance
      - Gap detection and documentation
      - Fallback routing logic
      - Provider capability research

  validation_and_evidence:
    count: 6
    responsibilities:
      - Conftest Rego policy authoring
      - Checkov scanning configuration
      - Plan validation across providers
      - Evidence collection and linking
      - Compliance dashboard generation
      - Cross-provider parity checks

  authorization_readout:
    count: 6
    responsibilities:
      - ATO-style briefing deck (Marp)
      - SSP assembly and review
      - POA&M summary
      - Rendered diagram assembly
      - Compliance dashboard finalization
      - Lessons learned documentation

total_agents: 44
# Capability Parity Matrix - JWCC Simulation
# Maps mission-required capabilities to each JWCC provider
# Last updated: 2026-07-03

mission_capabilities:
  identity:
    description: "Identity and access management with MFA, least privilege"
    aws:
      service: "IAM + AWS SSO"
      status: "available"
    azure:
      service: "Entra ID + Conditional Access"
      status: "available"
    gcp:
      service: "Cloud IAM + Identity Platform"
      status: "available"
    oci:
      service: "IAM with Identity Domains"
      status: "available"

  networking:
    description: "Virtual network with segmentation and inspection"
    aws:
      service: "VPC + Network Firewall"
      status: "available"
    azure:
      service: "VNet + Azure Firewall Premium"
      status: "available"
    gcp:
      service: "VPC + Cloud IDS"
      status: "available"
    oci:
      service: "VCN + Network Firewall"
      status: "available"

  data_classification:
    description: "Managed data discovery and classification for CUI"
    aws:
      service: "Macie"
      status: "available"
    azure:
      service: "Purview"
      status: "available"
    gcp:
      service: "DLP API"
      status: "limited"
      notes: "Different integration pattern, API-based not managed service"
    oci:
      service: "none"
      status: "unavailable"
      notes: "No equivalent managed service"

  state_storage:
    description: "Encrypted object and block storage"
    aws:
      service: "S3 + EBS (SSE-KMS)"
      status: "available"
    azure:
      service: "Blob Storage + Managed Disks (CMK)"
      status: "available"
    gcp:
      service: "Cloud Storage + Persistent Disk (CMEK)"
      status: "available"
    oci:
      service: "Object Storage + Block Volume (Vault)"
      status: "available"

  crypto:
    description: "FIPS-validated key management and encryption"
    aws:
      service: "KMS (FIPS 140-2 Level 3)"
      status: "available"
    azure:
      service: "Key Vault (FIPS 140-2 Level 2, HSM Level 3)"
      status: "available"
    gcp:
      service: "Cloud KMS (FIPS 140-2 Level 3)"
      status: "available"
    oci:
      service: "Vault (FIPS 140-2 Level 3)"
      status: "available"

  monitoring:
    description: "Centralized logging and audit trail"
    aws:
      service: "CloudTrail + CloudWatch"
      status: "available"
    azure:
      service: "Monitor + Log Analytics"
      status: "available"
    gcp:
      service: "Cloud Logging + Cloud Audit Logs"
      status: "available"
    oci:
      service: "Logging + Audit"
      status: "available"

Your workspace is scaffolded, the swarm is defined, the boundary is drawn, and the parity matrix is already surfacing where the agnostic baseline will break. Next up, the Terraform team fans out to build the cloud-agnostic interface and four provider modules in parallel.

Build the Cloud-Agnostic Baseline and Four Provider Modules

Your boundary is drawn, your diagrams are rendered, and your 44-agent organization is ready to execute. Now it is time to fan out the build.

In this step, eight Terraform agents write four provider modules in parallel while four Connectivity agents build the CAP-equivalent boundary simultaneously. Six Validation agents write the policy-as-code gates. You review, resolve conflicts, and make the architectural calls.

In this step, get ready to:
  • Define a common Terraform interface and build provider-specific modules for AWS, Azure, Google Cloud, and OCI.
  • Construct the CAP-equivalent network boundary with inspection egress and FIPS-validated cryptography.
  • Write and run policy-as-code validation across all four providers using Conftest and Checkov.
Define the common interface and build provider modules in parallel

A multi-cloud baseline is not write-once-run-anywhere. Four clouds do not have parity. The pattern is a common interface backed by provider-specific modules, each implementing the same contract with native resources.

  • In Cursor Composer, instruct the Terraform team (8 agents) to build the common interface and four provider modules simultaneously by sending this prompt:
@Terraform team

Build the common Terraform interface and four provider modules in parallel.

## Common Interface (modules/interface/)

### variables.tf
- name (string)
- size_class (string: small/medium/large)
- region (string)
- encryption_required (bool, default true)
- network_id (string)
- tags (map of strings)
- Size mapping locals: small/medium/large mapped to provider-specific instance types
  (small: t3.small / Standard_B1ms / e2-small / VM.Standard.E4.Flex)
  (medium: t3.medium / Standard_B2ms / e2-medium / VM.Standard.E4.Flex 2 OCPU)
  (large: t3.large / Standard_B4ms / e2-standard-4 / VM.Standard.E4.Flex 4 OCPU)

### outputs.tf
- instance_id
- private_ip
- public_ip
- network_id
- encryption_status

## Three primitives per module: compute, network (VPC/VNet/VCN), encryption (KMS)

## Provider Modules (implement common interface, each in its own directory):

### modules/aws/main.tf
- aws_instance, aws_vpc, aws_kms_key
- AES-256 encryption, FIPS endpoint for KMS
- Tag all resources with authorization_boundary = "jwcc-simulation-il5"

### modules/azure/main.tf
- azurerm_linux_virtual_machine, azurerm_virtual_network, azurerm_key_vault
- HSM-backed Key Vault, encryption at rest/transit
- Tag all resources with authorization_boundary = "jwcc-simulation-il5"

### modules/gcp/main.tf
- google_compute_instance, google_compute_network, google_kms_crypto_key
- Customer-managed encryption keys, encryption at rest/transit
- Label all resources with authorization_boundary = "jwcc-simulation-il5"

### modules/oci/main.tf
- oci_core_instance, oci_core_vcn, oci_kms_vault
- Vault with HSM protection mode, encryption at rest/transit
- Tag all resources with authorization_boundary = "jwcc-simulation-il5"

Each module must:
1. Accept the same variables as the common interface
2. Output the same schema (instance_id, private_ip, public_ip, network_id, encryption_status)
3. Include inline comments referencing the authorization boundary
4. Apply provider-specific hardening (IMDSv2 on AWS, trusted launch on Azure, shielded VM on GCP, secure boot on OCI)

What does this prompt produce?

The 8 Terraform agents split into pairs and write simultaneously. Two agents per provider produce the module while referencing the common interface contract from modules/interface/.

  • The common interface defines abstract sizes (small/medium/large) mapped to real instance types via locals. This prevents leaking provider-specific names into the calling code.
  • Each provider module wraps native resources (aws_instance, azurerm_linux_virtual_machine, etc.) behind the same variable and output contract.
  • The authorization_boundary tag on every resource links it back to the RMF boundary diagram from Step 1.
  • Review the generated files in your editor. Confirm that each module directory (modules/aws/, modules/azure/, modules/gcp/, modules/oci/) contains a main.tf implementing all three primitives.
  • Validate the interface module by running this command in your terminal:
cd modules/interface && terraform validate
  • Validate each provider module independently by running:
cd ../aws && terraform init && terraform validate
cd ../azure && terraform init && terraform validate
cd ../gcp && terraform init && terraform validate
cd ../oci && terraform init && terraform validate

You should see Success! The configuration is valid. for each module.

  • Run terraform plan for each provider module to confirm the baseline plans successfully:
cd ../aws && terraform plan -out=aws.tfplan
cd ../azure && terraform plan -out=azure.tfplan
cd ../gcp && terraform plan -out=gcp.tfplan
cd ../oci && terraform plan -out=oci.tfplan

Each plan should succeed and show resources to be created. Confirm the outputs match the common schema: instance_id, private_ip, public_ip, network_id, encryption_status.

Seeing validation errors?

  • If terraform init fails, check that your provider CLIs are authenticated to the correct accounts (aws sts get-caller-identity, az account show, gcloud auth list, oci iam user list).
  • If a module references a variable not defined in the interface, instruct the agent to align outputs with modules/interface/outputs.tf.
  • If size mapping locals are missing, confirm modules/interface/variables.tf includes the locals block mapping size_class to provider instance types.

Ask for help: My Terraform modules are failing validation. Can you help me debug the interface contract mismatch?

Build the CAP-equivalent boundary and FIPS-validated crypto

In a real DoD deployment, the Cloud Access Point (CAP) is the DoDIN-to-cloud connection managed by DISA. Your commercial simulation mirrors this with transit networks and inspection firewalls on each provider.

What is the CAP-equivalent boundary?

SC-7 boundary protection requires logical separation with inspection and authorization required for traversal. The CAP-equivalent boundary ensures no workload reaches the internet without passing through an inspection layer first.

Each provider implements this differently: AWS uses Transit VPC with Network Firewall, Azure uses a Hub VNet with Azure Firewall Premium, Google Cloud uses Shared VPC with Cloud IDS, and OCI uses a DRG with Network Firewall. The principle is the same across all four.

  • Instruct the Connectivity team (4 agents) to build the CAP-equivalent boundary by sending this prompt in Composer:
@Connectivity team

Build the CAP-equivalent network boundary for all four providers simultaneously.
All files go in boundary/cap-equivalent/.

## Requirements (SC-7 compliance)
- ALL egress must route through inspection. No direct internet breakout.
- Logical separation between workload subnets and public-facing components.
- Inspection and authorization required for traversal.

## Provider implementations:

### boundary/cap-equivalent/aws.tf
- Transit VPC as the central hub
- AWS Network Firewall for stateful inspection
- TLS inspection enabled
- Route tables forcing all workload egress through the firewall
- No 0.0.0.0/0 route on workload subnets

### boundary/cap-equivalent/azure.tf
- Hub VNet with Azure Firewall Premium
- TLS inspection via Firewall Premium SKU
- User-defined routes on spoke subnets pointing to the firewall
- No direct internet route on workload subnets

### boundary/cap-equivalent/gcp.tf
- Shared VPC as the host project
- Cloud IDS for threat detection
- Packet mirroring for inspection
- Firewall rules denying direct egress from service projects

### boundary/cap-equivalent/oci.tf
- DRG (Dynamic Routing Gateway) as the central hub
- OCI Network Firewall for stateful inspection
- Route tables forcing workload VCN egress through the DRG to the firewall
- No direct internet gateway on workload subnets

## FIPS-validated cryptography:
- Transit: TLS 1.2+ with AES-GCM-256 and ECDHE cipher suites
- Rest: Provider-native KMS with FIPS 140-2/140-3 validated modules
- Reference FIPS endpoints where available (e.g., AWS KMS FIPS endpoint)

Include inline comments on every resource referencing SC-7 and the authorization boundary.

What does each boundary file implement?

  • AWS: Transit VPC acts as a hub. Network Firewall performs stateful inspection. All spoke VPC route tables point egress at the firewall.
  • Azure: Hub VNet with Azure Firewall Premium handles TLS inspection. User-defined routes on spoke subnets force traffic through the firewall.
  • Google Cloud: Shared VPC separates the host project from service projects. Cloud IDS and packet mirroring provide the inspection layer.
  • OCI: The DRG connects VCNs. OCI Network Firewall inspects all traffic traversing the DRG before it can reach the internet gateway.
  • Review the generated files in boundary/cap-equivalent/. Confirm each file exists and references SC-7.
  • Verify no direct internet breakout by checking that no workload subnet has a 0.0.0.0/0 route pointing directly to an internet gateway.
  • Validate the boundary configuration by running:
cd boundary/cap-equivalent && terraform init && terraform validate

You should see Success! The configuration is valid. confirming the boundary module is syntactically correct.

Validation fails on the boundary module?

  • Check that provider blocks are included or inherited. Each .tf file in boundary/cap-equivalent/ needs the appropriate provider configured.
  • If the agents generated resources without a required_providers block, instruct them to add one referencing the correct provider source and version.

Ask for help: My CAP-equivalent boundary files are failing terraform validate. How do I fix provider configuration?

Run policy-as-code validation across all providers

Policy-as-code is how you prove compliance is real. A control without evidence fails the bar. The Validation and Evidence team writes Rego policies that map directly to NIST 800-53 Rev 5 controls and runs them against every provider's plan output.

Why Conftest and Checkov together?

Conftest lets you write custom Rego policies for your specific 800-53 controls. It validates structured data including Terraform plan JSON.

Checkov provides over 1000 built-in policies covering CIS, NIST, and SOC 2 with graph-based cross-resource analysis. Together they cover custom control validation plus broad baseline scanning without any dependency on compromised tools.

  • Instruct the Validation and Evidence team (6 agents) to write the Rego policies and run validation by sending this prompt:
@Validation and Evidence team

Write Conftest Rego policies and run validation across all four providers.

## Rego Policies (in policies/rego/):

### policies/rego/sc7_boundary.rego
- Package: main
- Rule: deny if any security group or firewall rule allows ingress from 0.0.0.0/0 on any port
- Maps to: NIST 800-53 SC-7 (Boundary Protection)

### policies/rego/sc7_egress.rego
- Package: main
- Rule: deny if any subnet has a route to an internet gateway without passing through inspection (transit/firewall)
- Maps to: NIST 800-53 SC-7 (Boundary Protection - egress filtering)

### policies/rego/sc28_encryption.rego
- Package: main
- Rule: deny if any storage resource or compute disk lacks encryption at rest
- Maps to: NIST 800-53 SC-28 (Protection of Information at Rest)

### policies/rego/sc8_transmission.rego
- Package: main
- Rule: deny if any listener or endpoint does not enforce TLS 1.2 or higher
- Maps to: NIST 800-53 SC-8 (Transmission Confidentiality and Integrity)

Each policy file must:
1. Include a comment header citing the 800-53 control ID and title
2. Use deny[] rules that return descriptive violation messages
3. Work against terraform plan JSON output (resource_changes format)

## After writing policies, validate:
1. Export terraform plan to JSON for each provider
2. Run conftest against each plan
3. Run checkov across the full directory

What do these policies enforce?

  • sc7_boundary.rego catches any security group or firewall rule that allows unrestricted ingress (0.0.0.0/0) on any port. This is the most common misconfiguration in cloud deployments.
  • sc7_egress.rego ensures all subnets route through inspection. No workload can reach the internet without passing through the CAP-equivalent boundary.
  • sc28_encryption.rego verifies that every storage volume and compute disk is encrypted at rest. Unencrypted data at IL5 is a hard failure.
  • sc8_transmission.rego checks that all endpoints enforce TLS 1.2+ for data in transit. This aligns with the FIPS-validated cipher suite requirement.
  • After the agents generate the policies, export each provider's plan to JSON and run Conftest against it:
# Export plans to JSON for policy testing
cd modules/aws && terraform show -json aws.tfplan > aws-plan.json
cd ../azure && terraform show -json azure.tfplan > azure-plan.json
cd ../gcp && terraform show -json gcp.tfplan > gcp-plan.json
cd ../oci && terraform show -json oci.tfplan > oci-plan.json

# Run Conftest against each plan
conftest test -p ../../policies/rego/ aws-plan.json
conftest test -p ../../policies/rego/ azure-plan.json
conftest test -p ../../policies/rego/ gcp-plan.json
conftest test -p ../../policies/rego/ oci-plan.json

What does the Conftest output look like?

A passing result shows the number of tests run with zero failures. If a policy denies, Conftest prints the violation message from your Rego rule, telling you exactly which resource and which control failed.

  • Run Checkov across the entire project directory to catch any findings the custom Rego policies do not cover:
checkov -d . --framework terraform

Checkov should report no HIGH findings across all four providers. If any HIGH findings appear, instruct the relevant agent team to remediate before continuing.

  • Compare outputs across all four providers to confirm interface parity. Each module should produce the same output keys with provider-specific values.

Conftest reporting denials?

  • If sc7_boundary.rego denies, a security group or firewall rule has 0.0.0.0/0 ingress. Instruct the Terraform agents to restrict the CIDR to the workload subnet range.
  • If sc7_egress.rego denies, a subnet routes directly to an internet gateway. Instruct the Connectivity agents to route through the inspection firewall instead.
  • If sc28_encryption.rego denies, a storage or compute resource lacks encryption. Add the KMS key reference to the resource in the provider module.
  • If Checkov reports HIGH findings, read the check ID (e.g., CKV_AWS_123) and instruct the agent to fix that specific resource.

Ask for help: My Conftest policies are denying on my Terraform plans. Can you help me trace which resource is violating the SC-7 or SC-28 control?

✔️ Awesome, I've got everything!

All four providers validate, plan successfully, and pass your policy gates. The baseline is proven.

ⓧ I'd like to double check the full structure

Your project should now contain these key files with the following responsibilities:

  • modules/interface/variables.tf defines name, size_class, region, encryption_required, network_id, tags, and the size mapping locals.
  • modules/interface/outputs.tf defines instance_id, private_ip, public_ip, network_id, encryption_status.
  • modules/aws/main.tf implements aws_instance, aws_vpc, aws_kms_key with AES-256 and FIPS endpoint. Tags with authorization boundary identifier.
  • modules/azure/main.tf implements azurerm_linux_virtual_machine, azurerm_virtual_network, azurerm_key_vault (HSM-backed). Tags with authorization boundary identifier.
  • modules/gcp/main.tf implements google_compute_instance, google_compute_network, google_kms_crypto_key. Labels with authorization boundary identifier.
  • modules/oci/main.tf implements oci_core_instance, oci_core_vcn, oci_kms_vault. Tags with authorization boundary identifier.
  • boundary/cap-equivalent/aws.tf builds Transit VPC, Network Firewall, TLS inspection. All egress through inspection.
  • boundary/cap-equivalent/azure.tf builds Hub VNet, Azure Firewall Premium, TLS inspection. All egress through inspection.
  • boundary/cap-equivalent/gcp.tf builds Shared VPC, Cloud IDS, packet mirroring. All egress through inspection.
  • boundary/cap-equivalent/oci.tf builds DRG, Network Firewall. All egress through inspection.
  • policies/rego/sc7_boundary.rego denies unrestricted ingress (0.0.0.0/0) on any port.
  • policies/rego/sc7_egress.rego denies subnets routing without inspection/transit.
  • policies/rego/sc28_encryption.rego denies unencrypted storage/compute.
  • policies/rego/sc8_transmission.rego denies endpoints not enforcing TLS 1.2+.

Your cloud-agnostic baseline is proven across four providers with boundary protection and encryption validated by automated policy. Next up, you will break this baseline on purpose by introducing a capability gap and proving the fallback.

Surface the Capability Gap and Prove Portability

Your cloud-agnostic baseline plans on all four providers. That sounds like success, but it hides a dangerous assumption: that every provider offers the same capabilities.

In this step, you will break that assumption deliberately. The Capability-Mapping team will surface a real gap in the JWCC provider set, you will build a routing layer that handles it, and you will prove portability by landing the mission workload on more than one provider.

In this step, get ready to:
  • Introduce a real capability gap where the cloud-agnostic baseline breaks.
  • Build a capability-mapping layer that routes workloads around the gap.
  • Prove portability by landing the mission on a second provider.
Introduce the capability gap

The mission requires managed data classification and discovery for its logistics data pipeline. This maps to controls SC-28 (Protection of Information at Rest) and AU-12 (Audit Record Generation).

Not all four providers support this natively. AWS has Macie, Azure has Purview, Google Cloud has only the DLP API (different integration pattern), and OCI has no equivalent at all. This is where the cloud-agnostic baseline breaks.

  • In Cursor Composer, direct the Capability-Mapping team (4 agents) to document the gap by creating capability-map/gap-analysis.md with the following prompt:
@capability-mapping-team

Document the capability gap in capability-map/gap-analysis.md:

1. The mission requires managed data classification/discovery (SC-28, AU-12)
2. Provider support:
   - AWS: Macie (fully supported, native integration)
   - Azure: Purview (fully supported, native integration)
   - Google Cloud: DLP API (limited, different integration pattern)
   - OCI: No equivalent managed service (GAP)
3. Impact on authorization boundary: a workload requiring data classification
   cannot land on a provider that lacks it without compensating controls
4. Include the honest caveat: provider capabilities change over time,
   this parity matrix is dated as of today

Do NOT paper over the gap. The gap is the point.

Why document the gap instead of working around it silently?

In a real JWCC onboarding, a missing capability affects the authorization boundary. If a workload requiring data classification lands on a provider without it, the system lacks a required control implementation.

Documenting the gap forces an explicit routing decision. The authorizing official needs to see where controls are covered and where they are not.

  • Review the generated gap-analysis.md and confirm it contains: which capability is missing, which providers support it natively, the impact on the authorization boundary, and the honest caveat about dated provider capabilities.

Now confirm the gap is real in Terraform. The OCI module should fail or produce degraded output when you attempt to plan with data-classification enabled.

  • Run terraform plan targeting the OCI module with data classification required, confirming it fails or produces degraded output:
terraform plan -target=module.oci -var="data_classification_required=true"

What should I see?

The plan should fail or produce a warning indicating that the data-classification capability has no implementation on OCI. This confirms the gap is enforced in infrastructure code, not just documented in prose.

Plan succeeds without errors?

If the OCI plan passes cleanly, the module is not gating on the data-classification capability. Direct the Terraform agents to add a validation block or precondition in the OCI module that fails when data_classification_required is true.

The gap must be enforced, not papered over. Help me enforce the data-classification gap in Terraform so the OCI plan fails when the capability is required.

Build the capability-mapping layer

The gap is documented and enforced. Now you need a routing layer that uses the parity matrix to place workloads on providers that actually support their required capabilities.

  • Direct the Capability-Mapping team to update capability-map/parity-matrix.yaml with the gap finding and fallback order by running this prompt:
@capability-mapping-team

Update capability-map/parity-matrix.yaml:

1. Set data_classification capability status:
   - aws: supported (service: macie)
   - azure: supported (service: purview)
   - gcp: limited (service: dlp_api, note: different integration pattern)
   - oci: gap (service: none)
2. Add fallback_order for data_classification: [aws, azure]
3. Date the matrix entry with today's date
4. Add a metadata note: "Provider capabilities change. This matrix
   is dated and must be re-validated before each authorization decision."

What does this code do?

The updated parity matrix now records the gap as structured data, not just prose. The fallback_order field tells the capability router which providers can accept data-classification workloads and in what priority.

  • Next, direct the team to create the capability router. This is the Terraform that reads the parity matrix and routes workload placement by required capabilities. Prompt Cursor Composer with:
@capability-mapping-team

Create capability-map/capability-router.tf:

1. Read the parity matrix from capability-map/parity-matrix.yaml
   using yamldecode(file(...))
2. For each mission capability, determine which providers support it
3. For data_classification: route to the first provider in fallback_order
   that has status "supported" (AWS or Azure)
4. Skip OCI for data-classification workloads
5. Record degradation: output which capabilities were routed away
   from the primary provider and why
6. The core workload (compute, network, crypto) can land on any provider
   since all four support those capabilities

The router must be proven by execution, not asserted.

What does the capability router do?

The router separates the mission into individual capabilities and places each one on a provider that supports it. Core capabilities (compute, network, encryption) land on any provider. Specialized capabilities (data classification) route only to providers with native support.

This is the "map capabilities, do not assume parity" principle in action. The routing is data-driven from the parity matrix, not hardcoded.

  • Review the generated capability-router.tf and confirm it reads the parity matrix, routes data-classification to AWS or Azure, and records degradation when a provider is skipped.
  • Run terraform validate on the capability-map directory to confirm the router parses correctly:
terraform validate
  • You should see Success! The configuration is valid. confirming the router logic is syntactically correct.

Seeing a YAML decode error?

If terraform validate fails with a decode error, the parity matrix YAML likely has an indentation or syntax issue. Open capability-map/parity-matrix.yaml and check that the YAML parses cleanly.

Help me fix a YAML parsing error in my parity matrix file.

Prove portability and document the decision

A baseline that only runs on one provider is not portable. It is just an implementation. You need to prove the core workload plans successfully on a second provider while the data-classification capability routes to its supported provider via the capability router.

  • Run terraform plan targeting a second provider (different from your primary) to prove the core workload lands successfully:
terraform plan -target=module.azure

What should I see?

The plan should succeed, showing resources for compute, network, and encryption on the alternate provider. The common outputs (instance reachable, network segmented, encryption active) should match what the primary provider produces.

The data-classification capability routes separately to AWS or Azure via the capability router, regardless of which provider runs the core workload.

  • Confirm the common outputs match between your primary and alternate provider plans. Both should produce instance_id, private_ip, network_id, and encryption_status.
  • Direct the Capability-Mapping team to document the portability proof by creating capability-map/portability-proof.md with this prompt:
@capability-mapping-team

Create capability-map/portability-proof.md documenting:

1. Which capabilities landed where:
   - Core workload (compute, network, crypto): proven on Provider A and Provider B
   - Data classification: routed to AWS/Azure via capability router
2. Which provider is primary, which is fallback, and why
3. The decision rationale for the routing
4. Honest caveat: a provider move is a significant change that
   re-inherits controls, re-draws the authorization boundary,
   and returns to the authorizing official. It is not a free swap.
5. A baseline that only ran on one provider fails the portability bar.

Why is the caveat about provider moves important?

In a real NIST RMF authorization, switching providers changes which controls are inherited from the provider's existing FedRAMP authorization. New inherited controls must be validated. The system boundary diagram changes. The authorizing official must review.

Portability does not mean free swapping. It means the baseline is proven on more than one provider so the option exists when mission-justified.

  • Review portability-proof.md and confirm it records: which capabilities landed where, the primary/fallback provider pair, the decision rationale, and the re-authorization caveat.
  • Commit all three new files to Git by running:
git add capability-map/gap-analysis.md capability-map/parity-matrix.yaml capability-map/capability-router.tf capability-map/portability-proof.md
git commit -m "Step 3: capability gap, routing layer, portability proof"

Terraform plan fails on the second provider?

If the alternate provider plan fails, check that the provider module implements all three common interface outputs (instance_id, network_id, encryption_status). Also verify that your CLI is authenticated to that provider's commercial account.

Help me debug why terraform plan is failing on my alternate provider.

Your capability gap is surfaced, documented, and enforced. The routing layer handles it. The baseline is proven on more than one provider. Next, you will tailor the 800-53 control set, structure the evidence in OSCAL, and generate the compliance dashboard that ties every control to its implementation.

Tailor the Control Set and Structure OSCAL Evidence

The engineering baseline is built, the boundary protects, and the capability gap is documented with its fallback.

Now the compliance arc integrates. The NIST 800-53 Rev 5 control families are tailored for the IL5-equivalent baseline, inheritance is documented against each provider's FedRAMP High authorization, and evidence is structured in OSCAL during the build. Controls are captured now, not reconstructed for an assessor at the end.

In this step, get ready to:
  • Tailor the IL5-equivalent control set with inheritance documented for each load-bearing family.
  • Structure evidence in OSCAL with compliance-trestle and generate the interactive compliance dashboard.
  • Validate that every system-owned control has policy-as-code coverage and all named bars pass.
Tailor the IL5-equivalent control set

The FedRAMP High baseline covers approximately 410 controls across 18 control families. IL5 adds the CNSSI 1253 NSS overlay on top. Your job is to document which controls the provider's existing FedRAMP authorization already covers (inherited), which your system implements (system-owned), and which split responsibility (shared).

  • In Cursor Composer, address the Control Set and RMF team (6 agents) with this prompt:
@control-set-rmf Tailor the FedRAMP High baseline for our IL5-equivalent mission.

Produce evidence/oscal/control-tailoring.yaml covering these load-bearing families:
- AC (Access Control) and IA (Identification and Authentication)
- SC (System and Communications Protection)
- AU (Audit and Accountability)
- CM (Configuration Management)
- CA (Assessment, Authorization, and Monitoring)
- IR (Incident Response)
- CP (Contingency Planning)

Plus the IL5 delta families: SC, PS, IA, IR, SR.

For EACH control in these families, mark it as:
- inherited: cite the provider's FedRAMP Provisional Authorization (PA)
- system-owned: reference the Terraform resource or Conftest/Checkov policy that implements it
- shared: document both the provider's responsibility and ours

No orphan controls. Every control has an implementation reference.
Reference boundary/cap-equivalent/ for SC-7, policies/rego/ for SC-8/SC-28, and modules/ for encryption.

What does this tailoring produce?

The agents produce evidence/oscal/control-tailoring.yaml with every control in the load-bearing families categorized. Inherited controls cite the provider's PA number. System-owned controls point to the exact Terraform resource or Rego policy file. Shared controls document both sides.

This is the 'evidence as you go' principle. The tailoring happens during the build, linked to the resources that already exist, not reconstructed months later for an assessor.

  • Review the generated evidence/oscal/control-tailoring.yaml in the Explorer sidebar.
  • Verify that SC-7 (boundary protection) references boundary/cap-equivalent/ as the system-owned implementation.
  • Verify that SC-28 references policies/rego/sc28_encryption.rego and the provider KMS resources in the modules.
  • Confirm no control is left without an implementation reference (no orphans).

Seeing orphan controls in the output?

If any control shows no implementation reference, check that the prompt referenced the correct directories. The agents need visibility into boundary/, policies/rego/, and modules/ to map system-owned controls.

Re-prompt the Control Set team specifying the missing control IDs and the resources that implement them. Help me fix orphan controls in my tailoring output

Structure evidence in OSCAL and generate the compliance dashboard

With the control tailoring complete, the evidence needs a machine-readable structure. compliance-trestle provides the OSCAL tooling to initialize a workspace, import the NIST catalog, and scaffold the SSP.

  • Switch back to your terminal inside the jwcc-simulation directory.
  • Initialize the compliance-trestle workspace by running these commands:
cd evidence/oscal
trestle init
  • Import the NIST 800-53 Rev 5 catalog by running:
trestle import -f nist-800-53-rev5-catalog.json -o nist-rev5
  • Create the SSP shell for the simulation by running:
trestle create -t ssp -o jwcc-simulation-ssp

What do these commands do?

  • trestle init creates the workspace directory structure that compliance-trestle expects (catalogs, profiles, component-definitions, system-security-plans).
  • trestle import brings the NIST 800-53 Rev 5 catalog into the workspace so controls can be referenced by ID.
  • trestle create -t ssp scaffolds a bare System Security Plan that you populate with control implementation statements.

Command not found for trestle?

If trestle is not recognized, confirm it was installed in Step 1 with pip install compliance-trestle. If you used a virtual environment, make sure it is activated.

Help me troubleshoot trestle not being found

  • Return to Cursor Composer and address the Control Set and RMF team plus the Validation and Evidence team (12 agents total) with this prompt:
@control-set-rmf @validation-evidence Structure the OSCAL evidence for our JWCC simulation.

Using the control-tailoring.yaml and the trestle workspace just initialized, produce:

1. evidence/oscal/component-definition.json
   - Map each system-owned control to its implementation:
     - Terraform resource (e.g., boundary/cap-equivalent/aws.tf for SC-7)
     - Conftest Rego policy (e.g., policies/rego/sc7_boundary.rego)
     - Checkov check ID that gates it

2. evidence/oscal/jwcc-simulation-ssp.json
   - System characteristics and authorization boundary description
   - Reference docs/diagrams/system-security-boundary.svg for the boundary diagram
   - Control implementation statements for all tailored controls

3. evidence/poam/poam.json
   - Any controls not yet fully evidenced get a POA&M entry
   - Each entry has a remediation plan and timeline

4. evidence/dashboard/compliance-dashboard.html
   - Interactive HTML generated from the OSCAL JSON
   - Color-coded by status: green=implemented with evidence, blue=inherited, amber=POA&M, red=gap
   - Drill-down links to evidence per control family
   - Must render in a browser standalone

Why structure evidence during the build?

Traditional authorization processes reconstruct evidence after the build is complete. That gap between implementation and documentation is where controls go undocumented and assessors find surprises.

By linking each control to its Terraform resource and policy check now, the SSP stays current with the actual system state. The compliance dashboard then visualizes this linkage for the authorizing official.

  • Verify the agents produced all four artifacts in the Explorer sidebar: component-definition.json, jwcc-simulation-ssp.json, poam.json, and compliance-dashboard.html.
  • Open evidence/dashboard/compliance-dashboard.html in your browser to confirm it renders with color-coded control families.
  • Confirm the SSP references docs/diagrams/system-security-boundary.svg in its authorization boundary description.
  • Validate all OSCAL artifacts by running:
trestle validate -a

You should see validation passing with no errors across all models in the workspace.

Validation errors from trestle?

If trestle validate -a reports errors, check the specific model it flags. Common causes: missing UUID fields in the SSP, component definitions referencing control IDs not present in the imported catalog, or malformed JSON.

Re-prompt the Validation and Evidence team with the specific error output and ask them to fix the flagged artifact. Help me fix trestle validation errors

Validate control coverage against the baseline

The final validation confirms that no system-owned control exists without a policy-as-code check. Every Rego policy maps to a specific 800-53 control ID. Any gap goes to the POA&M with a remediation timeline.

  • In Cursor Composer, address the Validation and Evidence team (6 agents) with this prompt:
@validation-evidence Run the final coverage validation.

1. Cross-reference: confirm every Rego policy in policies/rego/ maps to a specific 800-53 control ID in the component-definition.json.

2. Coverage check: for each system-owned control in control-tailoring.yaml, confirm at least one policy-as-code check (Conftest or Checkov) validates it.

3. Gap identification: any system-owned control without a policy check goes to the POA&M with a remediation plan.

4. Named validation bars (all must pass):
   - Boundary: every diagram and control ties to the RMF authorization boundary
   - Control coverage: 800-53 families tailored, inheritance documented, OSCAL evidence structured and policy-checked
   - Crypto: transit and rest use FIPS-validated modules in approved configuration
   - Portability: capability-mapping proven, workload landed on more than one provider

Report which bars pass and which need remediation.

What are the named validation bars?

These four bars are the acceptance criteria for the authorization package. Each one must be provably met before the briefing to the mock authorizing official.

  • Boundary: IL5-equivalent data stays inside the authorization boundary. Every diagram references it.
  • Control coverage: all system-owned controls have OSCAL evidence and at least one policy-as-code gate.
  • Crypto: AES-256 at rest, TLS 1.2+ in transit, FIPS 140-2/140-3 validated modules.
  • Portability: the mission workload plans on more than one provider via the capability-mapping layer.
  • Review the validation report from the agents. Confirm all four bars show as passing.
  • If any system-owned control was flagged without coverage, verify it now appears in evidence/poam/poam.json with a remediation timeline.
  • Confirm no system-owned control exists without either a policy-as-code check or a POA&M entry.

A validation bar is failing?

Each bar ties to specific artifacts. If Boundary fails, check that docs/diagrams/system-security-boundary.svg is referenced in the SSP. If Control Coverage fails, cross-check control-tailoring.yaml against component-definition.json. If Crypto fails, check that your provider modules reference FIPS-validated KMS endpoints. If Portability fails, confirm capability-map/portability-proof.md documents plans on two providers.

Help me debug a failing validation bar

Your IL5-equivalent control set is tailored, OSCAL evidence is structured, and every system-owned control has policy-as-code coverage. Next up, you assemble the ATO-style briefing package and deliver the readout to the mock authorizing official.

Assemble the Authorization Package and Deliver the Readout

Your control set is tailored, your OSCAL evidence is structured, and every system-owned control maps to a Terraform resource and a policy gate. The compliance arc is complete.

Now the authorization package comes together as presentation-ready artifacts. The Authorization-Readout team produces the briefing deck, renders the final boundary diagram, and structures the two-audience readout. This is what you carry into the architecture review with the mock authorizing official.

In this step, get ready to:
  • Assemble the authorization package as presentation-ready artifacts (rendered SVG, Marp slides, compliance dashboard, OSCAL bundle, terraform plan JSON outputs).
  • Structure and deliver the two-audience readout (risk for the AO, technical for engineers).
  • Document lessons learned and confirm all measurable outcome criteria are met.
Assemble the authorization package as presentation-ready artifacts

A stakeholder never sees raw markdown or unrendered JSON. Every artifact the mock authorizing official receives must be rendered, cross-referenced to the authorization boundary, and ready to present without post-processing.

  • In Cursor Composer, address the Authorization-Readout team (6 agents) with a prompt that directs them to produce the following package:
@Authorization-Readout team

Assemble the full authorization package. Produce these artifacts:

1. Finalize docs/diagrams/system-security-boundary.svg:
   - RMF/FISMA authorization boundary drawn and labeled
   - CAP-equivalent boundary distinct from provider FedRAMP boundary
   - Provider FedRAMP shown as inherited layer
   - System-owned controls explicit on the diagram

2. Create outputs/slides/ato-briefing.md (Marp source, 12 slides):
   - Slide 1: Mission and system description
   - Slide 2: Authorization boundary (embed the rendered diagram)
   - Slide 3: Control inheritance model (provider FedRAMP vs. system-owned)
   - Slide 4: IL5-equivalent control tailoring summary (families, counts)
   - Slide 5: CAP-equivalent boundary and crypto posture
   - Slide 6: Capability-mapping and the gap finding
   - Slide 7: Portability proof and resilience (RPO/RTO)
   - Slide 8: Risk posture and residual risk
   - Slide 9: POA&M summary
   - Slide 10: Recommendation to AO (conditional authorization with milestones)
   - Slide 11: Honest caveats
   - Slide 12: Questions

3. Render outputs/rendered/parity-matrix.html from capability-map/parity-matrix.yaml:
   - HTML table: capability-by-provider with status, fallback order, dated gap documentation

4. Finalize evidence/dashboard/compliance-dashboard.html:
   - Control families color-coded by status
   - Drill-down to evidence links

5. Ensure evidence/oscal/ bundle is complete and validatable:
   - SSP, POA&M, component definitions machine-readable

Honest caveats MUST appear in the deck and the package:
- Commercial simulation of a restricted pattern, not a real IL5 onboarding
- The authorizing official owns the decision; agents draft but never grant it
- Chaos event is a scenario; provider capabilities change, parity matrix is dated
- Provider move is a significant change that re-inherits controls, re-draws boundary, returns to AO
- Dependency class: software plus human judgment plus provider capability state

All artifacts must cross-reference the authorization boundary. No claim of real authorization.

What does this prompt produce?

The Authorization-Readout team generates six categories of artifacts simultaneously. The boundary diagram is the signature artifact because every control, every slide, and every compliance entry ties back to it.

The honest caveats are structural. They appear on Slide 11 and in the package metadata because this is a commercial simulation, not a real IL5 onboarding. The mock authorizing official needs to know exactly what the simulation covers and where it stops.

  • Once the agents produce the artifacts, save the Terraform plan outputs for all four providers as JSON evidence by running these commands:
# Save plan output for each provider as JSON evidence
terraform plan -out=aws.tfplan -var="provider_target=aws"
terraform show -json aws.tfplan > outputs/terraform-plan-aws.json

terraform plan -out=azure.tfplan -var="provider_target=azure"
terraform show -json azure.tfplan > outputs/terraform-plan-azure.json

terraform plan -out=gcp.tfplan -var="provider_target=gcp"
terraform show -json gcp.tfplan > outputs/terraform-plan-gcp.json

terraform plan -out=oci.tfplan -var="provider_target=oci"
terraform show -json oci.tfplan > outputs/terraform-plan-oci.json

Why save plan outputs as JSON?

The JSON plan files are machine-readable evidence that the baseline plans successfully on each provider. They prove the boundary and crypto controls pass without requiring the assessor to run Terraform themselves.

The -out flag saves the binary plan, and terraform show -json converts it to the JSON representation that integrates with downstream tooling.

  • Render the Marp briefing deck to presentation-ready HTML by running:
# Render the Marp slide deck to HTML
marp outputs/slides/ato-briefing.md -o outputs/rendered/ato-briefing.html

What does this command do?

The marp CLI converts the Markdown source into a self-contained HTML slide deck. The -o flag specifies the output path. The resulting file opens in any browser as a full presentation with slide navigation.

  • Verify the rendered artifacts exist by running:
ls outputs/rendered/
ls outputs/terraform-plan-*.json
ls docs/diagrams/system-security-boundary.svg

You should see ato-briefing.html and parity-matrix.html in the rendered folder, four JSON plan files in outputs, and the finalized SVG boundary diagram.

Missing rendered files?

If ato-briefing.html is missing, confirm marp is installed by running marp --version. If the command is not found, install it with npm install -g @marp-team/marp-cli.

If terraform plan fails for a provider, confirm you are authenticated to that provider's CLI (aws sts get-caller-identity, az account show, gcloud auth list, oci iam region list).

Help me troubleshoot my authorization package rendering

  • Open outputs/rendered/ato-briefing.html in your browser.
  • Confirm Slide 2 shows the authorization boundary diagram and Slide 11 lists all five honest caveats.
  • Open evidence/dashboard/compliance-dashboard.html and confirm control families are color-coded (green for implemented, blue for inherited, amber for POA&M).
Deliver the two-audience readout

An authorization briefing serves two audiences with different needs. The authorizing official needs risk framing to make a decision. The engineering team needs technical framing to maintain the system.

  • In Cursor Composer, prompt the Authorization-Readout team to structure the two-audience readout:
@Authorization-Readout team

Structure the readout for two audiences. Document this in docs/briefing/readout-structure.md:

AUDIENCE 1: Mock Authorizing Official (risk decision-maker)
- System boundary: what is inside, what crosses (point to system-security-boundary.svg)
- Risk posture: which controls inherited, which system-owned, which in POA&M (point to compliance-dashboard.html)
- Residual risk: the capability gap, the parity matrix state, the failover path
- Recommendation: conditional authorization with POA&M milestones

AUDIENCE 2: Engineering Team (implementation audience)
- Architecture decisions made (point to docs/adr/)
- What the baseline covers and where it breaks (capability gap)
- How the capability-mapping layer routes around gaps
- How evidence is structured for continuous monitoring (OSCAL + compliance-trestle workflow)

Artifacts are pointed to, not described. No conflation between audiences.

Why two audiences?

The authorizing official does not need to know how the capability router is implemented. The engineering team does not need to know the risk acceptance threshold. Conflating the two produces a briefing that serves neither audience well.

The readout points to rendered artifacts (the SVG diagram, the HTML dashboard, the ADRs) rather than describing them in prose. A stakeholder can click through to the evidence without re-reading the briefing.

  • Review the readout structure the agents produce.
  • Confirm the AO section references the boundary diagram and compliance dashboard by filename.
  • Confirm the engineering section references ADRs 001-005 and the OSCAL workflow.
Document lessons learned and confirm measurable outcomes

The final act of the build is capturing what it revealed. This is not a retrospective formality. It is the document you open first on the next onboarding.

  • Prompt the Authorization-Readout team to produce the lessons learned document:
@Authorization-Readout team

Produce docs/briefing/lessons-learned.md covering:

1. Where the cloud-agnostic pattern held and where it broke
2. Which provider was most/least mature for the mission's capability requirements
3. How the 44-agent parallelization performed:
   - What parallelized cleanly
   - What required serial decisions from the operator
4. Operator vs. agent time split:
   - What the operator spent time on (architecture, boundary, decisions)
   - What the agents produced (modules, evidence, diagrams)
5. What a real authorization would additionally require:
   - Assessment by a third-party assessor
   - DISA coordination
   - Physical separation
   - US-citizen workforce verification
6. Adoption arc:
   - Day 1: one workload lands
   - Day 30: four modules built and proven
   - Day 90: failover tested, SSP current, mock AO briefed
   - Day 180: operator runs the full pattern end-to-end

End with the measurable outcome confirmed:
- Mission workload onboarded onto commercial provider on IL5-equivalent baseline
- Capability-mapping fallback proven on scenario capability gap
- 800-53 families evidenced in OSCAL
- Provider failover path identified and RPO/RTO documented
- ATO-style briefing and boundary diagram ready for mock AO
- Presentation-ready artifacts: slides, dashboard, rendered diagrams

What goes in the adoption arc?

The adoption arc documents realistic timelines (targets, not guarantees) for an organization adopting this pattern. Day 1 is a single workload on a single provider. Day 180 is the full multi-cloud onboarding pattern running end-to-end with failover tested.

This framing helps stakeholders understand that today's build is the proof-of-pattern, not the finished state. The carrying cost (parity matrix maintenance, OSCAL currency, provider module updates) is what makes the pattern durable or fragile over time.

  • Review the lessons learned document the agents produce.
  • Confirm the measurable outcome criteria are all marked as confirmed.
  • Commit the final set of artifacts by running:
git add outputs/ docs/briefing/
git commit -m "Authorization package assembled, readout structured, lessons learned documented"
  • Run a final validation pass across the OSCAL evidence by running:
trestle validate

You should see a clean validation pass with no errors on the SSP, POA&M, and component definition artifacts.

Trestle validate reporting errors?

If trestle validate reports schema errors, the agents may have produced OSCAL fields that do not match the expected schema version. Open the referenced JSON file and check for missing required fields (uuid, metadata, system-characteristics).

Help me fix trestle validate errors in my OSCAL evidence

You now have a complete authorization package: rendered boundary diagram, briefing deck, compliance dashboard, OSCAL evidence, plan outputs, and a structured readout for two audiences. The mock authorizing official has everything needed to make a risk decision. The engineering team has everything needed to maintain the system.

Secret mission

Provider Failover Against RPO and RTO

Your baseline plans on four providers and the capability-mapping layer routes around gaps. But what happens when an entire provider goes down? Test the failover path against the mission's RPO and RTO, update the authorization boundary for the failover state, and document the re-authorization implication that a provider move carries.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. If you only ran terraform plan (no terraform apply), there are no cloud resources incurring charges.

Cost warning

If you ran terraform apply, resources across up to four cloud providers are accumulating charges. Network Firewalls (AWS, OCI) and Azure Firewall Premium are not free-tier eligible.

Budget approximately $2-5 per hour while resources are running. Destroy them within the session to avoid unexpected bills.

Resources you used:

  • Cloud resources across AWS, Azure, Google Cloud, and OCI (if terraform apply was run).
  • Local project folder jwcc-simulation/ on your Desktop.
  • Python packages: compliance-trestle and checkov (installed via pip).
  • Marp CLI (installed via npm as @marp-team/marp-cli).

Keep everything running

No action needed if you ran plan-only. Choose this if you are still actively building or want to keep the repository as a reference implementation for the JWCC onboarding pattern.

  • The rendered artifacts (slides, dashboard, diagrams) are immediately usable in stakeholder meetings.
  • If you ran terraform apply, cloud resources remain active and will continue to incur charges until destroyed.
  • The parity matrix and OSCAL evidence will go stale if not updated as provider capabilities drift.

Pause - I'll come back to this later

If you only ran terraform plan, no action is needed. Your local files remain on disk and no cloud charges are accumulating.

  • If you ran terraform apply, destroy the cloud resources to stop charges (see the Delete tab for commands), then re-apply later when you return.
  • Keep the jwcc-simulation/ folder intact so you can resume without rebuilding.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each step below to ensure nothing remains.

  • If you ran terraform apply, destroy cloud resources for each provider by running the following from inside the jwcc-simulation/ folder:
terraform destroy
  • Confirm the destroy when prompted. If you used separate workspaces per provider, switch to each workspace and run terraform destroy in each one.
  • Verify no resources remain by checking each provider's console (AWS, Azure, Google Cloud, OCI) for any lingering compute instances, VPCs, firewalls, or KMS keys tagged with the project name.
  • Remove the local project folder. On macOS or Linux:
cd ~/Desktop
rm -rf jwcc-simulation
  • On Windows:
cd ~\Desktop
rmdir /s /q jwcc-simulation
  • Uninstall the Python packages by running:
pip uninstall -y compliance-trestle checkov
  • Uninstall Marp CLI by running:
npm uninstall -g @marp-team/marp-cli
  • Confirm removal by running marp --version and trestle version. Both should return a "command not found" error.

What about carrying cost?

Even if you keep the repository, the four provider modules, the parity matrix, and the OSCAL evidence all require maintenance. Provider capabilities drift over time. Each provider ships breaking changes independently.

If the parity matrix is not updated, the drafted authorization goes stale. Plan to revisit quarterly if you intend to use this as a living reference.

That's a Wrap!

That's a Wrap!

Nice work. You just simulated a full JWCC-pattern multi-cloud onboarding from engineering baseline through authorization package, with a 44-agent swarm building the modules, controls, and evidence in parallel while you owned the architecture and the boundary decision.

You've learned how to:

  • Built a 44-agent organization in Cursor Composer that parallelizes a multi-cloud onboarding across four JWCC providers, from cloud-agnostic Terraform modules through OSCAL evidence through ATO-style readout.
  • Defined a cloud-agnostic baseline with four provider-specific implementations, a capability-mapping layer that routes around provider gaps, policy-as-code gates (Conftest Rego + Checkov) validating SC-7, SC-28, SC-8, and AU controls, and a CAP-equivalent network boundary with inspection egress.
  • Produced a stakeholder-ready authorization package with tailored NIST 800-53 Rev 5 controls, structured OSCAL evidence via compliance-trestle, a rendered boundary diagram, interactive compliance dashboard, and ATO briefing deck for the mock authorizing official.
  • Secret Mission: Tested provider failover against the mission's RPO and RTO, updated the authorization boundary for the failover state, re-generated all presentation artifacts for the failover configuration, and documented the re-authorization implication.

Ready to quiz yourself?