I Went to Turn Up the Output Knob and Found It Wasn't Connected

I was asked to scale up the shorts channel. An unattended pipeline builds and uploads videos daily, so this looked like turning up a generation count.

Before turning it, I read the log. The knob had never been connected.

When your automation says it made three, do three actually ship? I had been reading the planned number and never the shipped one.

Three planned, one shipped

The pipeline plans three videos per language per day: two personality, one compatibility. The publish cap is three, so the cap isn't the limiter.

Here's what the log actually said.

[ko] all approved (1 reviewed)
[en] all approved (1 reviewed)
[ko] to publish: 1 (queue 1)

Only one item reaches the review committee. Two disappear before they get there.

The planning stage was fine. Running the planner directly produced exactly two per language.

[ko] next rotation (weighted): [('ddi', 'd'), ('animalface', 'wild')]

So I ran the generation stage for real. One line came out.

skip (duplicate): animalface_soft

The queue never forgets what it shipped

Personality content uses slugs shaped like {app}_{group} — animalface_soft, zodiac_fire, ddi_d. The generator skips anything whose slug is already in the queue.

The catch: the queue does not remove items after they publish. They stay forever. So "skip duplicates" becomes a death sentence.

Four apps, a handful of groups each. The combinations are finite. Once every one has been produced, the personality track can never generate anything again. Korean and English were already there: zero personality videos, one compatibility video a day.

Here's the part that stings. The best-performing topic — zodiac animals — had used all four of its groups. The content that works could no longer be produced by that track at all.

No error. No warning. Just skip (duplicate) printed quietly every day, with a green dashboard above it.

Here's the fork — what would you do?

The obvious fix is right there. Add a revision suffix and regenerate. animalface_soft then animalface_soft_r2. A cooldown already enforces spacing between repeats, so it looks safe.

Ten minutes. I did exactly that.

It ran. regenerated: animalface_wild_r2, render succeeded, queued. Then I compared it to the original.

original hook:    'The attractive animal face?'
regenerated hook: 'The attractive animal face?'
cuts identical?   True

Same hook, same cuts. The group is three cuts and one hook line. It was the same video with a different slug. Shipping it would have manufactured one reused-content violation per day.

I reverted it, and left the reason as a code comment — so the next person doesn't retry the same "obvious fix."

So what did I actually scale?

There is a track built for infinite supply: compatibility. The combinations explode — 12 zodiac animals give 66 pairs, MBTI gives 120.

So I raised compatibility generation from one to two. That stays under the publish cap of three, so the cap stayed untouched.

Before raising it I checked one thing: do those match URLs actually return 200? Because the same pipeline contains this line.

SKIP match mbti/ko/intp-estj — not 200 (avoiding a screenshot of an error page)

If the URL 404s, the capture is skipped and that day's video is dropped entirely. Raising the count alone would have doubled the skips. I checked twelve ko/en URLs, all 200, then raised it.

Net result: Korean and English go from one video a day to two, and both are filled with the top-performing topic.

Three things to check

Do your "planned" and "shipped" logs show the same number? Look for a quiet filter between them. Mine was eating two thirds.
Does your duplicate check compare against a set that only grows? If the queue keeps published items, duplicate-avoidance slowly becomes production-prohibition. With a finite key space it eventually reaches zero.
Do you verify the source URL is 200 before generating from it? Capture-based pipelines either screenshot an error page or skip silently. Both make output vanish.

The honest part

This is not a story about broken automation. Everything ran as designed. Duplicate avoidance is a feature, and the personality track being finite was intentional — infinite supply was the compatibility track's job.

Except that same morning I found the compatibility track wasn't reading its own performance scores. Put the two together and you get this: the finite track was exhausted, and the infinite track was locked onto the losing topic. Each was a design decision. Combined, they were an accident.

What I took from it: read the log before you turn the knob. Had I only turned it today, the number would have gone from three to four, the output would have stayed at one, and I would have reported "scaled up."

Put yesterday's planned count and shipped count side by side. If they match, good. If they don't, there's a line in between that reads like the one I found today.