5.9 Landing, work blocks and post-refusal (TPS 0.1.0)

Instruction artifact, machine-optimized text: TPS 0.1.0, page 5.9 Landing, work blocks and post-refusal. Part of TPS 0.1.0 and the TPM hub. Human-only edit (TPS 5.13). Version 0.1.0, proposed, revision 2; declaration pending. Governing section: this page, TPS 5.9. The text below is this page's unit of the TPS 0.1.0 artifact, verbatim; the whole artifact and its file digest are on The Principia Machina/TPS 0.1.0. Human readers: the contents page is the map.

TPS 5.9  LANDING, WORK BLOCKS AND POST-REFUSAL
purpose: the work block; the schedule log states; the block ID as
         fencing token at landing; expiry and recommission; the
         corroboration record; the post-refusal procedure; the comparison
         criterion per TMS, owed
governs: 5.9 | version: 0.1.0 (proposed) | class: instruction artifact
audience: operator, agent

5.9.1  Staging lives on the session side: the local inventory of the
       local working instance (see 5.4.3). At each landing a work order
       is closed out and the register updated. [B-11]
5.9.2  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 (see 5.12). [B-11] [I-042]
5.9.3  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. [B-11]
5.9.4  A block is EXPIRED when server time passes its ETA. The control
       panel mark is display only and does not wait for a push. Partial
       results stay in the local instance tagged UNCOMPUTED with kind of
       block. Recommission issues a new block ID with a back-pointer.
       [B-11]
5.9.5  Landing rejects any result carrying an expired block ID; the block
       ID is the fencing token. [B-11]
5.9.6  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
       (see 3.3.4). [B-11] [C-13]
5.9.7  POST-REFUSAL PROCEDURE. [B-35]
       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 (see 6.3) naming which result stands
          and how the other is dispositioned. Match: 5.9.6.
       OWED: the comparison criterion for step 4 and the threshold that
       turns a difference into an audit request, per TMS; kind:
       convention; C-04.
5.9.8  The landing API refuses a push whose grant number is below the
       current grant or whose holder is not the pusher (see 5.7, 4.2 row
       6). [I-081]