R12 Dual-Provenance Carry-Motor Recovery Preregistration

Status: CPU/H100 execution NO-GO. Local CPU tests and static review are the only authorized actions. No recovery plan job, fit, development evaluation, confirmation generation, or confirmation evaluation is authorized until a fresh independent hostile reviewer returns exact-byte GO for this document and the other three recovery files. The review must be published as the immutable receipt required by the recovery executable. This document is not a capability claim.

1. Purpose and frozen upstream lineage

The sole purpose of this protocol is to recover the already preregistered carry motor fit from a mechanical Python/JSON representation defect without claiming that new executor code produced the upstream plan or feature tensors.

The immutable upstream identities are:

source commit: a0c258e6709766c643cf127a429a7d6ef4a4211b
source-manifest SHA-256: 9ae61e1a3e8f672a71a01edc16e6a5f1f8f3c69f49afd5e97f41c6cde15350a9
canonical plan SHA-256: 1b845d47f6875df571169efb5adb0716dfbc5d266a2499e4a92451351a262b6d
confirmation-commitment SHA-256: 1ee32e4e2e8f9eb56026b7b8de1fdff207e9fd3694e0ae354f103d58ebb820da
fit-row SHA-256: 6517b1ff3aa557e449a2eef9c5540c3d5f8699482d933d5c320b606adb4a0f1b
canonical board SHA-256: d6282610ba845b23ebe849efe574233bf657a50aea0a7edb901e9e1d95b24391

The eight immutable feature-shard receipts, in shard-index order, are:

4affa12434513ebe9587464ff38656abaaf7e47904d9db6ced252c3adea52a96
4731c1644703e26c1978ca1ec1ba80af7c173c5d9676ae68fbd04368f3b54c2c
e81639e68a838bfa6695be92f7c1333d100b2317c48fb2cf0d995f22a6e50a43
ae86ec1b70dca21d67849fc4be17ffec682472851735c3b9523292836a74e70f
ce5a151f89e20e774c7d37afc446ea026ec14a587c70fa614414f060f10a2144
f02d8221bf3a393566c279e27bf888fcbd1ef9ea17bdd33262472c898950ea83
009b83f0c2a70362654e3e3e4cad27d30f79f93f3bdd32d6ce3064695dd2b9db
8214d356288c56a116a3de753a8948a35f731d52c520fa906f4e31c1b0f14fb4

The upstream root artifacts/carry_motor/canonical_a0c258e6709766c643cf127a429a7d6ef4a4211b is read-only evidence. Recovery must require its root and shard directories to remain mode 0555, its plan and shard files mode 0444 and one-link, and its fit, development, and confirmation directories empty mode 0700. Recovery never writes, renames, links, copies, chmods, or publishes inside that root.

2. Observed failure and exact normalization proof

Job 692563 successfully replayed all eight shards and completed the frozen 2,000 treatment plus 2,000 shuffled updates. It then failed before publication because the generated in-memory board contained integer histogram keys while the JSON-loaded plan contained string keys. The prepublication fit directory remained empty.

An independent reconstruction from the exact tokenizer and episode bytes generated 65,536 rows with the frozen row digest. A recursive type-sensitive comparison found exactly these two differences:

[
  {
    "generated_key_type": "int",
    "generated_keys": [97, 99, 103, 105],
    "path": "board.prompt_length_histogram",
    "sealed_key_type": "str",
    "sealed_keys": ["97", "99", "103", "105"]
  },
  {
    "generated_key_type": "int",
    "generated_keys": [114, 116, 120, 122],
    "path": "board.token_length_histogram",
    "sealed_key_type": "str",
    "sealed_keys": ["114", "116", "120", "122"]
  }
]

The ledger SHA-256 is b43cb4a6fbfab97c659e8658f63185ae8b3dc1d8cce34089958d3b09df0593b6. All non-histogram fields, histogram counts, row order, labels, and values are type-strict equal. Strict finite JSON serialization followed by duplicate-key-rejecting parsing produces the exact sealed plan board and the canonical board digest above.

The sole allowed transformation is strict_json_round_trip_of_complete_generated_fit_board. It has zero permitted semantic changes and zero additional transformations. A count change, extra key, non-histogram difference, bool/int or int/float alias, duplicate JSON key, or a third type difference fails closed.

3. Dual provenance

The recovery lineage has two noninterchangeable source identities:

Upstream protocol source. The exact a0c258e source contract recorded by the sealed plan and every shard. This identity owns the board, features, labels, controls, fit mathematics, confirmation commitment, and frozen scientific semantics.
Recovery executor source. A later reviewed Git commit containing exactly this preregistration, train/causal_carry_motor_recovery.py, its tests, and its Slurm wrapper. This identity owns only binding, strict board normalization, recovery validation, and v9 publication.

