How Phases Work

The ten assessment phases, runtime lifecycle, and preview-first commit rules.

The phase system is configured in lib/instructions/phase_instructions.yaml and loaded through lib/PhaseConfig.ts.

Runtime phase workflow

Each phase follows the same high-level lifecycle:
  1. enter phase
  2. preload required prior-phase JSON and resources
  3. build or update candidate preview state
  4. validate the candidate
  1. ask focused missing questions only when needed
  2. commit the final phase artifact
  3. advance to the next phase

Phase list

  1. Identify assets and CIA impacts
  2. Build architectural model
  3. Assess current controls implementation
  4. Identify relevant threats
  5. Estimate likelihood and impact per threat
  1. Compute inherent risk
  2. Propose compensating controls
  3. Create remediation plan
  4. Assess residual risk
  5. Generate final report
See Risk Assessment Walkthrough for screenshots of each phase in the product UI.

Important runtime rules

Preview-first behavior

The system keeps candidate JSON and optional DOT previews live during a phase, then commits them once the user confirms completion.
Use the status panel at any time to inspect JSON, DOT, tables, and validation alerts before committing.

Preload-heavy later phases

Later phases reuse earlier saved artifacts rather than re-interviewing the user from scratch.

Committed artifact is canonical

Once a phase artifact is committed, it becomes the canonical source for that phase and the runtime advances. Remaining in the same phase after commit is treated as an anomaly.

Dot phases

Some phases produce DOT diagrams. A diagram preview is shown only when a valid DOT preview exists, not merely when a DOT string is present.