The Principia Machina/TPS/3.4 Inheritance under copy-forward

Instruction artifact, machine-optimized text: TPS, section 3.4 Inheritance under copy-forward. 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 3.4  INHERITANCE UNDER COPY-FORWARD
purpose: inherited records as fresh allocations, PROVISIONAL, REFUTED
         kept; back-pointers; promotion by re-derivation; batch
         re-promotion at a successor's first CAC when its D(TPK) and
         D(TrM) equal the source's; ENVIRONMENT MODULE claims carried
governs: 3.4 | version: 0.5.0 (proposed) | class: instruction artifact
audience: operator, agent

3.4.1  COPY-FORWARD is a standing Public Recorder operation: source
       container to new container, new UUID, new prefix, each inherited
       record landing PROVISIONAL (NOT GRADED kept), INHERITS naming its
       predecessor, and STATUS not inherited, the record landing
       UNMARKED; a predecessor's REFUTED or WITHDRAWN grade is kept by a
       WITHDRAWAL of cause INHERITED (3.4.2) (D5). Offered on a change
       request against the TFK or on a digest-gate failure (see 5.5,
       2.5). [I-040] [D193.2] [D215.2]
3.4.2  Inherited records enter as PROVISIONAL regardless of the
       predecessor's grade (NOT GRADED for a NOT GRADED class). A
       predecessor's REFUTED or WITHDRAWN grade is kept by the record
       that carries it: in the same instantiation, after the inherited
       records and before the badge, TPX writes in the successor one
       WITHDRAWAL of cause INHERITED per inherited record whose
       predecessor's current grade is REFUTED or WITHDRAWN, its
       status_set that grade, withdrawn_by the predecessor's full
       identifier, prior_status PROVISIONAL, still_stands and cascade
       empty (3.3.3); one of REFUTED also writes STATUS REFUTED in place
       (3.3.14). So REFUTED stays REFUTED and WITHDRAWN stays WITHDRAWN
       in the current grade. Promotion requires re-derivation under the
       new TPK, except the batch re-promotion of 3.4.6, where
       byte-identical inputs stand for re-derivation. [B-04] [D193.2]
       [D202.1] [D215.2]
3.4.3  Each inherited record is a fresh allocation in the successor's
       prefix; its INHERITS names the predecessor's full identifier; its
       BLOCK, AUTHOR, VETTED_IN, TPS and D_IS are the predecessor's,
       LANDED_BY is "TPX" and LANDED the copy's time. The list-form
       records stay in the source as its audit trail. [B-04] [D193.2]
3.4.4  A same-digest fork still enters PROVISIONAL (see 2.1.2). [I-061]
3.4.5  Everything in the successor belongs to the new UUID; back-pointers
       are provenance, not binding. [I-060]
3.4.6  A retired predecessor's pages stay readable and its back-pointers
       resolve directly (see 5.11). [B-10]
       BATCH RE-PROMOTION (D202.1). At a successor's first CAC, when its
       D(TPK) and D(TrM) equal the source's, every inherited RESULT that
       was ESTABLISHED in the source at the copy and meets 3.2.12's
       conditions over the successor's register and TMS is re-promoted
       in one PROMOTION record (3.3.17), bottom-up to a fixed point (TPC
       repromote_batch); otherwise re-derivation as 3.4.2 states. A
       record the copy withdrew (3.4.2) was not ESTABLISHED in the
       source and is never re-promoted, and a candidate citing it fails
       3.2.12's conditions. [D202.1] [D215.2]
3.4.7  The re-audit scope rule for a successor's first CAC, TPC
       reaudit_scope, reads which zones and TMS parameters differ and
       returns the checks to re-run over the inherited records (see
       2.1.5, 4.1.9). [C-06] [D202.1]
3.4.8  ASSUMPTION RECORDS inherit as records do (see 3.4.2, 3.4.3); an
       inherited record's ASSUMPTIONS field cites the successor's
       identifiers for them. Each carries INHERITS and lands as any
       inherited record does, a WITHDRAWN predecessor's grade kept by
       its WITHDRAWAL of cause INHERITED (3.4.2). [D41.2] [D193.2]
       [D215.2]
3.4.9  ENTRIES UNDER COPY-FORWARD (D170.1 (e)). A successor of a UWC whose
       BIBLIOGRAPHY SETTING is ON or CLOSED is ON and inherits the
       bibliography first: each entry, in number order, is a fresh BIB ID
       in the successor's prefix with a back-pointer and its CHECK LINE and
       NOTICES LINE as they stand, not looked up again at the copy; every
       inherited record's LITERATURE is then remapped through the
       back-pointers (5.21.2). A successor of an OFF UWC takes the form's
       choice. [D170.1]
3.4.10 ENVIRONMENT MODULES UNDER COPY-FORWARD (D178.1 (g)). A
       successor's pre-filled draft keeps the source certificate's
       MODULES USED as CARRIED claims, whatever their versions' status
       now, each status shown and none updated by the machine; its
       author keeps or re-selects each, a new claim naming an OFFERED
       version (5.22.5, 5.22.14). The successor's certification fixes
       its claims anew (5.22.15). [D178.1]