The Believability Pipeline
The simplest way to build AI review is two stages: the model emits text, and the text becomes a comment. Nothing sits between the model’s judgment and your PR thread, so when a finding is a hallucination it has nothing to clear before it reaches you. That two-stage baseline is the design Sigilix set out to improve on.
Sigilix puts five gates in that gap. A finding produced by a specialist is not a comment; it is a candidate. To become a posted finding, it has to survive evidence, provenance contracts, refute/execute, proof-tier receipts, and memory. Believability here is architectural, not a prompt that says “please be accurate.”
The five gates
Evidence
A finding has to point at something. It must cite the code it is about — the lines it quotes, the symbol it names. A finding with no anchor to real code does not clear this gate.
Provenance contracts
The cited evidence has to actually correspond to the diff under review. The finding’s claim is checked against where it says it came from — the right file, the right lines, the change actually present. This is what stops a finding from being attached to code that does not exist or to a line it never touched.
Refute / execute
Sigilix actively tries to disprove the finding. The synthesizer cross-references the claim against the surrounding source and the repo context; where a claim is checkable by execution, it is checked. A claim that survives the attempt to refute it is far stronger than one that was simply asserted.
Proof-tier receipts
A finding that survives is stamped with a receipt that records how it earned its place — see the tiers below. The receipt travels with the finding so you can see why it is trustworthy, not just that the model said so.
Memory
Finally, the finding is weighed against what Sigilix has learned about this repo — taught rules and prior dismissals. A finding that contradicts a learned rule (“we use integer cents here”) can be suppressed or down-weighted before it posts. See Conversational Learnings.
Proof tiers: the receipt every finding carries
Gate 4 attaches a proof tier to each finding that survives. The tier is a pill on the posted comment. It replaces any single number — believability is about how the finding was established, not a 1-to-5 score.
VERIFIED
Corroborated by a signed receipt from your own CI — an independent scanner confirmed the same finding. The strongest tier: two systems agree.
REPRODUCED
Demonstrated by execution. Sigilix’s sealed sandbox re-ran the cited code and reproduced the claimed behavior — shown, not argued.
GROUNDED
Anchored to cited code and evidence that the provenance and refute gates confirmed. The finding points at real code that supports it.
MODEL
Model judgment. The finding cleared the earlier gates but rests on the specialist’s reasoning rather than an execution check or a hard anchor.
The tiers are a hierarchy of witness independence, from an independent receipt (VERIFIED) through demonstrated execution (REPRODUCED) and confirmed anchoring (GROUNDED) down to reasoned judgment (MODEL). Every posted finding wears one, and a tier can only ever move up — a later, weaker signal never demotes an earned receipt. See Verification & the Trust Ledger for how the top tiers are earned.
What the gates actually check
The five-gate narrative above is the shape; underneath it runs a roster of named, individually-toggleable validation gates. A candidate finding walks through them in order:
| Gate | What it catches |
|---|---|
| Hallucination guard | A finding citing a deterministic-fact ID that no check actually produced. Only real scanner and rule outputs are admissible evidence |
| Inline grounding | The cited code doesn’t exist at the cited location |
| Absence grounding | ”X is missing” claims — the gate checks the thing claimed missing isn’t actually present nearby |
| Window blindness | A claim that only looks true because the model saw a window of the file — refuted against the surrounding source |
| Per-domain evidence gates | Security, logic, performance, and test findings each have their own evidence requirements (e.g., a security finding must tie to a real sink/usage, not just a scary-looking name) |
| Refutation survival | The claim is actively argued against; findings that lose the argument are dropped or downgraded |
| Out-of-scope tagging | A finding raised from graph or retrieval context whose subject is outside the PR’s changed files is tagged and rendered separately — it never blocks the merge |
Two engineering properties make this safe to run on every PR:
- Recall-safe rollout. Every gate ships in a shadow mode first — measuring what it would drop — and is only switched to enforcement once the telemetry shows it doesn’t cost real catches. Gates fail open on internal errors and never silently drop a top-severity finding.
- Auditable drops. Every suppression is recorded with its reason (failed grounding, failed refutation, hallucinated evidence, …) in telemetry. Nothing disappears without a paper trail.
Contrast: the two-stage baseline versus five gates
Two-stage baseline
Model produces text → text becomes a comment. Nothing checks whether the finding cites real code, matches the diff, or survives refutation. Hallucinations pass straight through.
Sigilix
Evidence → provenance contracts → refute/execute → proof-tier receipts → memory. A finding cannot post unless it earns it, and it arrives wearing the receipt that says how.