Synthesis on Write vs. Synthesis on Read: Choosing the Right Knowledge Pattern for Enterprise

A clean architectural lens for evaluating LLM knowledge systems

Andrej Karpathy’s LLM Wiki is a genuinely elegant idea for personal knowledge management. At its core it represents a deliberate architectural choice — one that works beautifully in the right context and runs into serious friction in others. That choice is synthesis on write.

Understanding why that matters, and what the alternative looks like, requires stepping back from the specific tool and looking at the pattern.

Two Ways to Synthesize Knowledge

Every knowledge system — LLM-powered or otherwise — has to answer a core question: when does synthesis happen?

Synthesis on write means knowledge is processed, transformed, and consolidated at the time it is ingested. The raw source goes in; a synthesized artifact comes out and is stored. Future queries are answered from the stored artifact, not the original source.

Synthesis on read means knowledge stays at the source in its original form. When a query arrives, the system figures out which sources are relevant, retrieves live data from them, and synthesizes the answer in the moment.

This is not a new debate. Data engineers have been arguing about it for decades under different names:

• Materialized views vs. views. A materialized view pre-computes and stores query results (synthesis on write). A regular view computes on demand from base tables (synthesis on read). The tradeoff: materialized views are fast but stale; views are live but more expensive to query.
• ETL vs. ELT / data virtualization. Traditional ETL pipelines extract, transform, and load data into a warehouse (synthesis on write). Data virtualization and federation leave data in place and transform at query time (synthesis on read).
• Eager vs. lazy evaluation. A well-understood pattern in computer science: compute everything upfront and cache it, or compute only what you need when you need it.

LLM Wiki is firmly in the synthesis-on-write camp. Data federation is synthesis on read. Neither is universally correct — but the choice has very different consequences depending on your scale, governance requirements, and data volatility.

LLM Wiki: Synthesis on Write

In LLM Wiki, the workflow is: ingest a source → LLM reads it → LLM synthesizes summaries, cross-references, entity pages → writes the result into the wiki. The wiki is the artifact. Future queries are answered from the wiki, not the original documents.

Karpathy is explicit about this being the point: “the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files… The knowledge is compiled once and then kept current.” The synthesis happens at write time. The wiki is a materialized view of your knowledge corpus.

For a single user maintaining a curated personal research base, this is exactly the right tradeoff. Synthesis is expensive; doing it once and caching the result means fast, rich queries later. And with one person controlling ingestion, the staleness and consistency problems are manageable.

But synthesis on write carries structural costs that scale badly.

The Reconciliation Problem

Two copies of every fact now exist: the original source and the wiki’s synthesis. Both evolve independently. When the source changes, the wiki does not automatically know. You have introduced a reconciliation problem as a direct consequence of the architectural choice.

Karpathy’s “lint” operation — periodic LLM health-checks of the wiki for contradictions and stale claims — is a reconciliation mechanism. You are paying the cost of reconciliation because you chose to materialize the synthesis. In a personal workflow with a controlled source corpus, this cost is manageable. In an enterprise where sources are updated by hundreds of people continuously, reconciliation becomes a full-time engineering problem.

The Update Ownership Problem

Synthesis on write requires a writer — an agent or person responsible for processing new sources and updating the wiki when they change. In LLM Wiki, this is you. You decide what to ingest, when, and how.

In an enterprise, sources change without notice and without a clear owner of the downstream synthesis. Who triggers re-ingestion when a Confluence page is updated? Who reviews whether the LLM’s re-synthesis is correct? Who is accountable when an automated re-ingest overwrites a correct wiki page with an incorrect synthesis of a poorly-written source document? Synthesis on write requires an answer to these questions. Most enterprise teams do not have one.

The Access Control Problem

This is the most structurally damaging issue. Enterprise data lives in systems with their own access controls — Salesforce restricts by role, SharePoint by folder ACL, Jira by project visibility. These controls exist for legal, regulatory, and business reasons.

Synthesis on write extracts data from those systems and places it in a new store — the wiki — with whatever access model the wiki has. You have decoupled the knowledge from the security context that governed it. Now you must re-implement access control on the wiki layer, mirroring the permissions of every source system you ingested from, and keeping those mirrors in sync as permissions change over time.

This is not a solvable engineering problem at enterprise scale. It is a compliance and legal risk. Regulated industries — healthcare, finance, legal — cannot accept it.

The Correctness Problem

LLMs make synthesis errors. They misread ambiguous language, conflate similar concepts, miss critical nuance, and sometimes produce confident but wrong conclusions. In Karpathy’s personal workflow, the human reviewer catches these errors because they are reading the wiki and can notice when something is wrong.

In an automated enterprise pipeline, the error is silent. A misinterpreted design decision gets filed as a wiki page that looks like any other. It is read by colleagues, consumed as context by downstream LLM queries, and potentially drives decisions. There is no audit trail from the wiki claim back to the specific inference the LLM made from the source document. The error is invisible until something breaks.

Data Federation: Synthesis on Read

