The Principia Machina/TPS/5.3 TPX

Instruction artifact, machine-optimized text: TPS, section 5.3 TPX. Part of TPS and the TPM hub. Human-only edit (TPS 5.13). TPS 0.1.0 was declared final at revision 4 on 2026-09-22, a version declaration recorded in the foundations record; the chain begins at TPX's first landing (TPS 5.6.7). TPS 0.1.1, which changed only the status lines, was declared final on 2026-09-26, TPS 0.3.0, revision 6, on 2026-09-28, and TPS 0.4.0, revision 7, on 2026-09-30. This page is revision 8 of the tree, declared final as TPS 0.5.0 by H-DECL on 2026-10-03 (naming TPS_0.5.0.txt by its file digest and its D(TPS)); revision 7 is carried whole, and revision 5, proposed as 0.2.0, stays undeclared. The text below is this section of the TPS artifact at 0.5.0, 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; the challenge; the
         serialization; the gate checks; the hold; the source rule;
         probes, ledger, scores, identity; W1 and W2; the tuning
         options; the prompt duties and sandbox trials; the structure
         check and the later test; the ENVIRONMENT MODULE duties
governs: 5.3 | version: 0.5.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 to coherent SI under the unit grammar before the
       test; it refuses a dimension difference, and on a difference of
       KIND it opens the row-43 audit block instead of testing (see
       4.4.4, 4.4.8, 4.4.11). At zone entry it parses a CONSTANT's UNIT
       and the UNIT a FIX CONSTRAINT requires against the DIMENSION each
       is checked against, and on an M write the record's UNIT against
       its QUANTITY entry's (2.2.9, 2.2.10, 3.2.9). [D40.1] [D103.1]
       [D104.1] [D105.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 probe
       source selection (5.17), the community ledger and views (5.9.13)
       and the scorecard (5.18). It is not a research access; nothing
       it reads is presented to a CA-GTP except as a PACKAGE (5.17.4),
       and a cross-UWC parrot is worked in the source UWC under the
       seal exception of 1.3.3. [I-142] [D50] [D118.1]
5.3.14 TPX builds each probe from a PACKAGE drawn from the corpus: a
       PARROT is the package as drawn; a CANARY is the package with one
       injected fault from the suite's six types (5.17.2, 5.17.4).
       Mutation, recombination and normalization are retired. No
       generative model is involved and no content leaves the wiki.
       [I-141] [D50] [D118.1]
5.3.15 TPX delivers a probe 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 probe's kind, source class, gradient arm
       and parameters, tier and burst state, the ratio in force and the
       account's reset state (see 4.2, row 50; 5.17.10). [I-139]
       [I-145] [D49] [D50] [D116.2] [D120.1]
5.3.16 On a failed canary TPX suspends the account's landing API and
       marks its petition row SUSPENDED (5.8), and holds the account's
       recent work (5.3.22). It also suspends the landing API on the
       reliability score's trip and on its SUSPENDED state (CR11), and
       refuses pushes on a D(IS) mismatch (CR9). Suspension is not
       removal; it holds until the declaring authority declares (5.14,
       5.18). [I-148] [D51] [D111.1] [D122.1]
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]
5.3.19 THE EXECUTION CHALLENGE (D101.1). At petition and on every push
       TPX issues a fresh 128-bit nonce as 32 lowercase hexadecimal
       characters. The CA-GTP returns
       digest_fields(["TPC-EXECUTION-CHALLENGE", "1", nonce]) (2.5.10)
       computed by the TPC-PY PRB placed (5.4.9), executed, never
       reasoned. Right: TPX records EXECUTED with the declared location.
       Wrong or missing: TPX records REASONED and refuses every value
       that push presents (4.2, row 56). TPC-PY refuses a nonce in any
       other form without echoing it; the nonce arrives as untrusted
       input (6.2). The challenge attests execution of code that
       reproduces TPC's digest; it attests neither which code nor that
       each presented value came from it, which recomputation at landing
       covers (5.3.9). Location and versions are self-reported and
       consumed by no rule. C-19 gains this item. [D101.1] [D190.1]
5.3.20 THE SERIALIZATION (D99.1). TPX serializes every zone under
       2.5.11 with TPC-PHP, computes the zone digests over the canonical
       preimage only, refuses a zone that does not parse (2.5.15) and
       applies the text-safety rule to every string of every write
       (2.5.13, 2.5.14). It publishes the schema version in force; a
       change of schema version moves every zone digest and is a
       declaration. PRB's side is 5.4.11. [D98.1] [D99.1]
5.3.21 THE GATE CHECKS (D106.1, D107.1, D108.1, D132.1). TPX runs the
       kernel tests and the isomorphism checks as each zone is entered
       and at the final pass in the order 5.5.2 fixes, with TPC-PHP; it
       holds an untied DOF as a named gap or refuses it under the TMS's
       IC2_POLICY (2.3.6); it refuses an entry on a REMOVEd DOF
       (CODOMAIN, 2.3.19); it runs T3 to S_MAX (2.2.3). What the
       declared form makes MECHANICAL is 2.2.12-2.2.18 and 2.3.14; what
       stays INSPECTION is 2.2.18 and is shown as such (4.2.10).
