Audit 05 — Optimistic-teacher pretraining and curriculum ordering for an NNUE evaluator

Role of this document. Independent read-only second opinion. No existing file was modified, no gameplay cohort was run, no protected or final seed was touched, and no new experiment, theory, or contribution record was registered. Every claim below is traced to source lines in this checkout or to docs/research/history.md. Where the corpus records a result only as task-record only, that label is carried through rather than upgraded.

1. The owner's hypothesis, restated precisely

In the owner's words:

training a model based on a large number of games where I provide an "optimistic long-horizon strategy" — something where I think of the best possible outcome and simulate it for an ML model, so it is unfairly biased toward the possibility of something working out favorably. I then want to balance that favorable bias with training on a lot of normal games where the odds are evenly placed. I think this "order of training input" might be relevant to placing the NNUE model weights in the right place, or perhaps another ordering function is better.

Formalised, this is two separable claims. They must be separated because the evidence treats them very differently.

H-order (the stated hypothesis, an optimization/initialization claim). Hold architecture, total example count, optimizer, learning-rate schedule, and total gradient steps fixed. Vary only the order in which examples are presented. Then there exists an ordering — specifically optimistic-first then fair — that reaches a better parameter basin, measured by held-out legal-sibling ranking, than (a) fair-only, (b) optimistic-only, or (c) the same examples in shuffled order.

H-pool (a distribution claim, implied but not identical). Adding optimistic/hindsight-generated states to the training pool improves the evaluator relative to a fair-only pool of the same size, regardless of ordering.

H-label (a target claim, implicit in "unfairly biased toward the possibility of something working out favorably"). The optimistic teacher's labels — outcomes realised on a favourable future — are a useful regression target for a public network.

Section 6 argues H-label is not merely untested but mechanically harmful under this game's objective, and that H-pool is the salvageable core of the idea. Section 4 establishes that H-order has never been tested here. Section 5 establishes that the diagnosed failures of prior work are not of a kind that ordering can repair.

2. Inventory

Read from source, not from doc summaries. "Shuffle" column answers: does the trainer reshuffle the whole example pool every epoch (which erases presentation order by construction)?

2.1 Oracle and hindsight sources

2.2 "Optimistic" sources — a naming correction

Finding. There is no "optimistic-data" teacher anywhere in the repository despite the directory name. The only best-case-future data generators are the perfect-information oracle and the hindsight planner. Recorded outcome for optimistic-phase-ntuple: after exactly 50M transitions, direct n-tuple play averaged 181,733.4 / 56.36 and the two-boundary representative-outcome search made it worse, 113,644.0 / 37.38, failing both Stage-A halves (history.md:4371-4382).

2.3 NNUE-family work

2.4 Mixed oracle/fair RL curricula

2.5 Retained assets

• artifacts/models/denoised-value/v1.bin — 141,780 bytes, SHA-256 c8090759f3719fea8eb350dc1adf59e8578e6a36c1e380001a74e2c9470ef2fc. The only retained model checkpoint in the repository.
• research/datasets/ contains only a README. Every corpus referenced above (the 477-root H200 panel bfda8ae3…, the 4,096-state oracle curriculum 0x8657ac0dc83c6041 / 0xc649f123fc0cc4b9, the D4 root-label file f61801ab…) lived under /tmp and is gone from this machine (verified: ls /tmp/drop7* returns nothing).
• Consequence: any experiment proposed here must regenerate its own data from a leased training range. No shortcut through retained corpora exists.
• roadmap.md:127 additionally states the 477-root panel is "reusable diagnosis, not fresh model-selection evidence" — so even if recovered it could not gate a new model.

3. Verdict on the key question: was training ORDER ever ablated?

Using the requested three-way distinction:

Evidence for the "no" on (c)

