The Business Reality6 min read

My Gate Wasn't Killing the Games — It Was Killing One Impression

14 external visits against a threshold of 20, so: KILL. But over those nine days, my automated channels featured the games exactly once. A verdict with a numerator and no denominator rejects your distribution, not your asset.

#measurement#reality-check#automation#verification
Left: the gate compares 14 external tokens against a threshold of 20 and prints KILL. Right: the same window contained one automatic exposure, so the number was measuring channel absence, not the games.
Same number, different denominator. Until I wrote the denominator down, I was about to kill the wrong thing.

I built seven small web games and pinned a decision date to them: "If external visit tokens are under 20 by 2026-08-27, stop making new games." A report runs on its own, counts weekly, and prints the verdict itself when the date arrives.

Five days out, I opened the report. External tokens: 14. Threshold: 20. Left alone, on 08-27 it would print this:

KILL: decision date passed, external tokens 14 < 20. Stop new game production.

The number is right. The rule is one I preregistered myself. But what does that sentence say to me six months from now? "Nobody wants the games." That becomes the lesson I learned that day.

Does your decision rule have a denominator?

I decided to count one more thing: over those nine days, how many times did my automated channels actually feature these games?

I counted it straight from the posting ledger.

Automatic game exposures since 2026-08-14: 1 — 2026-08-22 app-choseong

Instagram: zero. Threads: one. And that one was today. The rotation pool holds 31 apps, and the posting rule picks apps on odd days and horoscopes on even days. When a game's turn lands on a horoscope day, that slot is skipped entirely. So across nine days, exactly one went out.

I was about to conclude "games don't work" from 14 visits generated by one impression. What I had measured wasn't the appeal of the games — it was the emptiness of my distribution. And distribution being empty was already the answer from an asset audit two months earlier, so this verdict adds no new information at all.

I hit the same disease four times in one day

I'd like to say it was a one-off. But when I swept every live gate that day, the same shape kept appearing.

A product-title experiment. I rewrote the names of three storefront listings and planned to compare "7 days before" against "7 days after." On the decision date, every value in the before window was zero. All 145 listings had been registered after that window. I had picked a baseline period in which the subject did not exist. The change rate was zero divided by zero — not a small effect, an uncomputable one.

Marketplace actors. I published four data actors and set "5 external users in 30 days" as the threshold. But from publication through the decision date, those actors were excluded from the store's default search results (an unfinished account verification). The entire observation window was a period in which discovery was impossible.

A confidence game. I attached "30 external tokens by the decision date" to a new release. When I computed the rotation, that app's turn came up on exactly one day before the deadline. One post cannot bring 30 people, so the verdict had been fixed at FAIL from the moment I wrote it.

All four had carefully chosen thresholds. In all four, I never wrote down how many chances there would be to reach that threshold.

Lower the bar, or refuse the verdict?

There's a fork here. When a verdict looks like it's going to come out wrong, you have two moves.

One is to lower the threshold. 20 becomes 10, 30 becomes 5. The verdict "comes alive." And it means nothing, because moving the bar after seeing the data isn't a verdict — it's rationalization with extra steps.

The other is to state the denominator and refuse to judge when it's too small. You get no conclusion. It's unsatisfying. But no false lesson survives it.

I took the second one. The report grew a section:

## Automatic exposures (the gate's denominator)
 
Automatic game exposures since 2026-08-14: 1 — 2026-08-22 app-choseong

And the verdict logic changed. Under five exposures, it no longer prints KILL:

NO VERDICT (too few exposures): 1 automatic game exposure < 5.
The 14 external tokens are not evidence about game quality —
they are a measure of channel absence.
 
DECISION: stop new game production. This is not a verdict, it is an
investment call — no new production budget goes into assets with no
distribution path.

The decision still executes. Not funding new production for assets with no distribution is reasonable regardless of any verdict. What changed is that the sentence now says so out loud. If you blend the verdict and the decision into one line, what survives is a lesson with no evidence behind it.

Don't count the denominator by hand

One more thing. If a human counts exposures, then every decision date runs on memory. I made it count from the posting ledger instead.

def game_exposures() -> tuple[int, list[str]]:
    """How many times automated channels featured a game since BASELINE.
    If a ledger is missing, raise — a failure is not empty data."""
    hits = []
    for log in POST_LOGS:
        if not log.exists():
            raise FileNotFoundError(f"posting ledger missing: {log}")
        ...

The last line is the point. If a missing ledger returns zero, then "no exposures happened" and "I couldn't read the log" become the same value — and a collection bug quietly kills an asset. Raising means the report prints "ledger read failed" and no verdict goes out.

A three-line self-check

If you have a decision rule running right now, check these three things.

  1. Is the observation window inside the subject's lifetime? Actually read the creation date of the listing, the page, the account. Pick a baseline before that and you'll be dividing zero by zero on decision day.
  2. How many chances to hit the threshold occur inside the window? If you can't write that line, the gate isn't ready to be set.
  3. What does it print when the denominator is short? If the answer is FAIL, that FAIL is a sentence rejecting your distribution, not your asset.

The honest part

This isn't a success story. I had already written "calculate power first" into a post-mortem and then failed to apply it to four live bots. That time it was sample size; this time it was exposure count. Different names, same disease — pinning a decision date before securing what the decision requires.

Choosing thresholds is fun. A plausible number appears and you feel rigorous. Counting the denominator is not fun. It usually returns something shabby like "1," and the moment you see it you know the whole experiment was pointless.

But that's what happened when I computed power before running an experiment too. A boring calculation cancelled an entire experiment, and that was the most valuable thing it did.

Is there a gate in your stack with a threshold but no denominator written down? Pick one and count it today. Three of my four were sick.

Related