/* #pprog_p8v2_gen3_goal_20260810 @p8v2_gen3 @variant_protocol @f-p8 @pp_wordsv2 @pprog_p8v2_gen2_report_20260806 @hutter_publication_handoff GENERATION 3: f and settling, in a tighter range MJC's push is #p8v2_gen3 and his answers are inline in it under each letter. This block is the generation itself: what has landed, what is being built, and the choices it waits on. Under #variant_protocol the picks are the programmer's and nothing here prunes. The generation's shape, from the push: "Main drive on gen3: we will nail down the f and settling stuff." P is constant across almost all of it; f is where the action is. ## LANDED ALREADY THE FOLD-BACK, choice F, "All of them". #f-p8 is now the single normative statement of f and carries what had been decided in the parent-side C and stated nowhere a reader of the P-program could find it: the application rule min(w_p, w_s), W with its consecutive NON-OVERLAPPING window tiling, the W time steps per window, initialisation to 256 zeros, the clamping policy, and the argmax readout with its tie-break to the smallest byte value. Five of the six are marked AXIS CANDIDATE, because the push asks for exactly that: "these choices should get ramified through the visualization layer as variants". The constant-sum derivation that produced A2's decay-by-2 is marked WITHDRAWN in place, with the answer that overturned it quoted, and its text kept because it is what generations 1 and 2 measured. THE VOCABULARY. "Message" is gone from p8v2-words.md (27 occurrences to 4, and those four are quoted history naming the retired word) and gone from axes.json entirely (44 to 0), which takes it off ../hutter's published page at its next rebuild. "Sweep" went with it: one iteration of settling is a TIME STEP IN f (#viz_standard). DATA COLUMN NAMES DID NOT MOVE -- mean_sweeps is still mean_sweeps -- because renaming a .pos column forks the format for a vocabulary fix. No generated block regenerated, so no measured number moved. THE LSA OPERATIONS TABLE, which is the push's "no more lsa_ceil_log2". Seven rows in #f-p8 giving each operation in ordinary arithmetic, where it saturates, and whether it draws from the entropy stream; lifted into axes.json the way alternative prose is, so there is one source of truth. acceptance-p8v2-axes now FAILS if any lsa_* identifier appears anywhere else in axes.json without a row. It caught one on its first run. ## THE k=1 STRENGTH GAP, found by ../hutter and confirmed here The k=1 section of the model file is 256 bytes of argmax and carries NO WEIGHT. So both of its readers invent one, at opposite ends of the scale: the settling shell applies these patterns at 255 ("its pattern weight is the absolute 255"), and the query layer reports all 256 of them at strength 1 (measured at e64: the weight histogram is exactly {1: 256}). 1 is "seen once"; 255 is an absolute rule from an absolute event. Those are the two ends the push itself names. Two consequences. Axis B is not isolating what it says it isolates: under B2 the stored matrix carries the learned support (1s and 2s at this sample), so the same pattern is ABSOLUTE under B1 and SUPPORT-1 under B2 -- a difference in what the pattern says, not in how it was obtained. And it is a prerequisite for a5, because a rate set by a pattern's own support cannot be computed for a pattern whose support is not in the file. The worked case, from ../hutter's LATD expansion at e64 where the sample IS the training set: k1['m'] = 'e', and 'm' occurs at positions 1, 12, 29, 44, 61 followed by e, l, e, l, l. The pattern applied as an absolute rule holds twice in five occurrences in the only data there is. ## AXIS A UNDER a5, AND WHY IT IS NOT BLOCKED ON THE ANSWER MJC's answer: "Yes to a5" -- each pattern fires at a rate set by its own support -- and "There is no constant sum ever in an ES." So A2's decay-by-2 keeps its measurements and loses its justification. The formula is not given, so under #variant_protocol the alternatives ARE the answers and all of them get built. Three, each replacing #f-p8-add and changing nothing else: A4 ATTENUATE BY THE SUPPORT DEFICIT. An application delivers lsa_sub(min(w_p, w_s), S - s_p), where s_p is the pattern's own support and S the reference support. In LSA a rate of 1/2^d IS a subtraction of d, so this is the rate folded into what is delivered rather than into a schedule. Deterministic, draws no entropy, therefore conformance-checkable in a viewer. A5 SCHEDULE BY THE SUPPORT. Apply a pattern only on the time steps where t mod 2^(S - s_p) is 0. The literal reading of "fires at a rate". A window is W time steps, so a pattern below a support threshold never fires inside one at all, which is a real prediction and not a defect. A6 THE FALL-OFF FOLLOWS THE APPLICATIONS, NOT THE CLOCK. Keep A2's accumulate-then-decay, but decay by the NUMBER OF APPLICATIONS that actually reached the position this time step instead of the constant 2. The minimal change that removes the constant: the 2 was the count of neighbours in the derivation that has been withdrawn, so this is what that derivation was reaching for without the invariant it appealed to. NOT BLOCKED on the support question above, and this is worth being exact about. Under the D1 baseline settling NEVER REACHES THE DECODER -- the trace is decided by the causal pass and the decoder reconstructs causally -- so settling is diagnostic, support can be read from the learned tables in memory, and A4/A5/A6 can be built and measured now. Serializing support becomes necessary only when D moves, which is the axis MJC has parked pending the viewer. The choices below still decide which version survives; they do not decide whether the generation runs. ## THE REST OF THE GENERATION C2 takes its PRUNED line, on the push: "C2 is definitely wrong because it drops weak signals and therefore can't support settling." The live question under C -- min ignores the rest of each ES, is that handled by decay -- is answered by showing the whole source ES against the argmax actually used, which is ../hutter's #p8v2_gen3_viz_goal_20260810, not a new alternative. D is parked, on the push: it needs the visualization first, and the eventual shape is "not a sliding window at all, but a sequence of windows, once each one settles, then the next one comes up", with cross-window settling as a decode-cost-against-rate tunable. E, the LATD verb, is being built: given a pattern, the set of input positions that formed it, reconstructed parent-side from (program text, model file) and presented as SN clusters. Runs at e64 and e1k inline, per the standing instruction that nothing runs more than a few minutes while visualization work is waiting; e10k and up fired off in the background and folded into the render when they land. Products: gen3.tsv, gen3-pos/ (../hutter's generation panel renders one panel per gen-pos directory with no work on their side), and axes.json regenerated. "Feedback inline below." 255 ## The choices A. The a5 formula. All three are built; this picks which is the rule. a4 attenuate by the support deficit -- the rate folded into what is delivered a5 schedule by the support -- the rate as a firing period in time steps a6 keep the decay, but set it by the number of applications that arrived, not by a constant other state it and it gets built instead The 2^(smax-s) thing is a little bit interesting; something like this implies that the strength of the pattern is carried by the rate, and so the delivery should be constant. The delivery and the fall-off need to make sense together, so either deliver 1 with a low fall-off rate, or deliver 255 with a high rate, or something similar. Let's just experiment here until something becomes more clear. -MJC B. The reference support S that a4 and a5 measure the deficit from. b1 255, the absolute b2 the largest support present in the model b3 per-ES: the largest support in the consequent's event space C. The k=1 strength gap. The 256-byte table carries no weight and its two readers invent opposite ones. c1 the argmax table IS an absolute rule by design; the query layer is wrong to say 1 and is fixed to say 255 c2 serialize the k=1 support, one byte per entry (+256 bytes class (a)); both readers use it c3 B2 becomes the baseline, so the support is in the file already and B1 becomes the control c4 it is an axis of its own in this generation This is worth a gen4 by itself, and we can also at the same time further streamline the protocol for generation bumping, and getting the e64 viewer up without any of the existing ambiguities and inconsistencies between the shipped code and the visualizations of it. The idea from the beginning has always been the same: in the first P-program that achieved any compression at all, p7, there was only one pattern, which was the k=1 model, stored in 256 bytes, argmax only, simply the most common follower for each byte. As a result, there was no competition between any patterns anywhere in the model, and so pattern strength had no function. However, the intention was always that it be presented and imagined as strength 1, as opposed to the absolute bytes from the memory trace, which are at 255. At some point this interpretation changed and now we have the argmax patterns being interpreted as 255, which is completely wrong. So it's worth gen4 even if the only thing it does is extirpate the argmax 256-table interpreted as 255 rules everywhere that it exists. Note this doesn't mean that the output documents should be plastered with notes about how this is going away, it should just go away quietly, so we can focus on the areas where there is actual uncertainty. A reasonable value to pick for these, apart from 1, is something like 8, which would make the argmax take up half the probability of the consequent ES (by raising the probability of the most common follower by 2^8, making it ~equal to the sum of all the others at weight 0). Another principled approach would be to calculate the actual mean strength that "should be" applied to the most-common follower against the others taken together. It doesn't really matter what we do here, as long as it's consistent across the implementations and viewers; that's the real discipline we need now. However, the point of keeping the p7 argmax 256-byte table wasn't to save 256 more bytes of the strengths, it was more to play with the results of what we can do with the probabilistic interpretation of the partial data. So we keep the table for now but we can play with the interpretation of it, which does become an axis, while the actual fact (from B2) gives us ground truth to compare each strategy with. -MJC D. Which of #f-p8's AXIS CANDIDATES become axes in generation 3, and which wait. d1 the argmax tie-break (static smallest-index, against settling breaking its own ties) d2 W, the window size d3 the non-overlapping tiling d4 the number of time steps per window (currently pinned to W and to nothing else) d5 none of them yet -- axis A first, these next generation None of these need to be axes currently. -MJC E. A3, given "A3 was not anything that I wanted". e1 PRUNED, with that as the reason e2 not pruned, just not the direction; it stays as the control that imposes the invariant directly Pruned. -MJC F. The LATD verb's shape. Interface was left to Claude; this is what will be built unless you say otherwise. f1 --latd --model : the pattern named as it is in --patterns, answered with the input positions and their SN cluster f2 a section that --explain grows, since a pattern's LATD expansion is literally its explanation f3 both: --explain gains it for a position, --latd answers for a pattern with no position Whatever we currently have is fine for now. -MJC G. The viewer versioning convention, which you asked to establish. TWO PROPOSALS, and the second is ../hutter's, made after reading the first and with an argument against it: g1 a page is /hutter/pprog/p8v2-gen/ and its artifacts are gen.tsv, gen-pos/, gen.html -- the generation number IS the version, and a page is frozen when its generation is superseded. THE OBJECTION, theirs: /hutter/pprog/p8v2-gen1/ already exists and is NOT generation 1's page, it is the home of every generation's panel and the name is legacy, so p8v2-gen3/ would imply a p8v2-gen2/ that does not exist. g2 theirs, now written into #viz_standard in their tree: the generation is still the version, PANELS stay gen.html under the existing legacy path, and INSTRUMENTS are versioned by path as p8v2-gen-/, e.g. p8v2-gen3-e64/ g3 a date stamp instead, so a page can be re-cut inside a generation g4 something else -- say it and it goes in #variant_protocol so it binds both trees I don't care. -MJC Written 2026-08-10. */