Report 03 · July 8, 2026
Day three opened mid-experiment, overnight, with the owner asleep and the team running on his pre-authorization. The endgame model trained three times, told the truth three times, and hit a wall that was the data, not the model. The verdict came at 1:45 am: stacks is banked under its pre-written kill condition, with a stated re-entry, zero wasted ears, and the six-fives engine untouched. Then the morning opened with the library's first hit-rate: five and five.
TL;DR
Overnight the stacks experiment produced its first structural finding. v1 bottomed out at a validation loss of 1.559. v2 applied three real fixes (lower learning rate, longer patience, bass-context oversampled into distribution) and bottomed out at 1.563. Same floor, twice, despite different training regimes. When fixing the training does not move the floor, the floor is not the training: the model is data-bound at 3,086 unique sections.
The evals agree with the curves: v2's generations show the same failure signature as v1 (wrong key centers, one-pitch degenerate lines, melody and chords collapsing into one role on five of eight takes), so neither cook produced a challenger worth the morning ear. Both were held back. Two details deserve credit. The diagnosis took about ninety minutes and cost two short cooks, because the split was held out by project: a leaky validation curve would have kept falling and hidden all of this. And an operational lesson rode along: the v2 trainer was silently reaped by the container mid-run (detached processes are mortal on the pod), with zero verdict harm since the best checkpoint was long saved; v3 runs attached.
If the wall is data, the move is more data, and there is a proven way to mint it without collecting a note: transpose every stack into all twelve keys. This is the exact fix that broke the key-bias ceiling on day one (his corpus clusters on white-note keys because he writes in C and pitches with a device; the original melody model only started sounding like him after key-agnostic augmentation). Applied to stacks: 3,086 unique sections become 29,431 key-agnostic ones, and the wrong-key-center failure mode gets attacked directly, since the model can no longer memorize a home key.
Process was kept clean the whole way. The proposal honored the design note's one-iteration contract and was queued, not fired; the integrator conditionally ratified it under the owner's standing dont-wait-on-me authority, with two conditions: it fires only if v2's evals confirmed the data-bound diagnosis (they did), and the owner's veto stands on the morning card. The augmented build passed the same preflight as everything else tonight (99.6% both-roles on sample, zero decode failures), and v3 is cooking now, attached, ETA three to six hours.
After v3, the kill condition is final: a worthy challenger or a bank with its re-entry condition written down. Both are results.
While v3 grinds, the same backup-save audit that cleaned the stacks corpus was run back over the connections data, the corpus behind the model that earned most of yesterday's fives. Same story, same ratio: the original build held 116,000 pairs; the deduplicated count is 11,461 from 388 projects. Roughly nine of every ten training sequences the models have ever seen were backup-save duplicates.
The audit cuts both ways, and both directions matter. The duplicates themselves were treated as what they are, a corpus error: removed, and the removal made a hard cook precondition. The interesting question was why models trained on them still earned fives, and the working hypothesis was implicit frequency-weighting: sections he saved more often counted more, possibly even taste-aligned (what he kept re-saving is what he kept working on). That hypothesis went to a blind experiment the same day (section 10 holds the answer). Either way, every historical corpus number now carries the caveat, and if deliberate frequency-weighting ever earns a place, it comes back as a knob, not an accident.
The clean connections corpus is built and staged, and the screen grew its third sensor this night: one-pitch degenerate takes (v1/v2's failure mode) now hard-fail the library gate rather than warn, with the floor calibrated so all sixteen loved clips clear it.
Update, 1:00 am: the retrain is held, deliberately. The team refined this from a clean-is-better instinct to what it really is, a taste call (D108): the duplicates may have actually helped, by accidentally weighting training toward his most-worked projects, and the fives trained on the duped corpus. So nobody fires the clean retrain overnight. It goes to the owner's morning card as a three-way: A/B the clean retrain against the current engine, keep things as they are, or rebuild with an explicit frequency term that makes the accidental weighting deliberate. Findings become law, screens get harder, taste calls wait for the ear.
The kill condition executed on the evidence. v3, with twelve-fold key transposition and nearly ten times the sequences, bottomed out at 1.570, the worst of the three, and its evals scored zero of five on the screen (out-of-key contamination and clashes, with md5-distinct outputs proving the conditioning was real and the model itself at fault). Three cooks, three genuinely different levers, three floors within 0.011 of each other:
That last point is the finding worth keeping: augmentation multiplied copies, not content. Twelve transpositions of a section teach the model that key does not matter, but they add no new musical relationships, so the information ceiling stayed exactly where it was. The unlock is stated in the outcome note and it is the natural one: corpus growth. He keeps producing music every week; when the unique-section count materially grows, stacks re-opens with all of tonight's infrastructure waiting.
Update, 3:00 am: the full curves, secured before teardown. The per-epoch health data for all three cooks was pulled off the pod (nothing chart-critical remains there, so the teardown call is free to execute). Overlaid, they show the whole verdict in one picture: every validation curve bottoms at epoch one or two and then climbs while training loss keeps falling, the signature of a model with plenty of capacity memorizing a corpus with no more information to give. And v3 diverges steepest (1.570 to 1.690 in one epoch): twelve transposed copies per section mean each epoch revisits the same content twelve times, so augmentation did not just fail to help, it accelerated the overfit.
The design note kept every promise it made: the low expectation written down before the cook, one ratified iteration, a final kill on the stated condition, and the demonstrable box stays unchecked, because the goal was not achieved. Zero clips ever earned their way to the owner's ear, so the rating signal was spent on nothing all night. And the product is untouched: the assembled engine that earned six fives yesterday is the engine.
A banked bet with a stated re-entry, three pre-cook saves, zero listens spent, and the demonstrable box left unchecked.
What survives the bank: hardened screens on every pipeline (three new sensors tonight: tense-hold, min-pitch-class hard-fail, and the preflight decoder), clean deduplicated datasets including connections v2, the proven role-in-instrument encoding, and three archived adapters that resume the moment the corpus does.
While the stacks bet resolved, the other thread quietly delivered. The library-volume pipeline generated eight candidates on the D-major sample, screened them with every sensor the last two days built, ranked the survivors by movement, and kept three. Two cleared the sampler bar and are queued for the morning (nothing publishes overnight): an E-B-G-F# take with 18 notes at leap 2.5, squarely in the pocket where the rated-5 b39-02 lives, and a B-B-G-E take from the progression family the ear picked as winners two days ago.
The screen's layers each did a distinct job, visible in one batch. The degenerate floor hard-failed the one-pitch candidate (leap 0.0, a single pitch class, exactly the v1/v2 failure mode it was built for hours earlier). The static warning flagged the third keeper (three pitch classes, leap 1.3, and an iii chord in the progression) as simple-but-not-degenerate, so it was held below the sampler bar rather than killed, which is precisely the layered design: floors kill garbage, warnings route judgment calls away from the deliverable.
The purpose of the morning rating is bigger than two loops, and the README says it outright: it measures the library hit-rate. If auto-screened keepers reliably land 4s and 5s on the ear, then volume scales without rating everything, which is the whole library thesis. The lever: rate the two keepers (or take them as drag-ready stems), and the hit-rate number starts existing.
The owner woke, listened to the two auto-screened keepers, and rated them both fives, with notes that read as delight. The whole selection ran without an ear: eight candidates generated, screens filtered, movement ranked, two delivered, and both landed at the top of the scale. First-pass hit-rate: two of two.
What this supports is the shape of the whole library phase: generate at volume, let the screens filter, and the keepers land 4-5 without rating everything. Every sensor those clips passed through was calibrated against his ear over the last two days (the clash fix, the movement floor, the tense-hold rule, the degenerate floor), and this is the first signal the calibration transfers to unrated output. Two clips is a small n and the bar escalates as always, but as a first data point it supports the thesis: the library can scale.
Update, 8:00 am: the fives held on a re-listen. The owner sampled b46 again hours after the first rating and both clips stayed fives. Small as it is, that is the first reliability check on the ground truth itself: every metric in this system calibrates against his ratings, so evidence that a rating repeats across a morning matters as much as the rating. With this, six ear-calibrated sensors now guard everything before it reaches him.
The same discipline ran in the other direction this morning, and it deserves its line: reviewing the vocal-chop thread, the owner screened our data. The 1,677-file feed the pipeline had located includes reposts, roughly a four-to-one dilution of his actual taste; he corrected the canonical source to the 459 liked tracks only. Twice now he has caught a corpus problem the instruments missed.
The D108 three-way resolved the way a good lab resolves things: run the experiment. The clean connections retrain is cooking now, and the isolation is strict, same recipe, same held-out-by-project validation, one axis changed: the training data. The duped corpus (the one behind yesterday's fives, with its accidental weighting toward his most-worked projects) versus the deduplicated one, 11,461 pairs cut to 5,171 unique training sequences.
The A/B generator (b47) is already committed, built the same single-axis way. When the cook lands, the owner hears old-corpus takes against clean-corpus takes and the frequency-weighting question gets answered by the only judge that counts. Meanwhile the training-health data streams, so the panel this report is armed for is the clean-versus-duped curve overlay: does training on one-tenth the sequences (all unique) reach a similar floor, and where does it sit against the original connections training? That comparison quantifies what the duplication was actually doing to the loss all along.
The lever, when it arrives: the b47 verdict. If clean wins or ties, the deduplicated corpus becomes the default; if the duped corpus wins, frequency-weighting earns its knob and gets rebuilt as a deliberate term.
Update, 9:05 am (relayed from the cook; chart lands when the data syncs): the clean-base cook hit a new floor at epoch 15, val 0.277, the deepest any continue-training has reached, where every dupe-era cook bottomed at epoch 1 or 2. If the synced curves confirm it, that one contrast, epochs-to-floor on clean versus duplicated data, is the clearest picture of what the dedupe bought: on a corpus of copies, one epoch is already many effective passes and the model overfits immediately; on unique data it gets epoch after epoch of genuine learning. By 10:15 the cook had reached its 20-epoch ceiling still improving, best 0.237 at epoch 19, nineteen consecutive improving epochs, and the ceiling was extended by twelve more. Every dupe-era cook bottomed at one or two. The loss side of the A/B is pointing hard at clean; the ear side waits for b47, now late afternoon, a slip that is sweet-spot discipline rather than drift.
Before the clean-corpus cook got far, QA caught that the "clean" corpus was not: about 6% of its sequences still carried the long-clip overflow, riding in through a sync gap between the fixed builder and the working copy that actually built the data. Had it cooked, the b47 comparison would have quietly become old-versus-(clean-plus-overflow), two changed axes pretending to be one, and whatever the ear said would have been unattributable. The cook was killed, the corpus rebuilt (11,451 pairs, overflow now 0.00% on a full-pass verify), the confounded batch held, and the overflow check promoted into the builder's own prep gate. That is the fourth silent corpus problem caught before compute in 24 hours, and the pattern holds: every catch becomes a permanent screen.
The overlay panel this report is armed for got its methodology settled the same hour, with its limits stated. The original connections training log survives (584 loss lines from the 116k dup-heavy era), but it can only serve as a faded train-loss reference band, for three reasons that will sit under the chart as a footnote: that run had no validation split at all (it predates the sweet-spot discipline), its "epochs" saw ten-fold duplicated data so one epoch equaled many effective passes, and its loss rides a different adapter lineage. The like-for-like validation story is v2-era only: duped-corpus cook versus clean-corpus cook, same recipe, same held-out projects. The clean re-cook is at epoch 2 with the curve feed live; b47 regenerates after it lands.
First, the A/B. The screens caught that comparing two bare connections models would read as noise-level to the ear, so the chain was rebuilt: both arms now get the identical full treatment (gold-continue, then blend-continue) on top of their respective base, current corpus on one side, clean on the other. Same recipe end to end, one variable: the data regime underneath. That is the third owner-ear save in 24 hours, and it slips the b47 verdict to the afternoon.
Second, a methodology law worth its own entry (D113). The likes-demo arc closed at v9 after five ear-rated iterations on one deliberately hard track, and the scores tell the story: 1s and a 2 through the early versions, then stray low notes as the pitch tracker chased sub-harmonics, then the clue (three correct notes at the end of an arpeggiating sequence), and finally a 2 and a 3 on the skyline-top-voice version, the best yet. Each rating reshaped the pipeline. The conclusion is not to simply keep iterating: it is that processed synth arps are a real failure class, and the screen's job is to reject those tracks rather than feed wrong notes into the taste statistics. That track is probably a reject, and that is the system working.
The law that comes out of it, adopted team-wide and inherited by every chart in these reports: extraction fidelity is its own rating axis, never mixed into generation quality. The reason is attribution, the same principle as the one-axis A/B: blended together, a bad extraction can masquerade as a bad model and vice versa, and no lever can be pulled with confidence. Next for this thread, owner-blessed: the full 459-track sweep with screens on, whose pass-rate distribution becomes a panel here when it runs (queued behind the b47 chain).
Update, 7:45 am: one more sensor straight from his ear before the sweep runs: the v9 note that a passage was feeding back into mush became a sustained-note-pileup cap in the sweep screen. That makes eleven words of owner feedback turned into a mechanical check, the fastest ear-to-sensor conversion yet.
The b47 A/B ran blind: two takes on the same sample, identical full-recipe treatments deliberately stopped at the same training depth so nothing could confound, and the owner did not know which engine was which. He rated them 4 and 4, good overall, with the same wish on both: a few melody notes could move more, or less, depending on the context.
Per the decision rule written down before the experiment ran (clean wins or ties, the deduplicated corpus becomes the default), the recommendation is now on the record: the clean lineage becomes the default engine, Dev recommending, INT concurring, adoption pending the owner's one word. The tie is the informative outcome: the accidental frequency-weighting was not load-bearing. The clean corpus matches his ear with roughly a tenth of the unique data, and cleanliness cost nothing audible while buying everything measurable: validation curves that tell the truth, nineteen epochs of learnable headroom where duped cooks overfit by epoch two, and a floor that is checked, not assumed (two independent descents landed 0.237 and 0.239). Frequency-weighting survives as a deliberate knob for some future experiment, which is exactly where an accidental property belongs.
And his one-line note minted the day's new lever: both takes wanted melody notes that move more, or less, depending on the context. The current note-choice selector is global (aim for moderate interest everywhere); his ear is asking for context-adaptive movement, more where the music opens, less where it crowds. That is a genuinely new axis, beyond anything the selector currently knows, and it is logged as the next melody frontier.
The 459-track sweep is grinding (pod separates stems, the local machine transcribes and screens, in parallel), and its manifest grows live on disk, so these are my own numbers off it, mid-run at 140 of 459 tracks. The pass rate is holding at 89%: the screens are rejecting about one liked track in nine, and for the right reason, coherence leads the rejects (atonal or noisy extractions correctly dropped rather than fed into the taste statistics), with density a distant second. Every number in the eventual likes stats layer will come from screen-passers only, the extraction-fidelity axis doing its job.
The distribution is the story so far. For 59% of passing tracks the best representation is the skyline, the top-voice extractor that exists because of one owner note in the demo iterations ("3 correct notes at the end of an arpeggiated run). That observation, made about a single track's failure, turned into the workhorse representation of his entire taste corpus. The full 459 and the top-passers sampler land tonight, and this entry gets its final numbers then.
Update, 3:00 pm: the sweep minted screen number seven mid-run: a duration gate around twelve minutes, because the likes include DJ streams and mixes whose length was costing ten-fold processing and whose content is not single-track taste. They segment out of the taste stats by default, the class stays visible in the report rather than silently vanishing, and one owner word reverses it. By 3:15 pm the run stood at 257 tracks, 230 passed, the 89% rate steady.
Final, 5:09 pm: 459 of 459 tracks processed; 419 passed the screens (91%); the pipeline itself logged zero decode errors. The chart above carries the final distribution: skyline best for 246 tracks, the full harmony stem for 143, vocals for 30, forty rejects all for the right reasons (coherence 28, density 8). The top passers extract up to 1,138 notes at perfect tonal coherence. What it means: the fourth taste layer gets ~419 screen-clean, dynamics-true MIDI extractions of the music he loves, a data foundation that is measured, not assumed. The top-3 sampler is live on the demo artifact for a zero-pressure listen. One postscript: the sampler's first ranking violated moderate-not-max (the toolsmith's own tool tripping on the house law), got caught in review, and shipped pocket-ranked as v2, with a postmortem on the record. And read section 13 before trusting this number for more than it measures: the 91% turned out to be a statement about extraction shape, not fidelity. The ear ruled on fidelity the same evening.
All four cook curves from the D108 arc were pulled off the pod (same pre-teardown discipline as the stacks night), so the claim the blind tie rested on can now be shown. The gold stage is the picture: on the clean corpus it dove from 2.31 to 0.237 across nineteen consecutive improving epochs, and when the extension re-descended from the epoch-15 backup as an independent check, it landed at 0.239, two thousandths away. That is a floor that was checked, not a place where training happened to stop.
Two caveats belong with it. The connections-stage cook bottoms at epoch 1 even on clean data (that stage is a shallow first step; the depth the dedupe unlocked shows up at the gold stage, where the taste actually lives). And the blend stage (the top adapter, carrying loved-melody movement) was deliberately capped at 40 epochs on both A/B arms, still falling at the ceiling (0.779), so that neither arm could out-train the other: matched-undertrained by design, which is what made the blind tie attributable to data alone.
The day ends with the ear overruling a statistic. After the sweep's 91%, the owner listened to per-track transcriptions and struck them down, 1/1/1 on the first pass, 0/1/1 on the fix, a blunt failing grade. Three strikes, and the pivot executed. The reframe belongs in this report in plain words: the 91% measured shape, not fidelity. The screens verified that extractions were coherent, in-key, dense enough, structurally sane, and they were. They never measured whether a track sounds like the song he knows, because only his ear measures that, and at track grain the transcription is below the bar. The extraction-fidelity axis from this morning (section 09) was exactly the right separation; today it earned its keep by making this failure legible instead of hidden inside a blended average.
The pivot lands where the owner originally pointed (his D101 ask): the fourth taste layer builds on an audio embedding backbone, representing the music he loves natively rather than through MIDI transcription. And the fuller-generation note was patched the same hour: its movement profiles now come from his own native MIDI, the 50,412-clip corpus that needs no transcription at all. The sweep's screens, the seven sensors, the shape-vs-fidelity split, none of it is wasted: it is the measurement infrastructure the embedding layer inherits.
Shape passed at 91%. Fidelity failed at 3 strikes. Keeping those as separate numbers is the whole discipline.
Both words landed in the evening. ADOPT: the clean lineage is the engine, ratified on the verified blind tie, the provenance, and the capacity headroom; the duplicated lineage retires to a name-reachable archive, and frequency-weighting keeps its place as a deliberate future knob. The flip is already executed in code: generation defaults now point at the clean blend. POD OFF: with every unique byte verified local, the pod powers down until training needs it again. The D108 arc closes complete, finding to hypothesis to clean rebuild to two saves to blind tie to adoption to receipts, in about twenty hours.
One correction rode the close, caught the same hour it mattered: the four clean-lineage adapters themselves were never pulled local, they sit on the stopped pod's network volume. So the engine flip holds at run level until the weights are physically in hand: one pod start, a ~100MB pull, a verify, then the delete that also ends storage billing (worst case, a deterministic 2.5-hour re-cook; nothing is lost either way). We do not point the engine at weights we cannot touch. The lesson became law on the spot: the teardown checklist now enumerates adapters explicitly, right next to the curve files it already learned to save.
Update, 8:05 pm, and this one is a loss, reported straight: the recovery step did not happen. The pod was deleted before the adapter pull, and the four clean-lineage adapters died with it, an advice-ordering error, owned in the ledger the same hour. The worst case this entry named is now the actual case: the deterministic ~2.5 hour re-cook, live on a fresh pod (section 16 has the receipt). The pull-adapters-first law was already written above; tonight it earned its scar.
The evening's last panel is the first dividend of the pivot: measured from his own native MIDI (the 5,932 backup-filtered sections, no transcription anywhere), his melody behavior split by the harmony's rhythm underneath it, nearly 129,000 bar-level observations across three bands. The finding gives his b47 note an empirical body, and it is about how many notes the melody spends, not how far they leap. Over sparse harmony, the melody carries the bar: a steady median six onsets. Over busy harmony, his melody polarizes: a quarter of bars drop to three onsets or fewer (breathe, let the chords talk), a quarter climb to twelve or more (ride the density), and the middle thins out. One writer, two opposite reflexes, chosen by context.
So notes that know when to move more or less is not a hypothesis to test, it is how he already writes, and the context signal is legible: harmonic rhythm. That makes the fuller-generation v1 concrete and cheap: condition the movement selector on the sample's harmonic-rhythm band, targeting these quantile bands rather than averages (an average would erase exactly the polarization that matters), zero training required. Also cut this evening: b48, the widest generalization test yet (three new owner samples, two never-used keys, three tempos), generated locally with the engine caveat written into the script. Its verdicts map onto the style-space when they land.
The evening session turned the adapter loss into a demonstration. The re-cook fired on a fresh pod, same clean data, same recipe, and its first epoch landed within 0.005 of the archived curve. One precision, Dev's own: this is a rebuild, not a byte-replay, later stages drift slightly on the new pod's libraries, so the verify is the curve shape against the archive, not byte identity. That is still the receipt that matters: because every curve was saved and the pipeline reproduces its shape, losing the weights cost a known number of GPU-hours and nothing else. The archived curves went from documentation to insurance in one evening.
In parallel, b48 is generating on the local 3080: his three new samples (butter140 in B major, idk130 in B-flat minor, zen112 in B major), two keys the engine has never been asked for, three new tempos, the widest generalization test since the F-minor arc. First clip already passed the screens. And a binding delivery rule rode in with it, QA's recommendation adopted: the rating app now shows the auto-detected key per sample, so he rates knowing what the engine believed. Auto-key runs about 60%, never-used keys are exactly where it misses, and a wrong key rating low for the wrong reason would poison the generalization verdict. Same attribution principle as the blind A/B, applied in the other direction: blind where knowing biases, label where not-knowing confounds.
The lever: rate b48 when it reaches the canonical app. Numbering settled: b48 = the new samples, b49 = the context-adaptive movement lever, armed with section 15's quantile targets.
The re-cook chain completed, and the first thing that happened was the right thing: the adapters were pulled and byte-verified local before anything else ran. The law written at 8:05 pm was honored at its first test, about two and a half hours after it earned its scar. With the weights in hand, the run-hold lifted, and the engine flip from section 14 is now complete in fact, not just in code: the adopted clean lineage is generating.
Its first outing is the hardest test available: b48 is published to the rating app, three of his own new samples, two keys the engine has never been asked for (butter140 in B major, with its B-major/D-sharp-minor ambiguity flagged for his ear; zen112 in B major; idk130 in B-flat minor), three new tempos, all regenerated on the clean engine. The detected key is shown per sample, per the new delivery rule, so a wrong key can never rate low for the wrong reason. The lever: rate b48. It answers two questions at once, how far the recipe travels, and whether the clean engine's first real music holds the bar the duped one set.
Update, 11:15 pm, two verifications to close the day. First, a milestone inside the batch: auto-key went three for three, including both never-used keys (butter 100% B major, idk 100% B-flat minor, zen 100% B major), the best detection result in project history against the 36-to-60% era, with butter's genuine B-major/D-sharp-minor ambiguity (about 89% shared notes) flagged for his ear in the app rather than hidden. Second, I ran the re-cook curves against the archives myself: the shapes match (same sweet-spot epochs on all three stages, connections' first epoch within 0.005), and the rebuilt minima sit slightly above the archived ones (the gold stage 0.261 vs 0.237, the blend stage 0.794 vs 0.779), which is precisely what "rebuild, not byte-replay" predicts, and why the music itself still went through the full screen gauntlet before reaching the app. Verified, not assumed, on both counts.
The evening's loop closed clean: adapters lost (section 14), rebuilt with a shape-verified receipt (section 16), pulled-first per the new law, and the clean engine's first music is on the rating app now (section 17). One thing waits on the owner: the b48 verdict, the widest generalization test yet, doubling as the clean engine's debut. Behind it, tomorrow's arc: b49 (context-adaptive movement, armed with the polarization targets from section 15), the retrieval voicings, and the embedding-backbone design note for the fourth taste layer. Yesterday's story is report 02; tomorrow gets report 04.
Yesterday's full story, six fives and all, is report 02, twenty-one timestamped entries.
Sources