Tasks / Experiment

Experiment specification

Can the model design a test that could actually change the decision?

Measures the modelTask v1.0 · 2 casesDifficulty

What AI gets right here, and what you’ll still have to catch

From 14 graded outputs by 7 models. 36% were usable with at most a quick edit.

Reliably right

  1. Addresses the actual decision91% pass
    The output commits to a clear decision rule: launch only if all gates pass, otherwise do not launch, and an inconclusive result is not a pass.
    GPT-6.1 Sol · API · Batching deliveries before peak season
  2. Tests one change at a time86% pass
    It explicitly keeps the free-delivery banner out of the variant and explains that adding it would make the result uninterpretable.
    GPT-6 Luna · API · Showing the delivery fee up front
  3. Identifies material uncertainty84% pass
    It identifies unknowns like power under correlation, carryover, and city differences, and states that if power is insufficient the rollout will not proceed, resolving the uncertainty.
    GPT-6.1 Sol · API · Batching deliveries before peak season

Where it slips

  1. Respects explicit constraints55% pass
    The output is approximately 780 words, exceeding the 'under 700 words' limit.
    Opus 5.5 · Claude · Showing the delivery fee up front
  2. Sized from the real traffic57% pass
    Sample size is correct, but the test stops when the enrolment target is reached rather than running fixed whole weeks.
    GPT-6.1 Sol · API · Showing the delivery fee up front
  3. Guardrails with thresholds59% pass
    Guardrail metrics are listed but no specific thresholds (e.g., maximum acceptable drop in AOV) are given to block rollout.
    GPT-6 Luna · API · Showing the delivery fee up front

Case viewer

Read the brief, then put up to three outputs side by side, each with the LLM judge’s verdict on every check. Highlights mark what a PM had to fix.

The brief

You're a Staff PM at Brisk. We want to know whether to roll out order batching (one courier carrying two orders from nearby restaurants) to all 14 of our cities before the peak-season code freeze on 6 November 2026. Write the experiment spec. Our COO, CFO, Head of Operations and courier relations lead will all sign it off, and each wants something different from it. Keep it under 1,200 words. A draft plan from our data science intern is below. Fix what needs fixing.

What the model was given7 items: About Brisk, What batching should do, What each exec wants to see, Courier agreement in Porto, Timeline, The intern's draft plan, Analyst's note
About BriskFood delivery in 14 European cities, about 1.9 million orders a month. Couriers are paid per order plus distance. Courier cost per order averages €7.40.
What batching should doCOO: “Roll batching out before the freeze if it cuts courier cost per order by at least 5% without making customers wait noticeably longer.” Simulations suggest it cuts courier cost per order by 6–11% and adds 3–6 minutes to the second order in each batch.
What each exec wants to seeCFO: courier cost per order. Head of Operations: the share of orders delivered more than 45 minutes after ordering (today 7.5%). Courier relations lead: courier earnings per active hour (today €13.20). Head of Growth, copied in: 30-day reorder rate.
Courier agreement in PortoOur agreement with the Porto couriers' association requires 14 days' written notice of any change to how orders are assigned, and says changes must not reduce couriers' average hourly earnings.
TimelineToday is 30 September. Engineering needs one week to put batching behind a switch that can be turned on and off per city at any time. Rollout to all cities takes a day. Operating hours are 11:00 to 23:00 in every city.
The intern's draft planRandomise orders 50/50 in every city: orders in the treatment group can be batched, control orders never are. Success metrics: courier cost per order, late deliveries, courier earnings per hour and 30-day reorder rate. Run for two weeks.
Analyst's noteIf we switch batching on and off by city in two-hour windows, detecting a 5% change in courier cost per order needs about 740 windows in total, assuming each window is independent of the others.
What a strong answer doesThe answer key the graders mark against

A spec that sees the draft can't work: batched and unbatched orders in the same city share one pool of couriers, so batching in the treatment group frees couriers for the control group and contaminates the comparison. It uses a switchback design instead (batching on or off by city in randomised two-hour windows), with a buffer at each switch (for example, orders placed shortly before a switch are excluded or assigned by dispatch time) so carry-over doesn't blur the arms. It picks courier cost per order as the one primary metric, because cutting it is batching's purpose and a fall is unambiguously good, and makes the others guardrails with thresholds: late deliveries (for example, no more than a 1pp rise from 7.5%), courier earnings per active hour (no fall, which the Porto agreement requires), with 30-day reorder rate named as a follow-up because it can't be read before the freeze. It sizes the test honestly: 14 cities × 6 windows a day is 84 windows, so 740 windows is about 9 days, but windows in the same city on the same day aren't independent, so it needs more, and a full weekly cycle plus time for couriers to adapt argue for about three weeks. It fits the timeline: build ready around 7 October, Porto given notice now and joining once its 14 days are up (or excluded), about three weeks of data, a read-out around 1 November and rollout before 6 November. It plans trust checks (the arms get the scheduled share of windows and similar order volumes; batching actually happens in 'on' windows), and states the decision rule up front: roll out if cost per order falls at least 5% and guardrails hold; don't if a guardrail is breached; and what happens if the result is inconclusive by the freeze.

