Evidence checked October 31, 2026. This independent article was commissioned by Austin Little. It does not imply collaboration with or endorsement by Andrej Karpathy. The proposed designs and examples below are original analysis, not reported results from a completed knowledge-vault deployment.
An idea file is a starting point
Andrej Karpathy's public LLM Wiki gist is dated April 4, 2026. It describes a pattern for a personal knowledge base, not a complete downloadable corpus or a finished application. The idea separates preserved source material, generated wiki pages, and instructions governing maintenance. It describes ingestion, querying, checking, an index, and a chronological log. The author explicitly leaves implementation choices open. Those are the relevant features of the source; the design developed in this article is independent analysis rather than a reproduction of the gist. Karpathy's LLM Wiki idea file.
The attractive promise is continuity. A useful answer need not disappear into a chat transcript. It can become part of a growing collection that supports later questions. But persistence changes the cost of error. A mistaken summary can be read again, linked from other pages, and treated as established background long after the original uncertainty has been forgotten.
For Austin Little's independently commissioned knowledge-vault experiment, the central design question is therefore how a future reader will distinguish a source statement, an interpretation, a correction, and an unanswered question. This article reports no completed import or deployed result. It examines what evidence a responsible implementation would need before making those claims.
The answer begins with change history. A knowledge page should not merely contain the current best wording. It should retain enough context to explain why the wording changed, which sources support it, and which downstream conclusions depend on it. That is what turns a convenient collection of generated notes into a record that can be inspected, corrected, and used with appropriate confidence.
A page can contain several kinds of statement
A personal wiki often mixes facts, quotations, summaries, hypotheses, and plans in one document. That can be natural for human reading, but the distinctions need to survive automated maintenance. Otherwise, a tentative idea can become a declarative fact when a later summary compresses the page.
Consider a hypothetical note about a research paper. The paper reports a result under a particular experimental condition. The reader proposes that the result might apply to another setting. A generated summary then says the method works in both settings. The error did not require a fabricated citation. It arose when the system failed to preserve the boundary between evidence and inference.
The article proposes explicit statement roles. A source claim records what a source says. An editorial inference explains what the curator concludes from it. A hypothesis identifies something to test. A question marks missing information. A plan describes intended work, not completed work. These roles can be expressed through lightweight metadata or clear prose rather than a complicated database.
The important feature is consistency. If a page uses uncertainty language, later edits should preserve it unless new evidence justifies a change. If a plan becomes complete, the record should include the observation establishing completion. A model's confident phrasing should not be allowed to create that transition by itself.
This is not an argument for making every note bureaucratic. Informal thinking has value. The distinction becomes essential when informal notes feed public writing, consequential decisions, or another automated process. The wiki should help a reader see where knowledge ends and interpretation begins, rather than smoothing every sentence into the same authoritative voice.
Provenance is a relationship, not a decorative link
The W3C PROV overview, published as a Working Group Note in April 2013, describes provenance in terms of entities, activities, and people involved in producing data or other things. It provides a framework for exchanging such information. It does not certify that a claim is true merely because its provenance is recorded. W3C PROV overview.
For a personal wiki, the useful idea is to connect an output with the process that produced it. A page may derive from several sources, an extraction step, a summary, and a human review. A single URL at the bottom can identify one source while omitting the transformations that introduced the actual wording.
A hypothetical comparison table combines two reports with different measurement periods. The final table should record which value came from which report and how units were converted. Without that relationship, a later reader may see a polished comparison but be unable to determine whether the quantities were comparable.
The article's proposed minimum provenance record includes source identity, source version or observation date, relevant location, transformation, and review status. For simple notes, these fields can be brief. For calculations or disputed claims, they may need more detail. The record should be proportionate to the claim's complexity and consequences.
Provenance also helps distinguish independent evidence from repetition. Three pages may all trace back to the same press release. Listing all three as sources does not create three independent confirmations. A relationship graph can make the shared origin visible. The goal is not to produce an impressive web of links, but to show where the information actually entered the collection and how it changed along the way.
Source identity needs a stable reference
A web address can change, disappear, or serve updated content. A local filename can be renamed. A title can be reused. A knowledge system therefore benefits from source identifiers that remain stable even when presentation changes. The identifier should connect the current note to the exact material that was examined.
Dublin Core's metadata terms include concepts for identifying and relating resources, describing sources, and recording dates and versions. These terms provide a reusable vocabulary, not a requirement that a small personal wiki implement every field or adopt a particular database. DCMI Metadata Terms.
A hypothetical source record might contain a stable local ID, title, creator where known, original URL, publication date, retrieval date, and a reference to an authorized preserved copy. The record should distinguish the date the source was published from the date it was read. Confusing those dates can make old evidence appear current.
If a source has a revision identifier, retain it. If it does not, record what was observable and avoid inventing precision. A checksum can identify local bytes, but it does not establish authorship or truth. A timestamp can record an observation without proving when the underlying claim first became valid.
The article recommends treating identifiers as plumbing that supports review. Readers should still see meaningful titles and links, but the system should not rely on titles alone to merge records. Two similarly named documents may be different versions; one document may have several names. Stable identity helps prevent accidental duplication, mistaken merging, and a later correction being applied to the wrong source.
A citation should point to the supporting passage
A link to a long document may be better than no citation, but it can leave substantial verification work to the reader. When a claim depends on a particular paragraph, table, or figure, the wiki should preserve that location where practical. The more specific the claim, the more valuable a specific locator becomes.
The W3C Web Annotation Data Model, a Recommendation from 2017, supports structured relationships between annotations and resources, including targeting parts of a resource. It offers concepts useful for passage-level annotation. The article's proposed note format is simpler and does not claim formal conformance to that specification. Web Annotation Data Model.
A hypothetical note says a study used a certain sample size. The citation should identify the section or table establishing that number, not merely the journal homepage. If a PDF's printed page numbers differ from the viewer's page index, the record should make the locator unambiguous. A later reviewer should be able to reach the evidence without repeating the entire search.
Passage locators can break when documents change. Preserve enough context to detect that failure, such as a short permissible excerpt, a section heading, or a versioned source reference. Avoid copying large amounts of copyrighted material merely to make citations convenient. A precise pointer and original summary are often sufficient.
The purpose is accountability at the claim level. A source can be generally credible while failing to support a particular sentence. Passage-level citations make that mismatch easier to catch. They also help the system update only the claims affected by a source correction, instead of treating every page linked to the document as equally changed.
Version control records edits, not their correctness
Git's official documentation describes tools for comparing changes between versions, including the git diff command. Such tools can reveal additions, deletions, and modifications in a text collection. They do not determine whether an edit is factually justified or whether a cited source supports it. Git diff documentation.
A hypothetical automated edit changes “may reduce error in this experiment” to “reduces error.” A text diff makes the removed qualification visible. A reviewer still needs to decide whether new evidence justifies the stronger wording. Version control supplies the comparison; editorial judgment supplies the interpretation.
The article proposes small, coherent change sets. An ingestion step that updates several related pages should have a clear purpose and a record of affected claims. Combining unrelated corrections, formatting changes, and new analysis into one large update makes review harder. A clean history is useful because it narrows the question a reviewer must answer.
Commit messages should describe the substantive change rather than merely say that files were updated. For example, a message can identify a corrected unit conversion or a revised interpretation after a new source. It should not claim verification unless verification occurred. Automated systems are especially prone to generating confident summaries of work they have only partially completed.
Version control also does not replace backups or access controls. A repository can be deleted, exposed, or corrupted. The scope of this article is knowledge maintenance, but the implementation should distinguish edit history from recovery and confidentiality. Each mechanism has a different job, and a useful design avoids treating one familiar tool as a universal solution.
A change log should explain the reason
A chronological log can answer what happened and when, but a useful knowledge record also explains why. A page may change because a new source arrived, an error was found, a definition changed, or the curator adopted a different interpretation. These causes have different implications for downstream readers.
Consider a hypothetical page about a technology's performance. A new study uses a different workload and reports a lower result. The page might add the study without replacing the earlier result, because the conditions differ. If the log merely says “updated performance,” a later reader may assume the old result was disproved. The reason for the edit should preserve the comparison's boundaries.
The article recommends a change entry containing the affected page, claim or section, reason, evidence, and review outcome. This can be compact. A minor typo does not need a dissertation, while a changed conclusion deserves a clear explanation. The amount of detail should follow the significance of the change.
An append-only operational log can coexist with editable pages. The log records events; the page presents the current synthesis. If a log entry itself is wrong, correct it transparently rather than silently pretending the event history was always accurate. The goal is a trustworthy account of the work, not an immaculate narrative.
A good log also records incomplete work. If an ingestion failed halfway through, the entry should identify which pages changed and which remain pending. That prevents a future session from assuming the source was fully processed because a task was started. Completion should be an evidence-backed state, not a consequence of the assistant moving on to the next request.
Contradiction needs a model of context
Two sources can appear to disagree because they use different definitions, periods, populations, or measurement methods. A wiki that automatically resolves every apparent conflict by selecting the newest source can erase valid distinctions. A wiki that preserves every conflict without analysis can become confusing. The system needs a way to represent context before declaring contradiction.
A hypothetical report says a battery delivered a particular capacity under one temperature and discharge rate. Another gives a different value under another condition. The values may be compatible. The useful synthesis identifies the conditions rather than choosing a winner. By contrast, two sources claiming different dates for the same event may require a direct evidentiary comparison.
The article proposes a contradiction record with the competing claims, their scope, source locations, and current interpretation. Possible states include genuine conflict, apparent conflict resolved by context, superseded claim, and unresolved ambiguity. These categories should remain revisable when new evidence appears.
The system should not invent a compromise merely to make the page read smoothly. Averaging incompatible numbers or blending conflicting accounts can create a third claim supported by neither source. A clear statement of uncertainty is more useful than a polished synthesis that hides disagreement.
Human review is particularly valuable when the disagreement affects a central conclusion. The model can locate candidate conflicts and summarize differences, but the review should examine the original evidence. A personal wiki earns trust by showing where it cannot yet reconcile sources, not by making every page appear internally consistent at the cost of factual fidelity.
Derived claims need dependency links
A correction can affect more than the page where it appears. A source fact may support a comparison, which supports a recommendation, which appears in a presentation. If the original fact changes, those derived artifacts may need review. A knowledge system should be able to trace this dependency without assuming that every linked page is equally affected.
The W3C PROV Data Model, a Recommendation from April 2013, includes relationships for derivation and revision among its provenance concepts. These relationships provide a useful conceptual foundation for tracing how one artifact depends on another. They do not automatically identify which conclusions are logically invalid after a change. PROV Data Model.
A hypothetical cost comparison uses a figure from a source page. If the figure's unit was wrong, the comparison and its conclusion may require recalculation. A page that merely mentions the same source in a historical bibliography may not. Dependency information should distinguish use as evidence from incidental reference.
The article's proposed system records dependencies at the claim or section level where practical. A full formal knowledge graph is not required for every note. Even a simple list of derived pages can support targeted review. The key is to preserve the relationship when the artifact is created, when the author still knows why the source mattered.
After a correction, the system can mark dependents as needing review rather than rewriting them automatically. This is an important distinction. A change in evidence triggers a question; it does not always dictate the answer. The curator should be able to inspect the chain and decide whether the conclusion changes, remains valid, or needs a narrower qualification.
Search relevance is not evidentiary strength
A search system can retrieve pages that resemble a query, but similarity does not establish authority or correctness. A frequently repeated claim can become highly retrievable even if it rests on one weak source. A personal wiki should therefore distinguish finding a passage from deciding what weight to give it.
A hypothetical query asks whether a method works in a particular setting. The search returns a persuasive summary written months earlier. The underlying source concerned a different setting, and the summary's qualification was omitted. If the answer relies only on the retrieved summary, the wiki can amplify its own earlier mistake.
The article recommends a source-aware answer procedure. For consequential or disputed claims, follow the note back to the supporting source and inspect the relevant passage. The generated page can guide navigation, but it should not automatically replace the evidence. The required depth of checking depends on the stakes and the freshness of the claim.
Search evaluation should include difficult cases: similar titles, superseded pages, conflicting claims, and questions whose answer is absent. A system that always returns something plausible may be less useful than one that clearly reports an evidence gap. Retrieval success should not be defined merely as producing a nonempty result.
The wiki can also preserve negative findings. A note that a particular source was checked and did not establish a claim can save repeated work, provided the scope and date are clear. Absence of support in one source is not proof that no support exists anywhere. Recording that distinction keeps the collection helpful without converting incomplete searches into sweeping conclusions.
A schema can prevent some mistakes and miss others
A schema defines expected structure: required fields, allowed values, identifiers, and relationships. It can make a knowledge collection easier to process and validate. It cannot by itself establish that the content is true. A perfectly formatted false claim remains false.
SHACL, the W3C Shapes Constraint Language Recommendation, defines a way to validate RDF graphs against specified conditions. It illustrates the distinction between checking structure and establishing real-world truth. This article's lightweight wiki proposal does not require RDF or claim SHACL conformance; the specification is cited as an example of explicit, testable constraints. SHACL specification.
A hypothetical page schema requires a title, source identifier, evidence date, and claim status. A validator can detect a missing date or an invalid status label. It cannot know whether the source actually supports the claim unless additional semantic review occurs. Both checks are useful, but they should be reported separately.
The article proposes beginning with a small schema that addresses known failure modes. Too many mandatory fields can encourage meaningless filler or discourage maintenance. Too few can leave important distinctions invisible. The schema should evolve through observed needs, with versioned changes and a plan for older pages.
Migration deserves its own review. Adding a new field to hundreds of pages can create false precision if the model guesses missing values. Unknown information should remain unknown. A successful migration means that the structure changed accurately, not that every field became populated. This principle prevents administrative completeness from becoming a source of fabricated evidence.
A generated answer should not certify itself
When a wiki answers a question and saves the response as a new page, the answer can become evidence for future answers. That feedback loop is useful for preserving analysis, but it can also launder uncertainty. A statement repeated across several generated pages may look established even though no new source was added.
A hypothetical first answer says a claim is plausible but unverified. A later summary omits the caveat. A third page cites the second as support. The collection now contains an apparently stable fact whose only origin was a tentative inference. The problem is not the number of pages; it is the loss of evidence type and ancestry.
The article recommends labeling saved answers as derived analysis and linking them to their underlying sources. A later response should not count the saved answer as independent confirmation. If new evidence is added, the record should identify it explicitly. Repetition can improve organization, but it does not increase evidentiary independence.
Review can be targeted. Routine navigation notes may need little scrutiny, while pages that synthesize contested facts or support public claims should receive a stronger check. The system should identify which level occurred rather than marking every generated page as verified by default.
This design preserves the value of cumulative work without pretending that accumulation alone improves truth. A wiki can become more useful as it grows, but it can also become more confidently wrong if derived claims lose their provenance. The safeguard is a visible distinction between stored reasoning and independently observed evidence, maintained across every transformation that turns one into the other.
Source access does not settle reuse permission
The public gist contains an idea file, and the inspected author text did not display an explicit license statement. Comments on the page describe other people's projects, whose terms should not be attributed to Karpathy's file. This article summarizes the idea briefly and develops its own analysis rather than presenting a copied corpus or claiming unrestricted reuse rights.
GitHub's licensing documentation explains that public availability and open-source licensing are not the same thing, and that a license communicates permitted uses. The page also directs readers to appropriate licensing resources. This article does not give a legal opinion about a particular reuse; it recommends checking the terms attached to the actual artifact. GitHub licensing guidance.
A personal knowledge collection can contain materials with different permissions. A public article, a private message, a purchased book, and an original note should not automatically share the same distribution settings. The wiki should preserve source-level restrictions and avoid treating internal access as permission to republish full content.
The article proposes separating brief original summaries and citations from stored source copies. If a source copy is retained lawfully for private use, that does not automatically make it suitable for a public export. An export process should examine what is included, not merely assume that everything in the knowledge folder can be shared.
Permission metadata is not a substitute for legal advice when a real decision requires it. Its practical value is to prevent accidental scope expansion. A system that remembers where material came from and what terms were recorded is better positioned to flag uncertainty before a private research collection becomes a public publication.
Privacy boundaries should follow derived information
A private source can influence a public-looking summary. Removing names may not eliminate identifying details, and combining several innocuous facts can reveal more than each source alone. A knowledge system should therefore consider the sensitivity of derived pages, not only the location of the raw files.
A hypothetical personal note describes a confidential meeting. A generated topic page summarizes the discussion without names but includes a distinctive project, date, and event. Someone familiar with the organization may still identify the participants. A simple rule that public pages must omit names would miss the disclosure.
The article recommends sensitivity labels tied to source relationships and intended audience. A derived page should inherit a review requirement when it uses restricted material. That does not mean every derivative must remain permanently private, but it means publication requires a deliberate decision about what information is safe and authorized to share.
Search and export should respect these boundaries. A query answered for the owner may legitimately use private notes, while an answer prepared for a public audience may need a different evidence set. The system should know the audience before drafting rather than attempting to sanitize an unrestricted answer afterward.
This is a knowledge-maintenance issue rather than a detailed agent-security design. The central point is that provenance supports confidentiality as well as accuracy. If the system cannot trace which private sources contributed to a page, it cannot reliably explain why that page needs review before sharing. Good organization should reduce accidental disclosure, not merely make sensitive information easier to retrieve.
Dates need several meanings
A wiki can become misleading when every date is treated as the same kind of timestamp. Publication date, event date, retrieval date, review date, and validity period answer different questions. A page updated today may still rely entirely on evidence from years ago. A source published recently may describe an older event.
A hypothetical note says a service is available. The source was published last year, the page was imported today, and no current availability check occurred. Labeling the page “current as of today” would overstate the evidence. The accurate statement is that the source was retrieved today and reports availability at its own relevant time.
The article proposes separate fields where temporal distinctions matter. Not every note needs all of them, but dynamic claims should identify when they were last checked and what was checked. A review date should correspond to actual review, not simply an automated file touch.
Staleness rules should be claim-specific. A historical event date may remain stable, while a product feature, price, or office schedule may need renewed verification. A universal expiration interval can create unnecessary work for stable facts and insufficient review for volatile ones. The rule should reflect the use of the claim.
When a page becomes stale, mark it as requiring review rather than silently replacing it with a guess. The old information may remain historically useful. A well-maintained wiki can preserve both the past state and the current uncertainty, allowing readers to understand what was known then and what has or has not been checked now.
Maintenance has a measurable workload
Automation can reduce repetitive editing, but maintenance still includes source selection, error review, schema decisions, and correction of mistaken synthesis. The appropriate question is how much useful work the system performs and how much review remains. Claims of negligible maintenance should be treated as propositions to test in a particular workflow, not as universal properties of language models.
A hypothetical pilot can measure time spent adding sources, checking summaries, resolving conflicts, and repairing links. It can also track errors discovered after an update and the time needed to correct dependent pages. These observations provide a more realistic account than counting how quickly the model creates files.
The article recommends distinguishing gross output from accepted output. A system that writes many pages but requires extensive correction may be less efficient than one that produces fewer, better-supported pages. Page count is an activity metric, not a knowledge-quality metric.
Review burden can change with scale. A small collection may be easy to inspect manually. A larger collection needs better navigation, dependency tracking, and prioritization. The design should measure when its current methods stop being adequate rather than assuming that a successful small demonstration scales unchanged.
The stopping condition for a pilot should be explicit: a defined collection processed, representative questions answered, errors reviewed, and maintenance cost recorded. That produces evidence about the workflow. It does not establish that every future source can be incorporated automatically or that the collection will remain accurate without continued attention. A realistic account of maintenance makes the experiment more useful, not less ambitious.
A test set should include absence and correction
A knowledge-vault evaluation should not contain only questions with clear answers already present in the collection. It should also include questions whose answers are absent, ambiguous, outdated, or contradicted. These cases test whether the system can preserve uncertainty rather than manufacture completion.
A hypothetical test asks for a figure that no source provides. A useful answer explains the gap and identifies what evidence would be needed. Another test introduces a corrected source and asks whether the relevant summary and dependent comparison are marked for review. A third presents two people with similar names and checks whether their records remain separate.
The article proposes evaluating both answer quality and maintenance behavior. Did the system cite the right passage? Did it distinguish source claims from inference? Did it update the index and relevant dependencies accurately? Did it avoid changing unrelated pages? Did it record the reason for a correction? These are observable outcomes.
Test materials should be controlled and appropriately authorized. Fictional sources can expose structural failures without involving private information. Real sources can then be used to evaluate the intended research domain, with limitations recorded. The two types of test complement one another.
A passing result should identify the tested configuration and collection. Changing the model, schema, or extraction tools can change behavior, so important tests should be repeated after material updates. The objective is a living evidence record for the system's reliability, not a one-time demonstration that it can produce a convincing wiki page when everything goes right.
An index is a map, not proof of completeness
A collection can have a polished index while missing important sources or pages. The index describes what has been registered, not necessarily everything the user intended to include. A claim that all material has been added requires a defined inventory and a reconciliation process.
A hypothetical import begins with fifty source files. The system creates forty-eight source records and an attractive topic map. Without comparing the input inventory with the processed records, the missing two files may go unnoticed. A page count alone cannot establish completeness because one source can produce several pages and several sources can share one synthesis.
The article recommends a source-level status ledger: discovered, authorized for use, available, read, processed, reviewed, and excluded with a reason. These states should not collapse into one imported flag. A file can be stored without being read, and a summary can be generated without being checked.
Reconciliation should identify exact targets. “All of Karpathy's wiki” is ambiguous if the source is an abstract idea file rather than a supplied knowledge corpus. A responsible system should clarify the artifact it has actually inspected and avoid claiming to import material that was never provided. This article makes no claim about any user's completed publication or import status.
Completeness is always relative to scope. The useful statement is that every item in a specified inventory reached a specified verified state. That is stronger and more honest than saying everything is done without defining everything. It also provides a clear path for continued work when new sources arrive or previously inaccessible items become available.
Public output needs its own review boundary
A private wiki can support exploration, including tentative ideas and incomplete notes. A public article or shared report needs a separate review step. The transition should not occur automatically merely because the material is well organized or already written in fluent prose.
A hypothetical draft draws on several wiki pages. Before publication, the reviewer should check the underlying sources for central claims, verify dates and calculations, remove private material, and confirm that citations support the final wording. The wiki can make this faster by preserving provenance, but it cannot eliminate the editorial responsibility.
The article proposes an export record linking the public artifact to the source-page versions used. If a central source later changes, the system can identify which published outputs may need correction. This is especially useful when one knowledge collection feeds many articles, presentations, or summaries.
The public artifact should distinguish its author or commissioner from the people whose work it analyzes. Austin Little's commissioning of this independent analysis does not create a collaboration with Karpathy, and the presence of both names does not imply shared conclusions or endorsement. Clear attribution supports discoverability without inventing a relationship.
The same principle applies to any future knowledge-vault output. Credit the source accurately, label original analysis, and avoid converting an influential idea into a claim that its author approved the implementation. A well-maintained collection should make attribution easier to get right, not provide a new route for borrowed authority to attach itself to unrelated work.
The record should make revision easier than repetition
The most useful personal knowledge system is not the one that produces the greatest number of pages. It is the one that helps its owner find evidence, understand uncertainty, revise conclusions, and avoid repeating mistakes. Generated synthesis can support that goal when its relationship to sources remains visible.
The design proposed here centers on stable source identity, claim roles, passage-level citations, coherent change sets, dependency links, and explicit review states. These are not claims about a completed implementation or requirements attributed to Karpathy. They are practical ways to test and strengthen a knowledge workflow inspired by the question his idea raises: what should persist after an AI-assisted reading session?
A good answer includes more than the latest summary. It includes the reason the summary exists, the evidence behind it, and the history needed to change it responsibly. When a source is corrected, the system should help locate affected conclusions. When evidence is absent, it should preserve the gap. When a public output is prepared, it should support a fresh review rather than treating stored prose as self-validating.
For Austin Little's independent experiment, those are measurable goals rather than promises already fulfilled. The next meaningful result would be a documented pilot showing which sources were processed, which claims were checked, what errors occurred, and how correction worked. Until such evidence exists, the honest product is a design and a test plan.
A personal LLM wiki can become a powerful aid to sustained inquiry. Its credibility will depend less on how confidently it writes than on how clearly it shows what changed, why it changed, and what remains open. That record is what allows accumulated notes to become accountable knowledge rather than an increasingly elaborate echo of earlier answers.