9.15.2026 · 6 min
The internet after answers.
A possible internet primitive
A possible internet primitive
Search found pages. Answer engines learned to write from them. Sapith asks whether a claim can survive being challenged, and keeps the record of what changed.
The web made documents addressable.
Search made documents findable.
Answer engines made documents compressible.
Sapith tries to make claims contestable.
If this works, the important output is not a longer answer. It is a claim that carries its evidence, the strongest challenge found against it, the change caused by that challenge, and the risk left behind.
The idea, in one correction
One claim. Two states.
A normal research system can search widely, cite its sources, and still make one smooth sentence carry more certainty than the evidence allows. This design run produced a real example.
“The 307-million-parameter mLateOn model beats embedding models twenty-six times its size.”
Precise. Memorable. Unsupported by the inspected paper or model card.
“mLateOn outperformed the dense baselines in its reported BEIR evaluation, including models up to roughly twice its size.”
The revision is less spectacular and more useful. It names the benchmark, limits the comparison, and records the deleted number. Sapith’s intended product is this change in claim state, not the spectacle of several models talking to one another.
What each system actually does
It is not another search engine.
PageRank, BM25, vector retrieval, RAG, answer engines, deep-research agents, and Sapith can belong in one system. They do different work.
The deeper change
The durable object is a change in belief.
A search result has a rank. An answer has citations. A Sapith claim is intended to retain its history.
- the claim
- its evidence
- the strongest contradiction
- a falsifying test
- the recorded change
- the risk that remains
The closest software analogy is a Git commit for belief. Truth does not become code. Change gains an identity, a parent state, a diff, and a reason.
That difference matters because a polished report hides its own construction. A reader sees the final sentence but usually cannot see which objection changed it, which source failed, or which uncertainty was deleted during synthesis. A workflow card can preserve those transitions.
The correction loop
A sequence of commitments.
The technical stage names matter to the operator. The reader should experience their consequence: important sentences must show why they survived.
- Frame State the decision, scope, stakes, success condition, and cheapest proof that could settle it. P0
- Discover Search the live web and source graph for primary records, disagreement, implementation detail, and counterexamples. R1
- Bind Turn prose into separate claims. Attach sources, evidence class, confidence, dependencies, and conflicts. S1
- Challenge Ask which claim carries the decision, what could falsify it, and which missing evidence deserves another live search. A1 · R2
- Revise Kill, weaken, strengthen, or retain each important claim. Publish the diff and residual risk with the final answer. S2 · SC
A useful claim record contains the sentence, source IDs, evidence class, confidence, status, dependencies, contradiction links, and the local reason for its present state. The structure gives later audits something precise to attack.
A critique is not enough. The auditor must name the load-bearing claim, identify the failure mode, and propose a falsifying test that live retrieval can answer. The ticket is evidence work, not another opinion.
Without a diff, synthesis can absorb a contradiction and quietly rewrite the conclusion. A recorded transition shows whether a claim died, weakened, strengthened, or survived unchanged. It also reveals when a costly loop changed nothing.
The product thesis
A correction layer for the internet.
The current implementation produces workflow cards for individual runs. The larger idea below is a product thesis, not a capability Sapith has already proved.
For this to become internet infrastructure, a claim would need a stable identity across reports. Its evidence would stay linked. Challenges would become first-class records rather than comments below a finished page. Revisions would preserve their parent state. Residual uncertainty would travel with the claim when another system reused it.
A URL addresses a document. A claim layer would also need a stable identifier for the assertion inside it, even as wording and support change.
Evidence must point to the exact claim it supports. A bibliography attached to a whole article is too coarse for automated correction.
An objection needs a status: unanswered, answered, decisive, irrelevant, or superseded. Otherwise the same challenge is rediscovered on every run.
A reader should be able to ask when a conclusion changed, which evidence caused the change, and which earlier state it replaced.
When another agent or document reuses a claim, it should inherit the known residual risk instead of copying only the confident sentence.
This is the new-internet argument in its strongest form: not a better page of answers, but a public memory of why important claims changed.
The method can fool itself
Visible rigor is not the same as truth.
A structured workflow can make weak work look disciplined. These risks are properties of the method, not edge cases.
Research on multi-agent debate gives adjacent evidence that structured disagreement can improve factuality in some settings. It does not establish Sapith’s mechanism, implementation, or advantage.[5]
Evidence state · 15 September 2026
Promising mechanism. Unproven advantage.
The current verdict must keep the positive mechanism and the negative receipts on the same page.
What would change the verdict
The experiment that decides it.
Compare full Sapith with a current deep-research system under the same budget, then remove Sapith’s parts one at a time.
- Questions30–50 preregistered decisions
- BudgetEqual time, tools, and source access
- JudgingBlind outside domain experts
- MeasuresTruth, usefulness, calibration, quality per minute
The question set must include technical work, science, history, local decisions, and markets. It must also include cases where ordinary search should win. Existing browsing benchmarks can supply task shapes, but the final test must measure decision quality and calibrated uncertainty rather than retrieval alone.[6][7][8]
Hold the source set constant in a separate arm. That isolates binding, audit, tickets, and revision from better discovery. Report factual correctness and decision usefulness, then calibration and quality per minute. Count severe unsupported claims and unsupported citations.
If Sapith wins, the result will show that explicit claim state and forced evidence-backed revision beat hidden iterative reasoning at an acceptable cost. A loss would still leave the workflow card useful as an audit format, but Sapith would be governance around ordinary deep research rather than a better method.
The claim that survives
Sapith is not search, RAG, or deep research with more boxes.
It is an attempt to add a correction layer after them: a place where important claims meet evidence and opposition before an explicit decision turns them into prose.
The implementation and internal results support taking the mechanism seriously. They do not support a general superiority claim.
The larger thesis remains worth building toward. If claims can retain provenance and opposition, plus revision history and uncertainty across documents and time, the internet gains something it does not have today: memory of why an answer changed.
- Implementation:
docs/research/sapith/README.md;sapith/contract.py;sapith/scheduler.py;sapith/protocol.py;sapith/discovery.py;sapith/score.py;sapith/scorecard.py;sapith/metrics.py. - Validation:
docs/research/sapith/validation/runs/VERDICT.md;docs/research/sapith/validation/runs/QUALITY-VERDICT.md;docs/research/sapith/reports/2026-08-25.md. - Fresh test:
python3 -m unittest discover -s test -p 'test_sapith*.py'ran 148 tests in 7.841 seconds, with 141 passed, five skipped, and two failed. - Live research:
run_7ffb16da37c9inspected 27 sources and produced 36 claims, three conflicts, two live tickets, one killed claim, and two weakened claims. The installed Codex build could not provide the required read-only sandbox, so Sapith used Claude for audit. The other required stages completed with their configured providers.
- Brin and Page: The Anatomy of a Large-Scale Hypertextual Web Search Engine
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
- OpenAI: Deep Research System Card
- Google: Gemini Deep Research Agent
- Improving Factuality and Reasoning through Multiagent Debate
- BrowseComp
- DeepResearch Bench
- BrowseComp-Plus
- Google: Guide to Search ranking systems
- Perplexity: Architecting and evaluating an AI-first Search API
- Insider Knowledge: How Much Can RAG Systems Gain from Evaluation Secrets?
- DenseOn with the LateOn
- LightOn: mDenseOn and mLateOn
- infolab.stanford.eduinfolab.stanford.edu/~backrub/google.html
- arxiv.orgarxiv.org/abs/2005.11401
- cdn.openai.comcdn.openai.com/deep-research-system-card.pdf
- ai.google.devai.google.dev/gemini-api/docs/deep-research
- arxiv.orgarxiv.org/abs/2305.14325
- arxiv.orgarxiv.org/abs/2504.12516
- arxiv.orgarxiv.org/abs/2506.11763
- arxiv.orgarxiv.org/abs/2508.06600
- developers.google.comdevelopers.google.com/search/docs/appearance/ranking-systems-guide
- perplexity.aiwww.perplexity.ai/hub/blog/architecting-and-evaluating-an-ai-first-search-api
- link.springer.comlink.springer.com/chapter/10.1007/978-3-032-21289-4_37
- arxiv.orgarxiv.org/abs/2607.27178
- huggingface.cohuggingface.co/blog/lightonai/mdenseon-mlateon
1,354 words, read from the filed brief.