Skip to content

How Forgecroft evaluates a change

Forgecroft answers one question at the moment a change tries to ship: is this safe to merge against the whole system, not just the files in the diff? Tests tell you the code runs; they cannot tell you the change is safe, because a test only knows what its author already thought of. Forgecroft sees the whole system and checks the change against everything it touches.

Forgecroft ingests your real systems into one map — application code, infrastructure, CI/CD, containers, and governance rules — and derives the Controls that govern how each part may change. You do not hand-maintain this map; Forgecroft keeps it current from your repository, CI, and configuration. See Core Concepts for the model.

  1. Match — Forgecroft maps the changed files to the Components they belong to and pulls in the Controls that govern them.
  2. Evaluate — each Control is checked against the change. The check is deterministic and carries no per-change cost; the same change always produces the same verdict.
  3. Verdict — Forgecroft returns one of four outcomes: safe to ship, proceed with caution, blocked, or needs review. A blocked verdict names the Control that blocks and why.
  4. Blast radius — every verdict reports what the change touches downstream, and how much of that surface Forgecroft can actually see. When coverage is thin, it says so rather than feigning certainty.

The evaluation runs at the moment a change ships — in your CI on every pull request (CI Gate), or inside an AI coding agent’s loop so it self-corrects before it pushes (Coding Agents). Only the changed diff is sent for evaluation; your full source tree stays in your environment.

Every verdict carries a confidence score and states what Forgecroft cannot yet see. Confidence sharpens as Forgecroft observes more of your real systems and their outcomes. A low-confidence surface earns a recommendation to observe before trusting a verdict — never a confident answer dressed over a gap.