feat: rewrite docs

2026-10-12 07:55:22 -04:00
1 parent 8b2df58266
commit 002e2c3552
@@ -1,18 +1,32 @@
 # 0. Introduction

+This chapter is for three readers.
+A newcomer, who knows what a scientific paper and a citation are, finds what the specification covers and how to read it.
+An implementer, who will write a reader, writer, converter or checker, finds the rules for conformance, identifiers, versions and status.
+An expert, who knows the neighboring standards, finds the status of each format and how the specification relates to those standards.
+
 ## 0.1 Scope

-These specifications define the data that tools for reading, correcting, annotating and checking scientific papers exchange: documents and their packages, anchors, receipts, rights records, layers, exercises, datasets, digitizations, views, projects and bundles.
-They define data, not programs.
+Tools that read, correct, annotate and check papers can work together only if they agree on the files they exchange.
+The specification defines that data: documents and their packages, anchors, receipts, rights records, layers, exercises, datasets, digitizations, views, projects and bundles.
+A package is a document stored as a set of files; an anchor is a reference to a place in a document that stays checkable when the document changes.
+
+It defines data, not programs.
 A conforming file can be read, checked and loaded without any particular program, and every rule is stated so that a second implementation, in any language, computes the same bytes.

+The specification does not replace the standards around it.
+JATS ([ANSI/NISO Z39.96-2024](https://www.niso.org/publications/z3996-2024-jats)) remains the format for publishers and archives to exchange journal articles; here it is only one kind of input to a document.
+Layers are [W3C Web Annotations](https://www.w3.org/TR/annotation-model/) with a custom selector for the anchor. [docs/comparison.md](../docs/comparison.md) compares the specification with the standards near it and says where each is the better choice.
+
 The [guides](../docs/README.md) explain what each format is for, and the [rationale](../docs/rationale.md) why its rules are what they are.

 ## 0.2 Conformance language

 The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in capitals.

-Three classes of implementation are distinguished.
+The suite is the set of test vectors (inputs paired with the outputs every implementation must compute) and fixtures (example files, valid and invalid) in the repository. [22](22-conformance.md) describes it.
+
+The specification distinguishes three classes of implementation.

 | Class | Does | Must |
 | --- | --- | --- |
@@ -25,19 +39,24 @@ An implementation states, for each format, which versions it reads and writes.
 ## 0.3 Format identifiers and versions

 Every format has an identifier of the form `scienting-<name>/<major>`, such as `scienting-doc/1`.
+The identifier tells a reader which rules apply to a file.
+The prefix `scienting-` is the namespace of the formats.
+The namespace is not the name of this repository, manuspec, and formats are named after what they hold.
+
 A file or record that can travel on its own carries its identifier in a `format` property.
+The anchor in `fixtures/records/anchor-leaf.json` begins `{"doc":"hale2026harmonic","format":"scienting-anchor/1", ...`.
 Records inside a package file whose format the manifest fixes, such as the lines of `nodes.jsonl`, do not repeat it.

 A change that makes a valid file invalid, or that changes a computed value, is a breaking change and needs a new major version, with a migration.
-Adding an optional property, a node kind, a run kind or an enumeration value is a minor change.
+Adding an optional property, a node kind, a run kind, or an enumeration value is a minor change.
 A consumer of version *n* MUST refuse a major version it does not know, and SHOULD warn on, but accept, enumeration values added in a later minor version.

-The specification as a whole is versioned with semantic versioning; this is version 0.1.0.
-[registry/formats.json](../registry/formats.json) lists every format with its media type, schema and status.
+The specification as a whole is versioned with semantic versioning; this is version 0.1.0. [registry/formats.json](../registry/formats.json) lists every format with its media type, schema and status.

 ## 0.4 Status

 Each format has one of three statuses, listed in [registry/formats.json](../registry/formats.json).
+In version 0.1.0 the registry lists 27 formats: 20 are `candidate` and 7 are `provisional`; none is `reserved`.

 | Status | Meaning |
 | --- | --- |
@@ -46,11 +65,14 @@ Each format has one of three statuses, listed in [registry/formats.json](../regi
 | `reserved` | Named and shaped, but not yet specified in full. |

 Some fields matter only to some users: a personal library has no use for spot-checks, and a team that reads only open-access papers rarely needs a policy.
-Those fields are defined all the same, so that files move between a personal library and a team's store without conversion.
+Those fields are defined anyway, so that files move between a personal library and a team's store without conversion.
 A consumer that does not use a field MUST still preserve it when it rewrites a file.

 ## 0.5 How the repository is arranged

+A normative folder defines what conforming means.
+The other folders help people use the specification.
+
 | Path | Holds | Normative |
 | --- | --- | --- |
 | `spec/` | These chapters. | Yes |
@@ -64,4 +86,4 @@ A consumer that does not use a field MUST still preserve it when it rewrites a f
 | `docs/` | Guides for people getting to know the formats. | No |

 The programs in `tools/` compute every expected value, so that none is typed by hand.
-They are not a library: implementations conform to the chapters and the vectors, and `scienting-core` is the reference implementation of the shared rules.
+They are not a library, and implementations conform to the chapters and the vectors.
@@ -12,7 +12,7 @@ A document containing a lone surrogate, `NaN` or an infinity has no canonical fo
 Every hash of a JSON value in these specifications is a hash of its canonical JSON, encoded as UTF-8.
 The vectors in `canonical-json.jsonl` give JSON text to parse as IEEE 754 doubles and the canonical output.

-Lode keeps its own canonical form for its stored hashes; that form is Lode's and is outside this text.
+A store may keep its own canonical form for its stored hashes; that form is outside this text.

 ## 1.2 Numbers

@@ -67,7 +67,7 @@ No file carries the time it was written, unless the time is part of the record,
 | --- | --- | --- |
 | Node ID | Seven characters of lowercase Crockford base32, the first a letter. | `^[a-hjkmnp-tv-z][0-9a-hjkmnp-tv-z]{6}$` |
 | Record ID | 7 to 26 such characters, the first a letter. Derived records use 13. | `^[a-hjkmnp-tv-z][0-9a-hjkmnp-tv-z]{6,25}$` |
-| Key | A document, work, store, project or source key, as Lode's source keys are. At most 128 characters. | `^[a-z0-9][a-z0-9._-]*$` |
+| Key | A document, work, store, project or source key. At most 128 characters. | `^[a-z0-9][a-z0-9._-]*$` |
 | Alias | A legacy ID; it always holds a `.`, `_` or `-`, so it never looks like a node ID. | `^[a-z0-9][a-z0-9._-]*[._-][a-z0-9._-]*$` |
 | Dataset ID | `ds-` and a key. | `^ds-[a-z0-9][a-z0-9._-]*$` |

@@ -35,7 +35,7 @@ a figure-text item with kind `figure-text` and the text hash of its text.
 | --- | --- |
 | Permanence | Once established, an ID never changes, and no other node ever takes it. |
 | Retirement | A `merge` or a `delete` retires IDs ([11](11-corrections.md)). A merge records the surviving node as the successor; a delete records none. |
-| Aliases | Legacy IDs, such as the `b-p03-text-004` block IDs Lode's extracts use today, are recorded as aliases of the node that now holds that text. |
+| Aliases | Legacy IDs, such as the `b-p03-text-004` block IDs an earlier extract format used, are recorded as aliases of the node that now holds that text. |
 | Labels | What people say, such as "Eq. 3" or "Table S1", is a `label`, never an ID. |
 | Display paths | Tools may show a path such as `§2.3 ¶4 s2`; it is never stored or cited. |

@@ -10,14 +10,14 @@ In this chapter *H* is SHA-256 written as hexadecimal; under a keyed scheme, *H*

 | Value | Definition | Used for |
 | --- | --- | --- |
-| `text_hash` | *H*(normalize(plain projection)) | Quotations and Lode's verbatim check, where every character counts. |
+| `text_hash` | *H*(normalize(plain projection)) | Quotations and verbatim checks, where every character counts. |
 | `match_hash` | *H*(strict projection) | Certifying that two witnesses agree, and recognizing the same text elsewhere. |
 | `align_key` | *H*(lossy projection) | Proposing alignments. It never certifies anything. |
 | `own_hash` | *H*(canonical JSON of the node's own content, [5.2](#52-own-content)) | Anchors on containers that have content of their own. |
 | `node_hash` | *H*(canonical JSON of `{"own": own_hash, "children": [each child's node_hash, in order]}`) | Pins on leaves; the root hash; knowing that something below has changed. |

 Normalization is that of [1.4](01-conventions.md#14-text-normalization-for-hashing).
-Because each `node_hash` covers its children's, the root's `node_hash` is a Merkle root: a correction to one sentence changes that sentence's values and the `node_hash` of each ancestor, and nothing else.
+Because each `node_hash` covers its children's, the root's `node_hash` covers the whole tree (it is a hash over canonical JSON of `{own, children}`, not an RFC 6962 Merkle root, which [8.5](08-fidelity.md#85-merkle-roots) defines for receipts): a correction to one sentence changes that sentence's values and the `node_hash` of each ancestor, and nothing else.
 `hashes.jsonl` gives every value for every node of a small document, with each node's own content.

 ## 5.2 Own content
@@ -30,7 +30,7 @@ On the web the node ID is the fragment: `…/smithlab/cornell1995second#k3m9q2a`
 ## 6.2 The anchor

 An anchor, `scienting-anchor/1`, is the stored form of a pinned address, with enough context to survive change.
-It is what Lode extracts, annotations, dataset values and draft citations use.
+It is what extracts, annotations, dataset values and draft citations use.

 | Property | Required | Holds |
 | --- | --- | --- |
@@ -101,7 +101,7 @@ This finds a value again even in a table with multi-level headers or row labels
 The result is `{result, node, node_hash?, span?, drift?, via?, reason?}`: the outcome, the live node and its `node_hash`, the new span, the drift of a `changed-below` result, the IDs followed, and a reason for `stale` and relabel results.
 A `moved` or `reattached` anchor is re-pinned to the live node, and the move is recorded.

-Checks are stricter than readers: a Lode extract is a span or leaf anchor and never accepts `changed-below`, because a check is about exact words.
+Checks are stricter than readers: an extract is a span or leaf anchor and never accepts `changed-below`, because a check is about exact words.
 `resolve.jsonl` resolves seventeen anchors made at revision 0 against `fixtures/packages/hale2026harmonic` at revision 12, with every outcome.

 ## 6.6 Drift
@@ -69,6 +69,7 @@ Self-hosted deployments sign with team keys or a private Sigstore deployment; th

 A receipt's items are `["node", id, node_hash]` for each listed node, in order, followed by its `records`.
 The root follows RFC 6962: a leaf hash is SHA-256 of the byte 0x00 and the item's canonical JSON; an interior hash is SHA-256 of 0x01 and the two child hashes; a list of *n* > 1 items splits after the largest power of two less than *n*.
+RFC 6962 has since been replaced by RFC 9162, which defines the same tree.
 A root over one item is that item's leaf hash; a receipt with no items is invalid.
 The tree allows a proof that one node was covered without revealing the others; `merkle.jsonl` gives roots for one to seven items.

@@ -91,7 +92,7 @@ It is valid when its signature verifies and its signer is the revoked receipt's

 The roster, `scienting-roster/1`, lists the keys that may sign: each with an `id`, a `person`, a `scheme`, its `public` key (Base64 for Ed25519), its `purposes` (`sign`, `spot-check`, `export`), `registered_at` and `revoked_at`.
 A package MAY carry the roster its receipts need as `roster.json`, so its receipts verify without the store.
-The roster is meant to be the same one Lode verifies; see the [rationale](../docs/rationale.md#limits-worth-knowing).
+The roster is meant to be the one a store verifies against; see the [rationale](../docs/rationale.md#known-limits).

 ## 8.8 Spot-checks

@@ -118,7 +119,7 @@ A QA report, `scienting-qa-report/1`, states for each reviewer who signed a deli

 ## 8.10 Targeted F3

-The target set of a document is every node that a Lode extract, a dataset value, a confirmed `claim-link`, a draft quotation or a pinned citation anchors, plus every display equation, plus every sentence with a digit in a `text` or `math` run.
+The target set of a document is every node that an extract, a dataset value, a confirmed `claim-link`, a draft quotation or a pinned citation anchors, plus every display equation, plus every sentence with a digit in a `text` or `math` run.
 Digits in `cite`, `xref` and `fnmark` runs do not count.
 A project sets the digit rule to `all`, `anchored-sections` (only sentences in a section that holds an anchored node) or `none`.
 Neighbors shown for context are not in the set, and nothing new comes to rest on a node below F3 without the node joining the set.
@@ -31,7 +31,7 @@ Runs are made canonical after every operation, and the result MUST satisfy every
 | `author` | `{key}` for a person in the roster, or `{model, run}` for a model's session. |
 | `reason`, `at` | Why, and when. |

-A proposal, such as one an MCP client makes, carries these and `status: "proposed"`, and no applied fields.
+A proposal, such as one a tool makes, carries these and `status: "proposed"`, and no applied fields.

 ## 11.3 Applied fields

@@ -37,7 +37,6 @@ A producer that wants byte-identical archives writes entries sorted by path, dat
 `MANIFEST.json`, `scienting-package/1`, is `{format, doc, key, files}`: the package format, `scienting-doc/1`, the document key, and every other file as `{path, sha256, size}`, sorted by the UTF-8 bytes of the path.
 An asset whose bytes stay in the asset store is listed with `present: false`; nothing else may be.
 The SHA-256 of `MANIFEST.json` pins the whole package.
-The manifest is meant to have the same shape as Lode's `lode-cache/1`, so Lode can hold a package as a source cache.

 ## 12.4 Provenance

@@ -43,7 +43,7 @@ Each keeps its record whole in a `record` or `descriptor` column, with the colum

 ## 13.5 The bundle

-A bundle, `scienting-bundle/1`, is one SQLite file that a reader, a server or an MCP server queries.
+A bundle, `scienting-bundle/1`, is one SQLite file that a reader or a server queries.
 It holds the tables of `doc.sql` and `store.sql`, then those of [sql/bundle-sqlite.sql](../sql/bundle-sqlite.sql):

 | Table | Holds |
@@ -4,7 +4,7 @@ A dataset, `scienting-dataset/1`, is a Frictionless Data Package (`datapackage.j

 | Addition | Meaning |
 | --- | --- |
-| Units | Every numeric field has a `unit`, a string Pint can parse, as Lode's dimension check expects. |
+| Units | Every numeric field has a `unit`, a string Pint can parse, so a checker can test dimensions. |
 | Uncertainty | A field may give `uncertainty`: `{field?, kind}`, the field that holds it and its kind, `sd`, `se`, `resolution` or `unknown`. |
 | Origin | Each resource has an `origin`, or `origin_field` and `origins` when it varies by row. |

@@ -12,7 +12,7 @@ A dataset, `scienting-dataset/1`, is a Frictionless Data Package (`datapackage.j
 | --- | --- |
 | `reported` | Values anchored to the table cells or sentences that print them, in `anchors.jsonl`. |
 | `digitized` | Values read off a figure: the digitization's ID, and `anchors.jsonl` naming each value's series and point. |
-| `computed` | A Lode claim's implementation, by claim and pin. |
+| `computed` | A claim's implementation, by claim and pin. |
 | `measured` | The team's own data, with its provenance. |

 The descriptor also carries `format` and an `id`, `ds-` and a key.
@@ -23,5 +23,5 @@ Values keep their digits as printed: CSV cells are never reformatted, and in JSO
 A digitized value never passes as reported, and its uncertainty is at least the resolution of its digitization.

 A dataset's content hash is SHA-256 of the canonical JSON of `{"format": "scienting-dataset/1", "files": [[path, sha256, size], …]}` over its files, sorted by path.
-A dataset can be a Lode source of kind `dataset`, so a claim can rest on a value read from a figure, with that fact visible in its evidence.
+A dataset can be a source of kind `dataset`, so a claim can rest on a value read from a figure, with that fact visible in its evidence.
 `fixtures/packages/hale2026harmonic/datasets/ds-hale-bond-params` reports Table 1, and the suite checks that every value resolves to the cell that prints it.
@@ -2,7 +2,7 @@

 A view, `scienting-view/1`, is a Vega-Lite specification whose `usermeta.scienting` pins its data: `{format, id, data, computation?}`.
 Each entry of `data` names a Vega-Lite data source, the dataset it is, the dataset's content hash and a resource, and the specification refers to it as `{"data": {"name": …}}`.
-A view is declarative JSON, so it is diffable, renders without studio code, and is easy for a model to write.
+A view is declarative JSON, so it is diffable, renders without custom code, and is easy for a model to write.

-A view can also hold a computation: a Lode claim's implementation, by claim and pin, run in the browser by Pyodide, with Vega-Lite parameters bound to its inputs.
+A view can also hold a computation: a claim's implementation, by claim and pin, run in the browser, with Vega-Lite parameters bound to its inputs.
 That is how a reader drags a bond constant and watches the energy curve change beside the equation that defines it.
@@ -6,7 +6,7 @@ The JSON-LD context is [context/scienting-1.jsonld](../context/scienting-1.jsonl

 ## 18.1 One rule decides what is a claim and what is a layer

-If a statement is true independently of this paper, it belongs in Lode as a claim, where it is checked and leveled.
+If a statement is true independently of this paper, it belongs in a claim store as a claim, where it is checked and leveled.
 If it is about reading this paper, it belongs in a layer, where it is attributed and signed but not checked.

 ## 18.2 The layer
@@ -40,8 +40,8 @@ Replies are annotations that target annotations, so discussions are threads anch
 | `kind` | W3C type | Adds | Says |
 | --- | --- | --- | --- |
 | `gloss` | `TextualBody` | `audience` | An explanation at `novice`, `student` or `expert` level. |
-| `claim-link` | `SpecificResource` | `source` (`lode:<tag>`), `pin`, `role` | That the span `states`, `uses` or `disputes` a Lode claim. |
-| `symbol` | `SpecificResource` | `source`, `pin`, `symbol` | That this occurrence of a symbol is a Lode symbol claim. |
+| `claim-link` | `SpecificResource` | `source` (`lode:<tag>`), `pin`, `role` | That the span `states`, `uses` or `disputes` a claim. |
+| `symbol` | `SpecificResource` | `source`, `pin`, `symbol` | That this occurrence of a symbol is a symbol claim. |
 | `comment` | `TextualBody` | | A remark, opinion or interpretation. |
 | `caveat` | `TextualBody` | | A warning a reader should see. |
 | `question` | `TextualBody` | `for` | A question for a `reader`, a `group` or the `authors`. |
@@ -19,7 +19,7 @@ Feedback is `{hit, miss}` per element.

 ## 19.2 Verdicts

-| Verdict | Means | As Lode evidence, if a person confirms it |
+| Verdict | Means | As claim evidence, if a person confirms it |
 | --- | --- | --- |
 | `supports` | The passage says what the citing sentence claims. | `supports` |
 | `partly` | It says some of it, or with a qualification the citing sentence drops. | `qualifies` |
@@ -9,7 +9,7 @@ A project, `scienting-project/1`, is the unit a team works in.
 | `documents` | The project's documents, each with the `reason` it is included, `tags`, and a reading `status` per member: `unread`, `reading` or `read`. |
 | `paths` | Reading paths: ordered steps through documents, nodes, claims and layers, for onboarding a student or preparing a reading group. |
 | `layers`, `datasets`, `views`, `drafts` | What the project holds. |
-| `claims` | The Lode namespace or bundle it uses. |
+| `claims` | The claim namespace or bundle it uses, as the `lode` setting. |
 | `settings` | The digit rule for targeted F3 ([8.10](08-fidelity.md#810-targeted-f3)), the drift threshold ([6.6](06-anchors.md#66-drift)), the spot-check rate and minimum ([8.8](08-fidelity.md#88-spot-checks)), what happens when a right is unknown (`refuse`, the default, or `warn`), and the stage requirements in use. |

 Projects are small on purpose: everything about them is designed for hundreds of documents, not millions.
@@ -5,7 +5,7 @@ Its sentences cite library sentences by address, in `xref` runs whose targets ar

 ## 21.1 The snapshot

-A snapshot, `scienting-snapshot/1`, is to a Typst draft what `lode.lock` is to a Quarto document: a pinned, verified file the compile reads, so a draft renders offline and reproducibly.
+A snapshot, `scienting-snapshot/1`, is to a Typst draft what a lock file is to a document: a pinned, verified file the compile reads, so a draft renders offline and reproducibly.
 It holds the `store`, when it was made, the `quotes` the draft cites (each an address, an anchor, the text, its fidelity and how the anchor resolved), the `claims` (each a reference and pin, with whatever renderings the draft uses) and the `datasets` (each an ID and content hash).

 ## 21.2 Sentence IDs in a draft
@@ -1,45 +1,51 @@
-# The scienting specifications
+# The manuspec specification

-This is the specification of the scienting formats: exactly what each file holds and how every value in it is computed.
-For what the formats are for, start with the [guides](../docs/README.md); this text assumes you know why and tells you how.
-Schemas, SQL, the JSON-LD context, the registries, the vectors and the fixtures are normative too, and the chapters say which.
-Where a chapter and a vector disagree, the disagreement is a bug; please report it.
+This specification states exactly what each manuspec file holds and how every value in it is computed.
+The schemas, SQL, JSON-LD context, registries, vectors and fixtures are normative too, and each chapter says which of them it relies on.
+A chapter and a vector that disagree signal a bug, so please report it in the repository, <https://git.scient.ing/infra/manuspec>.
+
+Two readers will get the most from it: implementers who build a reader, writer, converter or checker, and experts who want the precise rules.
+Newcomers should start with the [guides](../docs/README.md), which explain what the formats are for.
+This text assumes you know why and tells you how.

 ## Reading paths

+Find the row for the job you are doing and read its chapters after those in the first row.
+Chapter numbers are those in the table below.
+
 | If you are writing | Read |
 | --- | --- |
-| Anything at all | 0, 1, 3, 4 and 5: conventions, nodes, identity and the content values. |
+| Anything at all | 0, 1, 3, 4 and 5: introduction, conventions, nodes, identity and the content values. |
 | A reader of packages | Then 2, 6, 7 and 12: the model, anchors, geometry and the package. |
 | A converter | Then 9, 10 and 11: figures and tables, references, and corrections with the gate. |
 | A store or a server | Then 8, 13 and 14: receipts, the database form, and rights. |
-| A tool for annotation, teaching or data | Then 15 to 21. |
+| A writer or reader of annotation, teaching or data files | Then 15 to 21. |
 | A validator | Chapter 22, with [registry/rules.json](../registry/rules.json). |

 ## Chapters

 | Chapter | Subject |
 | --- | --- |
-| [00](00-introduction.md) | Scope, conformance, versions and status |
-| [01](01-conventions.md) | Canonical JSON, numbers, hashes, normalization, offsets, times, IDs, keys and files |
-| [02](02-model.md) | Works, versions, witnesses and documents; `document.json` and `witnesses.json` |
-| [03](03-nodes.md) | Nodes, their kinds and children, content, attributes and inline runs |
-| [04](04-identity.md) | Minting IDs, permanence, retirement, aliases and record IDs |
-| [05](05-hashes.md) | The five content values, the projections, alignment, suspects and keyed hashes |
-| [06](06-anchors.md) | Addresses, anchors and the five resolutions, with drift |
-| [07](07-geometry.md) | Page fingerprints, stamp rules, pages and locations |
-| [08](08-fidelity.md) | Fidelity levels, receipts, the roster, revocations, spot-checks and error bounds |
-| [09](09-figures-tables-equations.md) | Figures, panels, tables, cells and equations |
-| [10](10-references.md) | References and citations |
-| [11](11-corrections.md) | Corrections and the gate |
-| [12](12-package.md) | The package |
-| [13](13-database.md) | The database form and the bundle |
-| [14](14-rights.md) | Rights records, policies, stages and backends |
-| [15](15-datasets.md) | Datasets |
-| [16](16-digitization.md) | Digitization records |
-| [17](17-views.md) | Views |
-| [18](18-layers.md) | Layers and annotations |
-| [19](19-exercises.md) | Exercises, submissions and grades |
-| [20](20-projects.md) | Projects |
-| [21](21-drafts.md) | Drafts: snapshots and sentence-ID sidecars |
-| [22](22-conformance.md) | Conformance, the suite and the rule catalog |
+| [0. Introduction](00-introduction.md) | Scope, conformance, versions and status, and how the repository is arranged |
+| [1. Shared conventions](01-conventions.md) | Canonical JSON, numbers, hashes, normalization, offsets, times, determinism, IDs, keys, files and prose |
+| [2. Works, versions, witnesses and documents](02-model.md) | The four objects; `document.json` and `witnesses.json` |
+| [3. Nodes](03-nodes.md) | Nodes, their kinds and children, content, attributes, inline runs and the plain projection |
+| [4. Identity](04-identity.md) | Minting IDs, permanence, retirement, aliases, `ids.jsonl`, store-qualified names and record IDs |
+| [5. Content values](05-hashes.md) | The five content values, the projections, alignment, suspects, keyed hashes and the metadata hash |
+| [6. Addresses and anchors](06-anchors.md) | Addresses, anchors and the five resolutions, with drift |
+| [7. Geometry](07-geometry.md) | Page fingerprints, stamp rules, `pages.jsonl` and `locations.jsonl` |
+| [8. Fidelity, receipts and spot-checks](08-fidelity.md) | Fidelity levels, receipts, signatures, Merkle roots, the roster, revocations, spot-checks and error bounds |
+| [9. Figures, tables and equations](09-figures-tables-equations.md) | Figures, panels, tables, cells and equations |
+| [10. References and citations](10-references.md) | Reference nodes, `references.jsonl` and its resolutions, and sentence-level citations |
+| [11. Corrections](11-corrections.md) | Corrections and the gate |
+| [12. The package](12-package.md) | The files of a package, paths, manifest, provenance, text policies and assets |
+| [13. The database form and the bundle](13-database.md) | The database form and the SQLite bundle |
+| [14. Rights](14-rights.md) | Rights records, policies, stages and backends |
+| [15. Datasets](15-datasets.md) | Frictionless Data Packages with units, uncertainty and origin; `anchors.jsonl`; content hash |
+| [16. Digitization records](16-digitization.md) | How values were read off a figure panel: target, axes, series, method, verification and confirmation |
+| [17. Views](17-views.md) | Vega-Lite specifications that pin their data, and optional computations |
+| [18. Layers and annotations](18-layers.md) | Layers and annotations |
+| [19. Exercises, submissions and grades](19-exercises.md) | Exercises, submissions and grades |
+| [20. Projects](20-projects.md) | Members and roles, documents, reading paths, held layers, datasets, views and drafts, and settings |
+| [21. Drafts](21-drafts.md) | Drafts: snapshots and sentence-ID sidecars |
+| [22. Conformance](22-conformance.md) | Conformance, the suite and the rule catalog |