Skip to content
Impact Gate Impact Gate Impact Gate

How Impact Gate Works

Concept model

Impact Gate is easiest to understand as one pipeline: read a diff, map it to product areas, compare that to coverage, and only then decide whether AI should help extend the suite.

Pipeline

Diff in, evidence out, AI last

01 read a diff 02 map changed files to product areas 03 compare those areas to E2E coverage 04 produce a plan and a gate decision 05 optionally generate or heal with guardrails
Why this matters

The strongest story is deterministic first

The product is not “an AI test generator” first. It is a diff-aware evidence layer that becomes more valuable once a team trusts what it is telling them.

Core Mental Model

The product is not “an AI test generator” first. Its strongest path is deterministic:

  • read a git diff
  • determine what changed
  • determine what should run
  • determine what is missing
  • decide whether the current PR or release candidate is ready

That deterministic path is why impact, plan, and gate are the core commands.

Step 1: Diff In

Input

Everything starts with a git comparison

  • origin/main for pull requests
  • a previous release tag for release readiness
  • a hotfix base for emergency verification
Example

Release-ready plan from one tag

npx impact-gate plan --path . --since v2.1.0

Everything starts with a git comparison. In practice, teams use:

Step 2: Knowledge Layer

Project knowledge

The diff is interpreted through what the repo already knows

  • route families map code paths to product areas and flows
  • dependency graph catches transitive impacts
  • traceability adds file-to-test evidence from CI history
  • historical failure data can raise confidence that an area needs attention
Interpretation

This is what turns files into flows and tests

Without the knowledge layer, you only know which files changed. With it, you can reason about which product areas and E2E checks actually matter.

The diff is interpreted through project knowledge:

Step 3: Coverage Planning

Plan output

Coverage planning answers what changed, what to run, and what is missing

  • what is impacted
  • what should run now
  • what confidence we have in that decision
  • what flows appear under-covered
  • whether new tests or more manual verification are needed

plan produces a structured answer to:

The main artifacts are written under .e2e-ai-agents/.

Step 4: Gate Decision

Decision layer

Gate turns the plan into a CI policy decision

  • advisory while onboarding
  • threshold-based blocking once the manifest is trustworthy
  • stronger enforcement for release branches or critical paths

gate turns the plan into a CI decision. This is where you decide how strict to be:

Step 5: Optional AI With Guardrails

Guarded AI

The AI path helps only after the deterministic picture exists

  • enrich flow understanding
  • generate specs for uncovered gaps
  • heal failing generated specs
  • power deeper exploratory or crew workflows

The generation path uses local API-surface grounding, prompt sanitization, hallucination detection, quarantine into generated-needs-review/, compile checks, and smoke-run verification.

AI enters after the deterministic evidence is already established.

The AI layer is used to:

See AI Guardrails for the full safety model.

Why This Matters

Engineering evidence

Every layer answers a different confidence question

  • the diff explains why you are testing
  • the manifest explains what feature was affected
  • the plan explains what is covered
  • the gate explains whether confidence is high enough
  • the AI layer helps only after that foundation is already in place
Positioning

This keeps the product honest

The tool feels stronger because it can justify every recommendation with artifacts and repo knowledge, not just a prompt and a model opinion.