The Research Record

Sections carry maturity tiers, in the discipline the Foundation's Working Group model already applies to standards work: CORE is the ratified spine, PROPOSED is substantially specified and open to the Working Group, FORWARD-LOOKING records an intention and specifies nothing. Promotion across tiers requires evidence, not consensus alone.

Standing of this document. Ratified as a draft on 25 September 2026 and opened to public review; the Research Record Working Group is eligible to be chartered against it. Ratifying a draft settles its standing as a document, not the standing of what it asks for: the Working Group model treats a specification nobody has built as a proposal rather than a requirement, and Appendix B lists six things this framework would require of existing systems. The first of them now exists — registry/concepts.json was built independently while this was being drafted, which is the strongest evidence available that the shape is right, and the least flattering possible account of this document's originality. The other five are not built. So it remains a ratified draft and a mostly-unbuilt requirement, which is the honest description, and the Foundation applies that judgement to itself before applying it to anyone else. What it describes is already in force as practice, because the generators that maintain the corpus need a vocabulary now.

Throughout this document the word lexicon is used in its ordinary sense — a controlled vocabulary of defined terms. It does not refer to Lexicon™, which is a distinct Foundation technology, nor to the Lexicon Substrate Working Group, which is a separate body chartered to separate work.

0. Principle — maturity tier: Core

Artifacts are immutable. Claims are revisable. Evidence accumulates. Lineage remains visible. Status is derived where evidence exists, and labelled where it does not.

That last clause is the whole of this framework. Every rule below follows from it, and a record that cannot say which of the two it is showing has failed.

1. Scope — maturity tier: Core

The Foundation maintains two bodies of work that make statements about the world, and until now they have used separate vocabularies for the same objects.

Proving — the Proving Grounds: forges, blocks, cells, reproductions, verdicts, standings. Governed by METHOD.md and contracts/v1/CONTRACTS.md. Machine-verified.

Publications — this site: research papers, technical reports, specifications, and the exploratory archive. Governed by publications.json and the generators that read it. Human-authored.

This framework is the shared root both domains reference. It does not replace either. It defines each term once, names which system is the record of it, and states whether its status is derived or asserted. Where this framework and contracts/v1 appear to disagree about a term the contracts define, the contracts win and this document is wrong.

A term is in this framework only if some system is the record of it. Vocabulary with no system behind it belongs in §10.

2. The lexicon — maturity tier: Core

Nothing in this table is new except Inquiry and Citation. The rest names what already exists, so that both domains can stop naming it differently.

Where the machine-readable form lives. registry/concepts.json, generated and checked by tools/build_concepts.py, is the declared vocabulary of the corpus: each concept with its provenance, the document that defines it, and its relations to others. This table is the prose definition; that file is the data the generators read. A term that matters is declared there, not merely described here — and where the two disagree, the file is right and this page is stale.

3. Primitives — maturity tier: Core

Five objects. Four already exist.

Claim — contracts/v1/claim.schema.json, already locked, already versioned, already carrying statement, scope, a required falsified_by, refines[] and supersedes. One registry serves both domains; a claim does not change identity according to what kind of evidence happens to bear on it.

Artifact — a record in publications.json, immutable at @version, addressable with a content hash.

Evidence — a cell, or an artifact's own reasoning and figures. See §5.

Citation — a reference, a retrieved date, and the claim it was used for.

Inquiry — new. A line of questioning with a permanent identifier, which may open without a thesis and close without one.

Requirement. Every registered claim states what would count against it, whether its evidence is sealed or argued. This extends the discipline claim.schema.json already imposes on the proving side, and it is the single strongest requirement this framework makes. A claim with no stated falsifier is not registered.

4. Relations — maturity tier: Core

Six edges. An edge is in this framework when a system checks it; the rest are §10.

5. Evidence has exactly two kinds — maturity tier: Core

This is the framework's spine, and the reason it is worth ratifying.

Sealed evidence is a Proving Grounds cell: bars frozen before the data existed, run once, signed, sealed, and mechanically verified. Its verdict is recomputed from the frozen bars by pg-core. Its standing follows from independent reproductions. No one — author, moderator, administrator, or the Architect — can set either by hand.

Argued evidence is an artifact's own reasoning, figures, and measurements. It is dated, attributed, and immutable at its version. It is not mechanically verified, and it produces no standing.

Both are legitimate. Most of the corpus is argued, and argued evidence is how a claim becomes worth sealing in the first place. The failure this framework prevents is not the existence of argued evidence — it is a reader, or a generator, mistaking one kind for the other.

Display rule. Sealed and argued statuses are never rendered in the same register.