Critical failures (cap the score at 40)
  • Randomises by order or by customer within a city, where both arms share the same couriers
  • Changes order assignment in Porto without the 14 days' notice
Case

Staff-level · v1.1 · synthetic · marketplace, logistics, switchback, network effects, staff-level

The outputs

7 setups answered this brief. Pick up to three to read side by side.

Needs more than a quick edit9 of 12 checks passed

The spec is strong but would need material edits to the sizing and timeline, including converting the 740-window note, justifying a full three-week run, and adding explicit trust checks. A PM could not use it without reworking the experiment duration and power rationale.

Output

Brisk order-batching experiment: pre-freeze decision

Decision owner: Staff PM Required approvers: COO, CFO, Head of Operations, courier relations lead Decision deadline: 4 November 2026; rollout on 5 November, before the 6 November freeze.

1. Decision and hypothesis

Ship batching to all 14 cities only if it demonstrates at least 5% lower courier cost per order, with acceptable customer experience and protected courier earnings.

At today’s €7.40 baseline, 5% is approximately €0.37 per order. Simulated savings are not sufficient evidence.

The thresholds below are proposed sign-off terms, not established definitions of “noticeably longer.” Approvers must agree them before randomisation. An inconclusive result means no all-city rollout before the freeze, not permission to lower the bar.

2. Replace order randomisation with city switchbacks

Order-level randomisation is unsuitable: treatment and control orders share couriers, restaurant queues and dispatch capacity. Batching changes availability for both groups, contaminating the comparison.

Instead, switch each city between:

  • Treatment: batching enabled under frozen restaurant-proximity, route-detour and eligibility rules; maximum two orders per courier.
  • Control: current single-order dispatch.

Randomise six local-time blocks daily: 11–13, 13–15, …, 21–23. Balance treatment across cities, weekdays and clock times, with approximately equal exposure per city. Generate and lock the schedule in advance; do not let operators choose favourable treatment periods.

This estimates the effect of offering batching across a city, not merely its effect on successfully batched orders. Analyse all orders in the measurement cohort, including those never batched.

Carryover: Complete existing assignments safely at switches; never split an accepted batch. Set a fixed washout period using historical and shadow-mode assignment-to-completion times, before observing treatment results. Exclude order arrivals during that period from the primary cohort in every block, regardless of whether the state changed. Follow included orders through completion; do not truncate outcomes at block boundaries. If carryover cannot be contained within two-hour blocks, use longer blocks and re-power.

3. Metrics and launch gates

Use concurrent controls and pre-specified, one-sided 95% confidence bounds. Every gate must pass.

StakeholderMetricLaunch requirement
CFO / COOTotal courier compensation attributable to the order cohort ÷ completed ordersUpper confidence bound on treatment/control ratio ≤0.95
OperationsShare delivered more than 45 minutes after ordering; baseline 7.5%Upper bound on increase ≤0.5 percentage points
COO / OperationsMean order-to-door timeUpper bound on increase ≤2 minutes
Courier relationsEarnings per active hour; network baseline €13.20Lower bound on relative change ≥−2% outside Porto
PortoContract-defined average hourly earningsNo-reduction obligation met, as described below

Cost includes distance pay, incentives, failed-delivery compensation and any batching-related earnings protection. Finance freezes allocation rules before launch. Track cancellation/completion rates so apparent savings cannot come from abandoning orders.

Define active hours as available-for-work plus engaged time, excluding genuine offline breaks—not just delivery time. Use consistent definitions across arms. Report both total earnings/total hours and courier-level distributions.

Report results by city, peak/off-peak, first/second batch position and courier earnings decile. Batch-position comparisons are descriptive, not randomised causal estimates. Examine late-delivery tails and cancellations; averages must not conceal material local harm.

