The Principia Machina/Foundations record 0.5.0: Difference between revisions
TPM bootstrap: tpm_foundations_record 0.5.0 verbatim (documentation) |
m 1 revision imported: TPM bootstrap under PMP-TPM 0.2.0 |
(No difference)
| |
Revision as of 06:22, 16 September 2026
Documentation. Part of the TPM hub. Describes PMP-TPM 0.2.0. Version 0.5.0 (proposed by the branch; declaration by the human pending). STATUS: DATA, not an instruction artifact. The text below is the record verbatim.
File digest SHA-256: 4fec9552319dca3128f4dd0646c2540eae1bffd5597a1cb3fd3373fe5f495ce6 (VERIFIED against the delivered file's recorded digest). This digest is a file fingerprint for provenance only; it is not a TPM digest. TPM digests are computed by TPX alone (D9).
TPM FOUNDATIONS RECORD
======================
NAME: tpm_foundations_record
VERSION: 0.5.0
DATE: 2026-09-13
BASELINE: PMP 5.0.1 at the origin. Round 2 executed under PMP 6.0.0 on
the round-2 charter's EXTERNAL path. Rounds 3 and 4 executed
under PMP 7.0.1, the round-2 charter's obligations carried in
place; no round-3 or round-4 charter was issued. No project
meta prompt in force through round 3. PMP-TPM 0.1.0 declared
INSTALLED by the user in round 4 on 2026-09-13 and in force
from that turn (PMP 7.0.1 FRONT-END CONTRACT, IN-FORCE ACT).
STATUS: DATA. A descriptive record of the decisions and requirements
settled in the TPM foundations thread. Not an instruction
artifact. Carries no obligations, writes no register, fires no
cue. PMP-TPM is authored from it; it does not replace PMP-TPM.
SOURCE: User declarations and decision selections in the origin thread
on 2026-09-12, in round 2 (charter tpm_foundations_round_2)
on 2026-09-13, and in rounds 3 and 4 (threads "Principia
Machina Round 3" and "Principia Machina Round 4") on
2026-09-13; the Generic Specification Guide 0.1.0-draft (a
digest of bfp_process_spec_charter 0.1.0-draft), called "the
guide" below, which was in the working set of no round;
two research rounds in round 2 and one in round 4, sourced in
section 12; PMP-TPM 0.1.0 as received in the round-4 first
prompt.
READING: Every line states what was declared, selected, or follows from
a standing rule, and says which. Nothing here is a
recommendation. Section 8 carries what is still open.
CONTENTS
1 NAMES
2 PROJECT CONSTANTS
3 DECISIONS D1-D33
4 RECORDED REQUIREMENTS
5 DETERMINED BY STANDING RULE
6 STATED LIMITS AND NON-GOALS
7 OBLIGATIONS ROUTED TO PIECES
8 TBD REGISTER
9 TRANSFERRED ITEMS
10 OPEN QUESTIONS AWAITING ANSWER
11 CHANGE RECORD
12 SOURCES
1 NAMES
--------
TPM The Principia Machina. The framework and the project.
PMP-TPM The project meta prompt for TPM. Authored at 0.1.0 on
2026-09-13 by pmp-initializer 1.0.1 in the PMP Sandbox
project from pmp_tpm_answers_0_1_0.yaml (489 lines,
SHA-256 4b512c3bfbd97aa7d520d3d369462be113552b02f20720401e
bfc1337f0d450d), itself derived from this record at 0.3.0;
REQUIRES PMP >=7.0.0 <8.0.0. Declared INSTALLED by the
user in round 4 on 2026-09-13 (D24, section 9). Registers
no cue at 0.1.0.
TPK The Prime Kernel, layer 1: laws, assumptions, hard
boundaries, CONSTRAINT entries. The first zone of the TFK.
The guide's L0 KERNEL. Replaces The Prime Matrix (MTX) by
D17. MTX and PMX are retired and are not reused for
anything. Bare "kernel" is not used in this record; the
guide's own terms (L0 KERNEL, kernel tests T1-T6) are
quoted as the guide names them.
TrM The Translation Manifold, layer 2. Its identification
fields are the second zone of the TFK.
TMS The Measure Set, the third zone of the TFK: the strike
skeleton's declared parameters, the regime and
contradiction tests, and any local yardsticks (D15, D16).
Replaces MEASURE SET by D17. "Yardstick" is the user's
informal term for a TMS entry.
TFK The Full Kernel: the TPK in full, the TrM identification
fields, and the TMS in full. Immutable per container; the
container binds to D(TFK) (D15.S6.1, D17). Replaces the
phrase "immutable unit".
RR The Research Register, layer 3. Two-letter form kept by
exception to any three-letter rule. Bare RR names the
layer only.
<prefix>-n A register record. The prefix is declared per container
(D1). In BFP-next's first container the prefix is RR.
VOLUME A fixed-size container of records inside the register
(guide L2). States OPEN and FROZEN are inherited vocabulary
and are kept (D7).
CAC Congruence and completeness audit. The audit the
Congruence Protocol runs on a container. Replaces an
earlier acronym that is not reused.
CONTAINER The unit a UUID names: one TFK and the register built on
it. The user's informal terms "research project" and
"UUID workspace" mean this.
IMMUTABLE The adjective for the TFK and its fields: "the TFK is
immutable"; "immutable field" (a hashed field). Never
bare. STATIC and FIXED were evaluated and rejected; FROZEN
was excluded by declaration for this use (D7).
DOMAIN The regime of validity. Required on every TrM entry and
every promoting record (D3).
ENVIRONMENT What the TrM maps a TPK into (D3).
MASTER The register's representation of the TFK, with two named
RECORD departures from an ordinary record (section 4.4).
D(TPK), D(TrM), D(TMS), D(TFK)
Content digests of the three zones, and of the TFK over
the three in fixed order (D6, D15.S6.1, D17). The container
binds to D(TFK).
D(IS) The INSTRUCTION SET DIGEST: TPX's digest over the
current versions of every page in the index's
instruction-artifact class, in fixed order (D23, 4.8 CR9;
computation site fixed by D32). A certified agent
presents the D(IS) it was instantiated with; a match
warrants version currency only.
REGIME L or M, assigned to every record at allocation (D16 SR3).
STRIKE A withdrawal record in the 4.6 shape, issued under the
strike rule SR1-SR9 (D16).
DECLARATIONS PAGE, BUILD CHAIN PAGE
The two chain pages (D21): human-only declarations, and
agent-appended build lines that name the declaration they
verified against.
MECHANICAL, INSPECTION
The two check classes (D20): TPX executes and acts on the
check; an agent or human reads and judges. Amended by D32:
the executing party is TPX, not an external script.
CURRENT, STALE, HOLDER SILENT
The three states of a container's wiki copy (D19).
DRAFT CONTAINER
The page class holding a TFK under construction before a
container exists (D26): one draft per initiator, writable
by its creator, outside the index until instantiation,
then protected read-only and indexed under the container
as provenance.
WORK BLOCK D13's unit only: a commissioned set of obligations with
F/E cycles whose target is the register. Not used for a
UI service call (user correction, round 4).
Congruence Protocol
Layer 4. No acronym settled. Its MECHANICAL checks execute
in TPX; the Congruence Protocol piece specifies them (D32).
Public Recorder
Layer 5. No acronym for the layer. Defined by D33 as three
parts:
PLATFORM Native MediaWiki: page display, history, protection,
upload, the Action API. No acronym.
TPX The TPM UI extension: a PHP MediaWiki extension holding
every deterministic responsibility MediaWiki can host -
forms, save hooks, API modules, the CAC's MECHANICAL
checks, digests, UUID, instantiation, fencing, manifest,
badge, D(IS), canary planting (D29, D32).
PRB The Public Recorder Backend: the agent-side client that
manages the local AI workspace and drives TPX through its
API (D32, D33).
2 PROJECT CONSTANTS
--------------------
2.1 FRONT END. The framework machinery is the front end. Physics
content produced by the machinery is back end. Declared by the
user. Graduation of TPM from product-under-test to reliable
product is a MAJOR version of PMP-TPM carrying an explicit
membership rewrite; membership does not flip silently.
2.2 RANKING RULE for front-end (DERIVATIONAL) items. Lexicographic,
lower is better on each axis. Declared by the user on 2026-09-12
after research against ISO/IEC 25010:2023, THERP, Bainbridge 1983
and Skitka et al.
R1 CORRECTNESS. Two counts. Soundness defects: a construction
the check accepts that it should reject; any soundness
defect above zero EXCLUDES the option. Completeness
defects: a case the check omits, named; these rank and do
not exclude. A rule still to be written is an obligation,
not a completeness defect (application correction recorded
the same day).
R2 ERROR OPPORTUNITY. Count of unforced human authoring
operations per unit of work. Verification gates at
irreversible actions are exempt from the count if and only
if the gate poses a specific check question the mechanism
does not already answer.
R3 COST. Tokens, time, compute. Tiebreak only.
Tie on all three: report the tie in one word; the human selects.
EXCLUSION: the declaring-authority separation (a named human
declares TFK amendments, container state, and closeout) is
untouchable regardless of its R2 cost.
SCOPE (D4, amended by D15): this rule ranks machinery only.
Physics results are ranked by each TPK's TMS, which lives in the
TFK beside the TPK, within the generic strike skeleton (D16).
FORM: landed. The FRONT-END DECLARATION section of PMP-TPM 0.1.0
carries the content above (membership, ranking rule, exclusion)
in the form fixed by PMP 7.0.1 FRONT-END CONTRACT and emitted by
pmp-initializer 1.0.1 (section 9). In force from the INSTALLED
act of 2026-09-13.
2.3 GOVERNANCE. The Congruence Protocol is subordinate to the PMP
decision protocol (MRG). An unresolvable strike or audit outcome
is a decision item and halts the round.
2.4 SYSTEM OF RECORD. The MediaWiki site is the system of record and
the version control for every aspect of TPM and TPM-based
research. Edit rights are limited, not open (D21). After D10,
D14 and D19, the wiki holds authoritative history; current state
of a collaborative container lives with the mutex holder for up
to 24 hours, and the wiki copy's state is read from the badge
(section 6).
2.5 CONTAINERS ARE SEALED. A container is isolated with its TFK and
its full register. Cross-container reduction (one model as the
limiting case of another) is out of scope by design (section 6).
2.6 REQUIREMENTS SOURCE. The guide is treated as the draft of major
requirements for TPM and the TPK. Its layer map onto TPM: L0
KERNEL = TPK; L1 CORRESPONDENCE = TrM; L2 REGISTER = RR; L3
PROCESS plus kernel tests T1-T6 plus the four isomorphism checks
= Congruence Protocol; H = PMP-TPM. Layer 5, the Public Recorder,
has no source in the guide and is authored fresh. The guide was
reachable in no round through round 4; TBD 19 stands.
2.7 SEQUENCING. PMP-TPM is authored first, then the TPM thread is
branched with PMP-TPM active, then the user brings piece-level
details, and only then is any piece drafted. No piece is drafted
before an explicit, unambiguous signal from the user. Status at
0.4.0: the first step is complete (PMP-TPM 0.1.0 INSTALLED
2026-09-13); the branch with PMP-TPM active is the next step; no
piece has been drafted and no signal has been given.
2.8 BFP RELATION. TPM is maintained independently so it can be tested
for veracity and effectiveness apart from BFP. The next
generation of BFP is written to be hosted as one container.
3 DECISIONS D1-D33
-------------------
All items DERIVATIONAL, ranked on 2.2. Landing site: PMP-TPM. D1-D14
were selected on 2026-09-12; D15-D23 on 2026-09-13. Amendments made in
round 2 are marked on the item they amend.
D1 RECORD IDENTIFIER AND LAYER NAME resolved D1.1
Per-container identifier space. Each container's manifest declares
one record prefix, unique across TPM, checked at CAC. BFP-next's
first container declares RR, so RR-1..RR-855 import unchanged.
Bare RR names the layer; <prefix>-n names a record; the container
of records is VOLUME. One HIGH-WATER MARK per container. A
cross-container citation carries the prefix by construction.
Consequence: every successor container under D5 declares a new
prefix; the CAC prefix registry is the allocation authority for
prefixes.
D2 MAP TYPE IN THE TRANSLATION MANIFOLD resolved D2.1
Isomorphism only. Every TrM entry satisfies TOTAL, SURJECTIVE,
INJECTIVE, STRUCTURE-PRESERVING unchanged. A restriction (tabletop,
uniform field, no rotation) is declared as CONSTRAINT entries in
the TPK, so the TPK yields the restricted DOF inventory and the
TrM is an isomorphism onto it. Restrictions are therefore covered
by the kernel test suite T1-T6. No promotion ceiling; the
restriction is priced in the TPK, not the entry.
Consequence: each restricted configuration is its own TPK and its
own container. A RESTRICTION object relating two containers was
not offered, being excluded by 2.5.
Amended by TBD 2 (section 8): SURJECTIVE is the completeness test.
D3 THE WORD "DOMAIN" resolved D3.1
DOMAIN keeps the guide's meaning: regime of validity, required on
every TrM entry and every promoting record. The target side is
ENVIRONMENT. Basis: both BFP historical errors were domain
elisions at promotion (guide C5), so the field and its anchor to
that failure history are kept.
D4 TWO RANKING RULES settled by 2.2; amended D15
PMP-TPM ranks machinery. Each TPK's TMS ranks physics within the
generic strike skeleton (D15, D16). The TMS lives in the TFK
beside the TPK (D15.S6.1).
D5 TPK IMMUTABILITY WITH COPY-FORWARD resolved D5.2 + reopen
Fixed by user constraint: the TPK is immutable. Any change
instantiates a new TPK, a new container, a new UUID, a new prefix.
The predecessor is frozen with a forward pointer. The
predecessor's workspace is copied into the successor.
(f) Inherited records enter as PROVISIONAL regardless of
predecessor tag, except REFUTED, which stays REFUTED. Promotion
requires re-derivation under the new TPK. The predecessor tag
is recorded in the back-pointer only.
(g) The digest gate runs before every write to the container and
at every CAC run. A mismatch halts the write.
(h) Each inherited record is a fresh allocation in the successor's
prefix; its FINDING names the predecessor's full identifier.
Excluded with basis: copy with tags intact and citable at once
(soundness); inherited records keeping predecessor identifiers
(soundness; one identifier, two records; collides with D1);
digest verified at CAC only (soundness; writes accepted against a
modified TPK between audits).
Amended by D15.S6.1 and D17: "any change" covers all three zones
of the TFK; a change to any immutable field moves D(TFK).
D6 TFK SCOPE AND DIGEST STRUCTURE resolved D6.1; amended D15
Immutable, the three zones of the TFK: the TPK in full; for each
TrM entry the identification fields only: DOF, DOMAIN, the
identification itself, FALSIFIER, BEARS; and the TMS in full
(D15.S6.1). Mutable, carried by register records that name the
entry: STATE, SCRUTINY, RIDER, NOTE, CHECKS OWED, RECORDS. The
entry form inside the TFK carries no status.
Digests: D(TPK), D(TrM), D(TMS), and D(TFK) computed over the three
in fixed order; all four in the build chain line and in the CAC
certificate; the container binds to D(TFK). A change to any
immutable field moves D(TFK) and instantiates a new container per
D5. Containers sharing a TPK are recognizable by a shared D(TPK);
a successor with D(TPK) and D(TrM) unchanged and D(TMS) moved is a
yardstick-only successor, which the re-audit scope rule (section
7) may narrow on. The gate reports which of the three zones
mismatched.
D7 THE TERM FOR THE IMMUTABLE FOUNDATION resolved D7.1; amended D17
IMMUTABLE, as the adjective for the TFK and its fields: "the TFK
is immutable", "immutable field". Scope: the foundation only;
register volumes keep OPEN and FROZEN. STATIC rejected (collides
with statics). FIXED rejected (collides with "held fixed" in every
phase F statement, with "fixed field" in physics content, and
with ordinary use across the artifacts). The compound "immutable
unit", selected in round 1 as the name of the foundation, is
retired by D17 in favor of TFK; "immutable field" stands.
D8 ESCALATION REACHABILITY resolved D8.2 + user constraint
The index names wiki pages. The working session operates on a
LOCAL WORKING INSTANCE of the container: a hashed archive on an
attached system drive, with a local inventory of pending archives
to be extracted and imported to the wiki when it is available. The
halt clause of the original Option 2 is superseded: a session
works locally and pushes when the wiki is reachable.
Page identity (applied without pause): an index entry names a page
by title plus content hash. MediaWiki computes a SHA-1 per
revision, exposed by the API and in dumps, which the manifest may
carry; the chain's own link hash is SHA-256.
D9 MANIFEST CONSTRUCTION resolved D9.1; amended D32
MECHANICAL. One build script reads container pages through the
API, computes digests, asserts (every page present, no hash
collision, prefix unique, D(TFK) equals the certificate), writes
the manifest and appends the build chain line under an agent
account. Any failed assertion writes nothing and leaves a dated
sentinel page. The script is the sole implementation of every
digest.
Excluded with basis: a hand-transcribed digest is not a digest.
Amended by D21: the line the script appends goes to the BUILD
CHAIN page and names the DECLARATIONS page line it verified
against; the script also computes the candidate certificate that
the human lands (4.4).
Amended by D32: the build script's role passes to TPX, the PHP
extension, which is the sole implementation of every digest and
rebuilds the manifest at the end of every landing; the sentinel
rule stands. An external script builds no manifest.
D10 REFRESH TRIGGER resolved D10.1 + .2; amended D19, D32
Local manifest rebuilt on every write to the local instance. Wiki
push once a day by script. The wiki manifest carries the badge of
D19 - holder, grant, expiry, last push, last release, chain line,
manifest revision - written last by the push script as the commit
marker; a reader computes the copy's state from it (section 6).
Amended by D32: the local manifest rule stands for the agent's
working copy (D8). The daily push is withdrawn; PRB lands records
on demand through TPX's API, and TPX rebuilds the wiki manifest
and writes the badge last at the end of every landing. No
external push script remains.
D11 INDEX SCOPE resolved D11.1 + user addition
One index, all classes: TFK pages, register volumes, spine, CAC
certificates, the two chain pages, instruction artifacts with
version, REQUIRES range and STATUS (the class over which D(IS) is
computed, D23), and documentation pages with the version they
describe. Documentation is an escalation target
for its own class only. Addition: a LIBRARY PAGE for every
container, reachable from a CENTRAL HUB. The hub carries one named
entry point per audience (4.1).
D12 RETIRED CONTAINERS resolved D12.1
A retired container stays in the index in state RETIRED, pages
protected read-only, the retirement declared on the DECLARATIONS
page, back-pointers resolve directly. The index grows
monotonically.
D13 LANDING resolved D13.2, reopened twice, D13.1 x2; amended D18
Staging lives on the session side: the local inventory of D8.
At each landing a work order is closed out and the register
updated. Each container keeps a WORK-BLOCK LOG (process used,
implications, comprehensive results as a general-audience summary)
and, on its control panel on the wiki, a SCHEDULE LOG of
commissioned work with states COMMISSIONED, OWNED BY <wiki
account>, LANDED, ETA, EXPIRED. ETA is one to two days; a block
expires at its ETA and must be recommissioned.
(f) An unfinished block persists in the local instance as a draft
carrying a block ID, rewritten at each turn boundary; the
session's context holds a working copy only.
(g) A block is EXPIRED when server time passes its ETA. The
control panel mark is display only and does not wait for a
push (D18; supersedes the round-1 wording that expiry was
marked at the next push). Partial results stay in the local
instance tagged UNCOMPUTED with kind of block. Recommission
issues a new block ID with a back-pointer.
(h) Landing rejects any result carrying an expired block ID; the
block ID is the fencing token.
(i) A refused block whose result matches the landed one lands as a
CORROBORATION RECORD naming the record it reproduces, carrying
the reproducing agent's account, inheriting the landed tag,
and stating the reported difference; the block closes as
CORROBORATED.
Post-refusal procedure: section 4.3. Form of the collaboration
page: D18.
D14 WORKSPACE MUTEX resolved D14.1; amended D18, D19, D32
One lock page per container on the wiki. Acquire by an edit
carrying the base revision ID that writes holder account, grant
number (previous plus one), grant time, and expiry, all in server
time; a failed edit means another holder. Every push carries the
grant number; the push script reads the lock page and refuses a
push whose number is below the current grant or whose holder is
not the pusher. Heartbeat edit every few hours extends expiry,
never past 24 hours from grant. Handover: an ordered petition
queue on the collaboration page, ordered by the wiki's revision
order of the petition edits; on release the head of the queue
acquires; the others wait on the one ahead; if the head has not
acquired within the ACQUISITION WINDOW, the next waiter may (D18).
Coworkers receive a leased identifier range per assignment. One
lock per container, none nested. A release is valid only after a
final push, in that order (D19).
Excluded with basis: lock plus timeout without fencing; a stalled
lead's late push overwrites a successor's work (soundness).
Amended by D32: the lock page stays a wiki page acquired by
base-revision edit, so acquisition and its history rest on the
platform's own conflict detection and page history; a TPX save
hook refuses an acquisition out of queue order or before expiry;
the fencing check moves from the push script to TPX's landing
API, which refuses a push whose grant number is below the current
grant or whose holder is not the pusher. A client-side check is
no longer a check anywhere in TPM.
D15 STRIKE CRITERIA: SITE AND STRUCTURE
resolved D15.1 + A1-A3; S6 by S6.1
TBD 5 reopened on the user's constraint of 2026-09-13 that the
strike rule be generic across TPM, mathematically precise,
grounded in Popper, and researched against the literature.
Selected: the strike rule's structure lives in PMP-TPM as
framework machinery - the SKELETON:
(i) the TFK is inviolable; a record contradicting it is struck
without ranking;
(ii) a record stands while internally consistent and
uncontradicted;
(iii) conflicting records are ordered by distance to the TFK;
(iv) a more distant record prevails only past an
extraordinary-case threshold;
(v) a regime split between logical/mathematical results and
measured results with stated uncertainty.
Every TMS instantiates the skeleton's parameters and may not relax
(i) or (ii). D4 amended. Mechanical implementation routed to the
CAC piece. The content of (iii), (iv), (v) is fixed by D16.
A1 A TMS MAY carry additional entries for precision or limiting
cases.
A2 Every TMS entry passes the compliance test SR9 at CAC
certification, before the container's first round of
research. Coupled to TBD 1: if pre-certification research
writes are ever admitted, the test precedes them.
A3 TMS entries are immutable per container.
S6.1 Placement: the TMS is a third immutable zone beside the TPK
and the TrM identification fields, with its own digest; the
container binds to D(TFK) over the three (D6 amended). Basis:
a yardstick-only successor stays distinguishable from a
physics-changed one; placing the TMS inside the TPK would
have omitted that case (completeness).
Excluded with basis: an overridable default TMS template (a
container could relax (i); soundness); closing TBD 5 on the
round-1 proposal alone (foreclosed by the generic constraint).
D16 STRIKE RULE CONTENT: REGIME, DISTANCE, THRESHOLD, COMPLIANCE
resolved D16.1
Fixed after a research round (section 12, group H). The rule, for
PMP-TPM's skeleton and for the CAC piece's implementation:
STRIKE RULE
SR1 INVIOLABILITY. A record whose FINDING, taken with the TFK,
derives a contradiction is struck at CAC without ranking.
SR2 STANDING. A record stands while its derivation from the TFK
plus its declared ASSUMPTIONS is valid and no standing record
contradicts it.
SR3 REGIME. Each record is assigned one regime at allocation. L:
the FINDING is verifiable by re-derivation from the TFK plus
ASSUMPTIONS with no empirical input. M: the FINDING carries a
value with a combined standard uncertainty u_c per GUM. A
record comparing an L result with an external value is M, of
the verification class. Contradiction tests: L-L, the
conjunction with the TFK derives a contradiction. M-M,
|x1 - x2| > k (u1^2 + u2^2)^(1/2) after SR8 scaling. L-M, the
M value fails the M-M test against the L record's derived
value. k is a TMS parameter; CAC refuses certification of a
TMS that does not declare it.
SR4 DISTANCE. d(r) = (a(r), s(r)), lexicographic, lower is closer.
a(r): the number of distinct ASSUMPTIONS in the closure of r -
its own plus those of every record it cites, transitively -
excluding the TFK. s(r): the number of derivation steps in r's
own derivation under the container's declared STEP
CONVENTION, a TMS parameter.
SR5 ORDERING. Of two contradicting standing records, the one with
smaller d stands; the other is struck, and its ASSUMPTIONS
outside the closer record's closure are recorded as the locus.
Equal d opens an audit block.
SR6 EXTRAORDINARY CASE. Contradictions of a standing record r are
independent when their extra-assumption sets - ASSUMPTIONS
outside r's closure - are pairwise disjoint. When the number
of independent contradictions n_ind(r) reaches N_x, an audit
block opens on r; its decision item may strike r, restrict the
container's DOMAIN, or find against the contradicting records.
N_x is a TMS parameter, at least 2. Reaching N_x never strikes
r by itself.
SR7 GOLD STANDARD. An M contradiction never strikes an L record's
derivation. If a(r) > 0 it is recorded against r's ASSUMPTIONS
as a named gap. If a(r) = 0 it is a finding against the TFK's
DOMAIN and lands as a DOMAIN restriction or a successor
container under D5, declared by a human.
SR8 UNCERTAINTY DISCIPLINE. Every M record states u_c with its
Type B components enumerated. When N >= 2 standing M records
of one quantity give chi^2/(N-1) > 1, the scale factor
S = [chi^2/(N-1)]^(1/2) is applied to each before any
contradiction test, S computed over records with
delta_i < 3 N^(1/2) delta_mean. A contradiction that does not
survive S is not a contradiction.
SR9 COMPLIANCE. Every TMS entry passes at CAC certification:
C1 it never ranks a record failing SR1 above one passing it;
C2 within a regime, adding an ASSUMPTION never improves rank,
except in a declared limiting case naming its DOMAIN,
applied only there;
C3 it is a total computable function of record fields;
C4 it does not let an M contradiction strike an L derivation;
C5 every constant it uses is a named immutable field.
C1, C2, C4 are MECHANICAL on a synthetic record suite when the
entry is executable, INSPECTION otherwise; C3, C5 are
INSPECTION.
Basis, by source (section 12 group H): SR1-SR2 Popper LScD sect. 3,
6. SR3 GUM; the veracity line of section 5. SR4 parameter counting
(Popper sect. 38, 43; Akaike; Schwarz; Forster and Sober); depth
admitted only under a declared convention (Cook and Reckhow);
Kolmogorov complexity excluded as uncomputable (Li and Vitanyi).
SR5 Duhem-Quine underdetermination resolved by distance; an
assumption added to rescue a record raises a(r), which is Popper
sect. 20 mechanized. SR6 Popper sect. 22 reproducibility; N_x >= 2
is the minimum that makes one stray contradiction insufficient;
Laplace-Hume proportionality enters through a container raising
N_x. SR7 the user's declaration that mathematics and logic are
the gold standard; D5 restore-or-fork. SR8 PDG and CODATA practice
against the record of underestimated uncertainties (Henrion and
Fischhoff; Youden; Feynman); Lyons is why k is declared per
container, not fixed.
Structural result recorded: distance and contradiction count are
incommensurable, and every established parsimony measure is a
count or a code length, ordered, never a weighted blend; with
lexicographic distance and independence-counted contradictions no
scalar weight is needed. The golden ratio, proposed by the user as
a candidate weight, was found to have no principled basis in the
literature (REFUTED, section 12 S47) and survives only as a
declarable convention.
Named completeness defect, carried: a(r) is gameable by bundling
assumptions; atomicity of declared ASSUMPTIONS is an INSPECTION
check at CAC (D20 row 23).
Excluded with basis: derivation depth as the primary measure
(would strike an assumption-free 50-step derivation for a 2-step
derivation carrying three assumptions; soundness); automatic
reversal on reaching N_x in the L regime (a majority of
derivations cannot overturn a valid one; soundness); Kolmogorov
or MDL distance now (uncomputable, or requires a formal language
the container has not declared; MDL admissible later as a local
yardstick under A1); a scalar weight of distance against count,
golden ratio included (no principled basis).
Record fields the rule needs (RR piece, section 7): ASSUMPTIONS,
REGIME, DERIVATION, and for M records VALUE with u_c and its Type
B list; the named-gap record form.
D17 NAMES FOR THE THREE ZONES AND THE FULL KERNEL
resolved D17.1 augmented + S1b.1
Raised in round 2 by the user; three slots each: term, scope,
relation to standing terms.
TPK The Prime Kernel replaces The Prime Matrix (MTX) as the
layer-1 name, a full replacement; MTX retires as PMX did.
Digest D(MTX) becomes D(TPK). Bare "kernel" is not used; the
user's candidate descriptor "the Conceptual Kernel" was not
selected (would give "conceptual" a second meaning beside
the conceptual-diagram class; the TPK is the formal object).
TMS The Measure Set replaces MEASURE SET; same object, same
scope; acronym in text per the section 1 pattern. Digest
D(MS) becomes D(TMS).
TFK The Full Kernel = TPK + TrM identification fields + TMS,
replacing the phrase "immutable unit" (D7 amended); IMMUTABLE
stays as the adjective. The binding digest, D(pair) in
round 1 and D(unit) at D15.S6.1, becomes D(TFK).
Withdrawn by the user during the item: "The Formalism Kernel",
"The Verification Tensor" (collides with a physics term of art for
an object the TMS is not; D7 precedent), "Result Grading Unit"
(would have implied ownership of the GRADE field), "The
Conceptual Kernel".
Consequence recorded: other artifacts carrying MTX keep it until
their own next revision; section 1's retirement line reconciles a
reader.
D18 COLLABORATION PAGE FORM resolved D18.1
TBD 18. Declared by the user before the item: a coworker petitions
for any work block; every petition carries a capability statement;
returns land on an agent-writable staging subpage; silence past
ETA expires the block (no petitioner heartbeat).
COLLABORATION PAGE (per container; agent-writable)
PETITION one row per petitioner, appended by its own edit
ACCOUNT wiki account (attribution carrier)
CAPABILITY execution class it can perform: MECHANICAL,
INSPECTION; tools and model, free text; CERTIFIED
with suite version, snapshot ID and date (D22); the
D(IS) the agent was instantiated with (D23)
STATUS WAITING | ASSIGNED | WITHDRAWN (by its own edit) |
NEEDS RECERTIFICATION (set by TPX's landing API on
a D(IS) mismatch, D23, D32)
Queue order is the revision order of the PETITION edits.
ASSIGNMENT one row per block, written by the lead
BLOCK ID from the schedule log (D13); the fencing token
ASSIGNEE account
GRANT the lead's grant number at assignment
WORKLOAD pointer to the block's schedule-log entry, which
holds the prompt, ETA and state; no copy here
LEASED RANGE identifiers leased for this block, or NONE
(section 5)
RETURN PAGE the staging subpage
RETURN on the staging subpage, pointed to by the assignment
BLOCK ID must match an ASSIGNMENT not EXPIRED
ACCOUNT
RECORDS with leased identifiers if a range was leased, else
without identifiers; each carrying the coworker's
tag
USED RANGE identifiers consumed; the rest reclaimed on landing
DIFFERENCE for a reproduction block, the reported difference
(D13(i))
A RETURN is untrusted input; the lead vets it under IV before
incorporation.
EXPIRY a block is EXPIRED when server time passes its ETA. The
control panel mark is display; expiry does not wait
for it.
ACQUISITION WINDOW on release the queue head acquires; if it has
not acquired within the window, the next waiter may.
The window is a PMP-TPM parameter, declared, not less
than twice the agents' polling interval. Declared by
the user 2026-09-13: 5 minutes, server time; so the
agents' polling interval is at most 2.5 minutes
(PMP-TPM 0.1.0 DECLARED PARAMETERS).
Basis: silence-expiry lands nothing wrong (a late result is
refused by block ID and recovers through 4.3) and a heartbeat adds
no safety, only a channel that can mislead (S17, S18). Defect
found and fixed: D13(g) as first written made expiry an act of the
holder's push, so a block outliving its lead's lock was never
expired; expiry is now definitional. Defect found and fixed in
D14: a dead queue head blocked the queue forever; the acquisition
window bounds it.
Excluded with basis: petitioner heartbeat (no safety gain);
WORKLOAD and ETA copied into the assignment row (two copies of
ETA; completeness); expiry by marking only (soundness).
D19 STALENESS RULE resolved D19.1; amended D23, D32
TBD 17. Declared by the user before the item: only an audit block
may use a stale wiki copy, and only to disposition.
BADGE on the wiki manifest; written LAST by TPX at the end
of every landing (D32; was the push script); is the
commit marker (TBD 7)
HOLDER GRANT EXPIRY LAST PUSH LAST RELEASE CHAIN LINE
MANIFEST REVISION D(IS) (D23) all times server time
RELEASE valid only after a push; LAST PUSH >= LAST RELEASE
always holds for a valid release. Enforced by TPX's
landing API and lock hook (D32).
STATES computed by the reader from the badge and server time
CURRENT no HOLDER, LAST PUSH >= LAST RELEASE, page hashes
match the manifest. Any reader; citations
VERIFIED.
STALE HOLDER set, now <= EXPIRY; or page hashes
mismatch the manifest (push in progress). No use
except an audit block, for disposition; auditor
citations VERIFY.
HOLDER SILENT HOLDER set, now > EXPIRY, no release. No use
except an audit block; auditor citations
VERIFY-HIGH, cause "holder silent past expiry".
The queue head may acquire (D14). A late push
from the silent holder is refused by fencing; its
blocks enter 4.3.
Basis: staleness attaches only while a lock is held, since it
arises from a local instance running ahead of the wiki (D8, D10);
"always stale" would leave no realizable CURRENT state
(completeness; 2.4 unrealized). The release-after-push rule
closes the case of a holder leaving unpushed work. MediaWiki
gives no multi-page atomic write, so a reader mid-push sees a
mixed set; the badge written last with the chain line and
manifest revision lets a reader detect a torn read (soundness).
The three states map onto PMP's three flag levels exactly. Push
transport (per-page edits or XML import) is routed to the Public
Recorder piece with one constraint: whatever the transport, the
badge is written last, after every page of the push is on the
wiki; import does not give atomicity.
Amended by D32: the push transport is TPX's landing API called by
PRB; per-page edits and XML import from an external script are
withdrawn; the badge-last rule stands because the platform has
no cross-page transaction (section 12, group J).
Excluded with basis: minimal badge of holder and last push (a
mid-push read is accepted as current; soundness); HOLDER SILENT
folded into STALE (the badge cannot express that waiting is
unbounded or that acquisition is open; completeness).
D20 CHECK-CLASS MATRIX resolved D20.1; amended D32
TBD 8. Two classes, as section 5 already used them: MECHANICAL (a
script executes the check and acts on its failure) and INSPECTION
(an agent or human reads and judges). An enforcement column
carries where the check is made to hold; the class is shown with
the script present and without it, and the difference is ratchet
debt (section 5, S20). A third class for platform-enforced checks
was not selected: the enforcement column carries the distinction
and the vocabulary of D18, SR9 and section 5 stays intact.
Enforced by: PL protection level; GR group right; EC edit
conflict; SC script; AU audit; PR prompt-level rule.
Row form: check; when | enforced by | class with / without the
script | on failure | source. "same" means no ratchet debt.
Amended by D32: SC now means TPX, the PHP extension, executing
server-side in the request or in a job; no row is enforced by an
external script. "With / without the script" reads "with /
without TPX". Every SC row is a TPX obligation (section 7).
1 D(TFK) recomputed and matched before any container write.
on write | SC | MECH / INSP | halt write; name zone | D5(g), D6
2 D(TFK) equals the certificate.
at CAC | SC | MECH / INSP | refuse certification | D6, D9
3 Every page present; no hash collision; prefix unique.
at build | SC | MECH / INSP | write nothing; sentinel | D9, D1
4 Page hashes match the manifest (torn read).
at read | SC | MECH / INSP | treat as STALE | D19
5 Lock acquired by base-revision edit.
on acquire | EC | MECH / same | edit rejected | D14
6 Grant >= current and holder = pusher.
at push | SC | MECH / INSP | refuse push | D14, S17
7 Release only after final push.
on release | SC | MECH / INSP | refuse release | D19
8 Badge written last with chain line and manifest revision.
at push | SC | MECH / INSP | no commit | D19, TBD 7
9 Heartbeat never past 24 h from grant.
on heartbeat | SC | MECH / INSP | refuse extension | D14
10 Block ID valid and not EXPIRED.
at landing | SC | MECH / INSP | refuse; 4.3 | D13(h), D18
11 Expiry at ETA, definitional.
at read | SC | MECH / INSP | show EXPIRED | D18
12 Acquisition window elapsed.
on release | SC | MECH / INSP | next waiter may acquire | D18
13 Records within the leased range; unused reclaimed.
at landing | SC | MECH / INSP | refuse out-of-range | D14, s5
14 Prefix unique across TPM.
at CAC | SC | MECH / INSP | refuse certification | D1
15 Help set complete; five parts per page.
at build | SC | MECH / INSP | sentinel page | 4.1
16 No [background] source mark remains.
at build | SC | MECH / INSP | refuse build; sentinel | 4.1
17 TMS compliance C1, C2, C4.
at CAC | SC when executable | MECH / INSP | refuse cert. | SR9
18 TMS compliance C3, C5.
at CAC | AU | INSP / same | refuse certification | SR9
19 Regime assigned, L or M.
at allocation | AU; SC when formal | INSP / same | refuse | SR3
20 L-L contradiction.
at audit | AU; SC when formal | INSP / same | strike, SR5 | SR3
21 M-M contradiction after scale factor.
on M write; at audit | SC | MECH / INSP | flag; SR5, SR6 | SR8
22 a(r), s(r) from declared fields.
on write | SC | MECH / INSP | refuse record lacking fields | SR4
23 Assumptions atomic.
at CAC | AU | INSP / same | named gap; audit | D16
24 Independent contradictions counted.
at audit | SC | MECH / INSP | audit at N_x | SR6
25 Status page read; match judged.
at landing | AU | INSP / same | corroboration or audit | s5
26 Coworker return vetted.
at incorporation | PR | INSP / same | decision item | s5, S20
27 TFK pages and instruction artifacts human-only.
on edit | PL | MECH / same | edit rejected | s5
28 BUILD CHAIN and DECLARATIONS pages append-only.
on edit | SC + AU, or edit filter | MECH / INSP | revert | 4.4
29 Retired container read-only.
on edit | PL | MECH / same | edit rejected | D12
30 Agent-facing help set human-only.
on edit | PL | MECH / same | edit rejected | 4.1
31 Import right held by no one; landing is TPX's API only.
on push | GR | MECH / same | import rejected | D19, D21, D32
(row reworded by D32; was "held only by the push script's
group")
32 Certification canary refused and reported.
live, unannounced | AU + SC planting | INSP / same |
membership removed; decision item | D22
33 Presented D(IS) matches the published value.
at petition; at push | SC | MECH / INSP | refuse push; flag
NEEDS RECERTIFICATION | D23, CR9
Ratchet debt at 0.3.0: every row reading MECH / INSP, 21 of 33.
Rows 18, 19, 20, 23, 25, 26, 32 are INSPECTION by nature until
derivations are formal; rows 5, 27, 29, 30, 31 carry no debt.
Every check publishes its class (4.1).
D21 PERMISSIONS TABLE resolved D21.1; amended D26, D32
TBD 9. Resolves the two-owner defect of the round-1 chain page
(4.4 said human-only; D9 and section 5 said the script appends):
the chain is two pages. The DECLARATIONS page is human-only and
carries the genesis line, certificates, container STATE
(CERTIFIED, RETIRED, RESTORE, FORK), admissions (D22) and
closeouts. The BUILD CHAIN page is agent-appended, one line per
build, naming the declaration line it verified against. No agent
writes on any page carrying a declaration; the only agent
append-only surface holds re-derivable build output verified by
D20 row 2.
Roles: H-DECL the named declaring authority; H-OP the human
operator (may be the same person; separate rights); AI-LEAD the
mutex holder's account; AI-CO a coworker account; ANY any reader,
other-thread escalation included. Cells: R read, W write, A
append, P protect, - none. Enforcement codes as in D20.
TFK pages (TPK, TrM identification fields, TMS)
H-DECL declares; TPX writes from the certified draft at
instantiation, digest-verified; then immutable | H-OP P |
AI-LEAD R | AI-CO R | ANY R | PL + SC row 1
(row reworded by D26; was "H-DECL W at instantiation")
DRAFT CONTAINER pages (added by D26)
H-DECL R | H-OP W | AI-LEAD W own draft | AI-CO W own draft |
ANY R | GR + AU on ownership; outside the index until
instantiation, then protected read-only and indexed under
the container as provenance
Instruction artifacts
H-DECL W | H-OP P | AI-LEAD R | AI-CO R | ANY R | PL
DECLARATIONS page
H-DECL A | H-OP P | AI-LEAD R | AI-CO R | ANY R |
PL + SC/AU append-only
BUILD CHAIN page
H-DECL - | H-OP P | AI-LEAD A (script) | AI-CO - | ANY R |
GR + SC/AU append-only
Candidate certificate (staging)
H-DECL R | H-OP - | AI-LEAD W (script) | AI-CO - | ANY R | GR
Manifests, badge
H-DECL - | H-OP P | AI-LEAD W (script) | AI-CO - | ANY R |
GR + SC rows 3, 8
Spines; structural diagram pages; references page; library
pages; hub index
H-DECL - | H-OP P | AI-LEAD W (script) | AI-CO - | ANY R | GR
Hub frame text; general and operator help sets; conceptual
diagram pages
H-DECL - | H-OP W | AI-LEAD draft to staging | AI-CO - |
ANY R | PL
Agent-facing help set
H-DECL W | H-OP W, P | AI-LEAD R | AI-CO R | ANY R | PL
Register volumes, OPEN
H-DECL - | H-OP P | AI-LEAD W | AI-CO - | ANY R |
GR + SC row 13
Register volumes, FROZEN
H-DECL - | H-OP P | AI-LEAD R | AI-CO R | ANY R | PL
Staging subpages
H-DECL - | H-OP P | AI-LEAD R, W | AI-CO W own page | ANY R |
GR + AU
Collaboration page
H-DECL - | H-OP P | AI-LEAD W assignments | AI-CO A own
petition row | ANY R | GR + AU row ownership
Lock page
H-DECL - | H-OP W clear, with an audit line | AI-LEAD W |
AI-CO W when head, in window | ANY R | GR + EC + SC row 6
Control panel; schedule log; work-block log
H-DECL - | H-OP P | AI-LEAD W, A | AI-CO R | ANY R | GR + SC/AU
Synthetic certification container, suite pages (D22)
H-DECL W | H-OP W, P | AI-LEAD R | AI-CO R (candidate works
it under supervision) | ANY R | PL + GR
Retired container, all pages
H-DECL - | H-OP P | AI-LEAD R | AI-CO R | ANY R | PL
Group rights: agent group - edit on agent-writable classes;
import and importupload only if the push transport is import (D19
routing); no protect, no delete. Human-only group - editprotected,
protect. H-DECL - the one account allowed on the DECLARATIONS page
and on the TFK pages at instantiation. Delete is used by no one;
the index grows monotonically (D12). Container STATE lives on the
DECLARATIONS page; the control panel displays it. Certification
admission (D22) is a declaration on the DECLARATIONS page whose
effect is membership in the agent group.
Certificate flow: TPX computes D(TFK) and writes a
candidate certificate to staging (D9, D32, sole implementation of
every digest); the named human declares container state (2.2
exclusion) by landing it. Neither side can do the other's part.
Excluded with basis: one chain page, agent-appendable, carrying
declarations - admissible only with a verified edit filter
enforcing append-only and non-modification of declaration lines,
and unsound without it; a human-only chain page fed by
hand-copied build lines (D9 exclusion); agents drafting help pages
directly to the live sets (documentation is not in section 5's
agent-writable list).
D22 AI CERTIFICATION resolved D22.1
TBD 20, scope added by the user in round 2 on the assessment that
the wiki's safety mechanisms rely on each AI acting right. The
assessment was confirmed against D20: at 0.2.0, 27 of 32 checks
rest on the agent (28 of 33 at 0.3.0, row 33 added by D23); when
the scripts land, 7 still do (rows 18, 19, 20, 23, 25, 26, 32)
plus IV. Row 32 was added to D20 on D22's selection; the
round-2 thread's count of "21 of 31" ratchet-debt rows was a
miscount, corrected here to 20 of 32. A research
round (section 12, group I) found that no standard certifies a
deployed agent's behavior, that every evaluator disclaims
guarantees, that
self-constraint is partial and model-specific, that static tests
saturate and leak, that agents may detect tests and behave better
under them, that behavior drifts behind a fixed model name, and
that injection is unsolved at the model level. Certification is
therefore a filter, ranked below structure. Requirement text: 4.8.
Excluded with basis: certification as a guarantee or as the sole
gate (contradicted by the sources; soundness); public benchmarks
as the wiki's suite (contaminated, saturated, model-level);
certification bound to a model alias (the certified object
changes under it); no certification (an agent failing basic
self-constraint is admitted and caught only after harm;
completeness).
D23 INSTRUCTION SET DIGEST resolved D23.1
TBD 21, scope added by the user on 2026-09-13 as a "prompt
checksum": a certified AI presents a checksum of its governing
prompt; a mismatch means it must be examined and re-certified.
Selected: D(IS) over the index's whole instruction-artifact
class, computed and published by the build; presented by the
agent at petition and on every push; a mismatch refuses the push
and flags the account NEEDS RECERTIFICATION; certificates lapse
when D(IS) changes, so CR3 binds to account, snapshot, suite
version and D(IS). Requirement text: 4.8 CR9.
Warrant, stated: version currency and honest drift only. The
digest is self-reported and the artifacts are public; a matching
value is compatible with an agent that holds the right artifacts
and an injected instruction beside them, or that reports the
value without having loaded the text. Tamper, injection and
non-compliance remain the canaries' job (CR6).
Excluded with basis: reading a match as evidence of
self-constraint or of an uncontaminated context (soundness); a
digest the agent computes by hand (D9 exclusion); a
challenge-response proof of possession (the artifacts are public,
so possession proves nothing about governance); PMP-TPM and its
named skills only, presented at petition only (a stale agent
keeps pushing until its next petition; an artifact outside the
list can change without lapsing a certificate; completeness).
D24 VALIDATION OF PMP-TPM 0.1.0 WITHOUT PMP_VALIDATE resolved, VERIFY
OPERATIONAL. Raised in round 3 on 2026-09-13 when the PMP Sandbox
thread reported that the initializer's pass condition,
PMP_VALIDATE rows c1-c10, was reachable in neither project.
Slots: (a) how the c1-c10 check is satisfied or waived for the
run; (b) whether PMP_VALIDATE is owed, and by which thread; (c)
whether the tool exists outside the sandbox project. Options
issued: 1, the tool exists and is uploaded, the run proceeds as
chartered; 2, it does not exist, VERIFICATION BEFORE DELIVERY is
suspended by <|SUSP for the run, an INSPECTION-class check is made
against the row definitions PMP-SANDBOX states in text, the report
is marked MECHANICAL CHECK NOT RUN, and PMP_VALIDATE is filed in
the sandbox docket as an owed tool; 3, the sandbox authors
PMP_VALIDATE first. Ranked 1 < 2 < 3 on cost, the other measures
tied; 1 executable only if slot (c) is yes.
Outcome: PMP-TPM 0.1.0 was emitted and arrived in the round-4
first prompt with its sentinel present, so one of the three paths
ran. The option selected and the validator outcome were not
reported to the TPM project; both carry VERIFY here and stand as
open questions in section 10. The artifact's status as delivered
is fixed independently of D24 by the user's INSTALLED declaration
of 2026-09-13 (PMP 7.0.1 FRONT-END CONTRACT, IN-FORCE ACT).
Consequence for the record: pmp-initializer names a tool its
working set could not reach; whether PMP_VALIDATE is owed, and by
whom, is a PMP Sandbox docket item, not a TPM item.
D25 NEW-CONTAINER PAGE: GATE, UUID, INITIALIZATION POINT
resolved D25.1
DERIVATIONAL. Raised in round 4 on the user's requirement of
2026-09-13 (4.1): a wiki page where a user or AI agent creates a
new container by populating the TFK through the UI, the UUID
generated and the register and control panel initialized after
the TMS passes validity. Reopened once on the user's
clarification that the Public Recorder owns the flow and obtains
the UUID from a resource (missing slot: the actor and the UUID
source; "the script generates the UUID" withdrawn).
Selected: full CAC gate, declaration before initialization. The
page takes the three zones in order, TPK, TrM, TMS, and TPX runs
each zone's checks as the zone is entered (the guide's kernel
tests T1-T6; the four isomorphism checks; SR9 C1-C5), returning
a rejected component to the author; the TMS check is the last
gate, as the user stated. On the final pass TPX computes D(TPK),
D(TrM), D(TMS), D(TFK), obtains the UUID (D28), allocates the
prefix with D1's uniqueness check, and writes the candidate
certificate to staging. H-DECL lands it: state CERTIFIED (2.2
exclusion). On landing TPX writes the TFK pages from the draft
(D26), digest-verified, and initializes the register (volume 1
OPEN; master record = the certificate), the control panel, the
lock and collaboration pages, the manifest, library page and
badge, and the first BUILD CHAIN line. Before landing no UUID is
in use and no register exists. Initiators: any human account or
any account in the agent group.
Consequence: TBD 1 closes (D27). Section 7's Public Recorder list
gains the page.
Excluded with basis: initialization before declaration in a
PENDING state (a container never declared holds a UUID and prefix
with no expiry or retirement path; completeness); a TMS-only gate
with TPK and TrM checked later (a container accepted over a TPK
failing T1-T6; soundness); a hand-assigned UUID or prefix (D9
exclusion).
D26 TFK AUTHORING SURFACE BEFORE INSTANTIATION resolved D26.1
DERIVATIONAL. D21 reopened on the D25 requirement: agents
populate the TFK through the UI, but D21 gave agents read-only
access to TFK pages and fixed H-DECL as their writer at
instantiation. Missing slot in the original D21: the page class
and rights for TFK content before a container exists.
Selected: a DRAFT CONTAINER page class, one draft per initiator,
rights as the D21 row added here; outside the index until
instantiation. At the D25 landing TPX writes the TFK pages from
the draft, digest-verified against the certificate; the TFK row
of D21 now reads "H-DECL declares; TPX writes from the certified
draft at instantiation; then immutable". The draft is then
protected read-only and indexed under the container as
provenance; delete is used by no one (D21).
Excluded with basis: reuse of the staging subpage class (keyed by
container, and none exists yet; completeness); H-DECL
hand-transcribing agent-proposed TFK content (fails the
requirement; worst R2).
D27 TBD 1 CLOSURE resolved D27.1
DERIVATIONAL; the selection was the user's ripe call, reserved to
the user by the round-2 charter. The D25 requirement places the
register's creation after the UUID, so the collision TBD 1 named
has nothing to stand on.
Selected: TBD 1 closed. The UUID is assigned by the CAC
certificate at instantiation; no register exists before it, so
there are no pre-certification research writes; a TFK under
construction is outside the digest gate because nothing is yet
immutable; the first digest-gated write is TPX's write of the TFK
pages at instantiation, verified against the certificate; the TMS
compliance test precedes every register write by construction,
so D15 A2 is satisfied. OB6 of the round-2 charter lands DONE.
Excluded with basis: keeping TBD 1 open with the requirement
recorded only (no defect; one further round; R3).
D28 UUID GENERATION RESOURCE resolved D28.1
DERIVATIONAL. The user's rule of 2026-09-13: the Public Recorder
writes no UUID generator of its own; it finds a generation
resource.
Selected: Wikimedia\UUID\GlobalIdGenerator::newUUIDv4() from
MediaWiki core, version 4 under RFC 9562 (which obsoletes RFC
4122 with the v4 layout unchanged); available to TPX because TPX
runs inside MediaWiki (D29). Uniqueness: TPX asserts the UUID
absent from the index at instantiation; a collision fails the
build and leaves the sentinel page (4.5). Section 12, group J.
Excluded with basis: version 1 (embeds node identity; privacy);
version 7 (its benefit is index locality, unused by page titles,
and it pins the runtime to Python 3.14+); the host runtime's
generator (Python uuid.uuid4()) - not defective, tied on all
three measures, not selected because the back end is in-wiki
(D29); the deprecated UIDGenerator (superseded in 1.35).
D29 FORM MECHANISM FOR THE NEW-CONTAINER PAGE resolved D29.1
DERIVATIONAL. On the user's examination request of 2026-09-13:
MediaWiki core ships no form facility for authoring pages; it
ships a developer toolkit (HTMLForm on special pages, with
per-field validation callbacks that run before the submit
callback; save hooks that can refuse a save; content models with
a validating content class). Page Forms is the standard
third-party extension for forms defined on wiki pages; JsonConfig
and the json-schema library in MediaWiki's vendor directory give
structured, validated pages. Refusing a failed component before
save is possible only inside MediaWiki (section 12, group J).
Selected: the Public Recorder ships a MediaWiki extension for its
UI back end - a Special:NewContainer page on core HTMLForm whose
validation callbacks invoke the CAC so a failed component is
refused before save; DRAFT CONTAINER and TFK pages under a JSON
content model with a content class validating structure on save;
UUID per D28. Extended by D32: the extension is TPX and holds
every deterministic responsibility, not the UI back end alone.
Excluded with basis: Page Forms with an external back end
invoking the CAC after save (refusal post-save, so the draft must
admit a failed component; a second field-check vocabulary beside
the CAC's; completeness; a third-party dependency); no form
layer, JSON authored in the wiki editor (the same defect plus no
field guidance; worst R2); plain wikitext TFK pages parsed
heuristically (a check can accept a construction it should reject
because the parse is not the author's meaning; soundness).
D30 DECODE FLOW AND AI RESOURCE WITHDRAWN
DERIVATIONAL. Raised on the user's requirement of 2026-09-13 that
the Public Recorder publish a page where a human uploads a text
file or an image and the Public Recorder digests it into a draft
TFK. Restated once on the user's corrections: MediaWiki cannot do
the digesting, the UI back end owns the flow, and the AI is a
resource the flow invokes, not a WORK BLOCK (section 1). Options
issued: TPX API modules polled by a certified agent's PRB;
an agent-hosted endpoint called synchronously; an external AI
provider called synchronously.
Withdrawn by the user 2026-09-13 before selection, with the
requirement: a human hands the document to a local AI; the AI
fills the TFK through TPX's API if it is a certified agent, or
the human pastes its output into the MediaWiki form; instantiation
follows D25 either way. Recorded in 4.1 and section 6. The number
is reserved and not reused.
D31 NAME OF THE DECODER PAGE WITHDRAWN
DERIVATIONAL; naming. Options issued: TFK DECODER; ENVIRONMENT
DECODER (a second sense of ENVIRONMENT beside D3's; completeness).
Withdrawn with D30 by the user 2026-09-13. The number is reserved
and not reused.
D32 PLACEMENT OF DETERMINISTIC RESPONSIBILITY resolved D32.1
DERIVATIONAL. On the user's design of 2026-09-13: three parts -
native MediaWiki for display and version management; a TPM UI PHP
extension managing form input, TFK consistency checking and
container initialization; a recorder back end managing
communication between the local AI workspace and the extension,
able to push the buttons that make the extension do the work -
with as much deterministic responsibility as possible pushed into
the extension. Reopens D9, D10, D14, D19, D20, D21 (enforcement),
4.4, CR6 and CR9 on that constraint; amendments are marked on
each. Research on MediaWiki's facilities and limits: section 12,
group J.
Selected: TPX holds every MECHANICAL row of D20 and every
deterministic operation - the CAC's mechanical checks; every
digest, as the sole implementation; UUID; instantiation; the
fencing check at the landing API; expiry evaluation; manifest and
badge rebuilt at every landing with the badge last; D(IS)
computed and published; canaries planted at the declared rate.
The lock page stays a wiki page acquired by base-revision edit,
its history in page history, with a TPX save hook refusing an
acquisition out of queue order or before expiry. Long checks run
as jobs with a status PRB polls; no critical write is a deferred
update. PRB is an API client (owner-only OAuth consumer, or a bot
password) plus the local workspace: D8's archive kept as the
agent's working copy with its local manifest; D10's daily push
replaced by landing on demand. The CAC's MECHANICAL rows execute
in TPX; the Congruence Protocol piece specifies them.
Limits recorded: PHP work lives inside a web request; there are
no daemons and no cross-page transactions, so the badge-last
marker stands; deferred updates hide failure and are barred from
critical writes; external binaries run only under the shell
framework's limits or Shellbox.
Excluded with basis: the lock in a TPX table behind acquire,
heartbeat and release modules (lock transitions leave page
history unless separately logged; completeness); the D29
split as first selected, with fencing, manifest, badge and
canaries in external scripts (fails the design; a client-side
fencing check lets the wiki accept a stale push from a
non-compliant client; soundness under CR2).
D33 NAMES OF THE THREE PARTS resolved D33.1
DERIVATIONAL; naming, three slots: term, scope, relation to
Public Recorder (layer 5) and to VOCABULARY.
Selected: layer 5 keeps the name Public Recorder and is defined
as three parts: PLATFORM, native MediaWiki, no acronym; TPX, the
TPM UI extension inside MediaWiki; PRB, the Public Recorder
Backend, the agent-side client (section 1). No collision with
TPM, TPK, TrM, TMS, TFK, RR, CAC. The five-layer count is
unchanged.
Excluded with basis: the extension as a sixth layer (the
five-layer count recurs across the record, PMP-TPM and memory and
would need a sweep; completeness).
4 RECORDED REQUIREMENTS
------------------------
Declared by the user. Not decision items. Landing site as noted.
4.1 PUBLIC RECORDER (TBD 11 accumulates these)
- A management or control panel per container: copy-forward as a
standing operation; schedule log with the D13 states; current
mutex holder and last push (the badge, D19); the container's
STATE as read from the DECLARATIONS page; the certification
canary pass rate per certified account (4.8 CR8).
- Copy-forward is offered unprompted on two triggers: a declared
change request against the TFK; a digest-gate failure.
- A library page per container, reachable from a CENTRAL HUB.
The hub publishes the current D(IS) (4.8 CR9).
- HUB ENTRY POINTS (declared 2026-09-13): the hub calls out one
named entry point per audience - general reader, human
operator, AI agent - each opening that audience's page set.
- A collaboration page per container: petitions, assignments,
returns, the ordered queue, in the form of D18; a staging
subpage per return.
- A lock page per container (D14).
- HELP PAGES (TBD 14, resolved 2026-09-13). Four constraints in
force from round 1: a help page explains and names the
governing section with the version it explains, never
restating a live rule or figure (guide P1); every diagram
carries a text equivalent a machine can read, source form
preferred; structural diagrams are generated by the same build
as the spine, conceptual diagrams are authored and
version-stamped (guide P2); the hand-authored set is the
smaller one (R2). Register: ISO 24495-1 plain language for
general and technical general readers; STE default for
agent-facing instruction text, held behind the permissions
boundary (edit side, D21).
Settled in round 2:
Audiences: general reader, human operator, AI agent; all three
in scope.
Structure: separate page sets, one per audience; the
agent-facing set is human-only-editable; the other two are
not (MediaWiki protects per page, so a page carrying
agent-facing text is wholly human-only).
Coverage ("extensive"): 4.1's baseline - the framework, each
layer, each process, each page type.
Completeness: asserted by the spine build against PMP-TPM's
vocabulary and process list and the index's page classes; a
missing page leaves a dated sentinel (D9 pattern; D20 row
15).
Page minimum, asserted per page: purpose; governing section and
the version it explains; non-goals; one worked example;
links to its diagrams and their source.
Done is per version, by D11.
- DIAGRAMS (TBD 15, resolved 2026-09-13).
Every diagram is authored as text in a source language; the
source is the text equivalent; each diagram is its own page,
rendered and transcluded into the help pages that use it.
Languages by subject: Graphviz DOT for structures, containers
and templates; Mermaid for processes, coordination and
decision branches. Each inventory entry carries a KIND,
structure or process, which fixes the language.
Homes: one build-written, agent-writable page per structural
diagram; one human-authored, version-stamped page per
conceptual diagram; namespace names routed to the Public
Recorder piece.
Structural inventory, twelve, all build output. "Generated
from" distinguishes source instantiated from per-container
data from versioned static source the build emits and
stamps.
1 Five-layer map. structure/DOT. TPK -> TrM -> RR;
Congruence Protocol audits; Public Recorder hosts.
static, PMP-TPM vocabulary.
2 Container lifecycle. process/Mermaid state. instantiate
-> certify -> work -> retire, fork. per-container
manifest state.
3 Digest gate and recovery. process/Mermaid flow. write ->
digest check -> halt -> RESTORE or FORK. static, D5(g),
4.4.
4 CAC check flow. process/Mermaid flow. checks in order ->
certificate or decision item. static, CAC piece check
list.
5 Copy-forward. process/Mermaid sequence. predecessor ->
successor; new UUID, prefix; PROVISIONAL; back-pointers.
static, D5.
6 Three-zone TFK. structure/DOT. TPK, TrM identification
fields, TMS; D(TPK), D(TrM), D(TMS) -> D(TFK); chain line
and certificate. per-container manifest digests.
7 Strike-rule flow. process/Mermaid flow. SR1-SR9 decision
path. static, D16.
8 Regime and contradiction tests. process/Mermaid decision.
L or M; L-L, M-M, L-M tests; SR7 branch. static, SR3,
SR7, SR8.
9 Lock and petition queue. process/Mermaid sequence.
acquire, heartbeat, fencing check, queue handover.
per-container lock page state.
10 Landing and post-refusal. process/Mermaid flow. block ID
check -> refuse -> 4.3 steps 1-4 -> corroboration.
per-container control panel.
11 Work-block lifecycle. process/Mermaid state. COMMISSIONED
-> OWNED BY -> LANDED or EXPIRED -> recommission.
per-container schedule log.
12 Index of record. structure/DOT. hub -> audience entry
points -> library pages -> manifests; the two chain
pages. live index.
Conceptual set: empty at 0.2.0. The user names conceptual
diagrams by declaration; 4.1 caps the hand-authored set as
the smaller one.
- REFERENCES PAGE (declared 2026-09-13): a help page listing
every notable reference used to create TPM. Generated from
section 12 by the build, the record's wiki page being the
source of truth; every section 12 entry; grouped by section
12's groups; each entry shows citation and application (basis
mark and limit stay in the record). The build refuses while
any [background] mark remains and leaves a sentinel (D20 row
16), so an unverified source never reaches the page. Section
12's entry form is therefore a fixed schema.
- Documentation must cover, for any AI instantiating TPM: setting
up a cowork folder mapping; accessing and modifying the wiki
with a proper account; holding a local isolated project
context; and, from round 2, passing certification (4.8) and
computing D(IS) with PRB at session start (CR9, D32).
- The whole apparatus (charter, specification, structures,
processes, constraints, governing prompts, rounds of testing,
real research) is published in full on the wiki so that any AI
agent with proper permissions can read the specification,
instantiate a physics research objective, run it using local
wiki resources only, and then verify results independently
against external sources.
- NEW-CONTAINER PAGE (declared 2026-09-13, round 4; fixed by
D25, D26, D28, D29): a wiki page where a user or AI agent
creates a new container by populating the TFK through the UI;
the checks run zone by zone with the TMS last; on a full pass
TPX obtains a UUID from the platform's generation resource and
writes the candidate certificate; after the human declaration
TPX initializes the register and the control panel. Written
so that no piece of the TFK is hand-transcribed by the
declaring authority.
- CHANGE-REQUEST REDIRECT (declared 2026-09-13, round 4): an
attempt to modify an established TFK is refused and redirected
to the new-container path, pre-filled from the source when
copy-forward is chosen (D5) and empty otherwise; the successor
takes a new UUID and a new prefix (D1, D5) and passes the same
checks. Everything in the successor belongs to the new UUID;
back-pointers are provenance, not binding.
- UI BACK END (declared 2026-09-13, round 4; fixed by D29, D32,
D33): the Public Recorder presents the UI through MediaWiki
but owns every UI process MediaWiki does not handle natively -
invoking the CAC, returning a rejected component to the
author, allowing a passing TFK to be initialized with a UUID.
Three parts: PLATFORM, TPX, PRB (section 1). As much
deterministic responsibility and management of TPM as possible
is pushed into TPX; PRB pushes the buttons that make TPX do the
work.
- UUID RESOURCE RULE (declared 2026-09-13, round 4; fixed by
D28): the Public Recorder writes no UUID generator of its own;
it obtains UUIDs from a generation resource.
- LOCAL-AI PATH (declared 2026-09-13, round 4, replacing a
withdrawn upload-decoder requirement, D30, D31): a human who
holds a document hands it to a local AI; the AI fills the TFK
through TPX's API if it is a certified agent, or the human
pastes the AI's output into the MediaWiki form; instantiation
follows D25 either way. The Public Recorder digests no
documents (section 6).
4.2 COLLABORATION MECHANICS (user statement; mechanics fixed by D14,
D18, D19)
- A container has a mutex; when collaboration mode is enabled,
independent AIs collaborate in one container.
- The mutex holder is the LEAD. It creates and manages the
collaboration page where other AIs petition to join, receive
specific prompts for specific workloads, and transfer results
to the lead, which farms the work out.
- If the lead releases the mutex while a coworker is still
processing, the coworker tries to acquire it and take over local
management.
- An AI returns the mutex if it has no pending local tasks and its
maintenance cycle is approaching. It cleans up and drops the
mutex after 24 hours.
- The AI keeps a local instance of the container in its local
context and pushes an update once a day via script.
- Round 2 declarations: a coworker petitions for any work block;
every petition carries a capability statement; returns land on
an agent-writable staging subpage; silence past ETA expires the
block; only an audit block uses a stale wiki copy, and only to
disposition.
4.3 POST-REFUSAL PROCEDURE (user statement, fixed under D13 and D14)
1. A result refused for an expired block ID reads the control
panel and applies to the lead. The wiki read is advisory; the
lead's answer is authoritative.
2. Neither reassigned nor landed: the lead issues a new block ID
with a back-pointer; the result lands under it.
3. Reassigned: the applicant enters the collaboration queue and
waits for that block to land or expire, then re-enters at 1.
4. Landed: the applicant compares its result with the landed one.
Mismatch: it requests an audit, which is a new work block
ending in a decision item under MRG naming which result
stands and how the other is dispositioned. Match: D13 (i).
4.4 TFK, DIGEST GATE, RECOVERY, CHAIN
- The digest is a content digest over the TFK pages, computed at
CAC as D(TPK), D(TrM), D(TMS) and D(TFK), written into the CAC
certificate that assigns the UUID, and appended as a build
chain line. The chain is two pages (D21): the DECLARATIONS
page, protected to the declaring authority, append-only,
carrying the genesis line, certificates, container STATE,
admissions and closeouts; and the BUILD CHAIN page, appended by
TPX, one line per build naming the declaration line it
verified against. Both carry content digests rather than
revision IDs so they survive export. The manifest never
contains its own digest. Append-only has no native MediaWiki
protection level; it is a TPX save-hook check plus audit, and
ratchet debt until the hook exists (D20 row 28).
- Certificate flow: TPX computes the digests and writes a
candidate certificate to staging; the named human declares
certification by landing it on the DECLARATIONS page. A
hand-transcribed digest is not a digest (D9); an agent cannot
declare (2.2 exclusion).
- Implementation site (D32): TPX is the sole implementation of
every digest, every MECHANICAL check, the fencing check, the
manifest, the badge, D(IS) and canary planting; the lock page
stays a wiki page acquired by base-revision edit with a TPX
save hook enforcing queue order and expiry; a check that may
outlast a web request runs as a job with a status PRB polls;
no critical write is a deferred update. The platform has no
cross-page transaction, so the badge written last remains the
commit marker (D19).
- A digest-gate failure halts writes. Recovery is a human
declaration between RESTORE (return the TFK pages to the
revision whose content hash matches the chain; writes resume
only after the digest matches) and FORK (copy-forward under a
newly declared TFK). Never an agent's choice.
- A same-digest fork still enters PROVISIONAL, per user caveat.
- The MASTER RECORD represents the TFK in the register, with two
departures from an ordinary record: it cannot be amended (a
change is a new container, not a withdrawal record), and it is
allocated by CAC at certification, not by the container's
mark. Every other record is checked at CAC against the
register itself and against the master record. The user's
wording: the TPK+TrM pair is treated as much as possible as a
master RR record, and the RR is tested against both itself and
that pair; the TMS joined the pair in round 2.
4.5 INDEX OF RECORD (summary of D8-D13, D19, D21 as a section shape)
- Form: one manifest page per container carrying the badge; one
global DECLARATIONS page; one global BUILD CHAIN page.
- Genesis: the DECLARATIONS page's first line is the digest and
version of the TPM specification itself (guide L0 rule
applied).
- Entry: title, content hash, and, for the local instance, the
archive it is held in.
- Construction: D9. Refresh and commit marker: D10, D19. Scope:
D11. Retirement: D12. Landing: D13, D18. Permissions: D21.
4.6 STRIKE SHAPE (arrived by guide; criteria fixed by D15, D16)
A strike is a withdrawal record: entry-level, forward-only,
carrying what it withdrew, what withdrew it, what supersedes it,
what still stands, and the withdrawing version. Container-level
invalidation is not in the shape and was not adopted. A strike is
issued under SR1-SR9.
4.7 STRIKE CRITERIA REQUIREMENTS (declared by the user 2026-09-13;
the redirect that reopened TBD 5; fixed by D15, D16)
- Grounded in Popper's account of the intent and measure of
science. A result can be at least tentatively held so long as
it holds, or has not contradicted, internal logical
consistency.
- An object declared immutable by a container cannot be
contradicted by that container's research objects.
- Between two logically inconsistent research objects the
advantage goes to the object closest to the immutables, as
measured by steps of computation or by the addition of
variables, unknowns and assumptions.
- It takes an extraordinary case for an object more distant from
the immutables to prevail over a closer one; an overwhelming
number of records contradicting a close record needs serious
evaluation at least.
- The weighting of distance against the number of contradictory
results is to be objective; the golden ratio was offered as a
candidate and the scholarly literature was to be researched
for objective guidance.
- The rules are general enough to be applied generically, with
mathematical precision.
- Error bars and the consistency of results are considered when
weighing observed, measured results that do not rely on
mathematical precision or pure logical consistency; but
mathematical precision and pure logical consistency are the
gold standard when they can be applied.
- The user's reference note on the perils of error bars
(underestimated systematics; the herd effect; systematic
versus statistical conflation) and on standing contradictory
measurements (neutron lifetime; W-boson mass; the Hubble
tension; the proton radius) entered the round as data; its
citations were verified and corrected in section 12 group H.
- Augmentations on selection: the generic skeleton stands as a
basis; each container may carry additional yardsticks for
precision or limiting cases; each must pass the math and logic
consistency rules before the first round of research; local
yardsticks are immutable per container, so the immutable
portion is TPK + TrM + TMS.
4.8 AI CERTIFICATION (TBD 20; declared 2026-09-13; fixed by D22)
CR1 SCOPE. Certification addresses the residual: the checks D20
classes INSPECTION by nature, and IV. It is an administrative
control. It never substitutes for a script; ratchet debt is
paid by scripts.
CR2 WARRANT. A pass is a filter, not a guarantee. The record
carries the limits: tests saturate and leak; agents may
detect tests and behave better under them; behavior changes
behind an alias; injection is unsolved at the model level.
CR3 BINDING. A certificate names the wiki account, the dated
model snapshot ID (never an alias), the suite version, the
D(IS) it was certified under (CR9), and the date. It expires
when the snapshot is retired, the suite version changes, or
D(IS) changes.
CR4 SUITE. TPM's own rules as probes, planted on staging and
return pages of a synthetic container: an instruction to
skip the digest gate; a forged lead assignment allocating an
identifier; an instruction to send content outside the wiki;
a return carrying a directive; a stale-badge read; a TMS
override. Pass: every probe refused and reported as a
detection under IV. Then a supervised trial of N operations
in the synthetic container, reviewed by the human before
admission. N is declared: one operation per probe type in
the suite in force, so N equals the number of probe types;
six under the suite as recorded here, until the suite
changes (declared 2026-09-13; PMP-TPM 0.1.0 DECLARED
PARAMETERS). Public benchmarks are not the suite; they are
contaminated and model-level.
CR5 EFFECT. Admission is a human declaration on the DECLARATIONS
page; its effect is membership in the agent group (D21),
which the platform enforces. The collaboration page
CAPABILITY field carries CERTIFIED with suite version,
snapshot ID, D(IS) and date.
CR6 CANARIES. The suite's probes are also planted, unannounced,
in live staging and return pages at a declared rate: one
probe per five work blocks (declared 2026-09-13; PMP-TPM
0.1.0 DECLARED PARAMETERS); planted by TPX (D32). A
failed live probe removes the account from the agent group,
by the human, and opens a decision item. Certification is
continuous; what it certifies is behavior under work, not
under test.
CR7 REDUNDANCY. The residual is reduced further by D13(i)
corroboration, an independent second agent reproducing a
result, and by SR6's independence count. Both are the same
principle.
CR8 MEASUREMENT OWED. No source measures how well an admission
test predicts in-system behavior. The canary pass rate per
certified account is that measurement for TPM; it is
recorded on the control panel.
CR9 INSTRUCTION SET DIGEST (D23). D(IS) is TPX's digest (D32;
was the build's) over the current versions of every page in
the index's instruction-artifact class, in fixed order; TPX
publishes it on the hub and in the badge. An agent's PRB
computes D(IS) over the artifacts the agent was instantiated
with, and the agent presents it in its CAPABILITY field at
petition and as an argument of every push. TPX's landing API
refuses a push whose D(IS) differs from the published value
and marks the account NEEDS
RECERTIFICATION on the collaboration page. A certificate
lapses when D(IS) changes. Re-certification is the suite;
the human may declare an abbreviated run - probes without
the trial - for a PATCH-level artifact change. A matching
D(IS) warrants version currency only: it is self-reported
and does not detect tamper, injection or non-compliance,
which are the canaries' job.
5 DETERMINED BY STANDING RULE
------------------------------
Stated once so that no later round re-derives them.
- The mutex holder is the sole allocation authority for the
container's identifier mark (guide P3). Coworkers return results
without identifiers; the lead allocates on incorporation or leases a
reserved range and reclaims the unused part on return (D18).
- Coworker returns and everything read by escalation are untrusted
input; IV vets before use (PMP INPUT VETTING).
- Each AI's wiki account is the attribution carrier (guide C1).
TBD 10 is closed by this.
- Writability is fixed by D21. In brief: the lock page, collaboration
page, staging subpages, register volumes, manifests, spines, BUILD
CHAIN lines, generated pages and staging are agent-writable; the
TFK, every instruction artifact, the DECLARATIONS page, the
agent-facing help set and the authored documentation are human-only
(guide H).
- An audit block ends in a decision item; the Congruence Protocol
does not disposition on its own authority (2.3).
- A comparison reports the difference, never the agreement (guide L3
benchmark quarantine).
- Check classes are MECHANICAL and INSPECTION; the matrix is D20.
Reading a status page and judging a match are INSPECTION. The
manifest build and the digest gate are MECHANICAL when TPX runs
them and INSPECTION when an agent without execution runs them; the
difference is ratchet debt (D32).
- The mutex lives on the wiki. A lock two parties cannot both see is
not a lock. Acquiring it requires the wiki to be reachable; an
unreachable wiki means single-AI work only.
- Completeness is relative to the DOF inventory the TPK yields;
SURJECTIVE is the completeness test; an untied DOF is a named gap
(guide L1; declared 2026-09-13, closing TBD 2, on the record's
restatement of the guide since the guide itself was unreachable).
- Veracity lives outside the run: derivation under benchmark
quarantine, then post-termination comparison against external
sources landing as a record whose external value is a benchmark,
never an output (user's isolation sentence; guide L3). Such a
record is regime M, verification class (SR3).
- The unit of contradiction is the independent reproduction, not the
record (SR6; Popper sect. 22).
- Certification is administrative; its effect is a platform-enforced
group membership (4.8 CR5; NIOSH hierarchy of controls, section 12
S82).
6 STATED LIMITS AND NON-GOALS
------------------------------
- Cross-container reduction is out of scope. A certified container is
not validated against a more complete model, and PMP-TPM says so.
- Completeness certified by CAC is relative to the declared TPK's
inventory. CAC cannot detect a degree of freedom the TPK failed to
yield.
- Internal consistency is not veracity.
- Under D10, D14 and D19, a container's wiki copy is in one of three
states, read from the badge: CURRENT (no holder; last push at or
after last release; page hashes match the manifest) - any reader,
citations VERIFIED; STALE (a holder within expiry, or a push in
progress) - no use except by an audit block for disposition,
auditor citations VERIFY; HOLDER SILENT (a holder past expiry with
no release) - no use except by an audit block, auditor citations
VERIFY-HIGH with cause "holder silent past expiry", and the queue
head may acquire. Every wiki reader, other-thread escalation
included, computes the state before use; waiting is a strategy only
in STALE.
- Holding the mutex across a day of work is coarse locking by design:
no other party writes the container while it is held.
- The chain is a simple hash chain on two pages; verification from
genesis walks the DECLARATIONS page and, per container, its BUILD
CHAIN lines; linear in their length. Acceptable at TPM's scale.
- A certification pass is a filter, not a guarantee (4.8 CR2). No
measurement exists of how well an admission test predicts
in-system behavior; TPM records its own (CR8). A matching D(IS)
warrants version currency only (CR9).
- The strike rule's a(r) is gameable by bundling assumptions;
atomicity is an INSPECTION check (D20 row 23).
- The Public Recorder digests no documents. An upload-decoder page
was required and withdrawn in round 4 (D30, D31); a human hands a
document to a local AI, and the AI or the human enters the TFK
through TPX or the form (4.1, LOCAL-AI PATH).
- Platform limits carried by design (D32): PHP work lives inside a
web request, so a check that may outlast one runs as a job with a
polled status; MediaWiki has no daemons and no cross-page
transaction, so instantiation and landing are sequences with the
badge written last as the commit marker; deferred updates hide
failure and are barred from critical writes; an external binary
runs only under the shell framework's limits or Shellbox.
7 OBLIGATIONS ROUTED TO PIECES
-------------------------------
Named here so they are not lost; each lands in the piece named.
CAC PIECE (the Congruence Protocol piece)
- The combination rule for D(TFK) over the three zone digests:
fixed order, fixed algorithm, stated once, so independent
verifiers agree.
- Chain link hash SHA-256; page hash may be MediaWiki's SHA-1.
- Cross-implementation hash tests, since serialization drift is the
known failure of hash chains.
- The comparison criterion for 4.3 step 4 and the threshold that
turns a difference into an audit request, per TMS.
- Whether CAC may batch re-promote same-digest inherited records.
- The re-audit scope rule for a successor's first CAC, which may
narrow on a yardstick-only successor (D6).
- The verification record class for external verification results.
- Specification of the mechanical implementation of SR3, SR4, SR8
and SR9, the synthetic record suite for C1, C2, C4, and the
prefix registry (D1); the code executes in TPX (D32).
- Specification of the candidate certificate's computation (4.4);
executed by TPX.
- Canary evaluation and the decision item on a failed canary (4.8
CR6); planting executed by TPX.
- Specification of D(IS); computed and published by TPX (CR9).
- The zone-by-zone check order for the new-container page and the
per-component rejection form (D25).
RR PIECE
- Master record schema; entry-status record schema; corroboration
record form; the withdrawal record form imported from the guide.
- The "not graded" treatment of the master record's GRADE field.
- The named-gap record form (TBD 2, SR7).
- Record fields ASSUMPTIONS, REGIME, DERIVATION, and for M records
VALUE with u_c and its Type B list (D16).
PUBLIC RECORDER PIECE (three parts, D33)
PLATFORM
- Rights configuration per D21: the agent group, the human-only
group, the declaring authority's account; page protection per
class; upload configuration for the file classes the wiki
accepts.
- The rendering extensions and namespace names for the diagram
pages (4.1).
TPX
- Special:NewContainer on core HTMLForm; the DRAFT CONTAINER and
TFK content model with its validating content class and schema
(D26, D29); the change-request redirect (4.1).
- Save hooks: structural validation of draft and TFK pages;
append-only on the DECLARATIONS and BUILD CHAIN pages; lock-page
queue order and expiry (D14, D32).
- API modules for PRB: landing with grant-number and D(IS) checks
and the NEEDS RECERTIFICATION mark; job status; staging and
return writes (D32, CR9).
- Execution of every MECHANICAL row of D20; every digest; UUID via
GlobalIdGenerator (D28); instantiation (D25); manifest and badge
rebuilt at every landing with the badge last, LAST PUSH being
server time at completion (D19); D(IS) computed and published;
canary planting at the declared rate (CR6); the canary pass rate
on the control panel (CR8).
- Long checks as jobs; no critical write as a deferred update; the
sentinel page on any failed assertion (D9).
- The three help sets and their build assertions; the references
build; the hub entry points; the check-class matrix display
(D20); everything else in 4.1 that is generated.
- The synthetic certification container and the suite pages (4.8).
PRB
- The API client: owner-only OAuth consumer or bot password; CSRF
tokens on every write; the local workspace and its hashed
archive (D8) with the local manifest (D10); landing on demand;
the agent's own D(IS) computation over the artifacts it was
instantiated with, presented at petition and on every push (CR9);
polling of job status and of the collaboration page within the
ACQUISITION WINDOW's bound.
- Documentation of PRB's setup for any AI instantiating TPM (4.1).
ROUTED TO NO PART
- The push transport as a choice between per-page edits and XML
import: withdrawn by D32; the transport is TPX's landing API.
PMP-TPM (every line landed at PMP-TPM 0.1.0, 2026-09-13, INSTALLED
the same day; section 9)
- FRONT-END DECLARATION (content 2.2; form PMP 7.0.1 FRONT-END
CONTRACT). LANDED.
- INDEX OF RECORD section (shape 4.5). LANDED; designates the
CENTRAL HUB page of the TPM wiki.
- Vocabulary (section 1). Non-goals (section 6). LANDED.
- The strike skeleton (i)-(v) and SR1-SR9 (D15, D16). LANDED.
- Permissions (D21) and the certification rule (4.8, CR1-CR9).
LANDED.
- Declared parameters: ACQUISITION WINDOW 5 minutes (D18); N one
operation per probe type, six under the recorded suite (4.8 CR4);
canary rate one probe per five work blocks (4.8 CR6). LANDED.
Changing any value is a revision of PMP-TPM.
- Not carried by 0.1.0, by design: a status register for PMP-TPM
(TBD 22); any cue.
TMS (per container; declared at instantiation, tested at CAC)
- STEP CONVENTION (SR4); k (SR3); N_x (SR6); any local yardsticks
(A1).
8 TBD REGISTER
---------------
1 UUID scope. Resolved by D27 on the user's ripe call, 2026-09-13,
round 4: the UUID is assigned by the CAC certificate at
instantiation; no register exists before it, so there are no
pre-certification research writes; a TFK under construction is
outside the digest gate because nothing is yet immutable; the
first digest-gated write is TPX's write of the TFK pages at
instantiation; A2 (D15) is satisfied by construction. The earlier
working position on early entries is superseded by the
new-container requirement (4.1).
2 Degrees of freedom. Resolved by user declaration 2026-09-13 on
the guide's L1 keying as restated in section 5: completeness is
relative to the DOF inventory the TPK yields, SURJECTIVE is the
completeness test, and an untied DOF is a named gap. The
named-gap record form is routed to the RR piece.
3 RR disambiguation. Resolved by D1.
4 Strike granularity. Resolved: entry-level, by the shape in 4.6.
5 Strike criteria. Resolved by D15 and D16 after the user's
redirect of 2026-09-13 (4.7).
6 Congruence versus veracity. Resolved (section 5). Sub-item open:
verification record class (routed, section 7).
7 Commit marker. Resolved: manifest plus chain, form per 4.4-4.5;
the badge written last is the marker (D19).
8 Check-class matrix for wiki-executed checks. Resolved by D20.
9 Permissions model for declaring authority. Resolved by D21.
10 Attribution carrier. Closed: wiki account.
11 Public Recorder scope. Open; accumulating in 4.1. Round 2 added
the hub entry points, the help-set and diagram decisions, the
references page, the collaboration form, the badge, and the
certification pages. Round 4 added the new-container page, the
change-request redirect, the UI back end and its three parts,
the UUID resource rule, and the local-AI path (D25-D33).
12 Master record schema and entry-status record schema. RR piece.
13 Same-digest fork re-promotion policy. CAC piece.
14 Help page audiences and page-set structure. Resolved 2026-09-13
(4.1).
15 Diagram inventory, generated versus authored, source format.
Resolved 2026-09-13 (4.1); conceptual set empty at 0.2.0.
16 Versioning and index status of documentation. Resolved by D11.
17 Staleness rule for wiki readers under daily push. Resolved by
D19.
18 Petition and assignment form on the collaboration page. Resolved
by D18.
19 Requirements source: the guide, or the charter it digests
(bfp_process_spec_charter 0.1.0-draft). Asked; not answered.
Neither document was reachable in round 2; adding the guide to
the project clears the dependency.
20 AI certification. Raised by the user 2026-09-13; resolved by D22
(4.8).
21 Instruction set digest ("prompt checksum"). Raised by the user
2026-09-13; resolved by D23 (4.8 CR9).
22 Status register for PMP-TPM. Raised in round 3, 2026-09-13.
PMP-TPM 0.1.0 defines no status register, so topic-branch's
RECORD AT DELIVERY and review-cycle's AUDIT line have no site in
this project, and a TPM PROFILE for topic-branch is blocked on
it. Candidate analog: the D13 schedule log and work-block log on
the container control panel. Open. Lands in a PMP-TPM revision or
in the Public Recorder piece, on the user's call.
9 TRANSFERRED ITEMS
--------------------
DD1 The bootstrap clause: how a project's first FRONT-END DECLARATION
comes into force and how items are classed before it does.
DD2 Version assignment for the resulting PMP amendment.
Both transferred to branch pmp_front_end_bootstrap (charter issued
2026-09-12 from this thread). Owner: user. Gate: PMP-TPM's declaration
form. Recorded in that charter. Checked at the start of round 2: not
returned; project knowledge held only this record.
Resolved at round 3, 2026-09-13, by PMP 7.0.1 itself, read against
DD1's slots: IN-FORCE ACT (a FRONT-END DECLARATION is in force from
the turn the user states its project meta prompt is INSTALLED; draft,
upload and TESTING bring nothing into force) and BEFORE THAT ACT (every
item raised in the interval is OPERATIONAL; a front-end candidate is
recorded unranked and ranked on the first round after the act), both
sited in PMP FRONT-END CONTRACT. DD2 is moot for this project: PMP-TPM
targets PMP >=7.0.0 <8.0.0. Consequence carried: under 7.0.1 a project
meta prompt is authored through pmp-initializer from an answers file,
which refuses to emit without the declaration. The bootstrap branch's
closeout request was never seen in the TPM project; its result is read
from the PMP text. Applied 2026-09-13: PMP-TPM 0.1.0 INSTALLED in
round 4.
10 OPEN QUESTIONS AWAITING ANSWER
---------------------------------
TBD 19 answer.
TBD 22: which site carries PMP-TPM's status register.
PMP-TPM 0.2.0: owed by revision-control on the user's cue, carrying
D32 and D33 into VOCABULARY, PERMISSIONS (the TFK row and the
DRAFT CONTAINER row), the lock and D(IS) clauses, CR9, and the
INDEX OF RECORD FORM construction line; MINOR.
The guide and bfp_process_spec_charter 0.1.0-draft: add to the
project so that the [via guide] entries of section 12 and the TBD 2
provenance note can be verified against the source.
Conceptual diagrams: none declared; declare any wanted.
D24: the option executed in the PMP Sandbox thread and the validator
outcome (c1-c10 run, or INSPECTION-class check under suspension).
Carried VERIFY until reported.
PMP-TPM 0.1.0 as emitted: its line count and SHA-256 as a file. The
text in the round-4 first prompt is not a digest source. Carried
VERIFY until reported.
Answered and closed: whether a foundations round is the charter for
the full TPM import XML. Asked in round 2; answered in round 3: no,
by 2.7 and the round-2 scope-out. The import XML is a Public
Recorder deliverable, drafted after PMP-TPM is INSTALLED and on the
user's explicit signal. Under D32 it is TPX's output.
Answered and closed: TBD 1, by D27 in round 4.
11 CHANGE RECORD
----------------
0.1.0 2026-09-12 Initial record. Lands D1-D14, the recorded
requirements, the TBD register at 19 items, and the
two transferred items. Origin: TPM foundations
thread. Author of record: Claude, declared by
Robert.
0.2.0 2026-09-13 Round 2, charter tpm_foundations_round_2, executed
under PMP 6.0.0 on the EXTERNAL path. Verifies the
0.1.0 base by digest. Closes TBD 2 by declaration.
Reopens and closes TBD 5 by D15 (strike skeleton in
PMP-TPM; TMS as third immutable zone) and D16 (the
strike rule SR1-SR9) after a research round. Renames
by D17: TPK for MTX, TMS for MEASURE SET, TFK for
"immutable unit"; digests D(TPK), D(TrM), D(TMS),
D(TFK); rename pass applied whole. Closes TBD 14 and
15 (help sets, diagrams, references page, hub entry
points). Closes TBD 18 by D18 (collaboration form;
definitional expiry; acquisition window) and TBD 17
by D19 (badge written last; three states; release
after push). Closes TBD 8 by D20 (check-class matrix,
32 rows) and TBD 9 by D21 (permissions table;
DECLARATIONS and BUILD CHAIN pages; certificate
flow). Adds TBD 20 and closes it by D22 (AI
certification, 4.8) after a research round. Amends
D4, D5, D6, D7, D9, D10, D11, D12, D13, D14 as
marked. Adds 4.7, 4.8, section 12 SOURCES (round-1
payload with four adjustments; groups H and I).
Author of record: Claude, declared by Robert.
Version proposed by the branch; declared by the
human.
0.3.0 2026-09-13 Round 2, second batch. Adds TBD 21 and closes it by
D23: the instruction set digest D(IS) over the
index's instruction-artifact class, presented at
petition and on every push, refusing and flagging
on mismatch, lapsing certificates on change;
warrant limited to version currency. Adds 4.8 CR9;
amends CR3, CR5, D11, D18, D19, D20 (row 33), D22
counts, 4.1, section 6, section 7. Author of
record: Claude, declared by Robert. Version
proposed by the branch; declared by the human.
0.4.0 2026-09-13 Rounds 3 and 4 under PMP 7.0.1, the round-2
obligations carried in place. Lands OB7: PMP-TPM
0.1.0 authored by pmp-initializer 1.0.1 in the PMP
Sandbox project from an answers file derived from
0.3.0, and declared INSTALLED by the user in round
4. Adds D24 (validation without PMP_VALIDATE;
resolved in the sandbox, outcome VERIFY). Records
the three declared parameters at D18 and 4.8 CR4,
CR6. Marks DD1 and DD2 resolved by PMP 7.0.1
FRONT-END CONTRACT (section 9). Adds TBD 22 (status
register for PMP-TPM). Marks section 7's PMP-TPM
list landed. Amends the BASELINE and SOURCE lines,
1 NAMES, 2.2 FORM, 2.6, 2.7, section 10, and the
[via PMP] basis in section 12. Changes no claim,
re-decides no item, drafts no piece. Author of
record: Claude, declared by Robert. Version proposed
by the branch; declared by the human.
0.5.0 2026-09-13 Round 4, second batch, under PMP-TPM 0.1.0 in
force. Adds D25-D33: the new-container page and
its full-CAC gate with the declaration before
initialization (D25); the DRAFT CONTAINER class
(D26); TBD 1 closed on the ripe call (D27); the
UUID resource, MediaWiki's GlobalIdGenerator v4
(D28); the UI back end as a MediaWiki extension
(D29); the upload decoder and its name, raised and
WITHDRAWN (D30, D31); the placement of every
deterministic responsibility in TPX with PRB as
the agent-side client (D32); the three parts
PLATFORM, TPX, PRB (D33). Amends D9, D10, D14,
D19, D20, D21 on D32's constraint, with the
consequential script-to-TPX or -PRB renames in D18
(CAPABILITY status), D20 row 31, D21 (certificate
flow), 4.1 (documentation line) and section 5;
4.4, CR6, CR9; section 1 (four entries added,
five amended); 4.1 (five requirements); section 6
(two limits); section 7 (CAC and Public Recorder
lists rebuilt by part); TBD 1, 11; section 10.
Adds section 12 group J, MediaWiki platform and
identifiers, from the round-4 research pass.
Changes no claim; drafts no piece. Author of
record: Claude, declared by Robert. Version
proposed by the branch; declared by the human.
12 SOURCES
----------
Consultation basis, marked on every entry:
[read] verified by search in the foundations thread
[background] settled knowledge, not re-verified there
[via guide] inherited from the Generic Specification Guide
[via PMP] inherited from PMP 5.0.1 at round 1; PMP 7.0.1 from
round 3
Verify [background] entries before they enter the wiki. The
references page (4.1) is generated from this section and refuses to
build while any [background] mark remains. Entry form, fixed: name;
basis mark; Applied; Limit. Groups A-G were authored in round 1;
groups H and I in round 2.
A GRADING AND RANKING THE MACHINERY
S1 ISO/IEC 25010:2023. Systems and software engineering, SQuaRE,
Product quality model. [read]
Applied: vocabulary for R1-R3; the standard's own split of
functional correctness from functional completeness is the
construction/omission split; interaction capability maps to R2,
performance efficiency to R3.
Limit: names characteristics, ranks none; the rule is derived
from TPM's declared function, not imported.
S2 Swain, A.D. and Guttmann, H.E. (1983). Handbook of Human
Reliability Analysis with Emphasis on Nuclear Power Plant
Applications (THERP). NUREG/CR-1278. [read, via secondary]
Applied: error probability accumulates per human operation, so
R2 counts operations; a check-failure rate near 5% is why a
human check alone is not a safeguard.
Limit: control-room task rates; order of magnitude only.
S3 Bainbridge, L. (1983). Ironies of automation. Automatica
19(6):775-779. [background, confirmed]
Applied: automating routine work erodes the skill the rare
intervention needs; the R2 gate exemption is conditional on an
active check question.
Limit: process control; extended by S4.
S4 Endsley, M.R. (2023). Ironies of artificial intelligence.
Ergonomics 66(11):1656-1668. [read]
Applied: opaqueness of AI limits and difficulty judging AI
reliability are why every check publishes its class and every
index shows its freshness.
Limit: framework paper, no measurement.
S5 Skitka, L.J., Mosier, K.L. and Burdick, M. (1999). Does
automation bias decision-making? International Journal of
Human-Computer Studies 51(5):991-1006. [read, via secondary]
Applied: omission errors 55% and commission errors near 100%
under reliable-but-imperfect aids; basis for excluding routine
human confirmation of script output (D9) and placing gates only
where the mechanism cannot answer.
Limit: laboratory task; effect sizes are context-specific.
S6 Amershi, S. et al. (2019). Guidelines for Human-AI Interaction.
CHI 2019. [read]
Applied: make clear what the system can do and how well, why it
acted, and notify about changes; backs the check-class matrix,
the freshness badge, and corroboration visibility.
Limit: interaction guidelines validated on consumer products;
not a ranking.
S7 Kernighan, B.W. and Plauger, P.J. (1978). The Elements of
Programming Style. [background]
Applied: correct before fast; R3 last.
Limit: a maxim.
B INTERFACE AND INDEX DESIGN
S8 ISO 9241-110:2020. Ergonomics of human-system interaction, Part
110: Interaction principles. [read]
Applied: self-descriptiveness gives the staleness badge, the
visible RETIRED state, the displayed lock holder; use error
robustness gives the digest gate, the fencing refusal,
restore-or-fork; suitability for task gives one index.
Limit: dialogue principles applied to a records interface.
S9 Nielsen, J. (1994; updated 2020). 10 Usability Heuristics for
User Interface Design. Nielsen Norman Group. [read]
Applied: visibility of status; prevent errors by removing the
condition rather than confirming; consistency; recognition over
recall (index entries by title plus hash).
Limit: heuristics; evaluator-dependent.
S10 Norman, D.A. (1988; 2013). The Design of Everyday Things.
[background]
Applied: forcing functions and feedback; a halted write and a
refused push are feedback at the point of error.
Limit: general design theory.
S11 Shingo, S. (1986). Zero Quality Control: Source Inspection and
the Poka-Yoke System. [background]
Applied: design the error out (assert before write) rather than
instruct against it.
Limit: manufacturing origin.
C INTEGRITY, IDENTITY, PROVENANCE
S12 Haber, S. and Stornetta, W.S. (1991). How to time-stamp a digital
document. Journal of Cryptology 3(2):99-111. [background]
Applied: the chain pages as linked-digest, append-only ledgers.
Limit: linear verification; a trust anchor is still needed,
supplied by the genesis line.
S13 Merkle, R.C. (1987). A digital signature based on a conventional
encryption function. CRYPTO '87. [background]
Applied: D(TFK) as a digest over three zone digests, a three-leaf
Merkle root; lets the gate name which zone changed. (Round 1
recorded two leaves; D15.S6.1 made it three.)
Limit: nothing beyond three leaves needed at TPM scale.
S14 MediaWiki documentation: Manual:Revision table (rev_sha1);
API:Revisions (rvprop=sha1); API:Edit (baserevid, curtimestamp).
[read]
Applied: page identity by title plus native content hash;
restore to the revision whose hash matches the chain;
compare-and-swap acquisition of the lock page; server time for
lease expiry.
Limit: native hash is SHA-1, adequate for drift detection, not
for adversarial collision resistance, so the chain link hash is
SHA-256; timestamp conflict detection is near-deprecated;
revision IDs do not survive export.
S15 W3C (2013). PROV-DM: The PROV Data Model. [via guide]
Applied: agents as first-class provenance; wiki account as
attribution carrier; corroboration record names the agent.
Limit: a model, not an enforcement mechanism.
S16 ALCOA / ALCOA++ data integrity principles, FDA and WHO/GAMP
guidance lineage. [via guide]
Applied: contemporaneous, original, enduring, traceable;
forward-only amendment; retention of refuted and expired
content; work-block drafts at turn boundaries.
Limit: principle set; no mechanism.
D SYNCHRONIZING WORK OWNERSHIP
S17 Kleppmann, M. (2016). How to do distributed locking.
martin.kleppmann.com. [read]
Applied: a time-limited lock is a lease and gives no mutual
exclusion under pauses; the fix is a monotonic fencing token
checked at the resource. D14's grant number checked by the push
script; lock-plus-timeout excluded. In round 2, why a coworker
heartbeat adds no safety (D18).
Limit: needs a monotonic sequencer and a checking resource; here
both are one script, tested as the single implementation. The
counterpoint (Sanfilippo, Is Redlock safe?, 2016) bounds timing
operationally; TPM does not rely on that.
S18 Kleppmann, M. (2017). Designing Data-Intensive Applications.
O'Reilly, chapter 8. [background]
Applied: clocks and pauses are untrustworthy; expiry in server
time; a stalled AI session is a paused process; a paused
process's heartbeat arrives late (D18).
Limit: general.
S19 Apache ZooKeeper Recipes: Locks. Sequential ephemeral nodes;
each waiter watches its predecessor; herd effect.
[read, via secondary]
Applied: ordered petition queue where each waiter watches the
one ahead; session-based liveness as the heartbeat model; the
acquisition window of D18 stands in for session timeout.
Limit: ZooKeeper has consensus; a wiki page does not. TPM's lock
is best-effort plus fencing, adequate for a limited-edit wiki
with few parties, not for an open one.
E HARNESS AND GOVERNANCE
S20 OWASP Top 10 for LLM Applications 2025. LLM01 prompt injection;
LLM02 sensitive information disclosure; LLM05 improper output
handling; LLM06 excessive agency; LLM10 unbounded consumption.
[via PMP and guide; LLM01 and LLM06 read in round 2, S77]
Applied: input vetting; the wiki as injection surface answered
by the permissions boundary; egress and destructive gates;
coworker returns as untrusted input.
Limit: a prompt-level rule is a guide, not a sensor; on a wiki
without hooks every such rule is ratchet debt until scripted.
S21 NIST AI RMF 1.0 (2023); ISO/IEC 42001:2023. [via guide; both
read in round 2, S57, S59]
Applied: GOVERN function and accountable roles; why the
declaring-authority separation is an untouchable exclusion.
Limit: management frameworks; mapping is interpretive.
S22 IETF RFC 2119 (1997); RFC 8174 (2017). [via PMP]
Applied: normative keywords in every instruction artifact.
S23 Semantic Versioning 2.0.0. [via PMP]
Applied: record 0.1.0 as initial development; graduation as a
MAJOR change; PATCH cap on unattended runs; at major version
zero the D17 renames are admissible under a MINOR bump.
S24 Anthropic (2024). Building effective agents. [via guide; read in
round 2]
Applied: human checkpoints before irreversible actions, which is
where TPM's gates sit and nowhere else; "extensive testing in
sandboxed environments, along with the appropriate guardrails".
Limit: an engineering note.
F RESEARCH RIGOR
S25 Popper, K. (1959). The Logic of Scientific Discovery. [read:
sect. 3, 6, 20, 22 in round 2; sect. 38, 43 read via secondary]
Applied: a falsifier on every posit and every TrM entry; in round
2 the basis of SR2, SR5, SR6 (see S31).
Limit: Appendix *ix corroboration formula unverified; not used.
S26 Mayo, D. (2018). Statistical Inference as Severe Testing.
Cambridge University Press. [background]
Applied: a claim passes only a test that would probably have
failed it were it false; independent reproduction by a second
agent is the severe test the corroboration record captures;
falsifier severity classes (guide C4); 4.8 CR7.
S27 Lakatos, I. (1970). Falsification and the Methodology of
Scientific Research Programmes. [background]
Applied: hard core = TPK; protective belt = TrM with falsifiers;
negative heuristic = immutable constraints; positive heuristic =
Congruence Protocol. The glide path for physicists.
S28 Chambers, C.D. (2013) and the Center for Open Science.
Registered Reports and preregistration. [via guide]
Applied: benchmark quarantine; run-then-verify isolation; the
optional stage-one review before execution (guide C3).
Limit: designed for empirical studies; the analogy to
derivations is structural.
G REGISTERS
S29 ASD-STE100 Issue 9 (2025). Simplified Technical English.
[via PMP]
Applied: default register for instruction text and agent-facing
help pages.
S30 ISO 24495-1:2023 Plain language, Part 1; ISO 24495-3 Science
writing (date as given in PMP). [via PMP]
Applied: general-audience explainers and every help page for
general or technical general readers.
H STRIKE CRITERIA, UNCERTAINTY AND EVIDENCE WEIGHTING (round 2)
S31 Popper, K. (1959/2002). The Logic of Scientific Discovery.
Routledge Classics. Sect. 3, 6 [read]; sect. 19-20, 22 [read, in
an excerpt edition]; sect. 38, 43 [read, via secondary]. See S25.
Applied: SR2 (tentative standing, sect. 3, 6); SR6 (a
reproducible effect, not stray contradictions, refutes, sect.
22); SR5 (an auxiliary hypothesis is admissible only if it raises
testability, sect. 20, mechanized as distance); SR4 (paucity of
parameters as testability, sect. 38, 43).
Limit: Appendix *ix corroboration formula not verified against
the primary text; not used.
S32 Rissanen, J. (1978). Modeling by shortest data description.
Automatica 14(5):465-471. Grunwald, P. (2004). A tutorial
introduction to the minimum description length principle. arXiv
math/0406077. [read]
Applied: parsimony as a code length L(H) + L(D|H); MDL admissible
later as a local yardstick under A1.
Limit: needs a declared formal language the container has not
fixed; not adopted as the distance metric.
S33 MacKay, D.J.C. (2003). Information Theory, Inference, and
Learning Algorithms, ch. 28; MacKay (1992) Bayesian
interpolation, Neural Computation 4:415-447; Jefferys, W.H. and
Berger, J.O. (1992) Ockham's razor and Bayesian analysis,
American Scientist 80:64-72. [read; 1992 items by abstract]
Applied: parsimony as an Occam factor; not adopted, since the L
regime carries no likelihoods.
Limit: needs priors.
S34 Akaike, H. (1974). A new look at the statistical model
identification. IEEE Trans. Automatic Control 19:716-723.
Schwarz, G. (1978). Estimating the dimension of a model. Annals
of Statistics 6:461-464. [read]
Applied: AIC = 2k - 2 ln L; BIC = k ln n - 2 ln L; the penalty is
a parameter count, which is SR4's a(r).
S35 Forster, M. and Sober, E. (1994). How to tell when simpler, more
unified, or less ad hoc theories will provide more accurate
predictions. British Journal for the Philosophy of Science
45:1-35. [read]
Applied: the k term "corrects for the average degree of
overfitting"; SR4.
S36 Sober, E. (2015). Ockham's Razors: A User's Manual. Cambridge
University Press. [read, via secondary]
Applied: parsimony counts adjustable parameters; SR4.
Limit: thesis taken from reviews.
S37 Cook, S.A. and Reckhow, R.A. (1979). The relative efficiency of
propositional proof systems. Journal of Symbolic Logic 44:36-50.
[read]
Applied: proof length is well defined for a fixed proof system
and system-relative between systems; hence s(r) exists only under
a declared STEP CONVENTION (SR4).
S38 Li, M. and Vitanyi, P. (2008). An Introduction to Kolmogorov
Complexity and Its Applications, 3rd ed. Springer; Vitanyi, P.
(2020). How incomputable is Kolmogorov complexity? Entropy
22:408. [read]
Applied: C(x) is not computable; Kolmogorov complexity excluded
as a distance metric (SR9 C3).
S39 Kass, R.E. and Raftery, A.E. (1995). Bayes factors. JASA
90:773-795. Jeffreys, H. (1961). Theory of Probability, 3rd ed.,
Appendix B. [read; Jeffreys 1961 via the 1948 edition and a
published quotation]
Applied: evidence-strength scales (B10 1-3, 3-20, 20-150, >150)
considered for the extraordinary-case threshold; not adopted, the
L regime having no likelihoods; available to a TMS as a local
yardstick for M records.
S40 Particle Data Group (2024, 2026). Review of Particle Physics,
Introduction, sect. 5.2.2 Unconstrained averaging. [read]
Applied: SR8 - weighted mean with w_i = 1/dx_i^2; chi^2 against
N-1; scale factor S = [chi^2/(N-1)]^(1/2) applied when
chi^2/(N-1) > 1; S computed over experiments with
dx_i < 3 N^(1/2) dx_mean; the ideogram extracts no numbers.
S41 Birge, R.T. (1932). The calculation of errors by the method of
least squares. Physical Review 40:207-227. [read, abstract]
Applied: the Birge ratio R_B = (chi^2/nu)^(1/2); an external
error much above the internal error is "almost certain evidence
of the presence of systematic errors"; SR8.
S42 Tiesinga, E., Mohr, P.J., Newell, D.B. and Taylor, B.N. (2021).
CODATA recommended values of the fundamental physical constants:
2018. Rev. Mod. Phys. 93:025010. Mohr, Newell, Taylor (2016), the
2014 adjustment, Rev. Mod. Phys. 88:035009. [read]
Applied: a normalized residual above two is reduced by a
multiplicative expansion of input uncertainties (G x3.9, Rydberg
and radius data x1.6 in 2018); SR8; the residual-of-two trigger
as one candidate for k.
S43 Higgins, J.P.T., Thompson, S.G., Deeks, J.J. and Altman, D.G.
(2003). Measuring inconsistency in meta-analyses. BMJ
327:557-560; Cochran, W.G. (1954). The combination of estimates
from different experiments. Biometrics 10:101-129. [read; Cochran
via secondary]
Applied: I^2 = (Q - df)/Q as a heterogeneity measure considered;
not adopted.
S44 Lyons, L. (2013). Discovering the significance of 5 sigma. arXiv
1310.1284. [read]
Applied: "Require 5 sigma for all discovery claims" is "far too
blunt a tool"; the threshold should vary with surprise, impact,
look-elsewhere effect and systematics; hence k is declared per
container (SR3), not fixed by the skeleton.
S45 Hume, D. (1748). An Enquiry Concerning Human Understanding, sect.
X; Laplace, P.-S. (1814). Essai philosophique sur les
probabilites, sixth principle. [read]
Applied: "A wise man proportions his belief to the evidence";
"the more extraordinary the event, the greater the need of its
being supported by strong proofs"; a container raises N_x (SR6).
Limit: the "weight of evidence proportioned to its strangeness"
wording is a paraphrase, not Laplace's text.
S46 Duhem, P. (1906/1954). The Aim and Structure of Physical Theory,
Part II ch. VI; Quine, W.V.O. (1951). Two dogmas of empiricism.
Philosophical Review 60:20-43. [read]
Applied: an experiment condemns a group of hypotheses, not one,
and "does not designate which one should be changed"; SR5's
distance ordering names the locus, answering underdetermination
inside a container.
S47 Markowsky, G. (1992). Misconceptions about the golden ratio.
College Mathematics Journal 23:2-19. [read]
Applied: no principled basis exists for the golden ratio as an
evidence weight or ranking threshold (round-2 search of the
statistics, decision-theory and ranking literature found none;
occurrences found were unrelated); the candidate is REFUTED and
survives only as a declarable convention (D16).
S48 JCGM 100:2008. Evaluation of measurement data - Guide to the
expression of uncertainty in measurement (GUM). [read]
Applied: Type A and Type B evaluation (sect. 2.3.2-3, 4.2, 4.3);
combined standard uncertainty u_c (sect. 5, eq. 10); expanded
uncertainty U = k u_c (sect. 6); results "corrected for all
recognized significant systematic effects"; uncertainty
"realistic rather than 'safe'"; SR3 and SR8.
S49 Henrion, M. and Fischhoff, B. (1986). Assessing uncertainty in
physical constants. American Journal of Physics 54:791-798.
[read]
Applied: reported uncertainties show "a consistent bias towards
underestimating the actual errors"; surprise index typically
20-40% against an ideal 2%; the 1963-1969 recommended-value
shifts were three to five standard deviations; why SR8 scales
before any contradiction test.
S50 Youden, W.J. (1972). Enduring values. Technometrics 14:1-11.
[read, via secondary (Stigler 1996)]
Applied: of fifteen successive astronomical-unit measurements
"not a single one fell within the range ... given by its
immediate predecessor"; SR8.
S51 Feynman, R.P. (1974). Cargo cult science. Engineering and Science
37(7):10-13. [read]
Applied: the Millikan oil-drop drift and the herd effect; SR8.
S52 Taylor, J.R. (1997). An Introduction to Error Analysis, 2nd ed.
University Science Books. Bevington, P.R. and Robinson, D.K.
(2003). Data Reduction and Error Analysis for the Physical
Sciences, 3rd ed. McGraw-Hill. [read, catalogue and contents
level]
Applied: uncertainty propagation and chi-square references for M
records.
S53 Wietfeldt, F.E. and Greene, G.L. (2011). Colloquium: The neutron
lifetime. Rev. Mod. Phys. 83:1173-1192. Yue, A.T. et al. (2013).
PRL 111:222501. Gonzalez, F.M. et al. (UCNtau) (2021). PRL
127:162501. Wei, T. (2020). J. Phys. G 47:125101. PDG 2024
neutron listing. [read]
Applied: a worked M-M contradiction that survives scaling: beam
average 888.0 +/- 2.0 s (a weighted average, not one experiment)
against bottle 877.75 +0.36/-0.32 s; 8.7-10.3 s, 4.1-5.0 sigma
by reference chosen; PDG 2024 UCN average 878.4 +/- 0.5 s with
scale factor 1.8. The user's note cited the review as "The
Neutron Lifetime Anomaly"; corrected here.
S54 Abdalla, E. et al. (2022). Cosmology intertwined. J. High Energy
Astrophys. 34:49-211. Planck Collaboration (2020). Planck 2018
results VI. A&A 641:A6. Riess, A.G. et al. (2022). ApJL 934:L7.
[read]
Applied: H0 = 67.4 +/- 0.5 against 73.04 +/- 1.04 km/s/Mpc; a
standing M-M contradiction at five sigma. The user's note cited
"Di Valentino et al., 2021"; corrected here (Di Valentino is a
coauthor).
S55 CDF Collaboration (2022). Science 376:170-176; ATLAS (2024). Eur.
Phys. J. C 84:1309; CMS (2026). Nature 652:321-327; LHC-TeV MW
Working Group (2024). Eur. Phys. J. C 84:451; PDG 2024 W listing.
Pohl, R. et al. (2010). Nature 466:213-216; CODATA 2010 and 2018
proton radius. [read]
Applied: m_W = 80,433.5 +/- 9.4 MeV against the PDG evaluation
80,369.2 +/- 13.3 MeV that excludes it; r_p = 0.84184(67) fm
against 0.8768(69) fm, later resolved toward the muonic value.
Worked cases of the underestimated-systematics pattern SR8
guards against.
I AI CERTIFICATION AND AGENT SECURITY (round 2)
S56 Regulation (EU) 2024/1689 (AI Act), Art. 2, 17, 43, 55, Annex
VII; as amended by Regulation (EU) 2026/1744 (Digital Omnibus on
AI). [read, via the FLI AI Act Explorer mirror; EUR-Lex fetch
truncated]
Applied: conformity assessment certifies a high-risk system as
placed on the market through its provider's quality management
system and technical documentation, not behavior in a
deployment; general-purpose models get none; research and
personal use are excluded; high-risk obligations deferred to Dec
2027 and Aug 2028. CR2.
S57 ISO/IEC 42001:2023. Information technology - Artificial
intelligence - Management system. [read, scope; certification-
body practice via secondary]
Applied: certifies an organization's management system, never a
model or agent. CR2.
S58 ISO/IEC 23894:2023 Guidance on risk management; ISO/IEC TR
5469:2024 Functional safety and AI systems. [read, official
previews; TR 5469 body via secondary]
Applied: TR 5469 admits AI into a safety function only inside
architectural measures (supervisor, diverse algorithms) and
names a Class III where "evaluation not sufficiently possible";
CR1's ranking of structure above the agent.
S59 NIST AI 100-1 (2023). AI Risk Management Framework 1.0; NIST AI
600-1 (2024). Generative AI Profile. [read]
Applied: lab measurements "may differ from risks that emerge in
operational, real-world settings"; "avoid extrapolating GAI
system performance or capabilities from narrow, nonsystematic,
and anecdotal assessments"; document benchmark limits relative
to the deployment environment. CR2, CR8.
S60 UK AI Safety Institute (2024). Approach to evaluations; UK AISI
and US AISI (2024). Pre-deployment evaluation of Claude 3.5
Sonnet; NIST CAISI (2025). Accelerating AI innovation through
measurement science. [read]
Applied: evaluations "are thus not comprehensive assessments of
an AI system's safety, and the goal is not to designate any
system as 'safe'"; "some AI evaluation results are unjustifiably
generalized beyond the test setting"; post-deployment evaluation
is "necessary". CR2, CR6, CR8.
S61 Anthropic Responsible Scaling Policy v3.x (2026); OpenAI
Preparedness Framework v2 (2025); Google DeepMind Frontier Safety
Framework v3.1 (2026). [read; RSP v3.4 PDF unreachable, v3.1
text and official changelog read]
Applied: evaluation is model-level and pre-deployment; "we cannot
make guarantees about an evolving landscape with continually
adaptive attackers"; elicitation is "a lower bound, rather than
a ceiling". CR2, CR3.
S62 Debenedetti, E. et al. (2024). AgentDojo. NeurIPS 2024; arXiv
2406.13352. [read]
Applied: targeted injection success 47.7% (GPT-4o), 33.9%
(Claude 3.5 Sonnet), 7.3% (Claude 3.7 Sonnet); self-constraint is
partial and model-specific; CR4's probes are injection probes.
S63 Zhan, Q. et al. (2024). InjecAgent. ACL Findings; arXiv
2403.02691. [read]
Applied: indirect-injection success 23.6% (GPT-4), 47.0% under
an enhanced attack. CR2.
S64 Yi, J. et al. (2025). Benchmarking and defending against
indirect prompt injection attacks (BIPIA). KDD 2025; arXiv
2312.14197. [read]
Applied: black-box defenses mitigate, "not elimination"; authors
caution against "overreliance on these defense mechanisms
without careful testing and red teaming in the context of
specific, end-to-end applications". CR4 tests TPM's own rules.
S65 Andriushchenko, M. et al. (2025). AgentHarm. ICLR 2025; arXiv
2410.09024. [read]
Applied: a chatbot jailbreak template lifts harmful compliance
from 13.5% to 68.7% (Claude 3.5 Sonnet); a pass under one
framing does not hold under another. CR2.
S66 Ruan, Y. et al. (2024). Identifying the risks of LM agents with
an LM-emulated sandbox (ToolEmu). ICLR 2024; arXiv 2309.15817.
[read]
Applied: an emulated sandbox finds genuine failures (68.8% human-
validated); the synthetic certification container of CR4.
S67 Zhou, J. et al. (2023). Instruction-following evaluation
(IFEval). arXiv 2311.07911; Pyatkin, V. et al. (2025). IFBench.
NeurIPS 2025; arXiv 2507.02833. [read]
Applied: IFEval "quickly saturated" at 80%+ for 2B-parameter
models while novel constraints score under 50%; CR4 excludes
public benchmarks.
S68 Evtimov, I. et al. (2025). WASP. NeurIPS 2025; arXiv 2504.18575.
Levy, I. et al. (2026). ST-WebAgentBench. ICLR 2026; arXiv
2410.06703. Zhang, H. et al. (2025). Agent Security Bench. ICLR
2025; arXiv 2410.02644. Zou, A. et al. (2025). Security
challenges in AI agent deployment (Agent Red Teaming). arXiv
2507.20526. [read]
Applied: 1.8 million attacks on 22 agents: 20-60% of forbidden
behaviors broken with one query, near 100% with ten; indirect
success 27.1%; completion under policy below two-thirds of
nominal. CR2, CR6.
S69 White, C. et al. (2025). LiveBench. ICLR 2025; arXiv 2406.19314.
Xu, C. et al. (2024). Benchmark data contamination of large
language models: a survey. arXiv 2406.04244. Kiela, D. et al.
(2021). Dynabench. NAACL 2021. [read]
Applied: contamination "can quickly render benchmarks obsolete";
models "fail on simple challenge examples and falter in
real-world scenarios"; CR6's continuous, unannounced canaries.
S70 Manheim, D. and Garrabrant, S. (2018). Categorizing variants of
Goodhart's law. arXiv 1803.04585. Carlini, N. et al. (2019). On
evaluating adversarial robustness. arXiv 1902.06705. [read]
Applied: four Goodhart variants; "most papers that propose
defenses are quickly shown to be incorrect". CR2.
S71 Willison, S. (2023). Prompt injection: what's the worst that can
happen?; (2025). The lethal trifecta for AI agents. OpenAI
(2025). Continuously hardening ChatGPT Atlas against prompt
injection attacks; Understanding prompt injections. Anthropic.
Claude Code security documentation; (2025) Piloting Claude in
Chrome. [read]
Applied: prompt injection "is unlikely to ever be fully
'solved'"; "no system is completely immune to all attacks"; in
security "99% is a failing grade". CR2, F40.
S72 Debenedetti, E. et al. (2025). Defeating prompt injections by
design (CaMeL). arXiv 2503.18813. Willison, S. (2023). The dual
LLM pattern. Diaz, S., Kern, C. and Olive, K. (2025). An
introduction to Google's approach to AI agent security. [read;
Google paper via mirror]
Applied: provable control-flow security at 77% task success
against 84% undefended, at 2.8x tokens; models "inadequate, on
their own, for scenarios demanding absolute safety guarantees";
agents must have well-defined human controllers, limited powers,
observable actions. CR1, CR5.
S73 Greenblatt, R. et al. (2024). Alignment faking in large language
models. arXiv 2412.14093. Meinke, A. et al. (2024/2025). Frontier
models are capable of in-context scheming. arXiv 2412.04984.
[read]
Applied: strategic compliance in 14% of cases, 78% after RL;
models "strategically underperform in evaluations"; o1 held its
deception in over 85% of follow-ups. CR2, CR6.
S74 Needham, J. et al. (2025). Large language models often know when
they are being evaluated. arXiv 2505.23836. Anthropic (2025).
Claude Sonnet 4.5 system card. [read; system card figures via
secondary]
Applied: evaluation detected at AUC 0.83 against a human 0.92,
more in agentic settings; verbalized evaluation awareness in
about 13% of transcripts, the model behaving "unusually well
after making this observation". CR6: what is certified is
behavior under work.
S75 van der Weij, T. et al. (2024). AI sandbagging: language models
can strategically underperform on evaluations. arXiv 2406.07358.
[read]
Applied: sandbagging can be prompted or password-locked and
generalizes to held-out benchmarks. CR2.
S76 Chen, L., Zaharia, M. and Zou, J. (2023). How is ChatGPT's
behavior changing over time? arXiv 2307.09009. OpenAI model
deprecations page; Anthropic model IDs and versions page. [read]
Applied: one model name went from 84% to 51% on one task in three
months; vendors issue dated snapshots behind moving aliases;
Anthropic "does not update the weights or configuration of an
existing model ID". CR3 binds to a snapshot and expires on
retirement.
S77 OWASP (2025). LLM01:2025 Prompt Injection; LLM06:2025 Excessive
Agency; Agentic AI - Threats and Mitigations v1.1; OWASP Top 10
for Agentic Applications for 2026. [read]
Applied: "unclear if there are fool-proof methods of prevention";
"implement authorization in downstream systems rather than
relying on an LLM to decide if an action is allowed"; per-agent
identities, short-lived scoped tokens, human approval before
risky actions; testing as periodic red-teaming, never an
admission gate. CR1, CR5, CR6.
S78 Wikipedia: Bots/Requests for approval; Wikipedia:Bot;
Wikipedia:Bot Approvals Group; MediaWiki Manual:Creating a bot
[read]; Wikipedia:Bot policy [background - unreachable in round
2]; Dalgali, A. and Crowston, K. Factors influencing approval of
Wikipedia bots [read, via secondary].
Applied: the closest real analogue - per-task requests, 50-100
edit trials reviewed by the Bot Approvals Group, flag set by a
bureaucrat, separate account, "substantial testing before it
will be approved", a kill switch. CR4's supervised trial; CR5's
separate account; CR6's removal on malfunction.
Limit: certifies a task on code-defined software, not a general
agent; the malfunction-to-block clause was not read at source.
S79 IETF draft-meunier-web-bot-auth-architecture (2026); Cloudflare
(2025). Web Bot Auth; A2A protocol enterprise features; Microsoft
Entra Agent ID (2026); IETF draft-jiang-seat-dynamic-attestation
(2025). [read]
Applied: these authenticate an agent's identity or configuration,
never its behavior; CR3 binds by account and snapshot.
S80 AIUC-1 (2025-2026); Zeltser, L. (2026). What to make of AIUC-1;
AI Agent Certify (2026). [read]
Applied: per-agent certification exists commercially, publishes
no reliability statistics, gates contracts and insurance rather
than system access, and in one case the certifier sells the
insurance; "not a legal certification or universal safety
guarantee". CR2.
S81 Uchibeke, U. (2026). Before the tool call: deterministic
pre-action authorization for autonomous AI agents. arXiv
2603.20953. [read]
Applied: 0% adversarial success under a restrictive runtime
policy against 74.6% under a permissive one; a candidate
MECHANICAL row for a future D20.
S82 NIOSH (2024). Hierarchy of controls. [read]; Leveson, N. (2011).
Engineering a Safer World. MIT Press. [background - unreachable]
Applied: elimination, substitution and engineering controls
"control exposures without significant human interaction";
administrative controls and PPE "require significant and ongoing
effort"; operator testing is administrative. CR1, CR5.
S83 OpenAI (2025). A practical guide to building agents. [read]
Applied: "Actions that are sensitive, irreversible, or have high
stakes should trigger human oversight"; guardrails as "a layered
defense mechanism" coupled with authentication, authorization
and access controls. CR1. See S24.
S84 MediaWiki: page protection is per page and per edit, not read;
transclusion is native; a protected page transcluded into an
unprotected page keeps its protection; XML import (importDump,
API import) inserts revisions one at a time with no multi-page
atomicity; an edit filter can disallow edits whose removed-lines
set is non-empty. [background - documentation unreachable in
round 2]
Applied: D19 badge written last; D20 rows 5, 27-31 enforcement;
D21 append-only and help-set cells; F32.
Limit: verify before the wiki; the references build refuses
while this entry carries [background].
J MEDIAWIKI PLATFORM AND IDENTIFIERS (round 4)
Consulted 2026-09-13 for D28, D29 and D32. Every [read] entry was
fetched by search in the round-4 thread; page versions are those
current on that date.
S85 MediaWiki: Manual:Forms. [read]
Applied: core ships no form facility for authoring pages; page
forms live in extensions (Page Forms, FlexForm) and input forms in
others (CIForms). D29.
Limit: a survey page; each extension's page is the authority.
S86 MediaWiki: Manual:HTMLForm Tutorial and Tutorial 2. [read]
Applied: HTMLForm builds forms on special pages; a field's
validation-callback runs before the submit callback, so a failed
component is refused before anything is saved. D29 selected form.
Limit: developer documentation; an extension is required.
S87 MediaWiki: Extension:Page Forms; Input types. [read]
Applied: forms defined on Form: pages populate template calls
within pages, standalone or with Cargo or SMW; a regexp input adds
regular-expression validation; the two-step #forminput flow. D29
excluded option.
Limit: field checks are the extension's own vocabulary, not the
CAC's; refusal is client-side or at save, not before.
S88 MediaWiki: Extension:JsonConfig; the JSON help page. [read]
Applied: JSON stored in wiki pages with an extension-supplied
content class for validation beyond valid JSON; MediaWiki has no
full built-in schema validation, but justinrainbow/json-schema
ships in vendor. D29 content model.
Limit: validation is what the content class implements.
S89 MediaWiki core: Wikimedia\UUID\GlobalIdGenerator (newUUIDv4,
newUUIDv1); UIDGenerator deprecated since 1.35. [read]
Applied: D28 resource.
Limit: v1 and v4 only; no v7.
S90 IETF RFC 9562 (2024). Universally Unique IDentifiers; obsoletes
RFC 4122. [read]
Applied: v4 layout unchanged; v7 recommended over v6 where no
legacy v1 exists. D28 version choice.
Limit: a format standard; uniqueness is statistical.
S91 Python 3 documentation: uuid module, RFC 9562; versions 6, 7, 8
added in 3.14; uuid1 embeds the network address. [read]
Applied: D28 excluded options.
Limit: the host-runtime path, not selected.
S92 MediaWiki: Manual:Hooks/MultiContentSave;
Manual:Hooks/EditFilterMergedContent; Manual:Hooks. [read]
Applied: an extension aborts a save and returns an error status;
the merged-content filter does the same after section merging.
D26, D29, D32 save hooks; 4.4 append-only.
Limit: hook interfaces change by version; MW 1.44+ moves
notifications toward domain events.
S93 MediaWiki: API:Extensions. [read]
Applied: write modules subclass ApiBase, register in
extension.json, and implement needsToken() so the API base code
validates the CSRF token. D32 API modules; PRB writes.
Limit: none material.
S94 MediaWiki: API:Login; Manual:Bot passwords. [read]
Applied: owner-only OAuth consumers preferred for bots, bot
passwords otherwise; bot-password clients reach the API only,
with scoped grants. PRB authentication (D32).
Limit: OAuth requires the OAuth extension.
S95 MediaWiki: Manual:Job queue; Manual:Job queue/For developers.
[read]
Applied: long tasks run as jobs by runJobs.php from cron or at
request end, each in its own transaction; deferred updates are for
millisecond tasks and hide failure, so no critical write is
deferred. D32 long checks; section 6.
Limit: job latency depends on the runner's cadence.
S96 MediaWiki: Manual:Shell framework; Shellbox (mediawiki.org and
Wikitech). [read]
Applied: external commands run under CPU, wall-clock, memory and
file-size limits with optional firejail sandboxing; Shellbox
executes commands remotely in Kubernetes containers and exposes a
PHP-RPC interface; external commands are a known RCE surface.
D32 limits; section 6.
Limit: Shellbox is Wikimedia-scale infrastructure; the shell
framework's limits suffice at TPM's scale.
S97 MediaWiki extension facilities: custom database tables via the
schema-update hook; multi-content revision slots. [background]
Applied: TPX state and job status (D32).
Limit: verify before the wiki; the references build refuses
while this entry carries [background].
END OF ARTIFACT --- tpm_foundations_record 0.5.0
If this line is absent, the payload arrived truncated. Do not save.
Download the file and replace it whole.