Originally published on hexisteme notes.
I run a small ledger-driven pipeline for the consequential decisions in my agent fleet — money, technology adoption, anything load-bearing — and the single rule that has done the most work in it is almost embarrassingly simple: no claim is accepted without an explicit falsification condition. Not "high confidence." Not a percentage. A concrete, observable event or threshold that, if it happens, proves the claim wrong.
I got here by watching my own agents produce confident-sounding numbers that were really just fluent language modeling wearing the costume of analysis. "There's a 70% chance this stock moves up." "This approach will probably work." These read like conclusions. They aren't — they're pattern completion. The model has learned that a confident numeric claim sounds authoritative, and RLHF has rewarded exactly that pattern. The fix isn't better prompting. It's a structural constraint on what counts as an acceptable claim in the first place.
Karl Popper's falsifiability criterion, applied to AI agent outputs: a claim that cannot be falsified isn't a prediction, it's a narrative. For an agent making consequential decisions, every accepted claim has to answer one question — under what observable conditions would this claim be false? Without an answer, the claim can be noted or logged as uncertain, but it cannot be the basis for a decision.
Three concrete rules
I run this as three enforceable rules, numbered as reusable decision units (RDU-021, 022, 023) so the same logic gets reused instead of re-litigated every time a new domain comes up.
Rule 1: no LLM probability production
The agent cannot output a numerical probability in any consequential domain — finance, deployment decisions, technology adoption. When a probability is actually needed, a statistical model produces it, not the language model, and it has to clear Brier-score validation before it's ever shown to me. The LLM's job is to interpret the number, not generate it.
# Blocked output
"BTC has a 70% chance of moving up in the next 2 weeks."
# Required format instead
Scenario A (upward): requires X AND Y to materialize.
Leading indicators currently showing: [observable signals]
Scenario B (sideways): ...
Scenario C (downward): ...
Note: this system does not produce probabilities.
Rule 2: walkforward validation required
Any quantitative strategy or model has to pass walkforward validation before it's allowed anywhere near a deployment decision — training and validation windows kept separate, evaluated on genuinely out-of-sample future data. An in-sample backtest, however good it looks, is not evidence.
Rule 3: correlation is not causation, enforced
Events that co-occur cannot be labeled causal without explicit causal identification. Every observation the agent logs gets one of four labels:
| Label | Meaning | Action allowed |
|---|---|---|
FACT | Directly observed, source cited | Use in decisions |
INFERENCE | Derived from facts, assumption stated | Use with explicit caveat |
UNIDENTIFIED | Correlation only, causal mechanism unknown | Log, do not act |
SPURIOUS | Co-occurrence, no causal mechanism | Discard |
The falsifier protocol, generalized past finance
The same shape holds across every decision domain I run this on. A falsifier needs exactly three slots — an observable condition, a measurable threshold, and a concrete date to check it:
falsifier:
condition: [observable event that invalidates the thesis]
threshold: [measurable value, not vague]
evaluation_date: [concrete date to check]
# Example: technology adoption decision
falsifier:
condition: >
Library has no releases for 6 months, OR
Critical CVE published with no patch in 30 days, OR
Primary maintainer announces deprecation
threshold: any of the above
evaluation_date: 2026-09-13
A thesis without a falsifier isn't a thesis, it's an opinion with better formatting. I enforce this at the pre-decision gate: any load-bearing decision — deployment, investment, architecture change — that's missing an explicit falsifier gets blocked before it can go anywhere.
The empty-consensus problem
Running a multi-agent council surfaced a failure mode I hadn't fully anticipated: empty consensus. Several agents agree on a claim, unanimously — and the claim still isn't actually verifiable. Agreement felt like a signal of quality. It mostly wasn't.
Measured metrics from an 8-persona council system I run:
| Metric | Observed value | Threshold | Status |
|---|---|---|---|
empty_consensus_rate | 0.354 | < 0.30 | Over threshold |
council_repeat_rate | 0.44–0.48 | < 0.10 | 4.4x threshold |
outcome_report_rate | 0.036 | > 0.70 | Under threshold |
The finding underneath these numbers is the one that changed how I build this: model diversity doesn't fix empty consensus. Adding more, different models to the council doesn't reduce how often they agree on something unverifiable. What fixes it is verification — routing every council conclusion through a formal engine before it's allowed to count as load-bearing.
Verification bridges
For any council conclusion that's load-bearing — money, deployment, a decision I'll act on — and that contains a mathematical or logical claim, I route it through a verification bridge before accepting it:
Arithmetic claims → a symbolic math engine or a computational knowledge engine
Formal logic claims → a theorem-proving language server
Empirical claims → cross-referenced against primary sources, never a web-search summary
The verification result feeds back through an outcome-reporting step that closes the loop and improves how the council calibrates next time. Skip that feedback and the reporting rate stays near zero — mine measured 0.036 — which means the council never actually learns from being wrong.
The real bottleneck isn't model quality, it's verifiability. A unanimous council conclusion that can't be checked is worth less than a single verified calculation. Most of my empty-consensus cases were claims that sounded like analysis but couldn't be checked against any ground truth at all.
What this looks like in practice
The minimal version of this system is four steps:
- Gate every decision on one question: does it have a falsifier condition?
- Block LLM probability production structurally — not with an instruction, but with a hook that intercepts any output carrying an unsourced percentage
- Keep a ledger: every load-bearing decision, stored with its falsifier, its evaluation date, and eventually its outcome
- Close the loop: when an evaluation date arrives, check the falsifier against reality and update the ledger
The ledger is the part that actually matters. Without it, falsifiers are just good intentions — conditions that get stated once and never checked again. The whole point was to stop trusting confident-sounding claims; a falsifier nobody ever revisits is exactly that kind of claim wearing a disguise.
More notes at hexisteme.github.io/notes.