1. Every supervised trainer in the repository reshuffles the entire example pool at the start of every epoch. This erases presentation order by construction, and it is uniform across the corpus: structured-value-nnue.cpp:556-563, denoised-stochastic-value.cpp:751-758, nnue-value.cpp:1036-1038, d4-h200-sibling-nnue.cpp:1480-1486, curriculum-long-outcome-nnue.cpp:1355-1358 + :1387-1388, panel-value-nnue.cpp:1152-1158, phase-student.cpp:592-601, oracle-dagger/main.ts:628-635. There is no code path in any of them that presents a subset first.
2. The two multi-stage schedules that exist are DAgger data aggregation, not ordering arms, and each has exactly one arm. oracle-dagger/main.ts:760-790 runs oracle imitation, then collects student-visited states, then retrains on the union at half LR. phase-student.cpp:799-823 does the same shape. Neither has a comparator that shuffles the same union from the start, and neither varies which pool comes first. This is the closest structural precedent for H-order and it was never treated as a factor.
3. The one RL schedule that exists is a parameter-sharing switch, not a data order. optimistic-phase-ntuple.cpp copies pooled tuple weights into per-phase heads at 20M of 100M transitions (history.md:4307-4312) — one arm, frozen in a preregistered protocol (artifacts/protocols/optimistic-phase-ntuple/protocol.json).
4. Where a factor was deliberately ablated, it was capacity or samples, not order. scaled-long-outcome-nnue.cpp is the corpus's only clean single-factor learning ablation: 12 vs 48 hidden units at identical epochs, losses, optimizer, folds (history.md:3243-3251).
5. No trainer in the corpus runs multiple initialization seeds. Every one fixes a single network seed (e.g. d4-h200-sibling-nnue.cpp:516 kNetworkSeed, curriculum-long-outcome-nnue.cpp:80 kInitializationDomain). So even if an ordering effect had appeared, the corpus has no machinery to separate it from initialization noise. Any future ordering experiment must add this.

Conclusion. H-order is genuinely untested in this repository. It has not been rejected. A properly matched ordering ablation would be the first of its kind here, and its negative result would be a real, durable contribution. That said — see §5 and §8 — "untested" is not the same as "promising", and the reason it is untested is that no prior failure ever pointed at ordering.

4. Why prior oracle distillation failed — failure-mode classification

Classification scheme as requested:

• (i) representation / information gap — public features cannot express what the teacher used.
• (ii) distribution shift — the student visits states the teacher's data did not cover.
• (iii) sibling coverage / within-root discrimination — only the played (or too few) actions were labelled, or labels are too noisy to separate siblings at one root.
• (iv) objective mismatch — the fitted quantity is not the quantity that should govern the decision.
• (v) optimization / underfitting / bad basin — the model could express and the data could support the answer, but training failed to find it.

Counts

What this means for the owner's hypothesis — stated plainly

Curriculum ordering is an intervention on class (v). It changes which basin the optimizer lands in. It cannot create sibling labels that were never collected, it cannot add public information that the state does not contain, and it cannot change what quantity the loss is fitting.

Zero of the seventeen failures are class (v). Worse for the hypothesis, the two experiments that came closest to testing the initialization/basin idea both falsify it in the strongest available way:

• d4-h200-sibling-nnue.cpp:1199-1206 starts training at exactly fair D4 — the best known public policy, the ideal "right place" for the weights — and gradient descent walked away from it into a worse held-out ranking in every origin fold. If a better basin adjacent to D4 existed and were reachable, this arm would have found it.
• scaled-long-outcome-nnue.cpp (history.md:3227-3282) shows that the optimization is not starved: more data and more capacity made ranking worse, which is the signature of a label/objective limit, not a search-over-weights limit.

So: as literally stated, H-order does not address the diagnosed failure mode. A fair second opinion has to say that directly. The bottleneck in this corpus is that at a single root, the legal siblings' true long-horizon values are close together relative to the noise in any affordable label, and no amount of reordering the same examples changes that gap-to-noise ratio.

Two honest qualifications in the owner's favour:

• Class (i) failures 1, 2, and 10 are all oracle-target failures, and §6 argues they share a single removable cause — optimism in the label. Fixing that is a data-generator change the corpus has never made.
• The corpus has never trained any model on a pool whose state distribution is optimistic while its labels are fair. That is H-pool, it is untested, and item 8 of the oracle-manifold result (AUC 0.925 separating oracle from fair states on public features alone) says the two pools really do occupy different, publicly-visible regions.

5. Objective-alignment analysis — verified arithmetic

5.1 Verification against src/core/native/engine.hpp

Confirmed by reading the engine, not the docs:

So score = 17,000·(successful rises) + 70,000·(clears) + Σ_waves popper_count·floor(7·d^2.5).

5.2 What fair D4's 308,295.578 mean is actually made of

At 90.031 mean moves, the number of successful rises per game is between 17 and 18 (a game usually dies at a rise attempt, which forfeits that bonus):

