Jump to content

Guide 8: Index, chain, badge and recovery

From The Invariance Itself
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 operator's guide. It assumes the walk through; a newcomer should read that first. Each page opens with its diagram, states its purpose and scope, gives the procedure, names what it does not cover, works one example, and links the sections of the specification that govern it. Where this guide and the specification differ, the specification governs.

Chain pages, manifest and badge on the left; lock, collaboration and control panel on the right. (diagram page.)

Purpose

Keep the index of record honest: manifests, the two chain pages, the badge, retirement, and the succession of one container by another.

Scope

What TPX rebuilds at every landing, what the declaring authority appends, how a reader tells a current copy from a stale one, how a container is retired or succeeded. Not covered: the hub's frame text, which is ordinary editing.

Procedure

  1. At every landing TPX rebuilds the manifest: every page with its content hash, then the badge last. If any assertion fails, nothing is written and a dated sentinel page is left behind; treat a sentinel as an incident.
  2. The DECLARATIONS page is append-only and human-only: the genesis line, certificates, container states, admissions, closeouts. The BUILD CHAIN page is append-only and machine-only: one line per build naming the declaration verified against. Both are chained by content digests rather than by revision IDs.
  3. A reader computes the copy's state from the badge before use: CURRENT, STALE or HOLDER SILENT, with the citation level the specification assigns to each.
  4. Retirement is a declaration; the container stays in the index, pages read-only, back-pointers resolving.
  5. A change to the kernel is a successor by copy-forward: new UUID, new prefix, each record copied PROVISIONAL (NOT GRADED kept), its INHERITS naming the record it came from and its STATUS starting UNMARKED, a record whose original was REFUTED or WITHDRAWN withdrawn at once by a WITHDRAWAL record of cause INHERITED so that it stays so; the same checks; the first audit under the re-audit scope rule, and, when D(TPK) and D(TrM) are unchanged, the established results re-promoted in one PROMOTION record (TPS 3.4.1, 3.4.6, 4.1.9).
  6. The published calculator's source pages are their own index class: name, version, digest, and the specification version they conform to. They sit outside the instruction-set digest, they are non-normative, and each version enters by a declaration.

Checklist

  • No sentinel page left unexplained.
  • Every build chain line names a declaration line.
  • Retired containers protected read-only and still indexed.

Non-goals

The chain is a simple hash chain; verification from the genesis line is linear and is not a goal to accelerate (TPS 7.1).

Worked example

A reader opens a container's manifest and finds a holder within expiry and page hashes that do not match. The state is STALE. The reader does not cite it, except inside an audit block at level VERIFY, and waits; after the holder's push and release the hashes match, the badge shows no holder, and the copy is CURRENT again.

Governing sections: TPS 5.6, TPS 5.10, TPS 5.11, TPS 3.4.


Previous: Certifying agents. Next: Publishing a specification version.