Model policy impact and control coverage

The Decision Simulator is the modelling view inside Compliance. It compares the same historical detection window three ways: what would have reached a provider without CID222, what remained risky under the current policy, and what would remain after a proposed change. It also connects detections to NIST CSF 2.0 controls and shows whether each control is holding over time.

Read the three projections

For each regulation, the simulator returns these states over the same tenant, group, channel and date window:

The model saturates rather than growing forever:

exposure = statutory_cap × (1 − 0.5^(detections / 50))

The result carries formula_notes, regulation caps and the static exchange rates used for EUR conversion. Exported reports use the same server-side run, so the PDF cannot silently differ from the numbers on screen.

Test a policy change

Understand control status

Control coverage is the share of linked detections that CID222 masked or blocked. Volume alone does not decide the grade.

The default floor is 95%. The default partial band is 90–95%, and its width follows a floor an administrator moves. A row's reason names a disabled covering rule when one can be identified; otherwise it states the measured percentage and shortfall. Daily observations support an audit window: missing days remain missing and are never filled in as healthy.

Role boundaries

An auditor can read policy impact, baselines, controls, coverage, history and thresholds. The auditor can also run a non-persistent what-if and render its PDF. Only an admin_user can run the stored simulation workflow, record today's observation, run control targets and change grading thresholds.

API reference

Verify

1. Run the baseline and confirm its subject and date window match the page filters.
2. Set one what-if reduction and confirm Current stays fixed while Simulation changes.
3. Open control coverage and confirm every row has a state, evidence count and status reason.
4. Open control history and confirm days_observed matches the dates actually recorded.
5. Export a PDF and compare its subject, period and totals with the screen.

If it fails

• A 403 FEATURE_NOT_LICENSED means the installed licence does not carry compliance.
• An empty result usually means the selected scope or period has no detections. Confirm the same filters in Compliance and All detections.
• Untested means no matching evidence, not a healthy control. Do not lower a threshold to hide the absence of evidence.
• A PDF 503 means the report renderer is unavailable. Follow the report-rendering runbook:
  Runbookperformance Reset

  A PDF or report will not render

  You might see: Failed to render compliance scorecard PDF · Failed to render detections PDF · Failed to render executive summary PDF · Failed to render regulations PDF

  Before you start

  • Does the page you are exporting show data on screen?expected · The page shows the figures you expect in the PDF.If not, follow the dashboard-request-failed runbook instead.

  Checks

  1. 1

     Read whether the report renderer answered

     diagnostics · services[report-renderer].reachable = true

     Pass Fail
  2. 2

     Read whether the renderer reports itself healthy

     diagnostics · services[report-renderer].healthy = true

     Pass Fail
  3. 3

     Check whether only the large exports fail

     expected · The small export succeeds.

     Pass Fail
  4. 4

     For a compliance dossier, read whether the render was reconciled against the record

     expected · The renderer reported its rendered ids.

     Pass Fail

Related pages

• Compliance — source evidence and regulation coverage.
• Compliance reports — frozen reporting periods and exports.
• Input filters — the controls that actually change traffic decisions.
• Regulatory mapping — how detections map to articles and controls.