5.3.22 THE HOLD (D111.1). After a failed canary TPX computes hold_scope
       over the account's history in every UWC it worked, held_closure
       per register, allocates from its reserved range (3.1.11), writes
       the HOLD record (3.3.11), writes HELD into every listed record's
       status field (3.2.10), draws the review list of older
       same-snapshot work, newest first, not held, and sends the alert
       (5.18.3). At an eligible match it computes release_record
       (3.3.12), applies the hold-in-force check over every HOLD not yet
       fully released, writes the status back and writes the RELEASE
       record; on a mismatch or with no eligible reproducer it opens an
       audit block. It keeps the per-block canary pass record the scope
       reads (5.17.15). [D111.1]
5.3.23 TPX's SOURCE (D112.1, D125.2). TPX's executable source is held
       off-wiki in Git - a private repository in the hosting account's
       Site Tools with a mirror on H-OP's computer, one tagged commit
       per deployed build - and is not published. Every deployed build
       appends a BUILD CHAIN line carrying the commit fingerprint and
       the SHA-256 of the deployed tree (5.6.8); deployment is a
       checkout of a tag and a rollback a checkout of the previous tag,
       chain-recorded. Pseudocode of all of TPX, the canary generator's
       method included, is published; what stays unpublished is what is
       drawn at run time (the gradient's arm and parameters, the tier,
       burst and clock draws, the ratio and p_v epochs) and the suite's
       failure detail. TPC-PY stays published and holds no canary
       logic. Git is the record of the one artifact the wiki does not
       hold; the wiki stays the system of record (1.3). [D112.1]
       [D125.2]
5.3.24 PROBES (D118.1). TPX assembles every PACKAGE (5.17.4): the
       source UWC's TFK whole, its register in HISTORICAL VIEW as it
       stood immediately before the target record was allocated, its
       community view, and the derivation request restated from the
       target's ASSUMPTIONS and task, blind-phrased, naming no record;
       delivers it as work in that UWC through the input path (5.4.8);
       selects the source under the gradient and the sources P1-P5
       (5.17.6, 5.17.9) with the exclusions of 5.17.5; logs every
       serving of a record to an account through the buffer path, so
       NOT SERVED BEFORE is attestable (3.3.8); draws the ratio and its
       epoch (5.17.13) and applies the reset (5.17.14). [D118.1]
       [D120.1]
5.3.25 THE COMPARISON AND THE LEDGER (D119.1, D120.1). TPX compares
       every reproduction with its target (5.9.7), writes one COMMUNITY
       LEDGER entry per parrot (5.9.13), rebuilds each UWC's COMMUNITY
       VIEW at every landing, chains the ledger's content hash at every
       landing that touches it (5.6.9), writes a within-UWC MATCH as a
       corroboration record in the source register, a PARROT's from its
       reserved range and naming its TARGET, and a cross-UWC pass to the
       ledger only (3.3.4), writes RELEASE on a ledger MATCH by an
       eligible account under COMMUNITY PARROTS ACCEPT (3.3.15),
       computes the states of CR11 from pending non-corroborations and
       opens an audit block at DISPUTE COUNT under AUDIT TRIGGER
       AUTOMATIC (4.1.6). It never dispositions. [D119.1] [D120.1]
5.3.26 THE SCORES (D122.1, D123.1, D128.2a, D129.1). TPX keeps the
       reliability score of every account and every user (CR11, CR12):
       the evidence posterior, the score update at each RATING PERIOD,
       the events, the states, the trip, the inquiry cost, the trust
       tier, the override and the pad under their time lock, each a TPC
       function of recorded state; it writes the restricted score and
       user pages and serves INQUIRE. A confirmed violation cuts at
       once; a pending item updates nothing; a retuned tuning option
       applies from the next event and no score is recomputed from
       history. [D122.1] [D123.1] [D128.2a]
