The Principia Machina/Tutorial/7 Inspect, submit and declare

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)

Tutorial: create a new UWC. One small example - a mass on a linear spring, moving only along x - is taken from a blank file to a declared UWC in eight steps. Each step says what runs today and what is specified but not yet built. It explains; the specification governs. Field-by-field reference: Public Recorder inputs.

The checks in order, ending in a certificate or a decision item. (diagram page.)

Purpose

What happens between a passing draft and a declared UWC: the inspections, the submission, the final pass and the declaration.

Explains: TPS 0.1.0, revision 4 (declared final 2026-09-22); the zone schemas the declaring authority selected on 2026-09-22 (records D92.1, D98.1, D99.1, D100.1, and for units D103.1, D104.1, D105.1; schema 0.3.0), whose text enters TPS at revision 5, and the kernel tests and isomorphism checks selected the same day (D106.1, D107.1, D108.1; tpm_kernel_tests 0.2.0), whose text follows at the next TPS revision; TPC-PY as built 2026-09-22 (tpc_zone 0.3.0, tpc_units 0.1.0, tpc_tests 0.1.0; no TPC-PY version is declared yet) with check_draft 0.3.0. Where this page and the specification differ, the specification governs.

What exists today

Step 7.1 can be done today on paper; the checker has already done its machine part. Steps 7.2 to 7.4 are specified and not built: the form is part of TPX, and the DECLARATIONS page is created only at TPX's first landing, whose first declaration is the specification itself. The first UWC can be declared only after that.

Step 7.1: the inspections

The checker has already run what a machine can read: T1, T2's joins, T3 over the constraints, T5, IC1 to IC3, IC4's dimensions and what the entries bear, and CODOMAIN (step 5). What remains is what no machine reads yet, because laws, boundaries and signature images are prose. The declaring authority performs it by inspection before declaring, and each inspection is recorded as debt (TPS 2.2 and 2.3). On the spring draft:

Check	Question	On the example
T2, the meaning	Does each assumption state one claim, whatever its wording?	A_lin states one: the force is linear in x. The checker found no join.
T3 over laws and assumptions	Do the laws and assumptions, with the constraints, derive a contradiction within S_MAX steps?	No: N2 and KIN govern x and v; FREE_Z and C_NOZ are consistent (z stays 0). The checker compared the constraints: one FIX of z, nothing removed.
T4 dimensional homogeneity	Does every law balance?	N2: m dv/dt has M1 L1 T-2, and k_s x has M1 T-2 times L1, the same. KIN: both sides L1 T-1. FREE_Z: L1 T-2 against 0.
T6 boundary closure	Is every boundary decided for every value of its DOF?	B_small, the absolute value of x below x_max, is true or false for every x.
IC4, the signature	Is each signature relation carried to its image, and can each borne law be expressed in the environment?	the time derivative takes position to velocity as the signature says; N2, KIN and FREE_Z are statements about position, velocity and height.
IC5 falsifier invariance	Does any transformation change a falsifier?	a shift of the time origin changes none of them.
Equivalence	Are two differently named environment quantities in fact one?	no: position, velocity and height are three quantities.
REFS against prose	Does each statement use only the names its REFS list?	yes, for every law, the assumption and the boundary.

An optional machine-readable form for laws and boundaries has been chosen (record D108.1). When it is built, T4, T6 and part of T3 move from this table to the checker, for a draft that uses the form.

Step 7.2: submit

At the new-container form (Special:NewContainer, when built), choose the access policy, seed the access list if CLOSED, and enter the three zones in order. TPX runs the same checks you ran, as each zone is entered, and returns any refused component (TPS 5.5). Because the checks are the same, a draft that passed your check passes here too - unless it changed on the way in.

Step 7.3: the final pass

TPX runs the final pass - T3 over the constraints and the IC2 policy, as your check did - then computes D(TPK), D(TrM), D(TMS) and D(TFK), obtains the UUID, allocates the prefix and writes the candidate certificate to staging. Compare its four digests with the ones your check printed. If they differ, the draft TPX holds is not the file you checked: stop and find out why before anyone declares. Still no UUID is in use and no register exists.

Step 7.4: the declaration

The declaring authority lands the candidate certificate on the DECLARATIONS page with state CERTIFIED, the access policy, and you as H-OWN (TPS 5.6). That act is the birth of the UWC. TPX then:

• writes the TFK pages from the draft and verifies them against the certificate's digests;
• initializes the register: volume 1 OPEN, with the certificate as the master record;
• creates the control panel, the lock page, the collaboration page, the access-list page, the manifest, the library page and the badge;
• appends the first BUILD CHAIN line;
• protects the draft read-only and indexes it under the UWC as provenance.

Non-goals

Nobody types a digest, a UUID or a prefix at any point in this step. The declaration is the human's; everything computed is TPX's.

Worked example

The step is its own example.

Governing sections: TPS 5.5, 5.6, 2.2 and 2.3.

---

Previous: 6 Fix refusals. Next: 8 After the declaration.