Calculates the final risk score based on empirical evidence and architectural impact. Use when findings have been fully processed by previous stages and you need to append final risk scores to the finding files. Don't use for discovering new vulnerabilities or writing patches.

Risk Calibrator (/mantis calibrate) System Goal Risk Analysis Expert. Evaluates confirmed findings against a rigorous risk matrix, taking into account successful reproduction and production viability to produce a final risk score (1 10). Command Definition Command: /mantis calibrate Description: Calibrates the risk level of findings based on evidence and impact. Input/Output Contract Reads : workspace/findings/ .json (all finding files to load full pipeline state). workspace/kb/THREAT MODEL.md (if exists, to check threat boundary overrides and asset criticality). workspace/.mantis state.json (to track the current loop pass, and to read active snapshot — {snapshot id, snapshot pinned, root} — for finding provenance and history stamping; absent ⇒ degraded/today's behavior). Writes : Updates finding files in place with scoring/calibration fields ( impact score , likelihood score , availability tier , inferred exposure , attacker position , mantis risk score , priority , sanity triage applied (may begin with STALE EVIDENCE when the STALE EVIDENCE guard suppresses heuristics), calibration checklist (entries may carry STALE EVIDENCE: reasons), outrage commentary , executive summary ). Appends a history entry with snapshot provenance (see history JSON template in the body). Reusable helper script workspace/helpers/append calibrate.py . Preconditions : Confirmed or raw findings must exist in workspace/findings/ . Idempotency Guarantee : Updates findings in place by overwriting existing keys with the calculated score. Running multiple times on the same inputs yields identical outputs, with no duplicated entries. Instructions Convert the raw security findings and their empirical results (repro/patch) into a prioritized, actionable risk report. Execute the calibration as follows: Locator resolution (findings only). Calibrate never needs to read target source to compute a score, but some heuristics below may re inspect code; resolve the code root the same way every stage does. Block A is inlined below: [!NOTE] CURRENT PASS CHECK (defensive; the binding guarantee is on the harness per mantis pipeline adapter Scenario 2): if active snapshot is present AND active snapshot.pass != state.pass number , treat the snapshot as STALE for this pass — STOP "stale active snapshot: pass mismatch" or degrade as HALT ( snapshot pinned effectively false: no authoritative verdicts, Block B NOT MATCHED, reproduce not attempted ). This catches a custom harness that preserved active snapshot across the Stage 15 pass increment without re pinning. The reference meta agent re pins every pass, so this check never fires there. Block B itself cannot detect this (it is snapshot id only, not pass aware). Snapshot provenance & STALE EVIDENCE guard (mechanical; do this before scoring): P0. Read active snapshot ( {snapshot id, snapshot pinned, root} ) from state root/workspace/.mantis state.json (Block A step 0/1c). NEVER stop if it is absent — calibrate is a FINDINGS ONLY stage (Block A step 0). P1. MODE (single decision for the whole run — branches on active snapshot presence, 3 state model): active snapshot is ABSENT in state (no sync was requested — MODE OFF = today's default) MODE = MODE OFF. Score exactly as today : run every heuristic as written, do NOT compute PROVENANCE, do NOT emit STALE EVIDENCE , and do NOT emit any HALT/PINNED banners. (Backward compatible default path — byte for byte today's behavior.) active snapshot IS present AND snapshot pinned is not exactly true (HALT mode — the tree raced or could not be pinned) MODE = HALT. SNAPSHOT ID = active snapshot.snapshot id (a live: id). Compute PROVENANCE per P2 below and fire the STALE EVIDENCE guard conservatively (same as PINNED for guard purposes), because findings' locators may be stale. Authoritative verdicts (VERIFIED SECURE, failed to reproduce, DUPLICATE, FALSE POSITIVE, NON VIABLE) are forbidden this pass. snapshot pinned == true MODE = PINNED. SNAPSHOT ID = active snapshot.snapshot id . Full provenance + STALE EVIDENCE guard as below. P2. In MODE = PINNED or HALT, compute PROVENANCE per finding F using Block B's compare rule: F.discovery commit missing OR empty OR the literal "MIXED" NOT MATCHED. F.discovery commit != SNAPSHOT ID (exact string compare, no fuzzy) NOT MATCHED. F.discovery commit == SNAPSHOT ID MATCHED. P3. A per finding heuristic is STALE for F when MODE is PINNED OR HALT AND either: PROVENANCE(F) == NOT MATCHED, OR the finding's code paths target file does NOT exist under CODE ROOT. (Resolve CODE ROOT via Block A steps 1 & 3; strip a trailing :<digits ; read ONLY the pinned root, NEVER the live tree. If you cannot resolve CODE ROOT at all, treat the file as absent STALE.) P4. When a heuristic is STALE for F, do NOT apply it; keep the conservative (pre adjustment) score; and ensure the literal token STALE EVIDENCE is the FIRST token of sanity triage applied (add it once, before any UNKNOWN warnings and any fired rule list). The four guarded heuristics and their exact STALE handling are: Dead code 0.2 multiplier (Section 2, "Asset Criticality & Reachability"): do NOT apply the 0.2 reduction; use the multiplier you would otherwise have. repro failure (Section 3 rule): do NOT force LOW; set calibration checklist.repro failure.outcome = "UNKNOWN" , reason beginning "STALE EVIDENCE: " . vague code paths (Section 3 rule): do NOT force LOW; set calibration checklist.vague code paths.outcome = "UNKNOWN" , reason beginning "STALE EVIDENCE: " . static confirmation trace lift (Section 3 rule, its "valid external stack trace/sanitizer…" exception): do NOT apply the trace lift; KEEP the static HIGH cap in force ( likelihood score \<= 3, 0.8 Hazard multiplier, NOT CRITICAL). Set calibration checklist.static confirmation.outcome = "APPLIES" , reason beginning "STALE EVIDENCE: trace lift suppressed; trace/crash log may predate the active snapshot; " . P5. NON SOURCE finding: if the finding's code paths entry is a non source LOCATOR (contains "://" , or is not of the form <path :<integer — per Block A step 3: a symbol / offset / endpoint), SKIP all source only heuristics for it — dead code, file path/imports/caller hierarchy exposure inference, vague code paths , and static trace re inspection — and score from the finding's DECLARED metadata ( attacker position , privileges required , production viability , repro status , threat model). A non source skip is NOT flagged STALE EVIDENCE (it is normal, not drift). Non source findings default inferred exposure to "INTERNAL" (0.8) unless the finding/threat model declares otherwise. 1. Load Full Pipeline State: Read all JSON files from the workspace/findings/ directory. Because the pipeline appends data to each finding file at each stage, these files provide the complete picture of each finding's journey (including its id , reproduction status, and production viability). Missing Fields Fallbacks: If any finding is missing viability, or reproduction fields (such as chained findings), apply the following fallback defaults before scoring: If production viability is missing, treat it as "CONDITIONAL VIABLE" . If repro status is missing, treat it as "not attempted" . Snapshot provenance (only when MODE is PINNED or HALT): for each finding, compute PROVENANCE (MATCHED / NOT MATCHED) per preamble step P2 and record it in scratch. This value gates the STALE EVIDENCE handling in Sections 2 and 3 (preamble steps P3–P4). In MODE == MODE OFF, skip this — score as today. Read workspace/kb/THREAT MODEL.md from the Knowledge Base (if it exists) to evaluate component exposure, trust boundaries, asset criticality, and any custom Calibration Overrides (e.g., specific threat positions or caps that should be lifted or customized for the project). Batch Processing: If there are more than a few findings to calibrate, split the task into batches (a few findings at a time). If you have the ability to invoke subagents, delegate each batch to a subagent to process in parallel, then aggregate the results. Each batch/subagent inspects ONLY the pinned snapshot: pass snapshot root=<active snapshot.root , snapshot id=<active snapshot.snapshot id , and state root=<workspace parent so every subagent resolves the same CODE ROOT via Block A. Any code inspection a batch performs (exposure inference, dead code, static trace verification) MUST read through that CODE ROOT (the pinned copy), NEVER the live tree, and MUST honor the STALE EVIDENCE guard (preamble P3–P4). Findings only fields (score, priority, history stamp) are computed from the finding JSON regardless. 2. Calculate Risk Score (1 10): For each unique finding file, calculate the actual technical risk score in a matrix form based on the following formula components, where Hazard = Impact + Likelihood : Impact (1 5): Evaluate impact using the CIA triad (Confidentiality, Integrity, Availability) while strictly considering Blast Radius . 5: Complete, systemic loss of Confidentiality (full data breach, leak of root cryptographic/HSM master keys) or Integrity (system compromise, e.g., clear Remote Code Execution (RCE) by an unprivileged attacker who isn't already in an effective position to execute code). MUST NOT be used for attackers who already have execution privileges. 4: Substantial loss in one or more areas. This includes systemic Availability loss (total outage of a major service) or major data exposure. 3: Moderate loss (e.g., partial data exposure, temporary or partial system disruption). 2: Minor loss (e.g., minor information leak, localized disruption). A vulnerability whose blast radius is limited to affecting only a single user's own data MUST NOT be scored higher than 2. Exception: If the action lacks non repudiation (allowing the user to plausibly deny the action to commit fraud or blame others), or triggers side effects affecting other users/system stability, it should not be downgraded. 1: Negligible impact on CIA, mostly a cosmetic issue. Findings of the type "the code is fragile", "lack of defense in depth", or purely theoretical hygiene issues MUST have an Impact score of 1, ensuring they are rated LOW at most. Security Control Bypass (Upgrading): If the vulnerability directly bypasses a core security control (e.g., authentication, authorization, cryptographic signature verification) or defeats the primary security purpose of a library (e.g., a library meant to secure keysets allows attacker control), elevate the Impact score to at least 4 (or 5 if it leads to systemic compromise), even if the immediate technical impact seems localized. Note on Privileges Required & Lateral Movement: If the finding requires HIGH privileges (e.g., administrative privileges, admin to super admin escalation) or only allows lateral movement/pivoting between internal components from an already compromised state, cap its individual Impact score at 2 , unless the exploit results in escaping the container boundary (to the host node) or cross tenant escalation. If the finding requires LOW privileges (e.g., standard authenticated user), cap its individual Impact score at 3 (unless it leads to systemic compromise of other tenants/users, OR it directly bypass

mantis-calibrate