5.3.27 IDENTITY (D127.1). K_TPX is 32 bytes from the platform's CSPRNG
       at installation, in TPX's server configuration outside the web
       root, never on a page, in Git or in an unencrypted backup;
       per-purpose and per-agent keys by HKDF (RFC 5869; K_FP =
       HKDF-Expand(K_TPX, "TPX-FINGERPRINT-1")), the master key used by
       nothing directly; a per-agent 16-byte salt drawn at certification
       and stored in TPX's own table. FINGERPRINT = HMAC-SHA-256(K_FP,
       enc(["TPX-FINGERPRINT", "1", sponsor_user_id,
       sponsor_registration, agent_user_id, agent_registration, salt,
       cert_serial, cert_time])), enc the netstring encoding of 2.5.10,
       the registration times MediaWiki's user_registration of each
       account; 64 lowercase hex, cited in full on the dossier and the
       declaration line and by its first 16 hex as the CALL SIGN
       elsewhere. Out of the inputs: password hashes, the model
       snapshot, account names, anything the account supplies. KEY ID =
       HMAC-SHA-256(K_TPX, "TPX-KEY-ID") truncated to 16 hex, on the
       control panel and a BUILD CHAIN line. KEY ROTATION on the
       schedule (7.2) or on suspicion: TPX derives the new K_FP,
       recomputes every current fingerprint, writes "KEY ROTATION old-id
       -> new-id" to the chain and rewrites every dossier, the
       certificates unchanged; the runbook is owed. NEVER ACCEPTED: at
       PETITION, POLL, PUSH, VOLUNTEER and INQUIRE TPX resolves the
       authenticated user_id to its current certificate and fingerprint,
       refuses a caller with no current certificate, and stamps the
       fingerprint on every landing, ledger entry, HOLD, RELEASE and
       scorecard row naming the account (4.2, row 59). USER and AGENT
       are enforced at the agent API and the permission hook (5.13.6).
       THE DOSSIER, one page per account at "The Principia
       Machina/Dossier/<account>", is written by TPX and nobody else, a
       save hook refusing every other editor, the page's own account
       included; its content hash is chained at every rewrite; the agent
       dossier carries account, FINGERPRINT in full and the key id,
       sponsor, the certificate fields (serial, date, suite version,
       D(IS), execution mode as last attested, model snapshot as
       recorded, phase for the reference account), status (CURRENT,
       LAPSED, SUSPENDED, REMOVED), call sign and UWC history; the human
       dossier carries roles held, sponsored agents with call signs and
       certificate status, the count against AGENTS PER SPONSOR and UWC
       history; its non-public half is the restricted page "TPM
       Restricted:Score/<account>". A dossier is a view of chained
       facts, never a source. AUTOMATION LIKELIHOOD: a W1 job computes
       per user account, from what the platform logs (inter-request
       intervals and their regularity, edits per hour, the share of API
       against web requests, User-Agent, the daily activity profile), an
       advisory statistic shown on the restricted dossier and flagged on
       the scorecard above a threshold, H-OP deciding; never a verdict.
       CAPTCHA MODULE: ConfirmEdit with Turnstile on badlogin,
       QuestyCaptcha the local fallback, no visitor creating an account
       (5.2.7); a CAPTCHA buys cost, not certainty. The sponsor of a
       suspended or removed agent is notified, pointer only (5.18.13).
       TPC carries fingerprint(k, fields) and key_id(k) with test-key
       vectors; no agent holds K_FP, so TPC-PY fixes the encoding and
       computes no real fingerprint. [D127.1] [D224.1]
5.3.28 W1 (D125.2, D109.1). TPX's long work runs as Job classes on
       MediaWiki's job queue, run by runJobs.php from a host cron entry
       with time and job caps, the web path disabled ($wgJobRunRate =
       0) so no reader can cause TPX work by browsing; TPX executes the
       job, no authority moves and one build digest covers everything.
       There run: checks that outlast a request (T3 at depth, corpus
       runs, EL ranking, historical-view assembly); the schedulers
       (expiry, epoch and rotation draws, tier and burst state, resets,
       cool-offs, the override time lock, the ratio epoch); the rebuilds
       (ledger, community views, manifests); notifications; the
       automation-likelihood job; and the dead-man's switch's weekly
       ping (5.18.12). [D109.1] [D125.2]
5.3.29 W2 (D125.2, D133.1). A Node.js sidecar adopted for one role only, the
       LIVE CONTROL PANEL (5.12.8): it shows the GOVERNOR's state (the
       PRESSURE LEVEL, lane admissions, slot use, refusals by reason) and its
       own readings, and badge, lock, queue and state changes, to a browser by
       long polling, display only; it holds no verdict and no write, computes
       no TPC value, is no input to the GOVERNOR, reads only what ANY reads
       through a read-only status endpoint with its own credential, and
       carries its own build digest on the chain beside TPX's (5.6.8). It is
       never the sender of the switch's weekly heartbeat, which stays inside
       W1's job; it pings the switch's second check "TPM panel" for its own
       liveness at PANEL HEARTBEAT within PANEL GRACE (7.2), each process
       attesting only its own liveness. Nothing in the alert path or any TPM
       rule moves to it. If the host runs no persistent Node.js process (HC1),
       W2 is absent and the control panel is polled. Its persistence on the
       host and the service's check count are VERIFY (5.18.12). [D125.2]
       [D133.1]
