Blog
Garbage In, Confident Nonsense Out: Why Ingestion Is the Whole Ballgame
Nobody gets fired for the model. They get burned by what fed it. Provenance, freshness, dedup, and metadata are the boring plumbing that decides whether your AI is trustworthy or just fluent.
Part three of The Corporate Second Brain, a six-part series. The full map is at the end.
Everyone wants to argue about which model to use. Almost nobody wants to talk about how the documents get in. That is backwards. The model is a commodity you can swap in an afternoon. What you feed it is the whole game.
I have a plain way of saying it. Garbage in, confident nonsense out. A weak model on clean, well-labeled information will beat a frontier model drowning in duplicates, stale drafts, and mislabeled files every single time. The intelligence people think they are buying lives in the ingestion pipeline, which is the least glamorous part of the stack and the part that decides whether you can trust the answer.
The boring plumbing that does all the work
Ingestion is four unglamorous jobs. Get them right and the AI feels like magic. Get them wrong and it feels like a confident liar.
Provenance. Every answer has to be able to show its work. When the assistant tells you something, you need to click through to the exact document it came from. No source, no trust. This is the difference between "the AI said so" and "the AI found this in the signed contract, page four." One of those you can take to a board. The other you cannot take anywhere.
Freshness. The gap between when a document changes and when your AI notices is a lie waiting to be told. Someone updates the pricing page Monday. If the system does not pick that up until Friday, your assistant spends the week quoting last week's prices with total confidence. Somebody has to own the question of how fast changes flow through.
Deduplication. The same policy exists in nine slightly different versions across the company. Which one is real? If you feed all nine to the AI, it will average them into something that was never true and quote it back to you. Duplicates are not clutter. They are a way to manufacture wrong answers.
Metadata. Every document needs to carry its own labels. Who owns it. Who can see it. When it was last true. What it supersedes. This is the layer that lets the machine tell a signed contract from a scratch draft, and it is almost always the layer nobody has bothered to create.
What the nine refund policies do to you
Here is deduplication as it actually plays out, because "manufacture wrong answers" sounds abstract until it costs you a customer.
A company has a refund policy. Over five years it got pasted into an onboarding deck, a help-center article, two Notion pages, a sales enablement doc, and a contract template, and each copy got edited a little by whoever owned that surface. The window is fourteen days in one, thirty in another, "case by case" in a third. All nine are in the pile you fed the assistant. A customer asks about a refund. The AI does not pick the right one, because it has no way to know which is right. It blends them into a confident, reasonable-sounding answer that matches none of the nine and commits you to a promise no human approved.
Nobody wrote that policy. The machine did, by averaging your mess. That is what duplicates buy you. Not clutter. A liability with good grammar.
Where the file approach quietly wins
I keep coming back to plain files in this series, and ingestion is where the argument gets concrete.
In a folder of markdown files tracked with normal version control, three of these four jobs come mostly for free. Provenance is the file history. You can see who changed what, when, and why, because that is what version control does. Freshness is a habit, not a rebuild. You do not re-process the whole knowledge base to reflect a change. You edit the file. Metadata is a few lines at the top of the document, sitting right next to the content it describes, in plain text a human can read and correct.
Compare that to the standard approach, where every change means re-processing the document into a specialty database, and provenance is something you have to engineer back in on purpose. The file approach does not make ingestion trivial. Deduplication is still real work, and someone still has to care. But it starts you much closer to trustworthy, because the audit trail is built into how the files already work.
What I am seeing in the room
The companies with AI they actually trust did not buy better models. They did the janitorial work. They killed the duplicate policies. They put one owner on freshness. They made every answer cite its source, and they made "no source" a failure, not a shrug.
The companies that do not trust their AI skipped all of that and are now surprised that a system fed on mess produces mess. It is not the model. It never was.
What to do this week
- Pick one important question and trace the answer. Ask your system something that matters, then find the exact document it used. If you cannot, provenance is your first project.
- Hunt the duplicates. Take one core policy and count how many versions exist across your tools. The number will bother you. That is the point.
- Put a clock on freshness. For your top five documents, how long between a change and the AI knowing? If nobody can answer, nobody owns it.
- Add labels to the top ten. Owner, audience, last-verified date. Ten documents. One afternoon. Start there.
The uncomfortable truth is that most of the work in a trustworthy AI system happens before the model ever runs. It is intake, labeling, and cleanup. It is not exciting. It is the difference between an assistant your team relies on and one they have quietly stopped believing.
Next in the series I get concrete about the storage fight everyone has too early: why I keep replacing the vector database with a plain folder of markdown files, and the honest cases where a folder is not enough.
The Corporate Second Brain, a six-part series
- Your Company Already Has a Second Brain
- RBAC Is the Hard Part of AI
- Why Ingestion Is the Whole Ballgame (this post)
- I Replaced the Vector Database with a Folder
- From What We Know to What You Should Do
- Build a Corporate Second Brain in a Weekend