Core data model

Every claim carries an id, text with markdown and link tokens, a kind (fact, limitation or history), citations from code or commits, a supports array for lead claims, a staleness marker, and a hook flag for Main Page candidates.^[1] A revision is one version of a feature page, storing its id, feature id, git sha, commit date, generation date, parent revision id, reason (build, update or manifest-change), model name, token usage and an infobox with file counts and languages.^[2]

The Architecture article (the project's own page at /special/about/) stores the project title, feature edges with import and call counts, sections named lead, purpose, layers, request-paths, dependencies and infrastructure, and a basis of feature page ids it summarizes.^[3] A feature page carries cite links as code citations (file, line range, sha, optional symbol, content hash) or commit citations (sha, subject, optional PR number).^[4]

A person revision stores the id, person id, git sha, sections (lead, chronicle, areas), and claim violations are checked to ensure chronicle claims cite commits and area claims cite exactly one feature.^[5] The core data model defines six kinds of schema: claims and sections, features and the manifest, revisions, the Architecture article, people and people pages, and the export format that bundles everything together.^{[1][6][7][8][9]} A feature has a permanent lowercase kebab-case id (at most 64 characters), a title, aliases, a status (active, redirect, disambiguation or retired) and a lineage of events (create, rename, merge, split or retire).^[10]

The manifest lists all features, their ids and titles, maps files and symbols to features with weighted membership, and validates that all references exist and are consistent.^[11] Person schemas hold identity facts (id, name, kind), activity counts (commits, lines added and deleted), featured work, pull requests, and a people snapshot at each sha listing all people, their redirects, and excluded people's anonymous activity.^[12]

The model uses Zod, a TypeScript schema validation library, to define types as z.object() chains with refinements that check cross-field rules; safeParse() returns success or an array of typed issues, while parse() throws on failure.^[13][14][15] ClaimId is a non-empty string; claim text is at most 2,000 UTF-16 code units; the claimAnchor() function generates an HTML id from a claim id by prepending claim- if the id matches the regex [A-Za-z0-9_-]{1,64}, or returns null otherwise.^[16]

Manifest.safeParse() checks that all feature ids are unique, all membership entries point to active features (not redirects), weights are between 0 (exclusive) and 1 (inclusive), and all redirect and split targets exist and form no cycles.^[17] Architecture validates that its id is architecture-<sha12>-<n> where sha12 matches the first 12 characters of its sha field; its basis array is sorted without repeats; its edges are sorted heaviest-first (by import + call count); and no edge repeats or joins a feature to itself.^[15] ArchitectureClaim extends Claim with a pages array (at most 3 feature ids); lead claims must support at least one body claim and carry no citations or pages; body claims need either a citation or a page; request-path claims must have a code or commit citation.^[18]

PersonName must be a cleaned, non-empty string where cleanPersonName() has removed all control, invisible, bidi and filler characters, collapsed whitespace, trimmed it and cut it to 120 code points.^[19] FeatureId is lowercase kebab-case at most 64 characters; Feature validates that its lineage starts with create, that merges and splits have matching status, that a redirect does not target itself, and that disambiguation targets are unique and do not include the feature itself.^[20][21]

The llmsTxt.ts module renders the wiki as a text file for LLM consumption: llmsTxtLine() escapes markdown and block markers in a max-length line; plainClaimText() strips link tokens to plain words; renderLlmsTxt() outputs the title, summary, pages with lead snippets, the About article, people, and a link to the JSON export.^[22][23]

The export format (WikiExport) bundles the manifest, all feature page revisions (current only), the Architecture chain, all person revisions (current only), and inflight pull request snapshots; it is serialized to JSON and served at export.json.^[24] Citations bind claims to source code (file, line range, sha, symbol) or commits (sha, subject, PR); each code citation includes a content hash so readers can warn when code at those lines has changed.^[4]

Feature data flows from the repository into a manifest with file-to-feature membership weights; revisions store the current state of feature pages and are chained by parent id; Architecture articles summarize the feature graph at each sha.^[25][2][26] Person data flows from git commits into a people snapshot holding all people, their commits, lines and pull requests; person revisions are chained like feature revisions and store the narrative text at each sha; the export carries only current revisions.^[27][9]

• People facts, snapshot and narrative revision schemas were added on 7 October 2026.^[28][29][30]
• The people registry, snapshot and blame cache were added to the store schema as migration 10 on 7 October 2026.^[31]
• The export format was extended to include people and person pages on 7 October 2026.^[32]
• The llms.txt renderer was added on 4 October 2026, rendering the wiki as a text file for LLM consumption.^[33]
• Token usage tracking was added to the export on 3 October 2026.^[34]
• The Architecture article schema was given a title field and Purpose and features section on 2 October 2026.^[35]
• The Ask schemas and claimAnchor function were added on 5 October 2026.^[36]
• GitHub snapshot schemas and inflight data structures were added on 6 October 2026.^[37][38]
• Email sanitization was progressively hardened from 7 October 2026 onwards to catch addresses in various disguises.^[39][40][41]

A TODO comment notes that claim text longer than the maximum is truncated rather than paged.^[42]