• Sealed verdicts and standings are UPPERCASE, as contracts/v1 already writes them: PROVEN, DISPROVEN, INVALID, SEALED, REPRODUCED, RATIFIED, CONTESTED.
• Argued statuses are lowercase: open, supported, constrained, contradicted, withdrawn.

One glance distinguishes them, in prose, in a table, in a badge, and in a generated flag. The distinction costs a shift key and cannot be misread.

This rule describes existing practice rather than imposing a new one, which is the best evidence that it is the right rule. registry/concepts.json was built separately from this document and already observes it exactly: its verdict concepts are named PROVEN, DISPROVEN and INVALID, and its asserted statuses are specified, unratified and registry. Two independent hands reached the same convention without conferring.

Ordering rule. Where a claim holds both kinds, sealed evidence is presented above argued evidence, and the argued evidence is not hidden.

6. Claim status — maturity tier: Core

Where sealed evidence exists, standing is derived by pg-core from sealed cells, and this framework adds nothing. claim.schema.json states that standing is deliberately not a field; that decision stands and is not reopened here.

Where only argued evidence exists, the claim carries a lowercase status, asserted by its author, with a required pointer to the artifact that establishes it:

There is no asserted equivalent of RATIFIED, and there never will be. Ratification requires independent reproduction on other people's hardware, which is not a thing an author can assert about their own work.

contradicted is available to argued evidence because the corpus contains work that was refuted by experiments which were never Proving Grounds cells — the Invariant Theory of Meaning is the standing example, and it is retained at full prominence as refuted. Marking it contradicted with a named artifact is honest. Marking it DISPROVEN would claim a seal that does not exist.

A nine-state lifecycle is rejected. A hand-maintained status field with many states is the failure mode this repository has already lived through: records drift from the pages that describe them, and a page ends up asserting the opposite of the truth. Five asserted states, each requiring a named artifact, is the most this framework will carry.

7. Publication classes — maturity tier: Core

An artifact declares its class. The class is assigned explicitly and never inferred from a title.

Formal

• Research paper — a proposition defined sharply enough to meet evidence.
• Technical report — a system or a measurement, described for implementers.
• Specification — normative, carrying its own maturity states.
• Concept paper — a theoretical construction offered for examination.

Exploratory. Dated to when it was written. Not results, and not described as research.

• Inquiry — opens by not understanding something adequately, and records the walk.
• Note — written while thinking, not a result.
• Theory — proposed before it was tested.
• Experiment — run against code; findings are provisional.

The three exploratory glosses above are already in force in tools/label_archive.py and are reproduced here unchanged, so that the vocabulary has one definition rather than two.

On Inquiry. The corpus contains documents that are not research papers, not essays, and not expositions: they begin in genuine uncertainty and follow it. Naming that class legitimises metaphor, speculation, dead ends, and being wrong, under one obligation — that the reader can tell which is which. An inquiry must distinguish observation, intuition, analogy, hypothesis, proposition, result, and interpretation. That labelling is the whole of the discipline, and it is more honest than flattening the work into "paper."

Dead ends are first-class. A falsified path carries information: what exactly was believed, under which conditions, on what evidence. A claim refuted globally and later supported under a narrower condition is three claim versions with visible lineage, not one claim overwritten with "false." Disproofs receive the same prominence as proofs, which is existing Foundation practice and is recorded here as a rule.

8. Identifiers and the two citation forms — maturity tier: Core

Artifacts and claims are versioned, and every version keeps its own address. Identifier grammar follows contracts/v1 §1 for proving objects and publications.json for artifacts.

Immutable citation — SF-RP-2026-004@1.2, optionally with the content hash. Resolves to exactly what existed then, forever. This is the default, and it is what a citing author should use.

Living citation — SF-IQ-2026-014. Resolves to the current state of an inquiry, and the page states what that state is: how many claims are supported, constrained, contradicted, open, and when the last change occurred.

Constraint. A living citation is a permanent address carrying a maintenance obligation, and an address nobody maintains becomes the stale record this framework exists to prevent. Therefore an inquiry must be closeable — concluded or abandoned — and living citations are minted only for inquiries that are open. A closed inquiry's living citation resolves to its final state and stops moving.

9. Immutability and the correction flag — maturity tier: Core

An artifact never changes. What changes is the knowledge around it. A cited artifact acquires no edits and no silent corrections; citation drift is eliminated by never mutating the cited thing.

What the artifact acquires is a flag, stating that research status changed after publication, which claims are affected, what happened to each, when, and where the lineage continues. The flag does not say the artifact is wrong. It says the surrounding record moved.

The flag is generated from claim status, never hand-written. This is a requirement, not a preference. The hand-written version of this notice already exists in the corpus and has already contradicted the page it sat on. A generated flag cannot disagree with the registry it is generated from.

