What the Verification Engine does
The Verification Engine is a final checkpoint that inspects AI-generated responses before they reach your users or downstream systems. If a response fails validation, G8KEPR can block it inline — so problematic output can be stopped at the point of delivery rather than caught only after the fact.
How it works
The engine runs after your model generates a response but before that response is delivered. Each response passes through four independent layers, and it must clear all four to be released.
- 1.Conversation integrity — Looks for tampering and injected instructions hidden in the output, checks that the model only invoked tools it was authorized to use, and flags signs of manipulated conversation state.
- 2.Source grounding — Checks factual claims against the source material the model was given. Invented figures, fabricated URLs, and citations that don't match a real source are flagged here.
- 3.Structural verification — Checks that any tool or API call the model produced matches its registered schema: correct endpoint, allowed parameters, and values within policy.
- 4.Output constraints — Applies your final rules: PII scanning and redaction, dangerous-code detection, format and length limits, and any custom constraints your team defines.
Each layer reports its own result, so a problem caught in one is never masked by another.
What happens when a check fails
Every violation maps to an action, and the strongest action wins:
- ▸Warn — the response is delivered, and the violation is logged.
- ▸Suggest — the response is blocked and a compliant alternative is returned.
- ▸Block — the response is rejected and the caller receives an error.
A single Block overrides any Warn or Suggest raised on the same response.
Enforcement, not just alerts
Unlike detection-only tools that notify you after bad output has already shipped, the Verification Engine can stop it inline. High-risk paths — your AI gateway and MCP routes — fail closed, meaning a response that can't be verified is blocked rather than released. Lower-risk paths can be set to fail open during rollout.
Defining your own constraints
You can add organization-specific rules that run in the final layer:
constraint: refund_amount
type: numerical
min: 0
max: 5000
action: blockConstraints are versioned and audited, so you always have a record of what was enforced and when. Verification results are stored for review in your dashboard.
Start a new constraint in Warn mode to see what it would catch, then promote it to Block once you're confident.
See Reviewing verification results and Writing custom constraints.