Growth: Thirty-day reorder is exploratory, not a freeze gate. The first main-trial cohort matures on 14 November. Customer crossover also limits interpretation; do not present this switchback as a clean test of persistent customer retention.

4. Porto is a contractual prerequisite

Send written notice on 30 September, covering experimental on/off assignment changes and potential rollout. Legal and courier relations must confirm valid receipt, scope and the earliest permitted activation. Plan Porto activation for 15 October, providing a buffer beyond 14 days; late receipt moves that date.

Before activation, agree the contract’s hourly-earnings definition and comparison method with the association. The network’s €13.20 is not a Porto-specific contractual baseline.

Implement a funded make-whole mechanism accepted as satisfying the no-reduction requirement. Include those payments in experimental cost. A statistical non-inferiority margin cannot waive the agreement. Without compliant notice and earnings protection, Porto stays off—and the all-14-city decision is no-go.

5. Power, analysis and validity

The analyst’s 740 windows is not a sufficient sample-size justification:

  • Adjacent windows share demand, weather, couriers and backlog.
  • Washout reduces usable exposure.
  • Detecting a 5% saving versus zero differs from proving a saving of at least 5%.
  • Customer and earnings gates may require more data than cost.

Before launch, replay historical city-time data under the proposed schedule. Incorporate autocorrelation, city heterogeneity, washout and realistic take-up. Estimate power for every gate and the probability of passing them jointly, using simulation scenarios spanning 6–11% savings. Target at least 90% joint power under an explicitly agreed planning scenario.

Estimate intention-to-treat effects using city and calendar/clock-time adjustment, with fleet weights fixed from pre-experiment volume. Use schedule-respecting randomisation inference and dependence-aware uncertainty—not independent-window standard errors.

Publish city-level uncertainty. Pre-agree local safety thresholds and multiplicity handling; a pooled pass does not automatically authorise a city showing credible harm.

Feasibility gate: If adequate evidence cannot fit before the deadline, recommend no all-city pre-freeze launch.

6. Calendar and operating controls

  • 30 September: Approve protocol and proposed margins; send Porto notice.
  • 1–7 October: Build city switches, assignment logging, earnings protection and tested emergency rollback.
  • 8–14 October: Shadow-mode validation; finalise washout, power, schedule and registered analysis.
  • 15 October–2 November: Main experiment: 19 days, at most 1,596 nominal city-blocks before exclusions—not 1,596 independent observations.
  • 3–4 November: Reconcile outcomes and compensation; analyse; obtain four signatures.
  • 5 November: If approved, stage rollout across cities within the day, with monitored checkpoints.

Operations owns live monitoring. Pre-register severe-delay, cancellation, earnings and system-failure stop rules and a sequential-monitoring procedure. Emergency pauses remain permissible; log overrides and retain affected observations in assignment-based analysis. No opportunistic early declaration of success.

7. Sign-off package

Deliver effect estimates and confidence bounds, city diagnostics, notice/compliance evidence, incident logs, and Finance’s net savings forecast including protection payments and operating costs.

Go: Every statistical, contractual, local-safety and operational gate passes. No-go: Any gate fails, remains inconclusive, or cannot be evaluated reliably by 4 November. A subset rollout requires a separate, explicitly approved decision; it is not success against the all-city objective.

Grades and run details

Decision model 88 · LLM judge 9 of 13 checks
Decision model checks
  • passUses the supplied evidence correctly10%
  • passAddresses the actual decision82%
  • partialRespects explicit constraints25%
  • passIdentifies material uncertainty99%
  • passAvoids unsupported claims64%
  • passProduces the required deliverable44%
  • passAvoids contamination between the arms100%
  • passA realistic plan that beats the freeze99%
  • passAn unambiguous primary metric27%
  • passDecision rule written before the test98%
  • failSized from the real traffic24%
  • passGuardrails with thresholds89%
Run
Run
#1
Time to output
81 s
Submitted
1 Oct 2026

Usable with a quick edit10 of 12 checks passed

The spec is comprehensive and only needs a quick edit to add a trust check and rephrase one unsupported claim; no re-checking of evidence or redoing of reasoning is required.

Output

Experiment spec: Order batching before the peak-season freeze

Decision owner: COO · Sign-off: COO, CFO, Head of Operations, Courier Relations Lead · Copied: Head of Growth Status: Draft for sign-off, 30 September 2026

1. Decision

Should we switch batching on in all 14 cities before the code freeze on 6 November 2026? The switch works per city, so the result can also be "on in some cities."