Even the generous bracket puts at least 93.7% of D4's score in a term that is a pure step function of how long the game lasted. Chain scoring is nearly irrelevant: at D4's recorded ~2.04 numbered clears per move, a residual of ~19,300 over 90 moves is ~214 points/move, consistent with typical waves at depth 2–4 plus occasional rise-continued deep waves.

Score in this game is, to first order, a relabelling of survival. To reach a 1,000,000 mean you need ≈ 58.8 successful rises, i.e. ≈ 294 mean moves — about 3.3× D4's lifetime. Board clears are the only alternative currency (70,000 each ≈ 4.1 rises), and the corpus contains no measurement of D4's board-clear rate at all; the residual above bounds it at well under one clear per two games. That absence is itself a cheap, unclaimed measurement.

5.3 Consequence for the NNUE target — argue for hazard, not score

1. Raw score is a heavy-tailed affine encoding of a bounded quantity. status.md:106-107 already warns "Score is heavy-tailed. One million-point game can coexist with a much lower average." Regressing raw score spends capacity on a 70,000-point jackpot that contributes < 7% of the mean and carries almost all of the variance.
2. The corpus's own head-by-head results say survival is learnable and score is not. In scaled-long-outcome-nnue the survival head reached r = 0.855 / 0.849 while the return-residual head was r = 0.350, downside 0.325, variance 0.139 (history.md:2702-2704, 3260-3266). In denoised-stochastic-value the survival heads hit AUC 0.920/0.809 with ECE 0.021/0.006 (history.md:455-461). Every strong head in this repository is a survival head.
3. Therefore the target should be a per-rise hazard vector, not a scalar: h_j = P(survive rise j | public state, action) for j = 1…8 (≈40 moves), with expected rises Σ_j Π_{k≤j} h_k as the derived decision scalar and clear probability as a separate low-weight head. This is a strictly better-posed version of what curriculum-long-outcome-nnue.cpp:56-61 already blends into a single scalar (kBalancedSurvivalWeight = 0.45, kBalancedScoreWeight = 0.30, kScoreScale = 350,000) — the score component there is mostly re-encoding the survival component with extra variance.

5.4 Is the oracle's advantage (a) better choices, or (b) unavailable information?

This is the question that decides whether H-label can work at all. The corpus does not contain the clean decomposition, but it contains four independent measurements that all point the same way, and none points the other way.

Read together: the oracle's advantage is overwhelmingly type (b) — exploitation of the realised tape — with a genuine but non-actionable type-(a) residue. The type-(a) residue is real and shows up as state quality (AUC 0.93+), not as action preference (top-1 0.218, root-prior loss).

Which is exactly the split the owner needs to know about:

• Optimism in the label (regress what happened on a lucky tape) is a type-(b) target. It is not a function of the public state, so a public network cannot fit it; the best it can do is fit E[lucky outcome | public state], which is a systematically upward-biased hazard estimate. And the bias is state-dependent — largest exactly on cluttered boards where a favourable reveal is what saves you. Pretraining on it installs survival overconfidence precisely where overconfidence is fatal. The corpus has already seen what that looks like: the topology-residual extension's confirmation failed by "catastrophic loss of several long baseline trajectories, including 476,511/285 → 139,399/90 and 329,049/200 → 74,172/55" (history.md:1466-1470).
• Optimism in the state distribution (train on boards the oracle reached, but label them fairly) is a type-(a) target and is legitimate.

The single missing measurement. Nobody has ever reported: what is the fair value of an oracle-visited state? The machinery to answer it already exists and is unused. oracle-curriculum.cpp re-scores each oracle state under 7 independent public-derived futures with fair D1 (:352-528), computes mean_moves, survival_rate, clears_per_move, reveals_per_move (:482-528), and even bands them (FlowBand::kBlocked when survival < 0.25, :531-537). It generated 4,096 states. The aggregate band distribution and mean fair-relabelled survival were never recorded anywhere — the ledger has no entry, and experiment-index.md:203 records only that "4,096 restart states were generated and privilege-isolation checks passed."

That number is the crux of the owner's whole idea and it costs about an hour to produce. If oracle states re-labelled fairly are barely better than phase/occupancy-matched fair-D4 states, the optimistic pool has nothing to teach and H-pool dies with H-label. If they are markedly better, the pool is worth pretraining on and the program is alive.