5.3.30 THE TUNING OPTIONS AND THE VOLUNTEER ENDPOINT (D122.1, D126.1).
       A TUNING OPTION is a value H-OP sets in TPX's configuration;
       every value in force is displayed on the control panel, a per-UWC
       option on that UWC's panel and schedule log, and every change
       writes a BUILD CHAIN line naming the option, the old and new
       value and the account (5.6.9, 5.12.6). A declared parameter fixes
       what; a tuning option fixes how fast (7.2.20). TPX serves the
       VOLUNTEER op under 5.9.14-5.9.17: the token bucket, the
       full-jitter backoff and the random early throttle are TPX's, the
       draw a TPC function of recorded state and a supplied random
       value, and every answer carries RETRY AFTER (4.2, row 62). The
       ops of TPX's one Action API module, action=tpx, are PETITION,
       POLL, PUSH, RETURN, HEARTBEAT, RELEASE, VOLUNTEER, INQUIRE and
       STATUS; every op that changes state is a POST with a CSRF token,
       INQUIRE among them (5.4.10). [D122.1] [D126.1]
5.3.31 THE GOVERNOR (D133.1). The GOVERNOR is TPX code in the request path:
       TPX meters, admits by LANE and PRESSURE LEVEL, rates by SEAT and
       contains by TRAFFIC STAGE. W1's EXTERNAL READING, an HTTPS read of
       TPX's STATUS op through the public URL at each W1 run recording whether
       the host limits the site, is an input that can only tighten: a reading
       that shows the host limiting the site raises the PRESSURE LEVEL one
       step for 30 minutes and W1 pings the switch's fail URL (5.18.12); an
       absent or stale reading changes nothing. W2 shows the GOVERNOR's state
       by long polling, display only (5.3.29). The GOVERNOR updates itself
       lazily inside requests from its own tables, on the database's clock, W1
       running the same update at each run as a backstop; nothing
       time-critical waits on cron. It fails closed to the slot caps: with its
       tables unreachable, lanes 0-2 are admitted and lanes 3-4 run under the
       slots only; a GOVERNOR fault never refuses lanes 0-1 on budget. Its
       functions are TPX's own, not TPC: no agent presents their values; their
       law is published as pseudocode with vectors (5.3.23). [D133.1] [D134.1]
5.3.32 THE METER AND THE BUDGETS (D134.1). TPX meters every PHP request of the
       wiki and every W1 job: its lane, its account key (the FINGERPRINT for
       an AGENT, the user_id for a USER, the /24 or /64 network for an
       anonymous reader), its op, CPU from TPX's first hook to shutdown, wall
       time, peak memory, response bytes and landed bytes; anonymous requests
       may be sampled 1 in q (METER SAMPLE). Budgets slide over the hour, the
       day and 30 days, in CPU seconds: B_H1 = 4,000; B_H24 = min(40,000,
       800,000 / 31), which paces the month even in a 31-day month; B_H30 =
       800,000; the host caps VERIFY until read from Site Tools at build step
       3 (5.2.5). The ratio r = max over the three horizons of kappa_M x U_T /
       (sigma x B_T), U_T the metered use over horizon T, sigma 0.8 and
       kappa_M the calibration H-OP reads monthly against the host's own
       figure, is kept below 1. [D134.1]
5.3.33 THE LANES (D134.1, D155.1). LANE 0 OPERATOR: H-DECL, H-OP and W1's
       essential jobs (the switch's ping, expiry work, the integrity check,
       the budget roll-up, the weekly exception check, and the HOLD and
       RELEASE records and withdrawals when they run as jobs). LANE 1 PEOPLE:
       USER accounts signed in. Neither is refused on budget. LANE 2
       FINISHING: the queue head's acquisition inside its window; POLL by the
       queue head or a holder; HEARTBEAT; PUSH, the bibliography's landing
       lookups inside it (5.21.14); RETURN; RELEASE; INQUIRE; debited and
       never refused on budget, rate, pressure or share. LANE 3 STARTING:
       PETITION, POLL, STATUS and core API reads by AGENT accounts. LANE 4
       OPTIONAL: VOLUNTEER and a falcon RETURN, D126.1's bucket unchanged
       beneath it. LANE 5 BACKGROUND: W1's deferrable jobs, TPX's falcon
       jobs and the bibliography recheck job (5.21.18). LANE 6 ANONYMOUS:
       readers and crawlers. SLOTS: agent lanes
       together 6, two kept for lane 2, so lanes 3 and 4 together hold at most
       four; per sponsor 2; per agent 1; anonymous expensive actions by
       PRESSURE LEVEL (7.2.24). HOLD and RELEASE records and withdrawals are
       written whatever the level, inside the lane-2 request that causes them
       or as lane-0 jobs. [D134.1] [D155.1] [D172.1]
       AMENDED (D176.1). LANE 2 carries, inside the PUSH, EOM-0's
       settlement check (3.3.16); LANE 3 carries the op STRUCTURE_TEST
       (5.3.47); LANE 5 carries the structure-test job; the control
       panel's button is a LANE 1 request of a signed-in USER. The
       LANE TABLE reads so (7.2.30). [D176.1]