The federation approach inverts the architecture. Knowledge is not copied. The system maintains a map of where knowledge lives — customer data in Salesforce, project context in Confluence, team communication in Slack — and at query time, decomposes the query into sub-queries against the relevant sources, retrieves live data, and synthesizes the answer in the moment.

The synthesis happens on read. Nothing is materialized. The wiki page does not exist until you ask the question, and it is regenerated fresh every time you ask it.

This resolves every structural problem that synthesis on write introduces.

No reconciliation. There is no copy to reconcile. When a Confluence page is updated, the next query against it returns the updated content automatically. The source is always the source.

No update ownership. There is no ingestion pipeline to manage, no re-synthesis to trigger, no wiki to keep current. The federation layer’s job is routing and retrieval, not maintenance.

Access control is inherited. Queries execute against source systems using the requester’s own credentials. If they cannot see a Salesforce record, the federation layer does not retrieve it. The source system’s permission model applies without re-implementation.

Correctness is auditable. The LLM reasons over live, attributed source data. Every claim in the synthesized answer can be traced back to the specific document and passage that produced it. Errors are locatable and correctable at the source.

What Federation Does Not Solve

Federation is synthesis on read — which means it does not accumulate synthesis over time. This is a real limitation.

LLM Wiki’s most valuable output is not the retrieval — it is the accumulated synthesis: the cross-references already drawn, the contradictions already flagged, the evolving thesis that reflects months of reading. That synthesis does not exist in any source document. It is new knowledge, generated by the LLM and stored in the wiki. Federation cannot give you this, because it has no persistent synthesis layer to accumulate into.

If you want to understand how six research papers relate to each other, or track how a company’s strategy has evolved across two years of earnings calls, federation gives you the raw materials but you pay the synthesis cost fresh every query. LLM Wiki pre-computes that synthesis and amortizes it across every future query.

So the question is not which approach is right — it is which tradeoff fits the use case.

Choosing Between Them

The Right Enterprise Architecture

For enterprise, the hierarchy should be:

Federation as the default. Live retrieval from source systems with inherited access controls handles the large majority of knowledge needs. No copies, no reconciliation, no permission re-implementation. Synthesis happens at query time over fresh data.

Synthesis on write, selectively, where consumption is known. Not all knowledge belongs in federation. There is a class of knowledge where synthesis on write is the right call — but the criterion is not “knowledge that doesn’t exist in any source.” The criterion is: do we know the consumption pattern, and do we know the consumers?

FAQ-style knowledge, onboarding content, policy summaries, product explainers — these have predictable questions, defined audiences, and stable enough source material that pre-synthesizing them makes sense. The synthesis is done once, serves many, and the cost of pre-computation is justified by the frequency of access. This is exactly the logic behind a CDN or a materialized view: you invest in pre-computation when you can predict demand.

When these conditions hold, synthesis on write belongs in the enterprise — but with a knowledge manager in the loop, not an automated pipeline. The knowledge manager understands the consumer context, validates that the synthesis actually answers what consumers will ask, reviews it before it is published, and owns the update cycle when underlying sources change. The LLM drafts; the knowledge manager approves. This is a sustainable model precisely because the scope is bounded: known consumers, known questions, defined review cadence.

The decision rule for architects is therefore:

• Known consumers + known consumption patterns → synthesize on write, with knowledge manager review
• Unknown consumers or ad-hoc queries → synthesize on read via federation

Federation is the default. Curated synthesis on write is the exception — and the exception is only justified when you can name the audience and predict the questions.

Conclusion

LLM Wiki is a well-designed synthesis-on-write system. For a single researcher or a small team with a controlled source corpus and an active curator, it is the right pattern. The synthesis compounds over time, the wiki gets richer with every source, and the query experience is fast and rich. It also has a legitimate place in the enterprise — for FAQ-style knowledge, onboarding content, and policy summaries where the audience is known and the questions are predictable, synthesis on write with a knowledge manager in the loop is a sound choice.

The challenge arises when synthesis on write is applied as the default enterprise knowledge architecture — across live, volatile sources, diverse audiences, and data with access controls that cannot be copied out of their source systems. In that context, the reconciliation burden, the ownership gaps, and the compliance risk are structural, not incidental. They follow from the choice to materialize knowledge outside its source systems.

Data federation — synthesis on read — is a better fit as the enterprise default: data stays where it was created, governed by systems that understand it, retrieved live with the requester’s own access credentials. The LLM synthesizes at query time over fresh, attributed context. No copy, no reconciliation, no permission re-implementation.

A final note on federation: data federation is not a licence to ignore knowledge quality. For synthesis on read to produce reliable answers, the federated sources themselves must be carefully curated and structured for AI consumption — well-organised, consistently maintained, and free of the ambiguity and noise that causes LLMs to misinterpret or hallucinate. A knowledge management lifecycle with accountable knowledge managers is just as critical in a federation model as it is in a synthesis-on-write model. Federation solves the architectural problems of copying and staleness; it does not solve the human problem of keeping knowledge accurate, current, and AI-ready. Both patterns ultimately depend on people who care about the quality of what goes in.