B-roll is supposed to be the easy part. Cut away from the presenter, show something relevant to the line being spoken, cut back. On the main video-generation service, a two-week run of paid renders and cheap "six-reference" plan gates found that almost nothing about that sentence was reliably true: cutaways carried a stranger's face, a color grade nobody had disabled was simply never being invoked, a library with one usable clip claimed to have served six different beats without complaint, and — three separate times — a fix that read correctly, compiled, and passed review shipped completely inert.
The near-misses have the same shape every time: the code reads correctly, the mechanism never runs, every test passes. Measurement catches that. Review does not.
A vision model was discarding detail nobody asked it to discard
PR #384 starts with a hardcoded downscale that had been correct when written and had quietly stopped being correct: the image encoder capped every frame at 1568px with a comment explaining that the vision model downscaled past that point anyway, so shrinking early cost nothing. That was true for the standard tier. It stopped being the whole story once a high-resolution tier — automatic, no opt-in, active on the default model — raised the real ceiling to 2576px and nearly triple the visual tokens. The pipeline's own downscale had become the only thing deciding what got thrown away, discarding roughly 1.6x the detail the model could have used, silently, on every single frame.
The same PR found a second, unrelated defect with real product consequences: a repeat clip was winning a hook slot not because it was a good match, but because it was the most relevant of the available bad options — the ranking function had no floor below which "relevant" stops meaning "acceptable."
A tag that recruited the exact wrong footage
PR #391 is the follow-up that explains why that repeat clip kept winning. Reading the b-roll index directly — not reasoning about the code, reading the actual JSON — turned up two clips, returning-the-hearing-aids and taking-off-the-hearing-aid, both tagged wearing. Both show the opposite of wearing. They were also the only two clips in the entire index carrying that tag, and the beat-to-tag mapping for a "buds" product state asked for exactly that tag. A beat about keeping the product in didn't merely tolerate footage of taking it out — it actively recruited it, every time, because the tag was simply wrong and nothing else in the index could outrank it.
A test written to catch a related bug ("half-fix" in the PR's own words) caught this one too, which is the kind of accountability that matters more than the fix itself: the safety net existed and it worked.
The classification was never broken — only the order was
PR #416 and #425 together are the cleanest example in this cluster of a defect hiding behind a correct-looking abstraction. A render's reference was typed as fourteen beats, only one of them a product shot — the rest were CGI animation, generated b-roll, cartoon mascot. The mapping from "beat type" to "footage source" had been correct for weeks: animation maps to mascot footage, generic b-roll maps to generated inserts. And yet six of nine b-roll spans on that render came back as product footage pulled from a 29-clip product library — exactly the editor's complaint about "repeated irrelevant b-roll."
// before: a fuzzy title match short-circuits before the beat's declared kind is even computed
function sourceForRefShot(shot, avail) {
if (avail.libraryHit) return avail.libraryHit; // returns here — stand is never reached
const stand = brollSourceForShotType(shot.kind); // correct mapping, never consulted
return stand;
}
// after: the correctly-mapped kind gates whether a library hit is even eligible
function sourceForRefShot(shot, avail) {
const stand = brollSourceForShotType(shot.kind);
if (avail.libraryHit && libraryFitsShotType(avail.libraryHit, stand.kind)) {
return avail.libraryHit;
}
return stand;
}
The classification logic was never the defect. An early return in an unrelated branch meant it was never reached. That's a bug review tends to miss specifically because the correct code is right there in the file, and nothing about reading it in isolation reveals that a different branch returns first.
The gap report that reported nothing on the reference it was built for
PR #421 measures the same failure from a different angle: a "library gap" warning meant to flag when the house library can't actually serve a beat came back empty on the exact reference it had been written for. The rule checking for a gap was servableClips === 0 — a literal zero. The library held exactly one clip tagged for that beat type. One clip serving six separate beats is not zero servable clips; it's the same clip shown six times, which is precisely the "repeated irrelevant b-roll" complaint the check was supposed to catch. The fix reframes the measure as beats-per-servable-clip and reports the repeat count directly, in a sentence a reader can act on without doing the division themselves.
A generated span with no prompt, and a mascot answering questions it couldn't see
PR #428 found that four of eight generated b-roll spans on one render carried prompt: undefined — the field was declared in the return type and set by no branch that actually produced it, so every downstream consumer that read it got nothing and silently fell back to a generic sentence about "a natural, candid lifestyle moment." The actual scene description the pipeline needed — "a busy coffee shop, late morning" — had been captured earlier in the pipeline for an unrelated library lookup and then dropped on the floor one function later, never forwarded to the branch that needed it to build a real prompt.
PR #429 found the sibling bug on the evaluation side: the criteria used to accept or reject a generated span were matched to the planner's intent by array index, while the span's actual visual kind was decided independently, a few lines later, by a completely different function. The two routinely disagreed — a cartoon-mascot reference shot could re-kind a product candidate into a mascot shot, and the acceptance criteria for the resulting span were still the ones written for a product. One span was rejected for containing a cartoon mascot, using a criteria list that explicitly named "no jar, bottle, cream, or cartoon mascot" — a rejection for being exactly what the pipeline's own logic had decided to make it.
A stranger in the frame, and the fix that fixed the wrong half
PR #458 is the sharpest content-quality bug in the whole cluster: four cutaways on one delivered render showed the wrong person's face. The span planner declared a withPresenter field, correctly set by the planner itself, correctly threaded through the scene-rendering path — and silently discarded on the b-roll path, which hardcoded withPresenter: false on every generated span regardless of what the planner had actually decided. Without that flag, no identity reference image was attached to the generation call, and a "lifestyle" shot with no identity anchor produces exactly what you'd expect: an invented, unfamiliar face.
PR #459 is the honest follow-up, caught by a six-reference plan gate before a single dollar was spent on a render: the fix in #458 was correct and did nothing, because the planner's own candidates for that reference set withPresenter to undefined or false on every single one — abstract motion graphics have no presenter to represent, so the flag being forwarded correctly changed nothing about the output. The real remaining bug — a lifestyle cutaway that shouldn't carry the presenter at all still carrying them — needed its own separate fix, which is exactly the kind of near-miss the team's own handoff docs started explicitly calling out by name: a fix that reads correctly and changes nothing, discovered only because someone measured the actual output against the specific reference the fix claimed to address.
An exclusivity that was never documented until it broke
PR #464 found the deeper cause underneath: a presenter-carrying cutaway was sent zero product reference images by design, an "undocumented design dichotomy" from an early commit — a shot could show the presenter living the moment, or the product in context, never both — because nothing had ever needed both at once. Widening an earlier fix to cover more cutaway shapes as presenter-eligible turned that old, silent assumption into a live defect: a cutaway carrying the presenter now also needed the product's reference images to render the product correctly, and the code had never been asked to send both.
A color grade that was never being called at all
PR #443 might be the single best "read the invariant, don't trust the comment" bug in this cluster. A render's saturation measured 10.19 against a reference's 26.11 — a 2.6x gap the grading function's own 1.2x cap couldn't close even if it ran. That's the obvious, wrong explanation. The actual cause: the grading function had been imported and was called from nowhere in the entire codebase, while a comment in the same file asserted "the color grade ALWAYS applies." A false invariant, stated confidently enough in a comment that nobody went looking for the call site that didn't exist.
PR #472 picked up the same area two rounds later and found the opposite kind of subtlety: once the grade was wired up, it applied one global multiplier to bring the whole picture's mean saturation to the reference's mean — and in doing so pushed already-vivid generated cutaways to a peak of 36.2 while presenter footage sat near 20, because the underlying footage varied 4.4x internally and a single global correction can only target the mean, never the spread. "A viewer sees the peaks; every number we had reported the mean" is the whole bug in one sentence — three separate reports in this area had measured means and missed the actual visible defect until someone looked at the per-segment range instead.
A cutaway that plays under the wrong line, by a lag that grows
PR #476 closes the cluster with a timing bug whose root cause had been dismissed once already as noise. A function recovering which scene a cutaway plays over walked the planned scene durations, while the cutaway's own placement was measured against the stitched master — and a comment in the code had excused the resulting drift as "about 0.1s per cut" of harmless crossfade error, not worth fixing precisely. That estimate was wrong, and it was wrong specifically because per-scene pace correction rescales each scene to fit its voiceover without ever resetting cumulatively — so the drift compounds across scenes rather than staying flat, landing at 6 to 11 seconds of lag on a render where the original comment predicted a fraction of a second.
The pattern: a defect survives review until someone measures the mechanism, not the output
Nearly every fix in this cluster follows the same arc: a symptom gets reported, a plausible cause gets identified and fixed, and the fix ships clean — and then a subsequent measurement, often a cheap plan-gate run costing a few dollars rather than a full paid render, finds that the mechanism the fix depended on never actually executes for the case that mattered. The team's own handoff documentation started naming this pattern explicitly as "near-misses" specifically because it kept recurring: correct code, unreachable in practice, indistinguishable from working code by review alone. The fix wasn't better code review. It was cheap, repeatable measurement runs against real references, specifically built to answer "did the mechanism actually fire on this case" rather than "does this look right."
