We didn't pick
an idea. We killed
sixty-three of them.
Every entrant in this hackathon will submit a product. Almost none will be able to show the selection process behind it. We can — because we ran one on purpose: three AI panels, each spawning its own fleet, generating candidates and then attacking each other's, against two hard tests that killed ideas for cause, not for taste. This page is that record, with nothing smoothed over.
- Panels
- 3
- Candidates generated
- ~72
- Candidates killed
- ~63
- Decisions logged
- 29
Three panels, cross-challenging each other.
Each Opus panel lead ran its own 4-agent Sonnet fleet. Two panels generated candidates from opposite directions — one starting from the format, one from the mechanic. A third didn't generate ideas at all: it simulated the other 200 people in the room.
Format-first
Started from "what boring document is this," then found the mechanic. 24 candidates generated. Top pick: a pay statement re-denominated into hours of your life — then killed by its own panel (see next section).
Mechanic-first
Started from "what hidden truth could a document reveal," then found the format. Killed all four of its own receipt variants despite the highest raw drama, because three of its four independent generators produced a grocery receipt unprompted — a direct measurement of where the field is heading.
Field simulation
Generated nothing. Four Sonnet agents role-played competitor archetypes — vibecoder, full-stack dev, designer-founder, show-off engineer — and predicted what ~200 entrants will actually build. Prediction, not fact; the ranking is what matters, not the exact counts.
The question that killed the panel's own favourite idea.
Panel-alpha proposed a test, then applied it to its own top-ranked candidate — and let it fail. That is the most intellectually honest moment in the whole record, and it's the reason the final pick has no hollow centre.
Does the mechanic add information that was NOT in the source document — or does it just re-render information that was already there?
— the test panel-alpha proposed, then used against itself
- Take a pay statement.
- Re-denominate every line into hours of your life.
- Hero: an 80-hour week bar, segmented by where the hours went.
- "HOURS YOU KEPT: 14.2 of 80"
- Ran the real arithmetic: Alberta tax, CPP, EI, RRSP.
- The drama — how few hours you "kept" — depended on those figures being dramatic, not accurate.
- A real paystub's math is mostly unremarkable. Making it hit hard meant inventing a harsher deduction picture than reality.
- Verdict: a monotonic transform of numbers already on the page — it re-rendered the source, it didn't add to it.
This is also why the final pick works: page breaks, blank-page detection, and ink coverage are all genuinely measurable from a real rendered document. Nothing about the print dialog's numbers has to be sweetened to be dramatic — see §7.
If the data has to be invented, the idea is dead.
A harder, blunter rule than the first: not "is the transform interesting" but "can this number be produced for real, in a browser, with no backend." Five candidates died on exactly this, including the format that was locked first.
The obvious pile-up, and the subtler one underneath it.
The field-simulation panel found what everyone expects — and then something most people wouldn't think to look for.
The obvious pile-up (predicted, of ~200 entrants)
| # | Format | Predicted count | Confidence |
|---|---|---|---|
| 1 | To-do / task manager | 34–42 | High |
| 2 | Weather | 15–20 | High |
| 3 | Notes / journal | 15–19 | High |
| 4 | Habit tracker | 14–18 | High |
| 5 | Expense / budget | 13–17 | High |
| 6 | Pomodoro timer | 11–15 | Med-high |
| 7 | Calculator | 10–14 | Med-high |
| 8 | Recipe / meal planner | 9–13 | Med |
| 9 | Calendar | 8–12 | Med |
| 10 | Music player | 5–8 | Med |
~85% of the field is predicted to land in these ten formats. To-do alone is roughly one entrant in five. All ten, "gamification" included, were treated as saturated at any quality.
The trap for the good ones.
The ~15–25 taste-literate entrants won't pick a to-do list. They'll independently converge on the same look — because it's the move a design-literate person reaches for. Being excellent there means being invisible.
The single most crowded slot at the top of the field is predicted to be the boarding pass / ticket / transit card — an estimated 8–12 of the ~20 tasteful entries alone.
bty
"acid" skin outright — the exact toxic-on-black direction we had in hand. The escape routes
identified were a non-dark, non-neon palette, or a one-line caption naming something no other
entry named. PROOF took the first: white ground, saturated primaries (#2B3BFF /
#FF4D9E / #FFD21C), hard offset shadows, rounded display type —
the bty "pop" skin, not "acid." D19 in the decision log.
The honest ledger.
Sixty-three ideas is too many to list individually. These are the ones worth naming — including the two the user rejected outright, overriding the panels.
Killed by the user, for failing instant comprehension
Killed on assessment, before the print dialog was chosen
Killed inside the panels, round one
Real runners-up — not killed, just outscored
Lowest saturation of anything either panel found — but it swaps the user from diner to owner, which may read as replacing the format rather than reinventing it.
Highest predicted LinkedIn-repost ceiling of anything generated. Risk: reads as data-art rather than a reinvented app, and the "Mom" framing can read as cheap emotional leverage.
Inverts who the document is addressed to. Lowest screenshot density — one page of typography looks thin on its own.
Pay $85 vs. contest — 61% dismissal rate, ~12 min average. Beats jury duty on recognizability, loses on novelty.
A dialog where every number is real.
The print dialog survived both gates because pagination, blank-page detection, and ink coverage are all genuinely measurable from a real rendered document. That's not a claim — it's checked twice, automatically.
Ink is measured, not rendered as pixels
Coverage comes from reading back the actual glyph-run rectangles the layout engine
produces (Range.getClientRects) across all 15 pages of the sample document
— never from rasterising the page and counting dark pixels.
Real pagination, real waste
Of 15 paginated sheets, 5 are flagged as waste under a 2.0% ink-coverage threshold (mean ink across all pages: 2.9%). Dropping them takes the job from 15 sheets to 10.
verify.mjs
Drives the real app in a real browser and asserts the claims on screen — every page measured (never estimated), every waste page under threshold, dropped pages actually excluded from the print root, no console errors, clean on mobile. 20 assertions, all passing.
verify-print.mjs
Renders the app to an actual PDF the way a printer would receive it, then counts the
pages in the output file. Full job: 15 pages. Reduced job: 10. Exactly the 5 dropped
sheets disappear. It caught a real bug — a trailing blank page from
page-break-after — which is now fixed.
The method is stated in the app's own UI, not just in this document — a "measured · glyph-run geometry" badge sits next to the count, because a tool that claims to measure honestly should say how.
Every decision, in order, with why.
The direction changed several times — DOSE was locked, then killed; the palette was reversed after D19; a "no reopening" rule was deliberately broken once, on purpose. None of that is hidden. The changes are the story, because each one was caused by evidence, not preference.
| # | Decision | Rationale |
|---|
- Panels run
- 3
- Formats locked
- 2
- Hard gates
- 2
- Decisions logged
- 29