6. Proposed decisive experiment

Two stages. Stage D0 is cheap and can kill or license the whole program. Stage E1 is the first matched ordering ablation in this repository. Do not run E1 before D0 passes — that would repeat the corpus's most common process error (building a model before establishing that its label carries signal).

Stage D0 — Oracle advantage decomposition (tier CHECK/PILOT, ≈1–2 CPU-hours)

Question. Of the oracle's lifetime advantage over fair D4, how much survives when the realised tape is replaced by independent public randomness?

Method. Reuse, do not rewrite: oracle-topology-audit.cpp for exact matching on rise phase / occupancy / max height / 20-move band; oracle-curriculum.cpp:352-528 for public restart re-labelling with domain-separated streams (kRestartRevealDomain "CRRV", kRestartVisibleDomain "CRVS"); fair-only-horizon.cpp for the D1/D2 continuation.

Collect on a freshly leased training range (a new 0x3d… lease; the allocator must first import every historical range per benchmarks.md:47-50):

• pool O: states from oracle (depth 4 / beam 128) roll-ins, sampled from move 50 onward as oracle-curriculum.cpp:28 already does;
• pool F: fair-D4 states matched to each O state on rise phase, occupancy, and max height (this matching is what made the manifold discriminator honest).

Report four numbers plus split halves:

1. R_tape(O) — oracle's realised remaining moves on its own tape.
2. R_fair(O) — mean remaining moves of O states over K = 32 independent public futures under a fixed public policy (D1 for cost, D2 if budget allows).
3. R_fair(F) — same for matched F states.
4. R_real(F) — fair D4's realised remaining moves from F states.

Derived: transferable fraction τ = (R_fair(O) − R_fair(F)) / (R_tape(O) − R_real(F)). Also report the FlowBand histogram over O (oracle-curriculum.cpp:531-537) — the fraction of oracle states that are kBlocked under fair randomness is the single most interpretable output of this stage.

Also compute, at oracle-visited roots, an oracle-action sibling regret: evaluate all legal siblings under common independent futures and ask how often the oracle's chosen column is the fair-best sibling, versus how often D4's is. This directly tests whether the oracle's actions are a legitimate label at all, independently of any representation question.

Falsification. H-pool is refused if τ < 0.25, or if the split halves of the O pool disagree in sign, or if the oracle's action is fair-top-1 less often than D4's. Any of those means the optimistic pool teaches tape luck, not strategy, and E1 should not be run.

Cost. Oracle planning is cheap relative to D4: a depth-4 / beam-128 receding beam expands ≈ 7·128·4 ≈ 3.6k nodes per move against D4's recorded 1,351,113 work units per move (history.md:975-977). 2,000 O states × 32 futures × 25 moves ≈ 1.6M public-D1 transitions — the same order as oracle-curriculum.cpp's original run, which fit inside a 30-minute wall cap and 256 MiB (:35-36).

Stage E1 — Matched curriculum-ordering ablation (tier CHECK for gates, ≈1 CPU-day)

Run only if D0 passes.

Dataset (one generator, one manifest, shared by every arm). Roots split by whole origin game into 8 origin folds. At each root, label every legal sibling under 7 common event-keyed independent futures at H = 100, with the continuation policy fixed at completed public D2/s5 (the same choice scaled-long-outcome-nnue and public-regenerative-b0 made). Record per sibling:

• survival indicator at each of the next 8 rises → hazard vector target;
• mean remaining moves;
• clears and reveals per move;
• board-clear event count (rare; separate low-weight head);
• realised score (recorded for reporting, not used as the primary target — §5.3).

Two state pools of equal size:

• O: oracle-visited public states, fairly labelled — optimism lives in the state distribution only. This is the corrected form of the owner's idea.
• F: fair-D4-visited public states, matched on rise phase / occupancy / max height.

Target ≈ 10,000 roots (≈ 5,000 per pool). At ~5 legal siblings × 7 scenarios × 100 moves that is ≈ 35M synthetic transitions; scaled-long-outcome-nnue generated 2.0M in 779.7 s on 4 workers (history.md:3238-3241), which scales to roughly 1.5–2 hours on 32 threads. Halve the horizon to H = 50 if the projection gate says otherwise.

