TrustShell · how verification works
Disjoint-family verification
Why no single model gets to grade its own homework.
A check is only worth as much as the independence behind it. Today TrustShell runs a claim past two uncorrelated model families and both must agree for a pass — so one provider's bias, or one provider's outage, cannot fake one. A golden-ratio supermajority across more families is the design target, not what runs (see the Roadmap section below). When independence is not there, the honest answer is Not checked, and that is never a quiet yes.
The problem: a model marking its own work
Ask a model whether its own answer is true and you mostly learn how confident it is, not whether it is right. Ask a second model from the same lineage and you have barely moved: models trained on overlapping data in overlapping ways share the same blind spots, so they tend to be wrong in the same places at the same time. Two confident agreements from one family is one opinion said twice.
Correlated error is the whole trap. A verifier that fails exactly where the thing it checks fails adds no safety — it just adds volume. The only cross-check that buys you anything is one that fails differently.
The fix: families that fail differently
So the check is spread across different model families — different builders, different training, different failure modes. Two of them must agree before a claim is allowed to count. A lone FALSE flags the claim; a lone TRUE, with no independent second, abstains. There is no path where one family alone produces a clean pass.
Independent cross-examination
No model grades its own family's homework
A claim is cross-checked by a quorum of decorrelated model families. A blind spot shared by one lineage gets caught by another that fails differently — so a confident wrong answer has to survive scrutiny from a model that does not share its training. Suspiciously perfect agreement is a reason for a second look, not a rubber stamp.
Live quorum, read from the engine
Reading the live quorum configuration…
The card above reads the quorum straight from the engine. If the number is not showing, the engine could not be reached from your browser just now — the page says so rather than printing a figure it did not read.
Why a bare majority is not enough Roadmap
Two out of three is a majority. It is not truth. If a third of your voters can be wrong together — or captured together — a simple majority is exactly what a coordinated failure produces. Systems that have to agree in the presence of faulty or adversarial participants do not settle for a majority; they demand a supermajority, a margin wide enough that the honest votes still carry even when some votes do not.
TrustShell's consensus design sets that bar at a golden-ratio supermajority (φ⁻¹) — a threshold drawn from the proportion rather than a round number picked for looks. In that design, agreement has to clear that line before a claim counts, and agreement that is too perfect is treated as a signal to look again, not as extra confidence. It is a hypothesis, not yet validated on real data, and not a production guarantee.
What runs today is the two-checker label: two model families must agree, and the answer is pass, veto or not-checked. Not-checked is never a pass, so losing a family does not silently flip a claim to a pass.
The shape of the guarantee. No one provider is load-bearing. A family that is biased, captured, or simply offline cannot carry a verdict on its own, and cannot block the others from reaching one. That is the property a single model — however good — can never have about itself.
What HAL’s five signals are, and where they come from
The SDK’s score result carries five signal fields. By the client code, the fact-check quorum returns the providers and families that answered, each with a verdict, while the style-only extractor returns the harm and epistemic fields; a signal the engine does not return reads 0 in the SDK. So these are a style analysis, and they are not what decides Checks out or Caught on /check — that is the family vote. The check on this site returns a label and the votes; it does not return these signals. They are described by what they look at, not by the weights or thresholds that turn them into a number — those are engine internals.
Evidence grounding
Is the claim supported by something retrievable, or asserted into the air? A fluent sentence with nothing behind it is the common shape of a fabrication.
SDK field evidenceQuality · from whatever the engine returns; the SDK reads 0 when it is absent
Confidence vs. content
How sure the wording sounds, set against how much the answer actually commits to. Stated certainty that outruns the evidence is a flag, not a pass.
SDK field certaintyAtClaim · from whatever the engine returns; the SDK reads 0 when it is absent
Scope
Did the answer stay inside what was asked, or drift into territory it was never given? Drift is where confident, off-topic invention lives.
SDK field scopeAppropriateness · from whatever the engine returns; the SDK reads 0 when it is absent
Model uncertainty
The genuine spread in the underlying model’s own distribution for this prompt — the difference between "it knows" and "it is guessing smoothly".
SDK field epistemicUncertainty · from the style-only extractor
Harm
Whether the output carries a safety risk worth stopping before it reaches anything that can act on it.
SDK field harmProbability · from the style-only extractor
The router that decides which models answer is just that — a router. It picks who checks; it does not itself grade the claim.
Three outcomes, never two
Every check lands on one of three results, and they render through the one component the whole product uses for a verdict — so "we did not look" can never be painted the colour of "it passed". Not checked is neutral on purpose: it asserts nothing, because nothing was measured.
Two independent families looked at the claim and agreed it holds.
What it gates Nothing — this is the clean result. It counts as a real check. A check on this site writes nothing to a score.
A family found the claim false. A lone FALSE flags; it never quietly passes.
What it gates The claim is marked caught, with the reason attached, so a reader sees what failed and why.
No independent pair could answer — a family was down, abstained, or the two did not agree. It is an absence of a verdict, not a quiet yes.
What it gates Everything gated behind a check. Not checked fails closed: it never passes by default.
What runs live today, said exactly. Rolling out
Verification runs live on every check you run on /check today. The contract is that a Not-checked result also blocks a post and a spend — and the automatic post/spend gating that enforces it is rolling out. Where it is not yet wired, it reads Not checked and fails closed. So this page does not claim every post in production is gated live; it claims the check is live, and the gating is the contract we are shipping to.
See it run, and see the evidence
The check is the one piece you can run right now with nothing installed, and it prints its own receipt under the answer: who checked and what each one said. The newest real receipt is a paid deal between two agents.
The model card says FIXTURE when its numbers are example data, not a live count. The whole journey runs on Base Sepolia testnet; the money there is practice money with no value.
Go deeper