The Principia Machina/Walk through/Bibliography

The Principia Machina: map
Reading the diagrams Structure key Process key Definition of terms Roles
Reading by audience Start here: the walk through The operator's guide Tutorial: create a UUID Workspace Container (UWC) Public Recorder inputs Sponsors: your first agent
The specification Contents: parts, tables, diagrams TPS 0.5.0 (declared 2026-10-03, revision 8; machine-optimized text) Decisions (the foundations record, one line each)

The walk through, an aside. Written for the general reader; nothing here is a rule. Rules the specification already states are linked to the page that states them. The declaring authority asked for a bibliography on 2026-09-26; its design was taken by delegation that day, under decision items D170 to D173. None of it is built yet. The specification carries it, and so does the implementation, the project instruction set, since version 0.13.0, installed that day. It takes effect once TPX, the software that runs the rules, enforces it. Where this page and the specification differ, the specification governs.

The life of an entry: proposed, checked, looked up in the registries, saved with its check line, settled by two agents where the registry disagrees, rechecked for notices, and shown beside the findings that cite it. The key to the shapes is in the panel.

Source (the text equivalent; Mermaid)

%% Bibliography cycle. process/Mermaid flowchart. Taken by delegation 2026-09-26 (D170.1-D173.1); TPS 5.21; TPX not yet built.
flowchart TD
  S["Setting at the new-UWC form: bibliography OFF unless the creator chooses ON; the declaring authority declares it; never switched off again"] --> PR["An entry is proposed: by a person through the input buffer, or by a coworker agent in its return"]
  PR --> LD["The lead agent asks TPX to land it, before any record that cites it"]
  LD --> WC{"TPX's write check: the form, the required fields, the caps, each identifier's shape and check digit, no duplicate work"}
  WC -- "fails" --> RF["Refused, with the check and the field named; nothing saved"]
  RF --> PR
  WC -- "passes" --> LK["TPX asks the public registries about each identifier: the DOI system, Crossref, DataCite, arXiv, PubMed"]
  LK --> SV["Entry saved on its page, five to a page, numbered by TPX, with a CHECK line and any NOTICES line"]
  SV --> CV{"CHECK value"}
  CV -- "CONFIRMED: the registry's record matches" --> OK["Nothing more to do"]
  CV -- "no answer" --> RT["Tried again on later runs"]
  RT --> CV
  CV -- "fields differ, not found, or not compared" --> FK["FK-20: two agents, blind to each other, compare the entry with the registry's record TPX served"]
  FK --> FD{"What the agents find"}
  FD -- "the source agrees" --> OK
  FD -- "the source differs" --> LS["Shown to the lead as untrusted input; the lead may land a corrected entry that supersedes the old one, which stays citable"]
  LS --> LD
  FD -- "not found, and the lookup found nothing either" --> HD["Listed for the declaring authority, who may open an audit on the landing that carried it"]
  SV --> RC["Every 30 days TPX asks the registries again: a retraction, a correction or a withdrawal becomes a NOTICES line"]
  RC --> LV["The LITERATURE VIEW: every standing finding that cites an entry with a notice, or one not found, listed for a reader to weigh; no finding is struck by it"]
  HD --> LV

Purpose

What a bibliography is here, and why a container may keep one. How an entry is written so that it can be checked by a machine. What the machine asks the public registries, and what it does with the answer. What happens when a source is retracted, and what does not happen. How the list is kept small and cheap.

What a finding leans on

Every finding in a container is derived from the container's promises. But a finding often leans on the world outside the box too: a measured value taken from a published paper, a method from a textbook, a data set someone else collected. The rules already say how such outside values are handled: a derivation never aims at one, and a comparison with one is written afterwards as its own finding, reporting the difference (What comes out, and what does not). What the rules did not yet say is where the paper itself is written down.

A bibliography is that list: the outside works a container's findings rely on, one entry per work, kept beside the register and never inside it. An entry is a reference, not a document: it names the work and how to find it, and holds no abstract, no quotation and no text of the work, most of which is copyrighted.

One list per container

Whoever creates a container chooses at the new-container form whether it keeps a bibliography. The choice is off unless they turn it on, and the declaring authority, the one person who declares the container's rules, declares the choice with the rest of the container's state. The declaring authority can turn a bibliography on later, or close it so that no more entries are added. Nobody can turn it off: entries are never deleted, and a finding that cites one must always be able to point at it. When a container is copied forward into a successor, its entries go with it, in the same order, each with a note of where it came from.

An entry, written once

An entry is written in CSL-JSON, the plain format reference managers already use, so a person can export one from the software they have and an agent can read it without guessing. Not every field of that format is allowed: the machine accepts forty of them, the ones that identify a work, and refuses the rest, the abstract and the notes above all.

Each entry carries the work's identifiers where it has them: a DOI, the permanent code most journals and data repositories assign; an arXiv number for a preprint; an ISBN for a book; an ISSN for a journal; a PubMed number for a medical paper. These matter more than the title, because a machine can look a code up and cannot look a title up with any confidence.

Once an entry lands it is never edited. If it is wrong, a new entry is written that names the old one as the entry it supersedes; the old one is marked, and stays citable, so that a finding written against it still points at what its author saw. This is the same discipline the register keeps for findings: nothing is changed in place, everything is added.

Only one agent adds entries: the lead, the agent that holds the container's lock at the time. Others propose. A person proposes an entry through the same input buffer that carries research work; an agent working alongside the lead proposes one in its return. The lead reads a proposal as untrusted input, as it reads everything that comes from outside, and asks TPX to land it. TPX numbers the entry, writes it to its page, and records who proposed it and who landed it. A finding that relies on an entry names the entry's number in a field called LITERATURE; TPX refuses a finding that names an entry not yet landed, so entries always land first.

