There's a post going around about a thing called CEE, short for Card Evidence Engine. The pitch is narrow and I think that's exactly why it's worth stealing: an AI's candidate answer is not a fact. Before you let it through, you re-check it against actual evidence and decide what deserves belief. The author says CEE grew out of a product called Card and turned into a local-first evidence-judging engine.
The benchmark numbers in that post — a p50 of 68.55 ms in a forced-offline run, 32 fixed contract tests all passing, zero difference between online and offline judgments across 9,600 measurements — are the kind of thing I'd flag as unverified. They come from synthetic contract benchmarks, the author says so plainly, and the source is not open. So treat those figures as claims, not results. The idea underneath them, though, doesn't depend on any of that.
The one idea worth keeping
Most RAG-style pipelines I've built do retrieval, stuff the passages into a prompt, and then hope the model stays honest. It usually does, until it doesn't, and the failure is silent. The interesting move in CEE is treating the verdict as a first-class output with explicit states: this answer conflicts with the evidence, there isn't enough evidence to decide, or the model is more certain than the evidence supports. That last one — wrong certainty — is the state I keep wishing I had a name for in my own systems.
Once you separate the answer from the verdict, a lot of things get easier. You can log the verdict. You can test the verdict. You can show a user why something was rejected instead of just quietly dropping it. The gate becomes inspectable, which is the whole point.
Rebuilding the gate, minus the mystery
You don't need CEE's source to build this. The shape is simple enough to reconstruct. On VicroCode I'd stand it up as a hosted Python service, since you can run Python online and expose it as an endpoint without wrangling your own server. The flow is: take the model's candidate answer plus the question, pull supporting passages, then score the answer against those passages and emit one of the explicit verdict states.
Retrieval is where the evidence actually comes from, so it needs a real store, not a prompt full of pasted text. A LanceDB knowledge base fits here — you embed your source passages once and query for the ones closest to the claim being checked. The gate then compares the candidate answer to what came back. If the passages contradict the answer, that's a conflict verdict. If nothing relevant comes back, that's insufficient evidence. If the answer overstates what the passages support, that's wrong certainty. None of this requires the model to grade itself; the scoring logic lives in your Python, deterministic and reviewable.
A note on scope: CEE claims offline parity, meaning identical judgments with the network cut. On VicroCode your retrieval and any hosted model calls run through the platform, so I would not claim offline parity for a rebuild — that boundary belongs to CEE's own environment, and I'd leave it marked unverified rather than pretend to match it.
The ledger is the deliverable
Here's the part I'd actually spend time on. Every time the gate fires, write a row: the question, the candidate answer, the retrieved passage IDs, the verdict, and whether the contract test for that case passed. A SQLite editor is enough to keep this ledger and to poke at it by hand when something looks off. You want to be able to sit down a week later and ask why answer #4471 got flagged as wrong-certainty, and get a straight answer.
The contract tests are the discipline. Instead of a vague "does it feel accurate" check, you write fixed cases where you already know the correct verdict — a claim that should be rejected as conflicting, one that should be insufficient, one that should pass. Then you run them on every change and log the outcome next to each live verdict. That's how you catch the day a prompt tweak quietly starts letting bad answers through. CEE reports 32 such tests; the exact number matters less than having any at all that you actually run.
Why this matters for a small team
A thread on the same board was asking whether agent development gets absorbed into the big models and disappears as a job. One reply landed for me: the platform-generic parts get commoditized, but wiring judgment into a specific business does not. An evidence gate is precisely that kind of wiring. The model is a component; deciding what to trust from it is your product.
Another post in the mix was about a code-review skill built by feeding it real historical bugs and checking whether the rules actually catch them. Same instinct as CEE's contract tests — don't trust the reviewer's mood, pin it to cases with known answers. The pattern keeps showing up because it's the honest way to run anything that generates plausible-sounding output.
If you build this on VicroCode, you get the endpoint, the knowledge base, and the ledger in one place, and you can publish or share it as a working service. Keep any latency or accuracy numbers you quote clearly separated from CEE's — those were synthetic and closed-source, and your own would need measuring in your own environment before you say a word about them.