Grounded AI

1. Introduction: the misconception

The most common objection raised by readers unfamiliar with conversational AI is that “it makes mistakes.” The objection is reasonable. Most public examples of language-model output — viral screenshots, casual chats, off-the-cuff prompts — are produced under conditions where the model is asked to recall, summarize, or extrapolate without any specific source material attached to the question. Under those conditions the model produces plausible text whose accuracy is uncorrelated with the truth, because the only thing it has to draw on is statistical patterns learned during training. The result feels confident and is sometimes wrong. The user reasonably concludes that the tool is unreliable.

This paper makes a narrower claim: language models, when supplied with primary-source data at query time and instructed to operate on that data, produce output whose accuracy can be verified against the source. The mistakes do not vanish, but they become detectable and correctable. The model is no longer guessing; it is summarising. The difference is large enough that it is best understood as a different mode of operation.

The conditions under which this mode works in practice are not exotic. The remainder of this paper documents one such workflow.

2. Background: what a language model actually is

A useful working description for non-technical readers is that a language model is a function from text input to text output, trained on a very large corpus of human writing. When prompted, it produces the text that statistically best continues the prompt according to its training. It is not a search engine, not a database, and not a thinking entity. Its memory of the world is approximate, undated, and unverifiable. It cannot read minds, but it can read text it has been shown.

Two practical consequences follow:

1. Without source material, output reflects pattern memory. Asking the model “what year did X happen” with no other input is asking it to gamble with whatever statistical impression it has of the question. Most of the time it will be right; sometimes it will be confidently wrong. There is no way for the user to tell which.
2. With source material in the prompt, output reflects the material. Asking the model “here is a transcript; what year did X happen” reduces the same question to a reading task. The answer is now verifiable against the transcript. If the answer is wrong, the error is also legible — it can be spotted by the user, or, more often in practice, caught by an automated verification step (see §4).

The methodological insight, then, is to design the workflow so that the model is almost never operating in the first condition.

3. The archive layer

The archive at the centre of this work is a single SQLite database (brain.db) of approximately 570,000 personal and public records, augmented by audio transcripts of roughly 5,000 video and podcast episodes drawn from a thirteen-year run of Bitcoin media. Records include show transcripts, social-media archives, public-document exports, and structured metadata. The database is local, private, indexed for full-text search, and addressable by source label (for example, mad_bitcoins, the_bitcoin_group, world_crypto_network, bitcoin_report).

The archive is the primary input to most analytic work. When a question is asked of the archive, it is asked of the records — not of the model’s training memory. The model’s role is to operate on retrieved records: summarising, cross-referencing, ranking, and surfacing quotations. The records themselves are treated as authoritative.

This division of labour is the entire premise.

4. Verification: how the workflow defends itself

The single most important pattern in practice is substring verification. Every direct quotation that appears in any published output must appear verbatim in the underlying source record. This is enforced by a build step that fails if any quoted string cannot be located in its referenced transcript. The check is small, mechanical, and fast. Its effect is to make hallucinated quotations impossible to ship.

Three secondary patterns reinforce it:

• Measured rather than estimated quantities. Where audio files exist, runtimes are read from the file itself (ffprobe), not estimated from word count. Where dates exist in source metadata, they are read from the metadata, not inferred from context. The general principle is to prefer the cheapest empirical method over the most plausible estimate.
• Honest both-sidedness on ambiguous record. Where the source record is genuinely contradictory or unresolved, the published output preserves the ambiguity. The model is not asked to render a verdict it cannot defend.
• Cited sources for every external claim. External-web findings are cited by URL and date of access. The verification burden moves to the reader, who can follow the citation. No claim is published without its provenance.

None of this is novel. It is ordinary newsroom hygiene. The contribution is in showing that the same hygiene, applied to AI-assisted output, eliminates the failure mode most non-technical observers associate with the tools.

5. Four small case studies

The following four episodes occurred during the work documented here. They are presented because each illustrates a specific point about the methodology in action.

6. Discussion: when this works, when it fails

The workflow described above succeeds wherever three conditions hold: the corpus contains the relevant material; the model is given access to that material at query time; and the published output is constrained by a verification pass against the corpus.

It fails — and the failure is illuminating — when any of those conditions is missing. If the corpus is incomplete, the model will summarise what is there and miss what is not. If the model is queried without the corpus, it returns to pattern memory and produces unreliable output. If the verification pass is skipped, mistakes ship.

The practical consequence is that the cost of trustworthy AI output is not in model quality. It is in the infrastructure around the model: the corpus, the retrieval, the citations, the verification. These are unglamorous engineering tasks. They are also the entire reason the output is trustworthy.

7. Practical notes for non-technical readers

The methodology generalises beyond Bitcoin archives. Anyone wishing to evaluate AI output for trustworthiness can apply three rules of thumb without writing code:

1. Ask whether the model was given source material. If not, treat the output as a confident guess. If yes, the output should be checkable against the material.
2. Ask whether the published output cites its sources. Quotations should be verifiable. Statistics should reference where they came from. If the citations are not there, ask why.
3. Ask whether ambiguity has been preserved. A reliable summary of a contradictory record will sound contradictory. A summary that resolves contradictions the source does not resolve has either invented its certainty or smoothed it from the record.

None of these rules require technical knowledge. They are forms of ordinary editorial skepticism. They happen to be sufficient.

8. Conclusion

The premise of this paper is small. It is that language models are tools whose usefulness depends entirely on what they are given to work with. Given primary-source data and a verification pass, they produce work that is grounded, citable, and correctable. Given nothing but a question, they produce confident guesses whose accuracy is uncorrelated with the truth.

The widespread perception that AI “makes mistakes” is, in our practice, a description of the second condition mistaken for a property of the first. The author’s position, after a year of building inside this workflow, is that the perception is incorrect not because the tools are flawless but because the failure mode is in the workflow, not the tool.

If a friend has been told that AI cannot be trusted, this paper offers a narrow but defensible response. The trustworthiness is a function of inputs. Supply the inputs. Verify the output. The rest follows.

■