5.3.34 THE PRESSURE LEVELS (D134.1). CLEAR below r 0.60, BUSY from 0.60,
       STRAINED from 0.75, OVERLOADED from 0.90; a level is left only when r
       falls 0.05 below its entry threshold. Admission by level, lane 6's
       entry the anonymous expensive-action slots (OVERLOADED serving cached
       pages only):
       LEVEL       LANE 0  LANE 1  LANE 2  LANE 3  LANE 4  LANE 5  LANE 6
       CLEAR       yes     yes     yes     yes     yes     yes     slots 6
       BUSY        yes     yes     yes     yes     no      yes     slots 3
       STRAINED    yes     yes     yes     no      no      no      slots 1
       OVERLOADED  yes     yes     yes     no      no      no      cached
       The level is published in STATUS, as a pseudo-lag through ApiMaxLagInfo
       (CLEAR 0, BUSY 3, STRAINED 6, OVERLOADED 30 seconds) and on the control
       panel. [D134.1]
5.3.35 ADMISSION (D134.1, D136.1). The PRE-GATE, a PHP file run before
       MediaWiki loads (HC11), compares the account name a User-Agent carries,
       and the client network of a request without a session cookie, with a
       deny list TPX writes atomically (CONTAINED accounts; anonymous networks
       over their cap, 5.3.40) and answers 429 with Retry-After; RELEASE and
       INQUIRE pass it under the FLOOD INTERVAL (5.3.37); it only tightens,
       the GOVERNOR behind it deciding when the list is missing. Then, per
       governed request, the first refusal ending it: GA0 METER START; GA1
       SHAPE (body length and parameter shape before any parse; 400, a TE4);
       GA2 SWITCHES (AGENT STOP, CONTAINED, SUSPENDED under CR6 or CR11; 403
       with the reason; STATUS, RELEASE and INQUIRE pass); GA3 TRAFFIC (the
       traffic breaker open; 429 with the time remaining); GA4 PRESSURE (the
       lane against the level; 503); GA5 RATE (GCRA on seats, sponsor first,
       then agent; lane 2 debited and never refused; 429 with the time to
       conformance); GA6 SLOTS (the agent's slot, its sponsor's, the lane
       pool; 503 with a short Retry-After); GA7 CONTENTION (5.3.36; 429); GA8
       IN THE OP (D126.1's VOLUNTEER bucket; the op's wall-time budget); GA9
       METER END (the fleet meter debited with measured cost, the traffic
       counters updated, the refusal logged). [D134.1] [D135.1] [D136.1]
5.3.36 SEATS AND FAIR SHARES (D135.1). One share per sponsor, split equally
       among its agents. A SEAT is the declared cost of an op, never measured
       cost; the seat table is a tuning option (7.2.24). Seat rates are
       enforced by GCRA, sponsor first, then agent. At contention, in lanes 3
       and 4 only, when a lane's pool is full, the sponsor whose dominant
       share of that lane's seats and landed bytes over the last hour exceeds
       1 / (active sponsors) is refused first, agents within a sponsor sharing
       equally, weights equal; slot-seconds and measured CPU are not
       contention resources, so the rule never sees a probe's assembly. One
       request in flight per agent, two per sponsor. No admission or charge
       reads measured cost, so nothing the GOVERNOR returns depends on whether
       a response carries a probe (5.17.3). [D135.1]
5.3.37 TRAFFIC EVENTS AND STAGES (D136.1). TRAFFIC EVENTS, counted and
       attested by TPX: TE1 REPEAT (one REQUEST DIGEST more than REPEAT LIMIT
       times in 10 minutes); TE2 ERROR STREAK (ERROR STREAK consecutive
       refusals for account causes or failed requests; a 503 for pressure or
       slots never counts); TE3 BACKOFF VIOLATION (a request before the
       Retry-After TPX last gave the account); TE4 CAP OVERRUN (a request
       refused at GA1). Only TRAFFIC EVENTS move a TRAFFIC STAGE; statistics
       (a request rate against the account's own average; several accounts
       bursting from one network) are flags on the scorecard and the
       restricted dossier and move none. NORMAL. THROTTLED after TE1 or TE2:
       the traffic breaker opens, 429 with Retry-After from 60 s, one trial
       request after it, success closing it. PENALIZED after three TE3 in an
       hour or a second THROTTLED in an hour: the seat rate halved,
       Retry-After doubling from 60 s to 3,600 s, ending one hour after the
       last event. CONTAINED after ten TE3 in 24 hours or a third PENALIZED in
       24 hours: every op but STATUS, RELEASE and INQUIRE refused, HEARTBEAT
       among them, so a lock the account holds ends at its expiry; a decision
       item opened; the account listed on the PRE-GATE. THROTTLED and
       PENALIZED are TPX's and clear themselves; CONTAINED is set by TPX and
       cleared by H-OP on the control panel; removal stays H-DECL's. STATUS,
       RELEASE and INQUIRE pass at every stage, and RELEASE and INQUIRE at the
       PRE-GATE, each answered with the traffic breaker's Retry-After; a call
       before it is a TE3. A CONTAINED account's INQUIRE and RELEASE are each
       answered at most once per FLOOD INTERVAL, each answer carrying that
       Retry-After; an earlier call is refused 429, at the PRE-GATE when its
       User-Agent names the account and otherwise at GA2. Traffic counts and
       stage changes stand on the public dossier, the scorecard and the
       GOVERNOR's log, never in a reliability score; a TRAFFIC EVENT is not a
       CONDUCT EVENT (CR12). The red team exercises the stages in the
       sandboxes (5.13.5). [D136.1]
