Pelagic Video Fidelity

Headline finding: the fix that actually scales isn't a cleverer prompt — it's simpler than that. Feed the model real, undegraded catalog photos instead of the padded/AI-outpainted stack production has been building, and a fully generic prompt (no per-product authoring at all) gets every headline defect fixed. A hand-written, per-product prompt was tried first and looked like the answer — it wasn't. See Section 5.

189 "video ads" were actually 18 real generations plus 171 derives

A derive is a free crop/retitle of an already-existing master into a different aspect ratio — it never generates new pixels. Splitting the two out:

Worse: 44 derives of a passing master still failed, and 9 derives of a failing master passed. Production QC on a derive is largely noise — the ~20% headline number was a derive statistic, not a generation-quality statistic.

Even the real 62% wasn't the full story

Production's own quality check judges each video against the reference stack it was given — which is itself padded, cropped, or AI-outpainted, not the real product photo. Judging the same 14 masters directly against the native catalog photograph instead:

A. A live money leak — refinedProducts missing from the catalog query

The code that decides "can we free-crop this reference, or do we have to pay for an AI outpaint" needs YOLO-detected product boxes. The query loading sibling reference images for a video simply never requested that field. Every auto-assembled sibling was forced onto the paid path regardless of whether a free crop was possible.

Found a teammate had already fixed this in a copy of the code that isn't the one actually running in production. Fixed in the live renderer, deployed.

B. Seed images padded at the wrong scale

The product-only seed image was padded to the video's delivery resolution (as small as 720×720 for the product itself) instead of the source photo's own resolution — throwing away most of the real detail before the video model ever saw it.

Fixed — pad now derives its canvas from the source image, preserving up to 3× more real pixels of the product.

C. The "zoom to detail" instruction was the single biggest source of invented defects

Counting every defect found across the 14-ad blind pass by the video timestamp it appeared at: the frame at the midpoint — exactly where the prompt says "slow zoom toward the most distinctive product detail" — carried 6 of 11 total defects. The zoom wasn't panning across real pixels; it was cutting to a newly generated close-up, and that's where the model invented things.

Partially addressed — see the real fix in Section 5, which supersedes the original "just remove the zoom" attempt.

What was verified, directly against Atlas's own API

The exact same combination that had been generating successfully all day — duration=10, aspect_ratio=9:16 — started returning:

HTTP 500 → "All channels failed. Last error: HTTP 422:
The model 【omni_flash-10s-portrait】 does not exist"

Confirmed by fetching the byte hash of the "new" video and finding it identical to the pre-outage file — Atlas never generated anything new, and critically, never billed for it either. One real generation that landed during the same window (a different ad, retried automatically) proved the persist logic itself was fine — when Atlas returns a real video, it saves correctly. The failure was isolated to one internal Atlas routing channel for that specific duration+aspect combination, confirmed by direct API calls, not inferred.

A retry policy was also caught and stopped mid-flight — it was about to auto-resubmit two more ads into the same dead channel.

Reference images actually supplied

Same three-image stack the production pipeline builds for every ad — shown here so the comparisons below are legible against real inputs, not assumed ones.

Three arms, same product, same original prompt

Same product, same prompt, three genuinely different outcomes — proof that the model, not just the reference prep, is a real variable in fidelity.

Why the hand-written approach hit a real wall

The sleeve print refused to clear no matter how the prompt was worded — the block explicitly said "forearms otherwise blank" and the model still copied a stacked invented print onto the sleeve. The reason: that print was already baked into the reference photo itself — a leftover artifact from an earlier AI-outpaint step. No prompt instruction can override what the model is literally shown in a picture.

Worse, on a second product the hand-written marks were factually wrong: the block said the waistband had "NO second line," but the real catalog photo genuinely shows BUILT FOR FISHING as a second line. The manual authoring had suppressed something that was actually true.

Verified independently, on a fifth product