Model (frozen, identical in every arm). Reuse the training kernel in d4-h200-sibling-nnue.cpp — it already provides exact direct/reflected accumulator averaging, sparse categorical inputs (kCategoryCount = 509, :497), listwise + pairwise + pointwise + auxiliary losses (:511-515), whole-origin folds, checkpoint round-trip, and a frozen schedule comment at :504-505. The only new code is a data-order module plus the hazard head replacing the score residual head. Retain the exact-zero primary head initialization (:1199-1206) so that an untrained arm is exactly D4.

Arms. Identical dataset, identical total gradient steps, identical LR schedule shape, identical batch composition size. Only presentation order varies.

Seeds. ≥ 5 network-initialization seeds per arm — 35 training runs total. This is non-negotiable and is the piece the corpus has never had: without it, an ordering difference cannot be distinguished from initialization noise. At the model sizes in play (12k–75k parameters, 16–48 epochs, 90–800 s single-core per run in the ledger) all 35 runs fit comfortably in a few hours on 32 threads.

Offline gate (whole-origin, all legal siblings, no gameplay). Per origin fold and per ordered origin half, against the fair-relabelled best-sibling target:

• top-1 accuracy (ties credited as in d4-h200-sibling-nnue.cpp);
• pairwise accuracy over every unordered legal sibling pair, ties at half credit;
• normalized regret;
• hazard-head calibration: ECE and Brier per rise index;
• scenario-half action stability (independent scenario splits must agree ≥ 70%, matching the martingale-dual-b0 and full-panel-cpi-preflight convention).

Falsification criterion for H-order (freeze before any metric is read). H-order is rejected unless the best ordered arm (A4, A5, or A6) beats the shuffled arm A3 by all of:

• ≥ +0.02 absolute pairwise accuracy, and
• ≥ 5% relative reduction in normalized regret, and
• a between-arm gap ≥ 2× the across-seed standard deviation within A3, and
• non-regression in ≥ 6 of 8 origin folds and in both ordered origin halves.

Additional named sub-conclusions, all recordable as valid results:

• If A4 > A3 but A5 ≈ A4, the effect is annealing, not optimism-first.
• If A2 ≈ A1 and A3 ≈ A1, then H-pool fails: the optimistic states add nothing, and ordering the same nothing cannot help.
• If every arm loses to A0 (fair D4 / exact D2), report that plainly. Given that no learned ranker in this corpus has ever beaten exact D2 or D4 on held-out sibling ranking, this is the modal outcome and it is still a publishable negative that closes the ordering question.

Hardware: does this need PyTorch on ROCm?

Verified on this machine: python3 -c "import torch" → ModuleNotFoundError. ROCm is present (/opt/rocm/bin/hipcc, /opt/rocm/bin/rocminfo, /opt/rocm/llvm/bin/clang++), plus system g++ and Node.

Recommendation: native C++, no PyTorch, no HIP.

1. The models are tiny. Every NNUE in this corpus is 3,937–75,395 parameters with 49–84 active sparse inputs per example. 35 training runs of that size are minutes of CPU, not GPU work. structured-value-nnue trained in 91.0 s at 9.28 MiB RSS (history.md:401-402).
2. The cost is data generation, and it is CPU-bound and irregular. Cascades, gravity, and variable legal-action counts are precisely what docs/hardware/amd-ryzen-halo.md assigns to the CPU ("Exact transitions and chain cascades → CPU: irregular control flow, tiny 7×7 state, exact integer semantics"). 16 cores / 32 threads is the right machine for this and the GPU would not help.
3. Installing PyTorch-on-ROCm would add unvalidated risk to a study whose whole point is a small controlled difference. gfx1151 support is stack-dependent; the hardware doc explicitly warns that "a detected GPU, a working display driver, and a supported ROCm compute stack" are not equivalent. Non-deterministic reductions would also break the corpus's determinism, exact-reflection, and bit-equal-checkpoint self-test conventions — and benchmarks.md:74-77 treats any change to floating-point action ranking as a new algorithmic candidate, not a speedup.
4. Note also that approaches/ntuple-rl/torch-ppo/ exists and its history entry (history.md:3764-3896, 3897-3989) is a chronicle of memory-ceiling aborts. The corpus's own experience with the PyTorch lane is poor.

Revisit GPU only for roadmap step 5's much larger distributional afterstate ranker, and then as the batched-leaf service prototype described in the hardware doc's Stage B — not for E1.

Process obligations (not performed by this audit)