2. What changed from the draft plan, and why

DraftProblemFix
Randomise orders 50/50Treatment and control orders share the same couriers. Batching frees courier time, and that spare capacity speeds up control orders, which shrinks the measured difference. Earnings per courier hour can't be split by order at all.Switchback test: randomise each city in 2-hour windows. Everything in a window is either on or off.
Runs in every city from day onePorto needs 14 days' written notice. The earliest a notice sent today can take effect is 14 October.Send notice today. Porto joins on 14 Oct.
"Late deliveries"UndefinedShare of orders delivered >45 min after ordering (baseline 7.5%)
30-day reorder rate as a success metricIt can't be measured before the freeze. In a switchback, each customer also sees both arms.Monitor it after rollout. It is not a decision metric.
No thresholds or stop rulesWe can't make a pass/fail callThresholds in §5, stop rules in §7
Two weeks, assuming 740 independent windowsWindows are not independent. Batches straddle switch times, couriers reposition, and windows on the same city-day are correlated.Exclude a washout period from each window, cluster the analysis, and run 21 days (~1,700 windows).

3. Timeline

DateMilestone
Wed 30 SepWritten notice to the Porto couriers' association. It covers both the test and a possible rollout. Legal to confirm wording today.
30 Sep – 7 OctEngineering builds the per-city switch. Analytics builds the randomisation schedule and dashboard.
Thu 8 OctTest starts in 13 cities
Wed 14 OctPorto joins (notice period complete)
Wed 28 OctTest ends
29 Oct – 1 NovAnalysis
Mon 2 NovDecision meeting
Tue 3 NovRollout (one day)
4–5 NovBuffer for rollback or fixes. Freeze on 6 Nov.

The dates are fixed by two constraints. The Porto notice cannot slip past today without losing Porto days. The test cannot run past 28 October without eating into the rollout buffer.

4. Design

  • Unit: one city in one 2-hour window. Each day has six windows (11–13, 13–15, 15–17, 17–19, 19–21, 21–23).
  • Assignment: randomised 50/50 within each city and time slot. Each city gets a balanced mix of on and off across lunch, dinner, weekdays and weekends.
  • Switch behaviour: new batches form only while the switch is on. Batches already in progress when it turns off complete normally.
  • Washout: the first 30 minutes of each window are excluded from analysis. This leaves 90 analysed minutes per window.
  • Sample: 13 cities × 6 windows × 21 days plus Porto × 6 × 15 days gives 1,728 windows. That is about 2.3× the analyst's 740. The extra covers the washout and the correlation between windows. Analytics to confirm the power calculation using the correlation seen in the first week's data. If power is short, we extend to 30 October and give up one buffer day.
  • Analysis: compare window-level metrics with adjustments for city, day and time slot. Treat all windows in the same city on the same day as one group when calculating uncertainty. Report the network result and each city's result.

5. Metrics and decision rule

MetricOwnerBaselineRule
Courier cost per orderCFO€7.40Primary. Pass if the estimated reduction is ≥5% (≥€0.37) and the 95% confidence interval excludes zero.
Share of orders delivered >45 minHead of Ops7.5%Guardrail. Fail if the increase is more than 1.0 percentage point (to 8.5%).
Courier earnings per active hourCourier Relations€13.20Guardrail. Fail if the drop is more than €0.40 (3%). In Porto, any drop fails.
Median delivery time, second order in a batchHead of Opsn/aDiagnostic. Simulation expects +3–6 min.
Complaints and refunds per 1,000 ordersHead of Opsn/aDiagnostic. This is our short-term stand-in for customer harm.
Share of orders batchedAll0%Diagnostic. Shows whether batching is actually happening.
30-day reorder rateGrowthn/aTracked after rollout. Not a decision metric.

Rollout rule: a city rolls out on 3 Nov if the network result passes the primary metric and both guardrails, and that city's own result shows no clear guardrail failure.

The 1.0pp and €0.40 margins are proposals. Signers must confirm or change them before 8 October. They cannot be changed after the test starts.

6. Tensions signers should know about

What "at least 5%" can mean. We can reliably detect whether batching cuts cost by 5% versus not at all. We cannot prove the true effect is above 5% if it is only 6%, which is the low end of the simulation. The decision rule therefore uses the point estimate. If the estimate lands between 4% and 6%, the COO decides with that uncertainty in view.

