²⁴The Platform

The discipline of the last two chapters would stay a set of good intentions without software to enforce it. At the heart of that software is the record, its single source of truth, kept in a deliberately plain form: one record to a file. Each fact, source, evidence item, person, company, place, act, performance, recording, resident, relationship, study, chapter, open question and timeline row has a file of its own. There is a practical reason. A single change touches a single file, so the history shows plainly what changed and why, instead of burying it inside a large combined document. The larger combined files and the human-readable views are rebuilt from those records, never written by hand. Edit a generated view directly and the next rebuild simply writes over it.

That address-book page is a source, and in the record it becomes several linked entries: the source itself, the preserved scan, the reading beside it, and each fact drawn from it. The snapshot behind this site holds 385 facts, 709 sources and 2,817 evidence records, meaning the scans, crops, transcriptions and readings that sit under the claims; the record in numbers breaks them down by kind. Some rules are enforced by machine rather than left to care, and a reader can check them. A cited evidence record must point at a file that exists on disk, and a source with no preserved bytes must give a written reason for the gap. Each open question is checked for freshness against the research filed under it, so one whose ground has shifted is flagged as stale instead of being silently trusted. A living person's contact details fail validation unless they are marked public and carry a source.

A finding travels a long way from an archive into the record, and only the last stretch may change accepted knowledge. First the material is retrieved and preserved. Then it is read and transcribed, and a claim is drafted with its support and its uncertainty. Only then does the claim reach the gate that can write it in, and the gate has four steps. The change is drafted as a proposal that sets out exactly what it would add or alter and what it rests on. It is previewed, laid out in full for the owner to read before anything is committed. It is accepted as a deliberate act, or it is not. Only after that is it applied and written into the record; rebuilding the read-only views the public sees is a separate step that comes afterwards. Acceptance is tied to the exact change that was previewed. If the proposal or the project has moved on since the preview, the stale acceptance is refused, so nothing the owner did not see gets applied. How a change is accepted walks through the whole gate and the faults it stops.

Behind the four steps sits a rule about who may write. One core software package owns every accepted write, every check and every local build. The command-line tool a person runs only launches it, through a handful of plain verbs: check the project, search the record, take in new material, review a change, build the local views. There is no publish command at all, so building the views on your own machine is never the same as putting them online. Each accepted change goes down a single controlled path, which means the people and models working on the corner at the same time cannot quietly overwrite one another. The many models that fetch, read and draft can prepare material as a draft, but they are built to fail closed if they try to change the record themselves. Validation fails closed too. A reference to something not registered, the same scan filed under two records, an acceptance gone stale, or a breach of the rule protecting a living person: each stops a change before it settles. The gate checks less than truth, though. It checks that a change hangs together, not that its reading of history is right, and that is why the site also keeps an open ledger of the values it has had to correct.

On top of the record sits a layer for reading it, and none of that layer is evidence. The generated views are rebuilt from the record. An offline dashboard, the Control Pane, gathers the corpus in one place to be read and searched. Two of these aids need a fuller explanation, because there a machine does the most, and there it would be easiest to mistake a convenience for a proof.

The first is the graph: the record drawn as a picture. People, firms, places and objects become points, and the recorded relationships between them become the lines that join them, so a reader can follow who was connected to whom without piecing it together a sentence at a time. The graph is generated from the record, not drawn by hand, and kept as a disposable, fingerprinted view that is thrown away and rebuilt whenever the record changes. It stays honest because a relationship is stored as a claim in its own right rather than a bare line, with its own standing (confirmed, probable, lead or disputed), exactly like a fact. Since each link is a claim, conflicting records about a connection are both kept and both drawn, and neither overwrites the other. Whether a link comes straight from a document or is inferred from other records is noted separately from how certain it is. A connection that runs both ways is held in one canonical place instead of being copied onto each end. When the graph traces a path from one person to another, it will not step through a mere lead or a disputed connection as though it were settled, nor lean on a hub that dozens of records happen to share. A heavier third-party graph framework, Graphify, was evaluated for querying, visualising and analysing the graph and was not adopted as the engine. It was kept only as an optional route further downstream, for an interactive view and for exporting the graph to other tools. What runs here is a thin layer the project owns.

The second aid is the search, which works two ways at once. One is a ranked word search. Rather than merely finding records that contain a word, it scores them by how well they fit the words of a query, using the long-established BM25 method. The other matches on meaning. It rests on an embedding, which turns a passage into a long list of numbers standing for what the passage is about. Two passages that say the same thing in different words end up with similar numbers and land near each other, so a search can surface a record that means what you asked even when it shares none of your words. The two rankings, by words and by meaning, are fused into one result by a method called Reciprocal Rank Fusion. The meaning half earned its place. Measured on a fixed set of questions, it lifted the share of right answers in the top ten from 34 to 39 per cent, winning most clearly on paraphrased queries. It is also freshness-gated: its index has to be rebuilt whenever the record changes, and while the index is out of step the meaning half fails closed and declines to answer from stale numbers, so it is consulted only when current. The embeddings are computed on the project's own machines by a local EmbeddingGemma-300M model running under Ollama, and nothing is sent out.

Whatever the surface, the rule is the one the proof chain already set. A generated summary, a graph or a search result helps you find your way through the record and never proves anything in it; where an aid and the document beneath it disagree, the document stands. The machine is a record, a gate, and a set of read-only views over it. The next chapter turns to who actually drives it, and how much of this work a model did.