100%

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.

First answer

“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 model remains. The benchmark is named. The unsupported ratio is gone.[12][13]

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.

  1. Frame State the decision, scope, stakes, success condition, and cheapest proof that could settle it. P0
  2. Discover Search the live web and source graph for primary records, disagreement, implementation detail, and counterexamples. R1
  3. Bind Turn prose into separate claims. Attach sources, evidence class, confidence, dependencies, and conflicts. S1
  4. Challenge Ask which claim carries the decision, what could falsify it, and which missing evidence deserves another live search. A1 · R2
  5. Revise Kill, weaken, strengthen, or retain each important claim. Publish the diff and residual risk with the final answer. S2 · SC
What the binder records

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.

What the auditor must return

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.

Why the final diff matters

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.

Addressable claims

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.

Linked provenance

Evidence must point to the exact claim it supports. A bibliography attached to a whole article is too coarse for automated correction.

Challenges with state

An objection needs a status: unanswered, answered, decisive, irrelevant, or superseded. Otherwise the same challenge is rediscovered on every run.

Versioned belief

A reader should be able to ask when a conclusion changed, which evidence caused the change, and which earlier state it replaced.

Portable uncertainty

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.

  1. Questions30–50 preregistered decisions
  2. BudgetEqual time, tools, and source access
  3. JudgingBlind outside domain experts
  4. 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.

Project receipts
  • 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_7ffb16da37c9 inspected 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.
External sources
  1. Brin and Page: The Anatomy of a Large-Scale Hypertextual Web Search Engine
  2. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
  3. OpenAI: Deep Research System Card
  4. Google: Gemini Deep Research Agent
  5. Improving Factuality and Reasoning through Multiagent Debate
  6. BrowseComp
  7. DeepResearch Bench
  8. BrowseComp-Plus
  9. Google: Guide to Search ranking systems
  10. Perplexity: Architecting and evaluating an AI-first Search API
  11. Insider Knowledge: How Much Can RAG Systems Gain from Evaluation Secrets?
  12. DenseOn with the LateOn
  13. LightOn: mDenseOn and mLateOn
Sources · 13
  1. infolab.stanford.eduinfolab.stanford.edu/~backrub/google.html
  2. arxiv.orgarxiv.org/abs/2005.11401
  3. cdn.openai.comcdn.openai.com/deep-research-system-card.pdf
  4. ai.google.devai.google.dev/gemini-api/docs/deep-research
  5. arxiv.orgarxiv.org/abs/2305.14325
  6. arxiv.orgarxiv.org/abs/2504.12516
  7. arxiv.orgarxiv.org/abs/2506.11763
  8. arxiv.orgarxiv.org/abs/2508.06600
  9. developers.google.comdevelopers.google.com/search/docs/appearance/ranking-systems-guide
  10. perplexity.aiwww.perplexity.ai/hub/blog/architecting-and-evaluating-an-ai-first-search-api
  11. link.springer.comlink.springer.com/chapter/10.1007/978-3-032-21289-4_37
  12. arxiv.orgarxiv.org/abs/2607.27178
  13. huggingface.cohuggingface.co/blog/lightonai/mdenseon-mlateon

1,354 words, read from the filed brief.