Chapter 16

The closest thing to H-JEPA yet predicts the future, not the image — and still loses to a plain average

Prerequisites: Chapters 1 to 15.

Beginner track

Where we left off

Chapter 15 closed, this time for good, an entire family of attempts: no calculation based on a

single image — learned, off-the-shelf, or hand-built to resist lighting changes — can cleanly

separate "this is a forest" from "this is dark", because in this game forests really are darker

than meadows. Five different attempts, five confirmations of the same wall. What remained on the

table, for picking the cold-start investigation back up: the memory of visited places (Chapter 12),

which has real but modest and fading results, and the heaviest, most ambitious idea on the menu —

a separate second brain, designed for long-range search. This chapter tells the story of the first

real attempt in that direction: not yet the full second brain, but a first, cheaper try, designed

specifically to dodge Chapter 15's trap from the outset.

A different idea: predict the discovery, not the image

Until now, every attempt of this kind asked a small model to look at an image and judge: "does

this look like a promising scene?". That is exactly the type of question that always ended up

caught by brightness. This time the idea changes in nature: instead of judging an image, a small

model learns to predict, for each possible direction the agent could go, how many new cells of

the explored grid would probably be discovered — a bet on how useful it is to explore that way,

not an aesthetic judgement about what is on screen.

To place that bet, the small model never looks at the colour or texture of an image. It relies

on only two kinds of clue: a classical calculation of motion between two consecutive frames (is the

camera moving a lot or a little in a given direction?), and the history of already-visited zones,

inherited from the memory built in Chapter 12. This is, to date, the attempt closest to the real

idea behind JEPA — the project's very name: instead of predicting a future image pixel by