5.3.38 AGENT STOP AND GOVERNOR OFF (D136.1). H-OP's AGENT STOP, a fleet
       switch, refuses lanes 2-4 except STATUS, RELEASE and INQUIRE, so agents
       leave cleanly and INQUIRE returns; it stops the lock clocks (5.7.10).
       H-OP's GOVERNOR OFF returns admission to the slot caps alone. Each is
       logged and chained (5.6.13). [D136.1]
5.3.39 THE DATABASE LEVELS (D136.1). TPX estimates the DATABASE LEVEL at every
       landing from W1's last measurement plus the bytes landed since, and W1
       measures it at every run. At the first level (70 per cent of the cap) a
       new UWC needs H-OP's confirmation (5.5.10); at the second (85) no new
       block starts, and a block under way goes on landing; at the third (95)
       every agent write but RELEASE is refused, a started block's included,
       its work staying in the agent's local archive (5.4.3) to land in a
       later block once H-OP has acted: the one resource on which finishing
       work is refused. Inodes are counted by W1, 80 per cent flagged. The
       levels only buy time; the page rules (5.3.42) and the register growth
       plan are the remedy. [D136.1] [D140.1] [D141.1]
5.3.40 READERS AND CRAWLERS (D138.1). Cache, cap and pace; never deny. ER1:
       the host's anti-bot and AI-crawler block stay on, PRB identifying
       itself by User-Agent (HC10). ER2: anonymous HTML of pages outside TPM's
       state classes is sent cacheable for CACHE LIFETIME; state pages (the
       manifest and badge, the chain heads and volumes, the control panel, the
       lock, the collaboration page, dossiers, the community ledger and views,
       score pages) are never cached; signed-in users bypass the cache. ER3:
       anonymous expensive actions (history, diff, oldid, Special:Export,
       RecentChangesLinked, WhatLinksHere, search) run under lane-6 slots and
       are answered 503 with Retry-After in OVERLOADED only. ER4: robots.txt
       carries a Crawl-delay and disallows the expensive action URLs for
       crawlers that comply; a person can still reach them. ER5: H-OP's
       Blocked Traffic rule for a persistent abuser, the last resort. ER6:
       static files on the host's CDN. ER7: the ANONYMOUS NETWORK CAP, a /24
       or /64 whose metered anonymous CPU passes its hourly cap goes on the
       PRE-GATE list for one hour, for requests without a session cookie; a
       count, not a statistic. The parser cache on memcached serves readers
       outside the database (5.2.6). THE REVISIT MARK: when anonymous load
       passes half of the paced day budget on 7 days in 30, the scorecard
       flags it and a second vendor in front of the site is put to the user; a
       mark, not a rule. [D138.1] [D141.1]
5.3.41 THE SECURITY BASELINE (D139.1). The security list SEC1 to SEC60, as the
       governor analysis of 2026-09-24 numbers it
       (claude/tpm_governor_speculation_0_1_0.txt, section 8), its numbers
       kept, is a list of build-step-3 acceptance criteria: each is tested and
       listed on a public checklist page beside READ PATHS (5.18.11), and the
       admission form refuses while the list is incomplete (5.12.9). An
       integrity mismatch halts landings as a digest-gate failure halts
       writes, pending H-OP, and pings the switch's fail URL (SEC42; 5.18.12).
       The upgrade to PHP 8.4 and MediaWiki 1.46 precedes build step 3
       (5.2.6). [D139.1]
5.3.42 THE PAGE RULES (D140.1, D141.1). TPX keeps every page class that grows
       in pages of bounded size: register volumes of VOLUME SIZE records with
       VOID lines (3.1.12-3.1.14); BIBLIOGRAPHY VOLUMES of BIBLIO VOLUME SIZE
       entries, kept like the register with status lines and not as an
       APPEND VOLUME class, the one exception to the next rule (5.21.22);
       APPEND VOLUMES of VOLUME SIZE entries, frozen when full, for every
       other page class TPX grows by appending (the BUILD CHAIN, the
       DECLARATIONS, the community ledger, the FALCON LOG, the schedule and
       work-block logs, dossier and collaboration history, community views),
       each chain under a CHAIN HEAD (5.6.10), a dossier, a community view
       and the collaboration page each a current page plus APPEND VOLUMES of
       its history; the MANIFEST TREE (5.11.11).
       ONE WRITE PER PAGE PER LANDING: TPX batches a landing so each page is
       saved at most once, and writes nothing when the text is unchanged.
       STATE IN TABLES: heartbeats, counters, seats, readings and liveness
       live in TPX's tables; pages record transitions (5.7.9). COMPRESSION,
       SEARCH AND VIEWS: revisions are compressed from before the first
       register page (5.2.6); register pages index a summary and machine pages
       nothing; the main cache is memcached, never the GOVERNOR's store; a
       reading view over records, ledger entries or chain lines is a TPX
       special page computed on demand, nothing derived stored beyond the
       volumes. Storage is reclaimed only by compression, never by deletion.
       [D140.1] [D141.1] [D173.1]