10. Not in this framework — maturity tier: Forward-looking

Recorded so it is not mistaken for an omission, and so a working group has somewhere to start. None of this is specified here, and nothing depends on it.

• External citation status — retractions, errata, corrigenda and follow-ups on cited third-party work, whether by published metadata services or by hand. The citation would not mutate; its status would change.
• Subscriptions — following a claim, an inquiry, or a citation, and being notified only when something epistemically material happens. This should ride the Proving Grounds application, which already specifies threads, notifications and digests. A second notification system is how two of them come to disagree.
• Further relations — generalizes, derives_from, interprets, fails_to_replicate, tests, interprets. Each is admissible the moment something checks it.
• A public claim graph — a rendered dependency graph of the corpus.
• Machine-readable vocabulary as a system type. The vocabulary in §2 is a controlled list with versioned members, which is the shape Lexicon™ exists to hold. That is a natural eventual home and is named here only as an observation.

11. Ratification — maturity tier: Core

This document follows the Foundation's standards process rather than inventing a parallel one. It is a Working Draft, and a Working Group is anchored to it: the Research Record Working Group, chartered per the program charter, operating under the same four commitments as the other groups — transparent and archived process, perspective drawn from more than one institutional context, implementation-first, and maturity-tier discipline.

The Working Group ratifies this framework, not the Board. The reason is a matter of what each body is for. Ratifying an instrument is a governance act; classifying a component is technical work. A vocabulary of thirteen terms, eight publication classes, six relations and five asserted statuses is a working document that will be amended repeatedly as the corpus grows, and routing each of those amendments through a board is how a framework stops moving. The Board's standing interest is that the Foundation keeps a research record on the principle in §0; the contents of the record's vocabulary are the Working Group's.

Sections are tiered individually so that ratification is not held hostage to the speculative parts. Offered as CORE: the principle, the scope, the lexicon, the five primitives, the six relations, the two evidence kinds with the display and ordering rules, claim status, the publication classes including Inquiry, the two citation forms, and the immutability rule with the generated flag. §10 is FORWARD-LOOKING, and is adopted as a list of intentions rather than a specification. Promoting anything out of §10 requires an implementation, on the same terms the Foundation applies to its standards.

Sequencing. The draft is ratified and in public review; the Working Group is eligible and not yet chartered. Those are separate steps on purpose. Public review can start immediately and needs nobody's permission, whereas chartering waits on the process the program charter defines, and holding the document back until a body existed to receive it would have kept it unread for no benefit. Until the Research Record Working Group is chartered, comment reaches the Foundation directly, and the engineering in Appendix B proceeds — that engineering, not the chartering, is what converts a ratified draft into a requirement anyone could be held to.

Where the Architect ratifies instead. Method versions are not in this framework's gift. METHOD.md §2 reserves method ratification to the Architect, and a steward may open a proposal but not carry it. Nothing here changes that, and a Working Group decision cannot promote a method version.

Amendment. This framework is a versioned object, as the method is. A change is proposed, ratified, and applies going forward. Artifacts and claims keep the framework version they were registered under and are never re-judged by a later one.

Appendix A · What was cut, and where it already lives

A longer scaffolding of ten primitives and twelve relations was considered. Five primitives were folded into objects that already exist, and are recorded here so the reduction is documented rather than silent.

Six of the twelve proposed relations were kept (§4). The remainder are listed in §10 and become admissible when something checks them.

Appendix B · What ratification would require of existing systems

Consequences, so the cost is visible before ratification rather than after. These six are also what the Working Group model's implementation-first commitment requires before this framework is a requirement rather than a proposal.

• ~~A machine-readable vocabulary~~ — built, independently, while this was being written. registry/concepts.json and tools/build_concepts.py hold the corpus's declared concepts with their provenance and relations, including the Method 1.0 verdict vocabulary sourced from METHOD.md §1.5. It is the machine-readable form this framework asked for, and it is normative where the two meet: this document is the prose definition, the registry is the data, and when they disagree the registry is what the generators read. Remaining work is extension rather than construction — §7's publication classes and §6's asserted statuses are not yet declared there.
• A claim registry for the publication side, sharing the identifier grammar and the falsified_by requirement with claim.schema.json, for claims whose evidence is argued.
• tools/label_archive.py gains the Inquiry class. The existing explicit-assignment behaviour is unchanged and is the reason this is cheap.
• The correction flag becomes generated from claim status, replacing the hand-written notices now in the corpus.
• Inquiry identifiers and closure state, so living citations have something to resolve to and something to stop at.
• The display rule enforced in the generators, so an asserted status cannot be rendered in the sealed register by accident.