pixel, you predict a small useful quantity about the future (here, "how much new ground am I going

to discover"), from compact clues rather than raw pixel colour. It is exactly the kind of

prediction this project has always aimed to make, applied here to a new question.

A real bug found along the way, not just a shortage of data

Before anything could even be trained, real examples had to be collected of "in this direction,

here is how much new ground was actually discovered". A first collection batch revealed a real

bug, invisible until then: when several directions are tied (which happens almost all the time

early in an exploration, when no neighbouring cell has been visited yet), the mechanism

systematically and unintentionally chose the same default direction — 54 times out of 57 triggers

in that first batch. So it was not a genuine exploratory choice each time, just a hidden reflex

always landing on the same spot. Fixed by adding a coin-toss option to break ties (the old

behaviour stays available and unchanged if you do not enable it), then re-collected: this time all

12 possible directions are properly represented in the data.

Two good signs, before training anything at all

Two safety checks were run on this freshly re-collected data, before any training attempt:

  1. Is there a real difference between directions? Clearly improved after the bug fix, but based

on few examples per direction (between 1 and 7) — encouraging, not yet a solid confirmation.

  1. Does scene brightness still dominate the target we are trying to predict? This test was run

twice, on two independent collection batches, and both times the answer is clear: no,

brightness has almost no link with the amount of newly discovered ground. This is the most

solidly reproducible result in this entire long investigation into the absence of a

brightness trap — at last, a direction that does not fall into the same hole as the previous

five.

The real test: can this small model predict one specific trial?

With those two good signs, a small model was actually trained — a tiny neural network, barely

1,900 internal settings. But this project has a strict rule, applied at every step: never judge a

model on its own training data. The honest way to check is to split the data into several piles,

train on some and test on the rest, several times over with different piles each time, so as not

to be fooled by a lucky or unlucky split — this is called cross-validation.

Measured with that rigorous method against the simplest possible benchmark — always guessing the

average of every value already seen, without even looking at the direction in question — the

learned model does worse, not better. A systematic trial of eight different variants (smaller

networks, more cautious settings against over-fitting) never once managed to beat that simple

average. And to be really sure this was not just a tuning problem with a neural network too

complicated for the task, an even simpler version was tested — a classical linear model, no neural

network at all, with an adjustable brake against over-fitting. Identical result: the harder you

apply that brake, the closer the model gets to guessing a nearly constant value — and it never

surpasses the simple average, even in that most cautious case.

Why this is a failure of a different kind from the previous ones

It matters to distinguish this result clearly from Chapter 15's five failures. There, the problem

was that a model was learning something misleading — a shortcut that gave the illusion of

working while actually measuring something else (brightness). Here it is different: both safety

checks show a real, honest aggregate signal, not fooled by brightness. The problem lies elsewhere:

guessing precisely the outcome of one particular trial, from only four coarse clues about the

scene, is a much harder task than spotting a general trend across all the trials — and with only

about a hundred examples in total, that is simply not enough data for a model, however simple, to

learn to do it reliably. This is not proof that the original idea is bad. It is an honest finding

that the task probably needs a great deal more data (likely several hundred examples, rather than

better tuning) before we can say whether it is learnable at all with these clues.

Following this project's honesty rule, that small model was not wired into the real game: no

run was spent testing a model whose cross-validation check clearly says it does not work yet.

Where the project stands, after 16 real attempts

At this stage of the cold-start investigation, an honest overall stocktake is useful, without

adding gloss in either direction:

  • The "fix the visual judgement" direction is now closed, with five independent confirmations

of the same brightness trap — a small learned module, that same module retrained on other data,

an artificial lighting variation during training, a giant off-the-shelf model, and a hand-built

colour calculation. None of those five ways of going about it worked, for the same underlying

reason.

  • The "search and coverage" direction holds the only real positive results of the whole

campaign — executing a good plan for longer (Chapter 8), the memory of visited places

(Chapter 12) — but with gains that are running out of steam: the anti-drowning rescue holds well

at scale (Chapter 15) without lifting the chop rate, and this chapter shows that pushing further

in that direction (predicting exploration rather than counting it afterwards) now runs into a

data-quantity problem, not an idea problem.

  • One mechanism, named repeatedly since Chapter 11 but never directly repaired, remains the most

important open thread: the chop planner's very compass — the one comparing an imagined story

against a memory of success — was confirmed inverted as early as Chapter 11, and every

attempt since (search, rescue, coverage prediction) has worked around that problem rather than

tackling it head-on. With the visual direction now closed and the coverage direction showing

diminishing returns, this never-repaired mechanism becomes the most significant lever left on the

table.

As with every chapter on this site since day one: this report dresses nothing up. A real signal was

found (brightness does not dominate this new model's target), a real bug was found and fixed along

the way, and the final result nonetheless remains an honest failure at this stage — not a disguised

victory, and not an abandonment either.

Expert track

Context

Chapter 15 closed candidate direction 1 from Chapter 11's menu (photometric score correction) with

a fifth independent confirmation of the brightness shortcut, under a new and stronger constraint

than before: no single-frame photometric feature can, structurally, separate brightness from

scene composition in this domain. This chapter covers attempt #16 in CLAUDE.md#Phase 5+ (no

corresponding docs/10 entry to date): the campaign's first mechanism built explicitly under the

"no single-frame photometric scoring" constraint, a first non-photometric, non-visual step towards

candidate direction 3 (H-JEPA) without paying its full cost.

Design: the Coverage-Value Predictor (CVP)

An Explorer proposal, externally reviewed and refined: a small MLP predicting Δunique_cells (the

expected coverage payoff) per candidate heading, from non-photometric features only — a

classical per-quadrant frame-difference optical-flow proxy, plus the local visitation histogram

already maintained by FrontierTracker (Chapter 12). This is a genuinely JEPA-shaped predictor

(input + action → future state), but with the target swapped: from pixel reconstruction to a

compact geometric quantity. It feeds the already-validated frontier scan macro rather than

replacing its handoff to the chop planner.

Instrumentation, collection, and a real bug found along the way

scan.frontier.logtransitions (config-gated, default off) added to scripts/playcraft.py; two

batches collected.

First batch (N=12, 57 rows) revealed a real, previously unnoticed bug:

FrontierTracker.frontierheadingdeg() breaks ties toward the smallest heading index, and since

cells in a still-sparse grid are almost always tied (0 visits each), 54/57 triggers "chose" heading

0.0° by construction, not by genuine preference. Gate 1 (dynamic range across headings) was

uncertifiable on that data.

Fix: config-gated tie_break="random" option (seeded), default "first" = old behaviour

verified unchanged. Re-collection (N=14, 44 rows): all 12 possible headings now represented

(1-7 rows each).

Offline gates on the re-collected data

  • Gate 2 (brightness does not dominate the target): PASSED on BOTH batches independently

(r ≈ 0.10, opposite signs) — the most reproducible non-confounded result in the campaign's

entire history.

  • Gate 1 (dynamic range): substantially improved after the bug fix, but resting on small

per-heading samples (1-7 rows) — assessed as "encouraging, not a rock-solid confirmation".

The actual trained model — NO-GO, thoroughly checked, not just badly tuned

Both CSVs combined (~101 rows), a small MLP (~1.9K parameters) trained with mandatory 5-fold

cross-validation against a trivial "always predict the mean" baseline.

Default configuration: model MAE 1.590 against the baseline's 1.169 (worse).

8-way hyperparameter sweep (smaller nets, heavier regularisation): never beats the baseline,

best ratio 1.06 (still worse).

From-scratch linear Ridge regression check, to rule out an MLP-specific over-fitting artefact:

as regularisation strength increases, the model's error only approaches the baseline as it is

forced towards a near-constant prediction — it never surpasses it.

Diagnosis: predicting one specific noisy trial's outcome from 4 coarse scene-level features is

a much harder task than the aggregate statistics checked by Gates 1-2, and is not learnable at

N≈100 with this feature set — this is not evidence that the aggregate signal is fake, only that

per-row prediction needs substantially more data (likely several hundred rows, not better

tuning) to be learnable, if it is learnable at all with these features.

In line with the dispatch's honesty discipline, the model was not wired into play_craft.py,

no scan.macro: "learned_frontier" was added, and no live episode was spent testing a model whose

cross-validation gate says it does not work. No checkpoint written

(checkpoints/coveragepredictor.pt does not exist). ebwm.pt and craftwm_v4.pt untouched.

Why this negative differs in nature from Chapters 11/12/14/15

The previous failures in the "brightness shortcut" family are cases where a model learns

something real but misleading — a shortcut producing a good gate score while actually measuring a

confounding variable (brightness). Here, both offline gates (Gate 2 twice, Gate 1 after the bug

fix) indicate a real, unconfounded aggregate signal — the problem is not the signal's validity, it

is the intrinsic difficulty of the per-trial prediction task combined with an insufficient

sample size (~100 rows). This is a failure of statistical power and task granularity, not a

failure of design principle like the previous five.

Where this leaves the campaign — status after 16 numbered attempts

  • Direction #1 (encoder/scoring correction) closed, confirmed 5 times: attempts #7, #11, #14

(phase 1 CLIP + phase 2 direct fine-tune), and #15 (ratio chrominance) each independently hit a

brightness/domain-composition confound. No single-frame photometric feature — learned,

off-the-shelf, or hand-designed for invariance — repairs it.

  • Direction #2 (coverage/execution) holds the campaign's only real positive results:

commit_length=4 alone (9.7% pooled), attempt #12's frontier search (1/20, later confirmed at

N=20 with attempt #13's hazard fix layered on: drowning 60%→15%, fair-shot episodes 40%→60%, but

chop rate stayed at 0/20 — diminishing returns from coverage alone, exactly the condition that

justified trying direction #3). Attempt #16 (CVP) extends this line under the "no photometric

scoring" constraint and finds a real aggregate signal (Gate 2, twice) but no learnable per-trial

model at this sample size.

  • Direction #3 (H-JEPA proper) not built — attempt #16 was the cheap, non-photometric first

probe the standing diagnosis called for; it did not produce a deployable mechanism, but it also

did not fail for a photometric reason, so the door is not closed the way direction #1 is.

Cheapest version if resumed: collect substantially more transition rows (several hundred) before

retraining, per the CVP dispatch's own recommendation.

  • The mechanism named but never directly repaired: attempt #10 (Chapter 11) confirmed that

ebwm.pt's native goal-centroid scoring — used live by the two-brain chop planner as soon as the

search finds something — inverts on Obtain's spawn distribution. Every attempt from #11 to #16 has

worked around that problem (search mechanisms, hazard avoidance, coverage prediction) rather than

fixing it directly. With direction #1 closed and directions #2/#3 both showing diminishing returns

without touching it, this is now the campaign's most decisive unexamined mechanism — not yet

decided whether, or how, to attack it directly.

References

This chapter rests on no new bibliographic reference verified in docs/references/index.md. The

CVP design is described in CLAUDE.md as an internally refined Explorer proposal, in the general

spirit of a JEPA predictor with a swapped target (predicting a geometric quantity rather than

pixels) — a principle already motivated for this project by the JEPA architecture itself

(Chapter 1, LeCun, original JEPA concept) and by the latent-space prediction choice already made

for mine_jepa/ebwm/ (Assran et al., I-JEPA, arXiv:2301.08243; Maes et al., LeWorldModel,

arXiv:2603.19312), without any of those references specifically describing exploration-coverage

prediction — so this precise component has no external reference of its own to cite.