Before E1: register one theory record with mechanism and falsification criteria, run make research-validate, obtain a seed lease that conservatively imports every historical range, preregister the experiment with cohort role and stop conditions, and write a machine profile via make research-doctor. Contribution records under research/contributions/ are required for anyone who materially contributes. This document is an audit and registers none of those.

7. Honest assessment

Is H-order, as literally stated, likely to work? No — perhaps 10%.

The reasoning is not "somebody tried it and it failed". Nobody tried it, and §3 says so plainly. The reasoning is that the mechanism does not connect to the diagnosed disease:

• 0 of 17 documented transfer failures are optimization/basin failures.
• The best conceivable initialization — the weights of fair D4 itself — was already the starting point of d4-h200-sibling-nnue (:1199-1206), and training moved away from it into a worse held-out ranking in every origin fold. "Placing the weights in the right place" was tested at its theoretical optimum and the optimizer left.
• The sample/capacity bottleneck was explicitly tested and refuted: scaled-long-outcome-nnue gave the model 5.24× the data and 4× the width and ranking got worse (history.md:3253-3266). Models that are already over-fitting a noisy within-root signal do not benefit from a better basin.
• Every trainer in the repository reshuffles every epoch over 16–260 epochs. In that regime, initial presentation order is largely washed out by construction. If the owner wants ordering to matter mechanically, the regimes where it plausibly could are (i) single-pass or very-low-epoch supervised training, and (ii) bootstrapped TD/RL where the target is non-stationary — which is exactly where the corpus's one real schedule lives (optimistic-phase-ntuple's pooled→phase-head switch). A many-epoch Adam fit on a fixed corpus is the least favourable possible setting for an ordering effect.

Is H-label likely to work? No — and it is worse than neutral.

Optimistic labels are a function of the realised tape, not of the public state. Fitting them yields E[lucky outcome | public state], an upward-biased hazard estimate whose bias is largest on cluttered boards. Under this game's objective — where §5 shows ≥ 93.7% of score is a step function of survival — a survival-overconfident evaluator is the specific failure that destroys long games, and the corpus has already photographed that failure (history.md:1466-1470). The corpus also contains the strongest possible warning against best-case-future planning as a public procedure: the hindsight planner, which is precisely "think of the best possible outcome and act on it" made fair, scored less than half of fair D3 (51,500.5 vs 107,076) and was diagnosed as strategy fusion (history.md:784-800).

Is H-pool worth testing? Yes — 25–35%, and it is the salvageable core.

Separate optimism-in-states from optimism-in-labels. The corpus supports each half of that split independently:

• Oracle-visited states are a publicly recognisable, genuinely distinct region of state space: held-out AUC 0.925/0.915, whole-fit 0.9459 (history.md:4085-4095, 4132). Whatever else is true, the pool is not degenerate.
• Fair re-labelling machinery already exists, already isolates privilege, and already passed its independence checks (oracle-curriculum.cpp:12-16, :352-528, :584-604).
• Survival/hazard targets are the only ones this corpus has ever fitted well (r ≈ 0.85, AUC 0.92, ECE 0.02), and §5 shows they are the right targets because score is 94–99% survival.
• roadmap.md step 9 already calls for "mature public restart states with independent future randomness" — H-pool is that idea with a proper control arm.

What I would actually do, in order.

1. Run D0. One to two CPU-hours. It produces the number the entire program turns on — the fair-relabelled value of an oracle state — which has never been reported despite the code to compute it having been written, run, and self-tested. Whatever it returns, it is a durable result. If τ < 0.25, the optimistic-teacher program ends here on solid evidence and the owner has saved a CPU-day and, more importantly, a wrong conclusion.
2. Only then run E1, and run it as designed: optimism in states, fairness in labels, hazard targets, all legal siblings, whole-origin folds, ≥5 seeds per arm, A3-shuffled as the null. Its most likely outcome is that ordering does not matter and that no arm beats exact D2/D4 — and that is a genuinely useful negative, because it will be the first matched-arm ordering ablation in this repository and it closes a question that would otherwise keep resurfacing.
3. Do not put optimistic labels into any training target, at any position in any schedule.

The most valuable thing in the owner's idea is not the ordering. It is the instinct that where the training states come from matters — and that instinct is correct, is supported by the AUC-0.93 manifold result, and is testable this week. The ordering is the part of the hypothesis the evidence does not support; the state distribution is the part it does.