Three unrelated-sounding questions turned out to share one root cause this round on the main video-generation service: why does every archived run use the same visual style, why does a $0.05 review-gate preview sometimes show something the paid render never produces, and why does restoring a run after a redeploy occasionally come back missing things nobody noticed were missing. Different symptoms, same answer each time — somewhere in the pipeline, two components had quietly stopped agreeing about what was true, and nothing was checking.
A preview that looks healthy and a render that looks healthy are not the same claim unless something has verified they're describing the same picture.
Styles: an operator's choice silently overridden by a default
The question that started this cluster was simple: do styles other than the pipeline's original Pixar-like default actually work? The measurement was blunt. Across all 53 archived runs on disk, pixar was the only visualStyle value ever recorded — and PR #1138 found that wasn't for lack of trying. resolveRunMediumWithStyle read visualStyleMedium(vs) ?? imageMediumSetting, and visualStyleMedium("custom") returned "live-action" — a non-undefined answer, so the ?? fallback never fired and a hand-set imageMedium: animated was silently discarded. An operator could pick "Others," type "claymation stop-motion," explicitly set the medium to animated, and still get live-action back. An entire category of output was unreachable through any combination of settings the form offered, and the deep machinery gated on medium === "animated" — the stylized twin, animated-person rules, realism-critic stand-downs — had simply never fired in production.
Fixing the gate didn't finish the job. PR #1139 ran two $0.20 probes at two operator-named styles and opened the resulting character twins at full size: a claymation request came back as genuine stop-motion, but a "2D hand-drawn anime, flat cel shading, no 3D rendering" request came back as a smooth 3D render — essentially the Pixar look again, just reachable now instead of blocked. No metric would have caught this; both runs reported medium: animated and carried their own style clause correctly. The cause was in the prompt itself: STYLISE_PROMPT opened by asserting "a STYLISED 3D-ANIMATED CHARACTER" and then appended the operator's 2D request afterward, rather than replacing the 3D assertion with it. PR #1140 traced this to a real finding in the generative-image literature the team already cited elsewhere — appending a contradicting instruction after an existing assertion is the weakest repair pattern tested, working in roughly 13% of cases, versus directly replacing the unwanted assertion with the desired one. The fix wasn't a better sentence; it was restructuring which clause got to make the claim at all.
The same contradiction showed up one layer down. PR #1154 found a character portrait — the single photograph that anchors every human frame's identity in a run — deciding its own visual register from a hardcoded string rather than the run's actual style clause, so a custom 2D request would get a Pixar-style portrait as its identity anchor regardless of what the operator typed. And PR #1160 found that a style's own described set and materials only ever reached cutaway shots, never person beats, because the compiler chose between a "has person" and "personless" style clause and routed the set description only through the personless branch — leaving every custom style with a person in frame and no description of the room around them at all.
A fallback that quietly won by being prettier, not by being asked
The sharpest bug in this cluster involved two different image models disagreeing about who should render a scene, with nobody deciding the winner on purpose. PR #1152 found one ad shipping with two image models' faces mixed across its clips — a scene's candidate list can hold outputs from more than one model when a fallback fires, and the scoring step that picks the best candidate has no opinion about which model drew it. The best-looking fallback output simply won, silently.
The initial diagnosis blamed the fallback mechanism itself. PR #1157 went back to the cost ledger, grouped by actual in-process task, and found that explanation didn't survive contact with the data: one task in the run held 34 frames from one model and 7 from another, mixed inside a single task — something the fallback logic can't produce, since it refuses to revise a pin once a frame already exists. The real cause, in PR #1159, was that the image-model "pin" — an in-process lock recording which model a run committed to — lived in a plain in-memory map that only got populated at the start of a full task. Editor-triggered redos and regenerations dispatched through a different code path that bound the run's scope but never acquired a pin, so a redo on a Gemini-pinned run would silently fall through to an unset ambient default that happened to resolve to a different model entirely. The team's first explanation — a vendor failing over — was wrong, and correcting it mattered, because the real fix (recover or re-acquire the pin on every dispatch path, not just the first one) is nothing like what you'd build to guard against vendor flakiness.
Previews: the cheapest gate lying about the thing it exists to show
A review-gate preview is supposed to be the inexpensive look at an ad before real money commits to it. This round found that promise broken in several distinct ways, each one undermining the entire reason the gate exists.
PR #1141 found every 4:5-aspect preview returning a 400 from the vendor — the requested resolution sat under a minimum pixel floor that 9:16 and 16:9 happened to clear. Because the failure surfaced as previewStatus: null rather than an explicit error, it read as "not generated yet" instead of "broken," and 4:5 happens to be the aspect every run using the pipeline's default style renders at. PR #1144 found the same null-reads-as-nothing-happened failure mode on reference-less runs: the batch preview pass skipped any scene missing a reference keyframe, and a reference-less run has no reference keyframes by definition — so eighteen of nineteen scenes on one measured run silently produced no preview at all, with only the single b-roll beat (which takes a different code branch) rendering anything.
PR #1150 found a preview that rendered successfully and was still wrong: a three-person cast beat's preview passed a single identity photo, while the real frame-generation step resolved every bound cast member and handed the rest over as additional reference images. The preview and the real frame answered "who is in this shot" from two different code paths, and only one of them was correct — so an operator approving nineteen beats of what looked like a solo presenter was approving a three-person ad they hadn't actually seen. PR #1153 found the plan-gate preview — the cheapest possible look at a swipe-mode ad, priced at five cents specifically so a bad plan could be caught before any paid frame exists — anchoring every post-scene-one person beat on "the first human scene's rendered frame," which is correct once frames exist and impossible at the plan gate, whose entire premise is that nothing has rendered yet. Those beats were handed a file path that didn't exist and couldn't until the operator had already approved and paid. And PR #1165 found the fallback preview template for every single scene using an identical, unconditional selfie composition — eyes at the lens, UGC framing — regardless of whether the beat was actually a narrated voiceover scene where the subject shouldn't be addressing the camera at all; the bug survived because every real, authored frame overrides the template entirely, so it was invisible on any run doing real work and only visible on the exact fallback path nobody was checking.
A gate is also supposed to stop a run, not just flag it. PR #1145 found a storyboard-error severity that the code's own documentation said should block approval without an explicit human acknowledgment — and nothing implemented that block. The only consumer was an autopilot "hold," which merely pauses automatic advancement; it doesn't make the approve route refuse. The team's own fleet-testing harness then cleared every such hold automatically after a 240-second stall, meaning a genuine plan-infeasibility or cast-contradiction error parked an unattended run for four minutes and was then waved through by the automation built to run tests, at precisely the one checkpoint where stopping was supposed to be mandatory and free.
Checks that exist, fire correctly, and change nothing
The most expensive bug shape in this round wasn't a missing check — it was a check that worked exactly as designed and had no path to acting on its own output. PR #1155 found that a lip-sync desync detector, built specifically to catch narrated beats whose rendered mouth movement can't possibly match the voice muxed in afterward (the two are generated independently, by construction), fired correctly on twelve of nineteen beats on one run and eleven of thirty on another — and nothing downstream ever read the result. The redo pipeline filtered only on a different, unrelated flag; the approve gate only blocked on error-severity findings, and this detector reported at warning severity. The detection logic had been deliberately split out of a broader check for accuracy, and in the split, silently lost the only code path that would have turned "detected" into "fixed."
A second judge is similarly only useful if its verdict is actually consulted correctly. PR #1148 found a redo mechanism whose own code comments insisted, twice, that only a criterion both judges failed should justify spending a paid retry — the intersection, not the union — while the actual implementation took the second judge's failure list wholesale. A clip got bought whenever the second judge failed any criterion at all, including ones the first judge had explicitly passed, defeating the entire reason a second judge exists.
Restore: artifacts that a redeploy quietly fails to bring back
The restore bugs in this round form their own small escalation. PR #1161 found that a bound cast's per-member reference photographs didn't survive a container redeploy — the restore routine's pattern-matching for "the character photo" matched only the single-presenter filename exactly, so per-member files written for a bound cast were never pulled back from storage. The failure mode was specifically deceptive: the legacy single-photo endpoint still answered with a 200, because a different, older photo genuinely did exist under that name, so the run looked healthy right up until something asked for a specific cast member by ID and hit a bare file-not-found five times in a row.
PR #1162 treated that as a symptom of a broader, unaudited mapping rather than a one-off miss, and checked every file-mirroring call site against every restore pattern in the codebase — finding four more mismatches, including the inverse of the cast-photo bug on a different code path, and a saved clip take whose filename convention (a dot the mirror step turns into a dash) simply had no corresponding restore rule at all. PR #1164 went one level further and asked a sharper question: what does the restore audit's own completeness check actually verify? The answer was that it could only catch artifact classes that are mirrored but map to the wrong name — an artifact nobody mirrors at all has no entry to fail on, so a true blind spot read as a clean bill of health. The fix wasn't more pattern-matching; it was an explicit, must-maintain list of every deliberately-unmirrored artifact and the reason each one is excluded, so the next person meets a documented decision instead of a silence that looks identical to correctness.
The pattern: verify the second claim, not just the first
Every bug in this post is the same shape wearing different clothes. A setting existed and a different code path silently overrode it. A prompt made an assertion and a second prompt contradicted it without replacing it. A preview rendered successfully and rendered the wrong thing. A check fired correctly and nothing consumed its output. A restore routine ran without error and restored the wrong subset of files. In every case, the first-order fact — "the setting is stored," "the check ran," "the restore completed" — was true and completely insufficient. The actual defect only became visible by checking the second, harder claim: does this setting reach the place that renders pixels, does this check's output reach a path that can act on it, does this restore step's coverage match everything a run actually writes. A system with enough moving parts will always have components that are each individually correct and collectively wrong — the only defense is measuring the handoff between them, not just the components themselves.