Cost savings and courier earnings pull in opposite directions. Couriers are paid per order plus distance, so a lower cost per order is lower pay per order. Earnings per hour only hold up if couriers complete more orders per hour.

  • During the test, the same couriers are logged in whether batching is on or off. That makes the test a fair early read on hourly earnings.
  • After rollout, the saving only stays a saving if we need fewer courier hours. Fewer hours affects couriers' income, even if the hourly rate is protected.
  • The CFO and Courier Relations Lead should agree on this before sign-off, not after results.

Porto. "Must not reduce average hourly earnings" is a contractual condition, not a statistical margin. Porto gives us only ~90 windows, too few to prove "no reduction."

  • If network earnings per hour fall at all, Porto stays off unless it comes with an earnings protection mechanism. One example is a per-batch supplement, which legal and Courier Relations should scope now.
  • If Porto rolls out, we measure its hourly earnings against the pre-batching baseline every week.

"Noticeably longer." We are defining this as the >45-minute late share plus the complaint rate. We are not using average delivery time, because a 3–6 minute delay on second orders is expected by design.

7. Stop rules (checked daily by the on-call analyst)

  • City level: the >45-minute late share in "on" windows exceeds 10% for two consecutive days. Batching goes off in that city pending review.
  • Network level:
  • Any courier safety incident linked to batching, or a formal complaint from a couriers' association: pause everywhere.
  • Earnings per hour in "on" windows below €12.50 for three consecutive days: pause everywhere.
  • Porto only: any clear drop in hourly earnings leads to an immediate pause and notification to Courier Relations.

8. What each signer is agreeing to

  • COO: the dates in §3, the rollout rule in §5, and making the call if the result falls between 4% and 6%.
  • CFO: cost per order as the primary metric, with the ≥5% rule. Also acknowledges that post-rollout savings depend on how many courier hours we buy (§6).
  • Head of Operations: the 1.0pp late-share margin and the stop rules.
  • Courier Relations Lead:
  • the €0.40 margin;
  • the separate rule for Porto;
  • sending the Porto notice today.

9. Open items

1. Legal, today: Porto notice wording, and whether one notice covers both the test and the rollout. 2. Analytics, by 7 Oct: - power calculation that accounts for correlated windows; - randomisation schedule; - dashboard. 3. Engineering, by 7 Oct: per-city switch with switch times logged, tested in one city after hours. 4. Courier Relations and Legal, by 2 Nov: Porto earnings protection option. 5. Signers, by 8 Oct: confirm the guardrail margins in §5.

Grades and run details

Decision model 88 · LLM judge 11 of 13 checks
Decision model checks
  • partialUses the supplied evidence correctly8%
  • passAddresses the actual decision43%
  • partialRespects explicit constraints18%
  • passIdentifies material uncertainty100%
  • passAvoids unsupported claims22%
  • passProduces the required deliverable56%
  • passAvoids contamination between the arms100%
  • passA realistic plan that beats the freeze100%
  • passAn unambiguous primary metric33%
  • partialDecision rule written before the test27%
  • passSized from the real traffic41%
  • passGuardrails with thresholds99%
Run
Run
#1
Time to output
63 s
Submitted
30 Sept 2026

Check by check

Where the outputs differ comes first. Open a check to read the judge’s reasons. “Mixed” means the two graders disagreed.

Where they differ 3

Avoids unsupported claimsRightMixed
GPT-6 Astra · ChatGPT

It labels thresholds and assumptions as proposed, treats simulations as insufficient evidence, and avoids presenting forecasts or causes as established facts.

Opus 5.5 · Claude

It presents as fact that the test cannot prove the effect is above 5% if it is 6% and that Porto's 90 windows are too few to prove no reduction, neither of which is supported by the supplied evidence.

A realistic plan that beats the freezeMixedRight
GPT-6 Astra · ChatGPT

It does not convert 740 windows into about 9 days, does not explicitly justify about three weeks from weekly cycles and courier adaptation, and schedules only 19 days rather than a full three-week test.

Opus 5.5 · Claude

It correctly converts 740 windows to about 9 days, explains why correlation and weekly cycles require about 3 weeks, and gives dates that fit before the 6 November freeze with Porto notice respected.

Sized from the real trafficWrongRight
GPT-6 Astra · ChatGPT

It does not size the test from supplied traffic, baseline, and smallest effect, and its 19-day duration is not whole weekly cycles.

Opus 5.5 · Claude

Sample size is derived from the analyst's 740 windows, increased for correlation, and runs full weeks (21 days).

All mixed 1

An unambiguous primary metricMixedMixed
GPT-6 Astra · ChatGPT

