5.3 TPX (TPS 0.1.0)

Instruction artifact, machine-optimized text: TPS 0.1.0, section 5.3 TPX. Part of TPS 0.1.0 and the TPM hub. Human-only edit (TPS 5.13). Version 0.1.0, proposed, revision 4; declaration pending. The text below is this section of the TPS 0.1.0 artifact, verbatim; the whole artifact and its file digest are on The Principia Machina/TPS. Human readers: the contents page is the map.

TPS 5.3  TPX
purpose: the extension's obligations: Special:NewContainer, the content
         model, save hooks, API modules, digests, UUID via
         GlobalIdGenerator, instantiation, fencing, manifest and badge,
         D(IS), canaries, jobs, sentinel pages
governs: 5.3 | version: 0.1.0 (proposed) | class: instruction artifact
audience: operator

5.3.1  TPX is the TPM UI extension: a PHP MediaWiki extension holding
       every deterministic responsibility MediaWiki can host (see 1.1,
       5.1.3). [I-046] [I-050]
5.3.2  TPX refuses a failed component before save, by validation
       callback or save hook; a check that may outlast a web request
       runs as a job with a status PRB polls; no critical write is a
       deferred update. [I-051]
5.3.3  UUID RESOURCE. TPX writes no UUID generator; it obtains version-4
       UUIDs from MediaWiki core's GlobalIdGenerator (D28) and asserts
       the UUID absent from the index at instantiation. [I-053]
5.3.4  The new-container page is a Special:NewContainer page on core
       HTMLForm whose validation callbacks invoke the CAC so a failed
       component is refused before save; DRAFT UWC and TFK pages
       are under a JSON content model with a content class validating
       structure on save. [B-24]
5.3.5  TPX carries: the change-request redirect (see 5.5.6); save hooks
       for structural validation of draft and TFK pages, append-only on
       the DECLARATIONS and BUILD CHAIN pages, and lock-page queue order
       and expiry (see 5.7); API modules for PRB: landing with
       grant-number, D(IS) and declared-TPS-version checks and the NEEDS
       RECERTIFICATION mark, job status, staging and return writes;
       execution of every MECHANICAL row of 4.2; every digest; the UUID;
       instantiation; the manifest and badge rebuilt at every landing
       with the badge last, LAST PUSH being server time at completion;
       D(IS) computed and published; canary planting at the declared
       rate; the canary pass rate on the control panel; long checks as
       jobs; the sentinel page on any failed assertion; the three help
       sets and their build assertions, the references build, the hub
       entry points and the check-class matrix display (see 5.15); the
       synthetic certification container and the suite pages (see
       5.14). [C-19] [F2]
       OWED: the specification of each item above at the level an
       implementer needs (page names, content schema, hook and module
       contracts, job forms); kind: absence; C-19. TPS specifies TPX; it
       carries no PHP.
5.3.6  Every check publishes its class; TPX displays the check-class
       matrix (see 4.2.7). [B-18]
5.3.7  TPX's pure functions are TPC-PHP: plain PHP classes inside the
       TPX tree, no MediaWiki dependency, unit-tested offline against
       the TPC vectors (see 5.1.5). [D43.1]
5.3.8  TPX registers a plain-text content model for the TPC-PY source
       pages, so the wikitext pre-save transform cannot alter them (see
       5.11). [D43.1]
5.3.9  At landing TPX recomputes every presented value. A mismatch is
       refused, logged, and opens a decision item (see 4.2, row 46).
       [D43.1]
5.3.10 TPX fills INDEPENDENCE, sets SAME-MODEL, and excludes SAME-MODEL
       corroborations from every count it displays (see 3.3.8, 3.3.10).
       [D42.1]
5.3.11 For a REPRODUCTION block TPX records the server time and the
       content hash of the staging write before any match judgment
       (see 5.9). [D42.1]
5.3.12 TPX refuses a cross-entry M-M test or SR8 scale and normalizes
       both values before the test (see 4.4.4, 4.4.8). [D40.1]
5.3.13 TPX holds a system-wide administrative read over every OPEN and
       FROZEN register volume in every UWC. Its only uses are canary
       source selection (5.17) and the scorecard (5.18). It is not a
       research access; nothing it reads is presented to a CA-GTP
       except as a mutated probe. [I-142] [D50]
5.3.14 TPX generates each canary by mutating and recombining real
       register content and injecting a known out-of-bounds condition
       (5.17). No generative model is involved and no content leaves
       the wiki. [I-141] [D50]
5.3.15 TPX delivers a canary by injecting it into the CA-GTP's own API
       read or poll response, and by no other route. It writes no page
       to plant one. It scores the response server-side and records
       the outcome with the gradient steepness and the probe type
       (see 4.2, row 50). [I-139] [I-145] [D49] [D50]
5.3.16 On a failed canary TPX suspends the account's landing API and
       marks its petition row SUSPENDED (5.8). Suspension is not
       removal; it holds until the declaring authority declares
       (5.14, 5.18). [I-148] [D51]
5.3.17 TPX enforces the access policy at the permission hook and the
       save hook (5.16). The platform has no per-subtree access
       control, so no part of this is the platform's. [I-153] [D52]
5.3.18 TPX generates the scorecard and sends it on the two channels
       5.18 fixes. [I-146] [D51]