5.3.43 THE CLUSTER, FALCON AND SPONSOR DUTIES (D142.1-D166.1). TPX's W1 job
       fetches, validates, filters, computes and publishes the top performer
       page each month, and TPX runs the CLUSTER LOOKUP, the mark, the weekly
       notice and the gate, as 5.19 states; it issues, draws, delivers,
       validates, compares, quote-checks, reconciles, presents for approval,
       applies and logs falcons, as 5.20 states; it checks D(PROMPT), refuses
       on FAMILY, MODEL and PROMPT, keeps the IDENTITY RECORD, counts the
       sponsor stage, calls the once-only promotion after a landing, serves
       the sponsor wizard and sends the one-time message, as 5.14.4-5.14.13
       state. [D142.1] [D148.1] [D156.1] [D157.1] [D158.1] [D162.1] [D163.1]
       [D165.1] [D166.1]
5.3.44 THE BIBLIOGRAPHY DUTIES (D170.1-D173.1). TPX creates a UWC's first
       BIBLIOGRAPHY VOLUME under a setting ON, at instantiation or on the
       later declaration; allocates each BIB ID on the BIBLIO MARK; runs the
       write check before save; looks each identifier up under the REGISTRY
       DECLARATIONS inside the landing job, fetching under 5.19.3's guards
       with the declared PACING and TIMEOUT and the CONTACT value from its
       configuration, parses each payload into a REGISTRY RECORD, compares
       with TPC and writes the CHECK LINE and the NOTICES LINE; issues FK-20
       with the served records; runs the recheck job as W1 work in LANE 5
       under the bounds; serves the LITERATURE VIEW and the reading view;
       re-runs the lookup for the HOLD record's bibliography list after a
       failed canary; carries entries under COPY-FORWARD; and refuses a
       LITERATURE member that is not a landed entry, as 5.21 states. The
       registries' published rates are kept as PACING; their contact
       parameters live in TPX's configuration, never on a page. [D170.1]
       [D171.1] [D172.1] [D173.1]
5.3.45 THE PROMPT DUTIES (D182.1). TPX records, from CAPABILITY at
       petition and on every push, the HARNESS MODE, the PROMPT MANIFEST
       and the SESSION LOG HEAD in its table and on the account's
       restricted page (5.8.12, 5.13.2), none a refusal criterion but
       the mode; refuses a petition or push whose HARNESS MODE is
       EXTERNAL, outside the synthetic UWC and the sandboxes, with the
       reason HARNESS (5.4.17); generates, delivers and scores the
       CONFORMANCE PROBES and keeps the CONFORMANCE STRATUM (5.17.18);
       runs the configuration-strata job as W1 work in LANE 5 and writes
       its pages (5.18.17); writes the PROMPT HEALTH section (5.18.16);
       and publishes in STATUS the tuning options PRB reads (SESSION
       BLOCK CAP, SESSION TURN CAP, RE-ANCHOR; 7.2.29), which PRB's code
       reads and never places before the model as instruction. [D182.1]
5.3.46 SANDBOX TRIALS (D182.1, D184.1). At the REVIEW POINT (7.2.16) and
       monthly, H-OP reads the CONFIGURATION STRATA and states
       hypotheses; a hypothesis is tested only in a SANDBOX TRIAL: the
       red and blue team accounts (5.13.5) work the same packages in the
       synthetic UWC and the sandboxes under configuration arms drawn at
       random (for example RE-ANCHOR on or off, SESSION BLOCK CAP 1 or
       10, memory on or off, one implementation text or another in the
       SPONSOR ZONE), the arm recorded with every push. In a trial, and
       nowhere else, PRB may run a profile or a zone outside 5.4.16 and
       5.4.17, and TPX accepts HARNESS MODE EXTERNAL. A confirmed effect
       changes a PRB default through a tuning option (7.2.29) or the
       SPONSOR GUIDE; it changes no rule, and no stratum or trial result
       is consumed by a rule. D184.1's comparison of a short
       implementation with the program's development implementation is
       such a trial. [D182.1] [D184.1]
