Ship or Stop

Start from brute force

The obvious gate is the dashboard reading: ship when curr["verifier_pass"] > prev["verifier_pass"] and the canary wins more than half its runs. It is O(1) time and O(1) space, and it ships the first example correctly. It is wrong in the cases this gate exists for. On the reward-hacking round, where the verifier rose 0.13 and the humans 0.01, it returns True. On a canary that has not started, wins / runs raises ZeroDivisionError instead of reporting that the sample is too small. And it returns a bare boolean, so when it does refuse, nobody knows which number to look at first.

The approach

Treat the gate as an ordered checklist and append as you go. The reference builds one list, stops, and runs the checks in exactly the statement’s order, so the output order is the contract and never needs sorting. Every check compares curr against prev, because each number only means something as a change.

Two checks have two halves: reward-hacking needs d_verifier > 0.01 and d_human <= d_verifier / 2, and memory-bloat needs the store to grow and the hit rate not to. unreproducible is guarded by curr["weights_updated"], so a prompt-only round cannot fire it. The canary comes last as an if/elif: canary["runs"] < canary["min_runs"] is tested first, and only otherwise is wins / runs computed, which keeps a 0-run canary from raising and makes the two canary stops mutually exclusive. Finally "ship": not stops means the flag can never disagree with the list.

Walk through an example

With prev at verifier 0.61, human 0.48, frozen 0.540, distinct 2.90, 1200 rows and rollback available, a curr that changes verifier to 0.74, human to 0.49, frozen to 0.51 and can_roll_back to False, and a canary of 5 wins in 5 runs against min_runs = 200, four of the eight checks fire.

Complexity

The reference and the one-line gate are both O(1) time and O(1) space: eight comparisons over a fixed set of keys, and a list of at most seven names, since the two canary stops exclude each other. The difficulty is correctness at the boundaries: strict versus non-strict comparisons, a division that must be guarded, and floating-point deltas.

Edge cases to test

• A canary with 0 runs reports canary-too-small instead of raising, because the size check runs before the division. The guard relies on min_runs being positive: with {"runs": 0, "wins": 0, "min_runs": 0} the reference raises ZeroDivisionError.
• Floating-point deltas decide exact boundaries. 0.62 - 0.61 is 0.010000000000000009, so a verifier gain of “exactly 0.01” fires reward-hacking. And a human gain of exactly half on paper (verifier 0.61 → 0.71, humans 0.48 → 0.53) computes as slightly more than half and does not fire. Use integer basis points or an explicit tolerance if those boundaries matter.
• A level canary, 100 wins in 200 runs, fires canary-not-ahead, because the rule is wins / runs <= 0.5.
• Diversity at exactly 80% does not fire: 2.90 * 0.8 is the threshold itself, and the rule is a strict <.
• No condition looks at a plain drop in the pass rates: with verifier 0.61 → 0.50 and humans 0.48 → 0.40 and everything else unchanged, the round ships. Regressions are meant to surface in the frozen set.
• A store that shrinks never fires memory-bloat, even when its hit rate falls (rows 1200 → 900, hit rate 0.34 → 0.20).

Common mistakes

• Sorting or de-duplicating the stop list. The order is specified; a caller reads the first entry as the most urgent.
• Using <= on the frozen set. It has no tolerance: any drop is a stop, and an unchanged frozen set is not.
• Computing wins / runs before checking runs, so a canary that has not started yet raises ZeroDivisionError.
• Firing unreproducible when no weight update happened. The condition is about a weight update you cannot re-derive, not about missing paperwork on a prompt change.
• Treating a round with identical measurements as a stop. Nothing got worse, so nothing fires.

Follow-ups an interviewer asks next

How would you make the canary check statistically sound?

Require a confidence bound above 0.5, not just a raw rate. With a 95% Wilson interval, 130 wins in 200 runs has a lower bound of about 0.58, so it is ahead; 11 wins in 20 has a lower bound of about 0.34, so it proves nothing. Fix the sample size in advance either way: checking repeatedly and stopping at the first good reading inflates false positives.

The list of conditions keeps growing. How do you keep it maintainable?

Make each condition a named row in an ordered table, a name plus a predicate over (prev, curr, canary), and loop over the table. The order then lives in one place, each rule can be unit-tested alone, and a new condition is one row. Keep the canary pair as a single row, since its two outcomes exclude each other.

What should happen after a stop fires?

Block the release and route the first stop to its owner: reward-hacking to whoever owns the verifier, unrollable to the release process. Log every measurement alongside the decision, so a reviewer can later see why a round did or did not ship. An override should be possible but never silent: it records who made it and why.

Why compare against the previous round instead of a fixed bar?

Because each number is meaningful only as a change for the same agent on the same evaluation. A fixed bar such as 0.7 verifier pass would accept a round that cleared it by gaming the verifier and reject a round that held steady on a harder task mix. Comparing curr with prev asks whether this round made things better, which is the question a ship decision has to answer.

Where this shows up

This is the gate between “the loop ran” and “the loop shipped”. Every condition here exists because some number that went up was mistaken for an agent that got better: a verifier agreeing with itself more, a model narrowing onto its own habits, a canary read early because it happened to be ahead. Writing it as code rather than a wiki page is what makes it a gate instead of a good intention.

Check yourself

Reference solution

def ship_or_stop(prev, curr, canary):
    stops = []

    d_verifier = curr["verifier_pass"] - prev["verifier_pass"]
    d_human = curr["human_pass"] - prev["human_pass"]
    if d_verifier > 0.01 and d_human <= d_verifier / 2:
        stops.append("reward-hacking")

    if curr["frozen"] < prev["frozen"]:
        stops.append("frozen-set-down")

    if curr["distinct_per_task"] < prev["distinct_per_task"] * 0.8:
        stops.append("diversity-collapse")

    if curr["memory_rows"] > prev["memory_rows"] and curr["memory_hit_rate"] <= prev["memory_hit_rate"]:
        stops.append("memory-bloat")

    if not curr["can_roll_back"]:
        stops.append("unrollable")

    if curr["weights_updated"] and not curr["training_set_reproducible"]:
        stops.append("unreproducible")

    if canary["runs"] < canary["min_runs"]:
        stops.append("canary-too-small")
    elif canary["wins"] / canary["runs"] <= 0.5:
        stops.append("canary-not-ahead")

    return {"ship": not stops, "stops": stops}