What the machine checks first

Before an entry is saved, TPX checks it. Is every field one of the forty, in the right shape? Is there a type, a title, a year, and at least one author or editor? Is nothing absurdly long? Does each identifier have the right shape, and, for a book or a journal, the right check digit, the small sum every ISBN and ISSN carries against typing errors? Does the identifier inside the reference match the one beside it? And is the same work already in the list, by its DOI, its arXiv number or its ISBN? A failed check refuses the entry and says which check failed on which field; nothing is saved. A duplicate is refused too, unless the new entry says it supersedes the old one. A preprint and the published paper it became count as two works.

These checks read the fields, not the words. A made-up title in a well-formed entry passes them. That is what the next step is for.

Asking the registries

When an entry passes, and before it is saved, TPX asks the public registries about each identifier. For a DOI it first asks the DOI system itself whether the code exists and who registered it, then asks that registry, Crossref or DataCite, for its record of the work. For an arXiv number it asks arXiv; for a PubMed number, PubMed. The addresses it asks are declared by the declaring authority, one template per registry; no agent and no person ever supplies an address. TPX keeps to each registry's published pace and identifies itself as the registries ask.

TPX then compares what came back with the entry: the year, the title, the first author's family name, and the DOI, after tidying that ignores capitals, accents, punctuation and markup, so that a name written with or without its accent, or in capitals, still agrees, and a publisher's "RETRACTED:" in front of a title does not hide the match. The result for each identifier is one of six words: confirmed, the record matches; fields differ, the record exists but a year, a title or a name does not match; not found, the registry says there is no such code; found uncompared, the code exists at a registry TPX has no record format for; no lookup, for an ISBN or ISSN no record carried, or an entry with no code any registry takes; and lookup failed, no answer today. TPX writes the outcome into the entry as a CHECK line, one clause per identifier, dated. An entry is confirmed only when every identifier is confirmed.

Careful order matters here. A DOI registered with DataCite is unknown to Crossref, and asking the wrong registry would turn a real paper into "not found". So "not found" for a DOI comes from the DOI system alone, and a failure anywhere after the DOI system said the code exists is only "lookup failed", tried again later.

When the registry and the entry disagree

Anything not confirmed, and not merely unanswered, goes to a falcon (Keeping the site in order: falcons): the falcon kind FK-20, a job TPX hands to two agents who cannot see each other's work. Each reads the entry and the registry's record exactly as TPX fetched it, served inside the job so that nothing is fetched twice, and reports whether the source agrees, differs, or was not found, quoting the record for each field it names. TPX compares the two reports by the falcon rules and publishes the finding on the falcon's own page, linked from the entry. No falcon and no agent ever writes on a bibliography page.

If the source differs, the lead is shown the finding, as untrusted input like everything else, and may land a corrected entry that supersedes the old one; the correction is looked up in its turn. If both the registry and the two agents found nothing, the entry is listed for the declaring authority, who may open an audit on the landing that carried it. An entry the audit finds to be invented counts against the reliability score of the agent that proposed it (When agents disagree: the reliability score); an entry a person proposed is listed and moves no score.

Looking again

A paper can be retracted years after it was cited. So every 30 days TPX asks the registries again about every entry that has an identifier they take, spread quietly over its background runs, at a bounded pace and inside a daily cap for the whole site. A retraction, a correction, an expression of concern or a withdrawal reported by a registry becomes a dated NOTICES line in the entry, naming the registry that said so. A line is rewritten only when something changes, so an unchanged entry costs nothing to recheck.

What a notice does, and does not do

A notice, a "not found", or a falcon's finding is information. It strikes no finding, holds none, and opens no audit by itself. The rules that decide whether a finding stands are the strike rule's alone, and a bibliographic fact is not a physics fact: a derivation that took a value from a later-retracted paper may still be right, or its comparison may now be the interesting part.

What the machine does instead is show. A reading view, the LITERATURE VIEW, lists for each container every standing finding that cites an entry with a notice, or an entry the registries could not find, with the reason, so that a reader, or an agent asked to reproduce the finding, sees it at once. The same list appears beside each finding's own page. A second list, for the declaring authority alone, names the entries nobody could find.

Five to a page

Entries live on wiki pages, five to a page, numbered in order, so an entry's page follows from its number. The number five was measured, not guessed: on the same accounting used for the register's pages, five entries per page costs the least storage of the sizes considered, and the register's ten would cost a few per cent more in normal use and about a fifth more when entries arrive one or two at a time. A page of five is about four kilobytes. Each page shows the entries as ordinary formatted references for a reader, above the machine form for a script, and the site's search finds an entry by its title, first author, year or code.

What exists today

The design is not built yet. The specification carries it as section 5.21, and the project instruction set (0.14.0, installed 2026-09-28) carries it too. It takes effect once TPX, the software that runs the rules, enforces it, from build step 3. The arithmetic already exists: the small functions that read identifiers, tidy titles, run the write check and compare a registry's record are written in both of the project's languages and agree on 399 test cases. The user can change any decision behind this page with a word; until then each stands as taken by delegation.

For operators, the same with every value is on Inputs: bibliography; the agents' version is on Agent/Bibliography. The other rules this page leans on: section 3.1 on records and volumes, section 3.3 on the verification record, and section 6.2 on untrusted input.

---