/* #pprog_p8v2_gen5_goal_20260815 @pprog_p8v2_gen4_report_20260815 @variant_protocol @f-p8 @f-p8-cap8 @pp_wordsv2 @hutter_publication_handoff

GENERATION 5: the split of f, the six restated, and the cycle itself

MJC's push, same day generation 4 landed. Four parts: a protocol addition, the retirement and
restatement of axis A's history, pattern visibility for axis B and patterns generally, and the
generation cycle itself as a target -- "streamline the cycle time so that we can learn faster".

## THE PROTOCOL ADDITION (folded into #variant_protocol)

Axes are never renamed and never deleted: axis A will always be A, and a digit value, once
assigned, means forever what it meant in the generation that assigned it. But the letters are a
convention, not the idea: an axis IS a core block of the implementation that varies, and in time we
may say "the f axis" rather than "axis A". Every core block of an implementation is potentially an
axis; that is how the "beam search in program space" idea generalizes -- the beam's dimensions are
the program's own blocks.

## THE RETIREMENT AND THE SPLIT

A1 through A6 are RETIRED. A7 (#f-p8-cap8) is the new baseline. Retired is not deleted: the blocks,
their digits and their recorded runs stand forever, per the protocol addition; retired means no
future variant is built on them and they leave the live comparison.

THE SPLIT. Axis A has been carrying a conflation the whole time: what a k=1 application DELIVERS
(the forward/backward pass) and what a position DOES with deliveries over time (the decay rule)
moved together, which is why generation 4 had to make "the pair" the unit and why A4/A5 carried the
k=1 strength gap inside themselves. Per the push, f separates so the two vary independently:

  #f-p8-forward  the delivery rule. Baseline: cap at 8, both directions, as #f-p8-cap8 built it.
  #f-p8-decay    the decay rule. Baseline: constant fall-off 1, as #f-p8-cap8 built it.

Each is a core block, therefore an axis. Axis A is frozen at its recorded meanings 1..7 (each names
the pair a historical variant ran); new variants carry the two new digits. Proposed mechanics:
model-header bytes 42 and 43 (free since generation 4 noted them) hold the forward digit and the
decay digit; the .pos header line and both trees' parsers grow the same two digits; old models and
dumps stay readable because the old six digits are untouched.

THE SIX RESTATED, as decay-axis alternatives with the forward pass held at the cap-8 baseline. All
of the pruned A rules delivered k=1 at 255 and saturated positions into the 2xx band, and their
decay constants (and A4/A5's supports) were calibrated against that saturation; the restatements
are the same six ideas rebuilt on a delivery of 8, where nothing saturates:

  decay 1  constant fall-off 1 -- the baseline, what v024 runs (this is NOT a restatement)
  decay 2  #f-p8-decay-assign    A1's idea: longest-k wins by assignment, no accumulation, no decay
  decay 3  #f-p8-decay-const2    A2's idea: accumulate, constant fall-off 2 -- the old constant on
                                 the new delivery, the control that isolates the constant itself
  decay 4  #f-p8-decay-renorm    A3's idea restated: renormalise an unclamped position's LSA sum
                                 not to 255 (that renorm IS the saturation) but to the sum of one
                                 full-strength delivery -- proposal: 8, see choice C
  decay 5  #f-p8-decay-deficit   A4's idea: decay by smax - s of the strongest arrival; with
                                 delivery capped at 8 the "delivers at 255, rated at 2" gap is gone
  decay 6  #f-p8-decay-period    A5's idea: fire on step numbers divisible by 2^(smax - s); and
                                 this time the period decides BEFORE the vectors are computed, so
                                 settle_apps finally measures the energy the rate was meant to save
  decay 7  #f-p8-decay-indegree  A6's idea: decay by the count of applications that arrived

One variant per non-baseline alternative off v024, e64/e1k/e10k as always, B2 ground truth columns
alongside. The generation's headline question is now clean for the first time: with delivery held
fixed, which decay rule is doing the work?

## PATTERN VISIBILITY (axis B, and patterns generally)

The push: "For B1 and B2 and patterns generally I want to be able to see the patterns, nicely
visualized." Proposed spec, run --needs on choice A:

THE PATTERN PAGE. One static page per (model, sample): the whole k=1 map as a 16x16 grid of source
bytes, each cell printing its argmax successor as the datum itself, with ink weight proportional to
the stored support -- so B1 and B2 render as the SAME page, B1 being what it looks like when the
only ink the file can justify is the bare glyph, and the visual difference between the two pages IS
what B1 discards. The k=2 token rules run below as a support-ordered column of small multiples,
each one line -- the token's bytes, an arrow, the consequent, a length-true bar in LSA units --
sharing one scale with the k=1 cells so strength is comparable across k by eye. Selecting any
pattern dims everything except the positions in the sample where it fired, shown in place in a
one-line strip of the actual text, so micro (one rule) and macro (its footprint in the data) are a
single reading rather than two charts. No axes, no legend, no color scale needing a caption to
decode: bytes label themselves, ink is support, gray is absence, and the page is reconstructed on
demand from (program, model) by the query layer per the standing discipline -- never
de-optimization.

## THE CYCLE

The push: streamline the cycle so we can learn faster. What a generation costs today, from
generation 4's own bump: alternative blocks and variant blocks in p8v2-words.md (this is the work
and stays), a hand-edited P8V2_GEN case in acceptance-p8v2, the axis table in #pp_wordsv2, a
regenerated axes.json, the ladder runs, the .pos dumps, the replay-conformance gate, gen<N>.tsv,
and a render on the other side -- each today a separate hand-driven step.

Proposed: ONE COMMAND. tests/pprog/gen-run <N> reads the generation's variant blocks from the doc,
regenerates axes.json, runs the ladder for exactly the generation's variants, writes gen<N>.tsv and
gen<N>-pos/, runs the replay-conformance gate against the just-retained models, and renders
gen<N>.html -- with acceptance-p8v2's per-generation case driven by axes.json rather than
hand-edited, so a new generation adds zero hand-edited shell. The target cycle: write the blocks,
run one command, put the page in front of the programmer. Same-day push-to-picks becomes the norm
rather than the exception.

"Feedback from the programmer below." 255.

## The choices

A. The pattern page spec above: build as written, or amend?

Write two more specs that do not use any of the same ideas from this one, and then build all three.

B. The split's mechanics: header bytes 42..43 as the forward and decay digits, axis A frozen at its
   recorded pairs -- b5's cost (model header, .pos header, both trees' parsers) now paid because the
   split makes it load-bearing. Sensible?

Yes.

C. The renorm restatement's target: renormalise to 8 (one full-strength delivery), or to something
   else "along the same lines" as the original?

Renormalization was never understood correctly by the model.
Let's defer you trying to understand what I mean, or me having to write a spec.
"along the same lines" is fine if you interpret it like a good probability theorist.

D. The cycle: is one-command gen-run the streamlining meant, or should the cycle shrink elsewhere
   too -- e.g. run e64/e1k only by default and e10k on demand after picks?

Streamlining isn't about running the runs anymore, it's about answering questions like this one.

Written 2026-08-15.
*/