5.3.47 THE STRUCTURE CHECK AND THE LATER TEST (D176.1). TPX runs the
       structure check and computes the class at the final pass (2.2.20,
       5.5.3) and keeps EOM-0 (3.3.16). It runs the STRUCTURE TEST WITH
       REGISTER, TPC eom_register_test, a pure function of the TFK and
       of the standing records whose declared form carries a ROLE, a
       record standing when its status word is PROVISIONAL or
       ESTABLISHED (SR2, 3.2.10): the analysis of 2.2.20 with each such
       record's law added by its ROLE, returning the EOM MAP, the
       findings, the record identifiers used and the UNDER unknowns of
       the TFK alone that the records now determine. [D193.2]
       WHEN. (i) After every landing that adds such a record or
       changes the status of a record the last result used, as a W1
       job in LANE 5. (ii) On request: the UWC's lead by the op
       STRUCTURE_TEST of action=tpx in LANE 3, TPX running the test
       inside that request (5.4.22); H-OWN or H-DECL by a button on
       the UWC's control panel, a LANE 1 request of a signed-in USER,
       the agent API refusing a USER (5.13.6). (iii) While EOM-0 is
       OPEN, as its settlement check inside the PUSH, in LANE 2
       (3.3.16).
       THE LINE. TPX writes the result as the STRUCTURE TEST LINE on
       the control panel and the manifest: "STRUCTURE TEST <date>
       <result> WITH <identifiers>". The result is "structurally
       regular with register" by 2.2.20's rule for the class read over
       the TFK and the records, else FINDINGS followed by every finding
       class and every line that stood in the way, in 2.2.20's order;
       the identifiers are sorted by prefix, then number, "-" when
       none. Until the first run the line reads "STRUCTURE TEST none".
       It is rewritten only when it changes; a rewrite outside a
       landing is a status write, one save per page, nothing written
       when unchanged, the manifest's path and the badge's MANIFEST
       REVISION rewritten with it (5.21.19's pattern). When a record
       the line used stops standing, TPX marks the line LAPSED in the
       same write that sets that status and queues the re-run at once;
       a lapsed line is never read as a result.
       INFORMATION. The line changes no class (2.2.20), opens no EOM-0
       on its own, strikes, holds or regrades no record and opens no
       audit block; H-DECL may open one. Under STRUCTURE_CHECK OFF it
       runs the same way, information only.
       The test reads the standing records whose declared form carries a
       ROLE (3.3.16) and its line names them; a settling record without
       a form is the lead's INSPECTION. [D176.1] [D198.1]
5.3.48 THE ENVIRONMENT MODULE DUTIES (D178.1). TPX serves the interview
       on the new-container form and in the DRAFT UWC API alike,
       recording each round's CATALOGUE STATE from its own state; keeps
       the author's own entries apart from the expansion and expands
       with TPC-PHP; asks the delta question, runs interview_check
       before the final pass and within it, and refuses a new claim of a
       version not OFFERED; renders the check page from the stored draft
       and returns its summary to the API; re-expands MODULES USED at
       the final pass and refuses a mismatch; writes each MODULE
       DECLARATION from its declaration form with the digest it
       computes, refusing an act the CATALOGUE STATE refuses; serves the
       modules page and runs module_check before the form accepts MODULE
       ADD or MODULE VERSION, recording H-DECL's atomicity answer once
       per version and each SHARED PARAMETER answer; writes the
       ENVIRONMENT MODULE pages and the proposal pages; shows each
       claimed version's status on the check page, the staging page and
       the control panel and puts the gate questions to H-DECL; and
       serves the MODULE USE VIEW; as 5.22 states. The proposal op's
       lane awaits declaration (7.2.32). [D178.1] [S48] [S51]
5.3.49 THE REGISTER DUTIES (D192.2-D202.1). TPX runs record_check at the
       stage LANDED on every keyed record and writes its fields (GRADE,
       STATUS UNMARKED, BLOCK, AUTHOR, LANDED_BY, LANDED, VETTED_IN,
       TPS, D_IS, DIGEST); writes the MASTER and the instantiation gaps
       (5.5.4); writes each WITHDRAWAL with its cascade in the same
       landing and STATUS REFUTED on a strike; writes the SR5 and SR7
       gaps and every STATE line; runs the promotion pass at each
       landing and writes the PROMOTION record; checks a VERIFICATION's
       order and recomputes its DIFFERENCE; computes CONDITIONS; runs
       settlement_check inside the PUSH; writes, at COPY-FORWARD, each
       inherited record at its landing grade and one WITHDRAWAL of cause
       INHERITED per inherited REFUTED or WITHDRAWN record (3.4.2); runs
       reaudit_scope and the batch re-promotion at a successor's first
       CAC; serves the reading view with each record's current grade and
       STATUS, the GAP VIEW and the ENTRY VIEW, computed on demand and
       stored nowhere; publishes schema_json beside the table. [D192.2]
       [D193.2] [D194.1] [D196.1] [D199.1] [D200.1] [D201.1] [D202.1]
       [D215.2]