It names courier cost per order as the decision metric but does not clearly explain why lower cost is unambiguously good for users and the business, nor specify a concrete trust check such as sample-ratio or batching-occurrence validation.

Opus 5.5 · Claude

It does not include a planned trust check such as a sample ratio check to verify that the arms are balanced and the experiment ran as intended.

All got right 8

Uses the supplied evidence correctlyRightRight
GPT-6 Astra · ChatGPT

The output’s factual statements about the current situation are drawn from the brief or follow by arithmetic, and its invented operational details are framed as proposals or requirements rather than existing facts.

Opus 5.5 · Claude

All claims about the current situation are taken directly from the brief or supplied context.

Addresses the actual decisionRightRight
GPT-6 Astra · ChatGPT

It commits early to ship only if courier cost per order falls at least 5% and guardrails pass, and says inconclusive or failed gates mean no all-city pre-freeze rollout.

Opus 5.5 · Claude

The spec includes a clear decision rule (roll out if primary metric passes and guardrails hold, COO decides if estimate between 4% and 6%) that answers the question of whether to roll out.

Respects explicit constraintsRightRight
GPT-6 Astra · ChatGPT

It respects the under-1,200-word limit, named approvers, Porto notice, engineering lead time, and freeze date, and its proposed gates and calendar would enforce those constraints.

Opus 5.5 · Claude

The output is under 1,200 words, respects the Porto 14-day notice requirement, and addresses all named signers.

Identifies material uncertaintyRightRight
GPT-6 Astra · ChatGPT

It names key uncertainties such as carryover, autocorrelation, washout, take-up, power, local harm, and Porto compliance, and specifies how they would be resolved or would change the decision.

Opus 5.5 · Claude

It names the uncertainty around detecting a 5% vs 6% effect, the tension between cost savings and courier earnings, and Porto's small sample, and says how they would be resolved.

Produces the required deliverableRightRight
GPT-6 Astra · ChatGPT

It is a usable experiment spec for the named approvers, with design, metrics, Porto handling, calendar, analysis, and sign-off package, within the requested length.

Opus 5.5 · Claude

The output is a complete experiment spec with timeline, metrics, decision rule, and sign-off sections, under the word limit, and usable by the signers.

Avoids contamination between the armsRightRight
GPT-6 Astra · ChatGPT

It rejects order-level randomisation, uses city switchbacks, and adds washout and assignment-completion rules to handle carryover at switches.

Opus 5.5 · Claude

It explains the shared-courier contamination problem and uses a switchback design with a 30-minute washout to keep the arms separate.

Decision rule written before the testRightRight
GPT-6 Astra · ChatGPT

It states a pre-test rule: go only if every gate passes, no-go if any gate fails or is inconclusive, and no all-city rollout before the freeze if evidence cannot be obtained reliably.

Opus 5.5 · Claude

It states a rollout rule (pass primary and guardrails, city-level no clear guardrail failure) and says the COO decides if the estimate is between 4% and 6%, covering the inconclusive case.

Guardrails with thresholdsRightRight
GPT-6 Astra · ChatGPT

It names late deliveries, order-to-door time, courier earnings, Porto earnings, and cancellation/completion as blocking gates with thresholds.

Opus 5.5 · Claude

It names late delivery share (>45 min) and courier earnings per hour as guardrails with thresholds (1.0pp increase, €0.40 drop, and any drop in Porto).

Results

Every setup we’ve tested on this task, across all cases and repeats, graded on the current checklist. Calibrated: the graders match our PM on 90% of checks.

#Model · HarnessTask scoreDecision modelLLM judgeRunsCritical failures
1GPT-6.1 SolwithAPI87.588.52None
2Sonnet 5.5withAPI81.388.52None
3Opus 5.5withClaude85.476.92None
4GPT-6 LunawithAPI85.473.12None
5GPT-6 AstrawithChatGPT87.565.42None
6Gemini 3.8 FlashwithAPI60.438.52None
7Gemini 3.5 Flash-LitewithGemini37.515.422 capped

About the task

The PM job

Specifying an A/B test before running it.

Why it matters

Most tests are underpowered, or measure a metric nobody agrees is good.

What good looks like

  • One primary metric everyone agrees on the direction of
  • Decision rule stated up front
  • Guardrails
  • Power considered

Deliberately not measured

    Capability tested

    Test design

    The failure we’re looking for

    A test with no decision attached

    Grading

    Decision model and LLM judge, calibrated against a blind PM review