Runtime requires HEAD to equal the recovery commit, a clean checkout, exact working bytes equal to git show, and an exact manifest over those four files. The recovery commit must have the full a0c258e commit above as its sole direct parent. git diff --name-status --no-renames between those commits must be exactly four additions: this preregistration, the recovery executor, its test file, and its wrapper. A modified baseline file, fifth file, rename, merge, grandchild, extra commit, untracked file, or module shadow fails closed. Every loaded recovery, upstream, and model module must resolve to its exact reviewed path. Both wrapper and executor compare every non-.git filesystem leaf against git ls-files; ignored files are not trusted as clean, so an ignored sitecustomize.py or package shadow also fails before executor import. Each of the four recovery sources must be Git mode 100644 and a one-link, non-symlink mode-0644 regular checkout file; hard-link aliases fail. Every imported upstream scientific dependency must still equal its bytes in a0c258e. Passing the old commit for modified code, PYTHONPATH substitution, monkeypatching, dirty checkout execution, or relabelling an old shard as recovery-produced fails.

4. Independent review gate

Before the recovery plan exists, a fresh independent hostile reviewer publishes one mode-0444, one-link hostile_review.json in the exact mode-0555 directory artifacts/carry_motor/recovery_reviews/review_${RECOVERY_COMMIT}. It has only:

audit causal_carry_motor_recovery_hostile_review_v2;
decision exactly GO;
the complete recovery executor source contract;
the complete pinned executor runtime contract;
the upstream plan SHA-256;
the complete normalization contract and sole allowed transformation; and
the frozen review claim boundary.

The receipt SHA-256 is supplied separately. A missing, writable, linked, aliased, post-source, wrong-commit, NO-GO, or expanded receipt fails before recovery planning or CPU/H100 execution.

The runtime contract fixes the launcher to /lustre/fs1/home/[redacted user]/shohin/miniforge3/bin/python and Git to the regular, non-symlink /usr/bin/git. It records the resolved interpreter identity and SHA-256, Python version, ABI, exact startup flags and sys.path, Torch and Tokenizers versions plus entrypoint identities and SHA-256 values, exact module paths, and the reviewed deterministic environment. Caller override of the Python launcher is impossible. PYTHONPATH is exactly the reviewed train directory; user-site and bytecode writes are disabled; hash seeding is fixed; thread counts and CUBLAS workspace are fixed; Python startup injection, LD_PRELOAD, and Torch deserialization override variables are forbidden. The same runtime is reconstructed and compared type-strictly before publication.

5. Immutable recovery plan

The exact recovery root is derived, not selected:

artifacts/carry_motor/recoveries/
  upstream_${UPSTREAM_PLAN_SHA256}_executor_${RECOVERY_COMMIT}/

It must not exist before publication. The planner validates and safely loads all eight upstream shards, independently regenerates rows, normalizes the board, recomputes the shuffled control, batch schedule, initial motor state, sentinel identities, and merged feature receipts, and then publishes one immutable causal_carry_motor_recovery_plan_v2 document. Its root is mode 0555; the plan is one-link mode 0444; and fit, development, and confirmation directories are empty mode 0700.

The recovery plan binds:

both source contracts and the hostile-review receipt;
upstream plan, commitment, generator, source, frozen-input, and all eight shard identities;
the complete normalization proof;
exact checkpoint step, dimensions, token IDs, board, row order, control, 2,000-update schedule, batch 512, rank 8, learning rate 0.003, weight decay 0.0001, seed, and initial state;
the upstream merged feature and teacher-metric hashes;
exact new recovery output paths; and
explicit safe deserialization behavior.

It also binds a complete upstream custody snapshot, not only content receipts. The snapshot covers the canonical root, plan, all eight shard directories and files, the empty fit/development/confirmation directories, and the confirmation commitment directory and file. Each entry records its exact lexical path, kind, device, inode, mode, link count, owner, group, size, mtime, ctime, closed world children, and file SHA-256 where applicable. The complete snapshot is reconstructed and compared type-strictly immediately before and immediately after artifact publication and again around final directory sealing. A same-byte inode replacement, mode change, new child in an empty directory, shard mutation, or directory substitution is fatal.

Any caller-selected alias, output under the old canonical root, changed budget, changed shard receipt, changed source, or extra transformation fails closed.

6. Safe deserialization

Checkpoint and shard tensor files are bound by exact lexical path, no-symlink open descriptor, inode/stat identity, and SHA-256 before deserialization. torch.load is called explicitly with weights_only=True inside a safe-global scope containing only torch.torch_version.TorchVersion, which is required by the already sealed runtime metadata. There is no unrestricted-pickle fallback. Both TORCH_FORCE_NO_WEIGHTS_ONLY_LOAD and TORCH_FORCE_WEIGHTS_ONLY_LOAD are forbidden ambient overrides.

7. Fit and publication

The reviewed H100 wrapper requires one visible NVIDIA H100 PCIe, four CPUs, Requeue=0, restart count zero, an exact clean recovery checkout, exact spooled wrapper bytes, the sealed hostile-review receipt, and the sealed recovery plan. The fit exposes no mutable optimization flags. It uses the plan's frozen values.