To make sure this wasn't specific to the four ads already under a microscope, the same clean-photo + generic-prompt approach was run on Leaderman — a product that had already passed under the old pipeline, used here as a check that the new approach doesn't regress a product that was already fine.

Mostly clean, with one honest miss worth keeping in the record: the waistband and construction came through perfectly, but a secondary hem tag came out with the wrong layout — the real tag reads "boxed P + fish icon, then PELAGIC below it"; the generated one swapped the order and dropped the box entirely.

Clean photos plus a generic prompt gets you most of the way there — it fixed the hardest marks on every product tested — but it isn't a guaranteed clean sweep on every secondary detail. A mark the prompt never specifically calls out can still drift.

What ships

1. Build the reference stack from real catalog originals — the plain product photo, an on-model shot, and whichever detail photo actually has the readable branding — instead of the padded/AI-outpainted derivatives used today.
2. Use the generic prompt, unchanged, for every product. No per-SKU writing.
3. Optionally, tell the model explicitly which of the three photos to trust for fine print. This turned out to be a non-issue — see below.
4. Keep hand-written marks only as a fallback, for the rare case where the reference stack is unavoidably degraded — never author them from a photo too small to actually show the real letters.

SettledDoes per-image staging require new classification? No — it's already there.

The remaining worry was real: if you want to tell the model which of the 3 photos to trust for fine print, don't you need to run a new vision pass on every catalog image first? Checked against production data: that classification already exists. Every catalog image already carries a label (plain product photo / on-model / detail shot), written once by an existing classifier and reused forever — verified directly against a real product's own 3 submitted photos, where the stored labels matched exactly what those photos show. A second existing field (extracted on-image text) already answers which photo has the readable branding.

One real caveat, also verified: on a different product, "detail" turned out to mean a fabric close-up, not a logo — so the fix reads the extracted text on the selected photo rather than trusting the label name alone. With that adjustment, no new spend is needed for this at all.

AnsweredDoes telling the model which photo to trust help?

Tried explicitly staging the three photos by role — "use this one for the wide shot, use that one for fine print" — on top of the hand-written-marks approach. It worked cleanly, but a direct side-by-side against skipping staging entirely (clean photos, no staging, no per-product marks) showed the marks were reproduced just as accurately either way. Staging is a nice-to-have, not a requirement.

AnsweredDo you need a new vision pass to know which photo is which?

No. Checked against production data: every catalog photo already carries a label (plain product photo / on-model / detail shot), written once by an existing classifier and reused forever — verified directly against a real product's own 3 submitted photos, where the stored labels matched exactly what those photos show. A second existing field (extracted on-image text) already answers which photo has the readable branding, with one caveat: "detail" sometimes means a fabric close-up, not a logo, so the fix should check the extracted text, not just the label name. Either way, this is a code change reading data that already exists — not a new cost.

All spend tracked against a $50 approved budget for this investigation; nothing close to the limit. No billable request was ever retried after a failure — every failed attempt above cost $0, confirmed directly against each provider's own settlement record. One transient (unbilled) API error was retried once, which is why the count of real generations is slightly higher than the ad count.

1. Land the three pipeline fixes (money leak, pad scale, the reframe cache reconciliation) — already written and verified, not yet merged to trunk.
2. Wire the real reference-selection path to catalog originals, not the padded/outpainted stack — this is the change that actually matters, confirmed across five products so far. A second round on five more products, using production's real selection logic, is in progress now to confirm this holds at broader scale.
3. Retire the per-product hand-written marks approach as the default — keep it only as a fallback for the rare case where a clean reference genuinely isn't available.
4. Build the minimal testing harness so this kind of investigation doesn't require hand-rolling a simulation every time — a true dry-run mode that shows exactly what production would submit without paying for it, plus a persisted record of what was actually sent to the model on each real ad.
5. Fix the reference-preparation pipeline itself — the sleeve-print contamination came from an earlier AI-outpaint step, and switching to clean images sidesteps it here but doesn't fix the root cause for cases where a clean photo genuinely isn't available.