The executor replays and validates the eight upstream shards, fits treatment and shuffled arms from the same initial state and schedule, recomputes all retained teacher evidence and diagnostics, and passes the complete upstream v8 payload validator in memory. Before that legacy validator, a recovery-owned exhaustive validator checks every legacy payload field with exact Python types. It rejects bool/int, int/float, mapping-subclass, state-container, tensor-subclass, fit-report, diagnostic, and nested evidence aliases; requires finite float loss and accuracy fields; recomputes the expected teacher evidence; and asserts that its field-coverage set equals the complete frozen legacy schema. It never publishes a v8 object. The sole output is causal_carry_motor_fit_v9_recovery, with top-level recovery status, both source domains, upstream plan and shard receipts, normalization proof, deserialization contract, and a headerless scientific fit payload. A top-level canonical field or v8 audit is forbidden.

Publication is recovery-owned and descriptor-bound. With the exact mode-0700 fit directory open by descriptor and proven empty, the executor creates the final leaf motor.pt directly using O_CREAT|O_EXCL|O_NOFOLLOW at mode 0600. It serializes to that same descriptor, flushes and fsyncs, verifies the linked name is the same one-link inode and the directory has no second child, hashes through the descriptor, then chmods and fsyncs the same inode to 0444. There is no staging path, rename, hard link, upstream atomic helper, or replace operation. It safe-loads and fully revalidates the published v9 object before descriptor-sealing the one-file fit directory to mode 0555. The upstream custody snapshot must remain exactly unchanged around both operations.

The fit directory has exactly four accepted states: empty mode 0700; one mode-0600, one-link motor.pt in mode 0700 after interruption during direct serialization; one mode-0444, one-link motor.pt in mode 0700 after a crash immediately after publication but before directory sealing; or the same sole artifact in sealed mode 0555. The exact executor removes only the closed-world mode-0600 interrupted leaf and fsyncs the directory before retry. It may seal the mode-0444 crash-recoverable state only after safe-loading and fully validating the v9 bundle and re-verifying the runtime, recovery plan, hostile review, upstream plan, confirmation commitment, frozen inputs, every shard binding, and full upstream custody snapshot. Any second link, staging child, other mode, child, filename, or substituted directory fails closed.

8. Threat model

The fail-closed boundary assumes an attacker or accidental operator may supply an aliased path, dirty checkout, wrong commit, merge or grandchild commit, additional committed or untracked file, shadow module, alternate interpreter, unsafe environment, modified review receipt, same-byte inode substitution, linked or renamed artifact, partial serialization, crash after publication, type-aliased Python payload, changed budget, changed board, changed shard, additional normalization, old-root output, or replacement confirmation generator. The executor must detect these before making or sealing a claim.

The protocol does not claim protection against a compromised kernel, root user, storage firmware, Git or Python binary whose bytes change after their final descriptor check, malicious CUDA hardware, SHA-256 collision, or a dishonest independent reviewer who deliberately signs the exact bad source/runtime. Those are explicit trust roots. Network availability is irrelevant because execution uses no network source. Recovery code has no authority to regenerate or inspect the confirmation secret and no authority to reinterpret a fit as capability.

9. Downstream boundary

This commit designs fit publication only. Development and confirmation recovery must receive separate preregistration and hostile review before implementation or execution. Any future confirmation path must keep the exact a0c258e confirmation generator source contract from the pre-fit commitment and record a separate recovery evaluator source contract. Recovery executor code may not substitute itself as the secret-derived board generator.

No fit result, teacher-forced accuracy, development score, confirmation score, mechanism conclusion, autonomous capability, or reasoning claim is established by this preregistration.

10. Required CPU gates before review

The exact recovery source must pass:

normalization success with exactly two frozen key-type differences;
rejection of non-histogram, count, extra-key, duplicate-key, and scalar-type rewrites;
path alias, symlink, receipt, shard, source, and executor substitution tests;
sole-parent/four-addition history, extra-file, grandchild, and shadow-module rejection tests;
pinned-interpreter, package-entrypoint, startup-flag, and environment tests;
complete upstream custody snapshot tests, including all empty directories, modes, and same-byte inode replacement;
frozen-budget, old-root output, and extra-transformation rejection tests;
confirmation-generator substitution rejection;
explicit weights-only/TorchVersion loading and ambient-override rejection;
immutable closed-world plan publication tests;
direct no-replace publication, interruption cleanup, immediate-post-publish crash recovery, and no-staging/no-two-link tests;
exhaustive legacy payload scalar/container type-alias rejection tests;
v9-only dual-provenance schema tests;
warning-clean CPU Pytest, Ruff, Python compilation, bash -n, and whitespace checks.

Passing these local CPU gates does not change CPU/H100 execution status. Only a fresh independent exact hostile-review receipt changes the recovery fit from NO-GO to eligible.