Tasks / Metrics & Experimentation

Experiment specification

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

Task type v1.0 · 2 tasksLast changed 6 Oct 2026 · ChangelogDifficulty

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

From 16 graded outputs by 8 models. 31% were usable with at most a quick edit.

Reliably right

  1. Randomises by user100% pass
    Randomises by logged-in user ID across platforms, explicitly citing cross-platform usage and session non-independence.
    Sonnet 5.5 · API · Show the fee sooner
  2. Works around the calendar94% pass
    Addresses both the payments test and the Black Friday freeze, proposes concurrent independent assignment with an interaction check, and avoids a one-week squeeze.
    Sonnet 5.5 · API · Show the fee sooner
  3. Addresses the actual decision91% pass
    Commits to a clear experiment plan with a decision rule that maps every outcome (ship, don't ship, kill, extend) to an action.
    Sonnet 5.5 · API · Show the fee sooner

Where it slips

  1. Guardrails with thresholds50% pass
    Guardrail metrics are named but lack explicit numeric thresholds; 'materially worse' and 'drops meaningfully' are too vague to block rollout without further definition.
    Sonnet 5.5 · API · Showing the delivery fee up front
  2. Says why a test is worth it here59% pass
    The output does not explain why this decision merits a test given the traffic and stakes, nor does it recommend a cheaper alternative.
    Opus 5.5 · Claude · Show the fee sooner
  3. Uses the supplied evidence correctly64% pass
    Unsupported claims about the traffic data's adequacy and the code freeze's preapproval requirement are presented as facts, not in the brief.
    GPT-6.1 Sol · API · Show the fee sooner

How it’s graded

Each check is built on how world-class product and growth leaders do this work, as they’ve described it on Lenny’s Podcast, and names the leader it comes from.

  1. An unambiguous primary metric

    Does the spec name one primary metric, explain why an increase is unambiguously good for the user and the business, and say how the result's trustworthiness will be checked?

    Passes when One primary metric with a clear rationale for its direction, plus a planned trust check such as a sample ratio check.

  2. Decision rule written before the test

    Does the spec say, before the test runs, which result leads to which action (ship, don't ship, iterate), including what happens if the result is inconclusive?

    Passes when Every outcome, including an inconclusive one, maps to a stated action, with the thresholds that separate them.

  3. Sized from the real traffic

    Is the sample size and duration worked out from the supplied traffic, baseline and smallest effect worth detecting, run in full weekly cycles?

    Passes when Sample size follows from the baseline and the smallest effect worth acting on, the duration follows from the traffic the brief gives (including how units accumulate), and it runs whole weeks.

  4. Guardrails with thresholds

    Does the spec name the guardrail metrics that would stop a rollout even if the primary metric wins, each with a threshold?

    Passes when The guardrails that matter for this change are named, each with a threshold that would block the rollout.

  5. Says why a test is worth it here

    Does the spec weigh whether a test is worth running here: enough traffic to detect an effect that matters, and a decision the result would actually change, and does it say what it would do instead if not?

    Passes when Explains why this decision merits a test given the traffic and stakes, or recommends a cheaper route where they don't.

Plus our standard checks

Uses the supplied evidence correctly · Addresses the actual decision · Respects explicit constraints · Identifies material uncertainty · Avoids unsupported claims · Produces the required deliverable · and 3 written for each task, which you’ll see in the tasks below.

The tasks

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

The brief

You're the PM for checkout at Waymark. Write the experiment spec for the idea below, in no more than 900 words: hypothesis, what's randomised and how, metrics (primary, secondary, guardrails), sample size and duration worked out from our real traffic, when it can run given the calendar, and the decision rule. Show your sums.\n\nThe files are attached.

What the model was given5 items: About Waymark, the_idea.md, checkout_traffic_last_8_weeks.csv (daily, by platform), who_checks_out.md, experiment_calendar.md
About WaymarkOnline groceries, ordered on the app or the website, delivered the next day.
the_idea.md3 lines · Download
# The idea (from the checkout squad)

Show the delivery date and the delivery fee on the basket page, before checkout, instead of on the final checkout step. Hypothesis: fewer people abandon at the last step when they see the fee, and more complete checkout. Risk: some people may leave earlier when they see the fee sooner.
checkout_traffic_last_8_weeks.csv (daily, by platform)date,weekday,platform,checkout_sessions,orders 2026-08-10,Mon,app,23970,1755 2026-08-10,Mon,web,16794,894 2026-08-11,Tue,app,23130,1691 2026-08-11,Tue,web,17534,943 2026-08-12,Wed,app,23807,1689 2026-08-12,Wed,web,16732,906 2026-08-13,Thu,app,23420,1673 2026-08-13,Thu,web,16871,900 2026-08-14,Fri,app,23082,1664 2026-08-14,Fri,web,17728,943 2026-08-15,Sat,app,15784,1039 2026-08-15,Sat,web,11893,600 2026-08-16,Sun,app,15784,1045 2026-08-16,Sun,web,11908,594 2026-08-17,Mon,app,23929,1725 2026-08-17,Mon,web,17584,947 2026-08-18,Tue,app,23133,1674 2026-08-18,Tue,web,17005,935 2026-08-19,Wed,app,23486,1661 2026-08-19,Wed,web,16706,912 2026-08-20,Thu,app,23242,1641 2026-08-20,Thu,web,17473,937 2026-08-21,Fri,app,23435,1719 2026-08-21,Fri,web,17242,946 2026-08-22,Sat,app,16371,1080 2026-08-22,Sat,web,12039,601 2026-08-23,Sun,app,16578,1081 2026-08-23,Sun,web,12044,602 2026-08-24,Mon,app,23475,1663 2026-08-24,Mon,web,17130,916 2026-08-25,Tue,app,23409,1669 2026-08-25,Tue,web,17304,918 2026-08-26,Wed,app,23406,1671 2026-08-26,Wed,web,17152,912 2026-08-27,Thu,app,23921,1724 2026-08-27,Thu,web,16846,915 2026-08-28,Fri,app,24224,1712 2026-08-28,Fri,web,17541,963 2026-08-29,Sat,app,16489,1113 2026-08-29,Sat,web,11921,602 2026-08-30,Sun,app,16065,1080 2026-08-30,Sun,web,11484,570 2026-08-31,Mon,app,23827,1748 2026-08-31,Mon,web,17352,951 2026-09-01,Tue,app,24029,1751 2026-09-01,Tue,web,16781,901 2026-09-02,Wed,app,24327,1766 2026-09-02,Wed,web,16949,908 2026-09-03,Thu,app,23853,1723 2026-09-03,Thu,web,17094,914 2026-09-04,Fri,app,24099,1745 2026-09-04,Fri,web,17509,960 2026-09-05,Sat,app,16493,1114 2026-09-05,Sat,web,11610,575 2026-09-06,Sun,app,16571,1109 2026-09-06,Sun,web,11899,598 2026-09-07,Mon,app,23179,1696 2026-09-07,Mon,web,16836,897 2026-09-08,Tue,app,23301,1689 2026-09-08,Tue,web,17187,937 2026-09-09,Wed,app,24344,1745 2026-09-09,Wed,web,17418,953 2026-09-10,Thu,app,23256,1691 2026-09-10,Thu,web,17123,933 2026-09-11,Fri,app,23911,1693 2026-09-11,Fri,web,17576,961 2026-09-12,Sat,app,16328,1099 2026-09-12,Sat,web,12082,609 2026-09-13,Sun,app,15784,1051 2026-09-13,Sun,web,11496,565 2026-09-14,Mon,app,23716,1722 2026-09-14,Mon,web,16886,905 2026-09-15,Tue,app,23295,1649 2026-09-15,Tue,web,17506,947 2026-09-16,Wed,app,23514,1717 2026-09-16,Wed,web,17152,934 2026-09-17,Thu,app,23714,1714 2026-09-17,Thu,web,17027,929 2026-09-18,Fri,app,23324,1698 2026-09-18,Fri,web,17233,942 2026-09-19,Sat,app,15792,1055 2026-09-19,Sat,web,11457,566 2026-09-20,Sun,app,15795,1044 2026-09-20,Sun,web,11932,596 2026-09-21,Mon,app,24102,1717 2026-09-21,Mon,web,17386,951 2026-09-22,Tue,app,24071,1722 2026-09-22,Tue,web,17445,940 2026-09-23,Wed,app,23672,1712 2026-09-23,Wed,web,17595,966 2026-09-24,Thu,app,24378,1759 2026-09-24,Thu,web,16705,911 2026-09-25,Fri,app,23375,1654 2026-09-25,Fri,web,16941,928 2026-09-26,Sat,app,15807,1053 2026-09-26,Sat,web,11924,601 2026-09-27,Sun,app,16572,1100 2026-09-27,Sun,web,11745,581 2026-09-28,Mon,app,23731,1685 2026-09-28,Mon,web,17480,960 2026-09-29,Tue,app,23336,1710 2026-09-29,Tue,web,17187,940 2026-09-30,Wed,app,24441,1745 2026-09-30,Wed,web,16799,913 2026-10-01,Thu,app,23404,1705 2026-10-01,Thu,web,17529,945 2026-10-02,Fri,app,24389,1789 2026-10-02,Fri,web,16952,900 2026-10-03,Sat,app,16669,1110 2026-10-03,Sat,web,12041,604 2026-10-04,Sun,app,15998,1077 2026-10-04,Sun,web,12088,593
who_checks_out.md6 lines · Download
# Who checks out (from the data team)

- 412,000 people placed at least one order in the last 30 days.
- 31% of them used both the app and the website to shop in that month.
- The average buyer starts 3.8 checkout sessions a month.
- Average order value: $64. Repeat purchase within 30 days: 38%.
experiment_calendar.md5 lines · Download
# Experiment calendar

- Payments squad: "Pay later" option on the checkout page, live for 50% of users until 9 November.
- Search squad: new ranking, runs on search results pages only, until 30 October.
- Black Friday promotions start 20 November; code freeze from 16 November.
What a strong answer doesThe answer key the graders mark against

Randomises by user, not session or platform, because 31% of buyers use both app and web and the average buyer starts 3.8 checkout sessions a month; sessions aren't independent. Uses the traffic file: about 41,000 checkout sessions a weekday and 28,000 at weekends (about 260,000 a week), with session conversion about 6.4% (higher on the app), so sizes on users (about 412,000 buyers a month) with a stated baseline and smallest effect worth detecting, and runs in whole weeks. Primary metric: completed orders per user who reaches the basket (not last-step completion, which the change could flatter by moving drop-off earlier). Guardrails: drop-off at the basket page, delivery fee revenue, average order value. Handles the calendar: the payments test runs on the same checkout until 9 November and the code freeze starts 16 November before Black Friday, so either run alongside payments with independent assignment and check for interaction, or start after the freeze lifts and avoid the promotional weeks; it doesn't squeeze a test into the single week between them. A decision rule for win, loss and inconclusive.

Critical failures (cap the score at 40)
  • Randomises by session
Task

Staff-level · v1.0

The outputs

8 setups answered this brief.

Needs more than a quick edit3 of 14 checks passed

The traffic numbers are wrong, the primary metric is flawed, and the calendar plan is unworkable; a PM would need to redo the analysis.

Output

Experiment Specification: Early Delivery Fee & Date Preview

Author: PM, Checkout Squad Date: October 2026

---

1. Hypothesis

Showing the delivery date and delivery fee on the basket page (pre-checkout) will reduce final-step checkout abandonment by setting upfront expectations. * Core Hypothesis: The reduction in late-stage drop-off outweighs any early-stage basket abandonment caused by friction, resulting in a net positive impact on overall checkout conversion.

2. Randomisation Strategy & Unit

  • Unit of Randomization: User ID (sticky across app and web platforms, given 31% multi-platform usage).
  • Allocation: 50% Control (status quo: fee shown on final checkout step), 50% Treatment (fee and date visible on the basket page).

3. Metrics

  • Primary Metric: Checkout Conversion Rate (Completed Orders / Unique Checkout Sessions).
  • Secondary Metrics:
  • Basket-to-Checkout Drop-off Rate (users leaving before entering checkout).
  • Average Order Value (AOV).
  • Guardrail Metrics:
  • Total Orders / Gross Merchandise Value (GMV).
  • 30-day Repeat Purchase Rate.

---

4. Traffic Analysis & Sample Size Sizing (The Sums)

Real Traffic Baseline (from past 8 weeks data): * Summing the 8-week dataset (56 days): * Total App Checkout Sessions = 1,304,784 (~23,300/day) * Total Web Checkout Sessions = 959,183 (~17,128/day) * Total Combined Sessions (8 weeks) = 2,263,967 * Daily Average Traffic = 40,428 checkout sessions/day * Total Orders = 155,752 * Baseline Conversion Rate ($p$) = $155,752 / 2,263,967 \approx 6.88\%$

Sample Size Calculations: To detect a relative change of 2% in conversion rate (e.g., from 6.88% to 7.02%) with $\alpha = 0.05$ (two-tailed) and power $(1-\beta) = 0.80$: * Using standard sample size formulas for proportions, we require approximately 375,000 users per variant (~750,000 total sessions). * At our baseline traffic of ~40,428 sessions/day (split 50/50 = ~20,214 sessions per variant daily): * Required Duration = $750,000 / 40,428 \approx 18.5$ days. * We will round up to 3 full weeks (21 days) to cleanly account for day-of-week seasonality (grocery ordering behaves very differently on Saturdays vs. Mondays).

---

5. Calendar & Timing

  • Overlaps & Conflicts:
  • Search squad: Runs exclusively on search results pages. Zero overlap with checkout/basket flows. Safe to run concurrently.
  • Payments squad ("Pay later"): Runs on the checkout page (affecting 50% of users) until 9 November. Because the checkout page is downstream of our intervention (basket page), running both creates a multi-variate interaction risk if not accounted for.
  • Holiday/Promo Constraints:
  • Black Friday promotions start November 20.
  • Code freeze begins November 16.
  • Proposed Window:
  • Start: Monday, October 12, 2026
  • End: Monday, November 2, 2026 (Exactly 21 days).
  • Note: This completely clears the Payments squad end-date (Nov 9) by launching earlier, and sits safely clear of the November 16 code freeze.

---

6. Decision Rule

We will evaluate the experiment after exactly 21 days of data collection.

  1. Ship (Rollout 100%): If the Primary Metric (Checkout Conversion Rate) shows a statistically significant positive lift ($p < 0.05$), and no guardrail metrics (GMV, 30-day repeat rate) drop significantly.
  2. Iterate / Inconclusive: If the primary metric shows no statistically significant change ($p \ge 0.05$), but secondary metrics show positive intent shifts, review basket abandonment drop-offs and redesign the UI placement.
  3. Rollback: If the Primary Metric drops significantly ($p < 0.05$) due to early basket abandonment outweighing final-step savings, or if guardrail metrics degrade, immediately halt the experiment and revert to control.

Claims the judge couldn’t find in the brief

  • Total Combined Sessions (8 weeks) = 2,263,967
  • Total Orders = 155,752
  • Daily Average Traffic = 40,428 checkout sessions/day
  • Baseline Conversion Rate = 6.88%

Grades and run details

Decision model 57 · LLM judge 27
Decision model checks
  • failUses the supplied evidence correctly25%
  • passAddresses the actual decision37%
  • failRespects explicit constraints20%
  • partialIdentifies material uncertainty86%
  • partialAvoids unsupported claims23%
  • partialProduces the required deliverable62%
  • passRandomises by user75%
  • passWorks around the calendar72%
  • partialDoesn't let the metric flatter the change34%
  • partialAn unambiguous primary metric87%
  • passDecision rule written before the test94%
  • partialSized from the real traffic46%
  • partialGuardrails with thresholds95%
  • partialSays why a test is worth it here47%
Run
Run
#1
Time to output
5 s
Submitted
5 Oct 2026

Needs more than a quick edit11 of 14 checks passed

The spec lacks a final sample size and duration, requiring additional data and recalculation, so a PM cannot act on it without major rework.

Output

Experiment spec: earlier delivery-date and fee disclosure

Status: Conditional launch approval. The supplied traffic supports a planning calculation, but not a defensible final sample size for the correct primary metric.

Hypothesis and experience

Showing the next-day delivery date and actual delivery fee on the basket page increases completed purchases by reducing late surprises. Earlier abandonment may increase; the test must measure the net effect from basket entry, not just conversion among people who proceed to checkout.

  • Control: Current disclosure at the final checkout step.
  • Treatment: Disclose on the basket page; retain an accurate fee/date in the final order summary. No changes to prices, delivery eligibility or payment options.
  • Eligibility: identifiable, signed-in customers opening a non-empty basket for which we can calculate the date and fee. Do not introduce a login requirement. Results initially apply only to this population.

Randomisation and analysis

Assign eligible customers 50:50 by persistent account-ID hash, immediately before their first eligible basket renders. Keep assignment sticky across sessions, app and web.

Cross-platform consistency matters: \(412,000 × 31\% = 127,720\) recent buyers used both platforms. Device- or session-level assignment would expose many people to both variants.

Analyse intention-to-treat: everyone assigned remains in their arm, including failed renders and immediate exits. Each customer contributes one primary observation. Pre-specify adjustment for entry platform and enrolment date; report app/web effects as secondary, not independently powered launch decisions.

Validate allocation, identity stitching, exposure events and order attribution before starting.

Metrics

Primary: Percentage of assigned customers placing a paid order within 24 hours of first eligible basket entry, on either platform. This captures both earlier exits and downstream gains without a treatment-selected checkout denominator.

Secondary: - Basket-to-checkout progression and final-step abandonment, as funnel diagnostics. - Orders and net revenue per assigned customer within 24 hours. - Order value among purchasers, labelled a conditional diagnostic. - Thirty-day repeat purchase; the supplied 38% is context, not necessarily this cohort’s baseline. This needs a separate mature readout.

Guardrails — proposed tolerances, requiring sign-off: - Net revenue/customer: no worse than −1% relative. - Payment-error and cancellation/refund incidence per assigned customer: no worse than +0.1 percentage points, using fixed, pre-registered observation windows. - Zero tolerance for confirmed incorrect fee/date disclosure or unintended charges. - Monitor basket latency, crashes and sample-ratio mismatch; material regressions trigger investigation or rollback.

The $64 average order value alone cannot establish revenue variance or power these guardrails.

Sample size and duration: sums

Across the supplied 56 days:

PlatformCheckout sessionsOrders
------:---:
App1,206,53785,526
Web876,85346,670
Total2,083,390132,196

Thus:

\[ p_{\text{checkout}}=132,196/2,083,390=6.345\% \]

\[ \text{sessions/day}=2,083,390/56=37,203 \]

Propose 80% power, two-sided 5% significance, 3% relative minimum detectable uplift, subject to commercial sign-off.

Illustrative checkout-session calculation only:

\[ \Delta=0.06345×0.03=0.0019035 \]

That is 0.190 percentage points.

\[ n_{\text{arm}}\approx \frac{2(1.96+0.84)^2p(1-p)}{\Delta^2} \approx257,200 \]

\[ N\approx514,400;\quad514,400/37,203=13.83\text{ days} \]

Two complete weeks would provide approximately:

\[ 2,083,390/8×2=520,848\text{ checkout sessions} \]

This does not prove the proposed experiment is powered. The intervention precedes checkout, and checkout sessions are neither eligible basket visitors nor independent customers. The 412,000 figure counts buyers only; 3.8 sessions/month describes buyers, not all eligible visitors. Dividing session traffic by 3.8 would be invalid.

Launch-blocking data request: Extract deduplicated eligible basket entrants, their 24-hour purchase rate and cumulative unique entrants over candidate windows. Recalculate:

\[ n{\text{arm}}= \frac{15.68pb(1-pb)}{(0.03pb)^2} \]

Choose a fixed enrolment duration covering at least two complete weeks and enough unique customers, then add 24 hours for primary-outcome maturation.

Calendar

There is no unconditionally clean two-week pre-promotion slot after Payments ends:

  • Payments runs through 9 November.
  • 10–15 November offers only six days before freeze.
  • Even if running tests may continue during freeze, 10–19 November offers only ten days before promotions.

Conditional slot: 31 October–13 November, outcomes mature 14 November, readout 15 November. Search has ended. This requires Payments to hold its configuration through follow-up and agree independent, orthogonal assignment, balanced payment strata and interaction analysis. It also requires the recalculated customer sample to fit.

Otherwise, negotiate isolation earlier or defer until after promotions and freeze; their end dates are not supplied.

Decision rule

No efficacy peeking or early “winner” calls. At the fixed endpoint, ship only if the primary 95% confidence interval excludes zero positively, the estimated uplift meets the agreed 3% business threshold, and guardrail confidence bounds exclude their harm margins. Require valid instrumentation and no material platform/payment interaction harm.

Otherwise retain control: distinguish evidence of harm from an inconclusive result. Missing power, immature guardrails or calendar approval means no launch, not an assumed pass.

Grades and run details

Decision model 89 · LLM judge 73
Decision model checks
  • passUses the supplied evidence correctly45%
  • passAddresses the actual decision51%
  • partialRespects explicit constraints24%
  • passIdentifies material uncertainty96%
  • passAvoids unsupported claims64%
  • partialProduces the required deliverable88%
  • passRandomises by user98%
  • passWorks around the calendar100%
  • passDoesn't let the metric flatter the change81%
  • passAn unambiguous primary metric83%
  • passDecision rule written before the test82%
  • partialSized from the real traffic78%
  • passGuardrails with thresholds58%
  • passSays why a test is worth it here85%
Run
Run
#1
Time to output
73 s
Submitted
5 Oct 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 10

Uses the supplied evidence correctlyWrongRight
Gemini 3.5 Flash-Lite · Gemini

The traffic totals (2,263,967 sessions, 155,752 orders) are not supported by the data; the correct sums are about 2,083,390 sessions and 132,196 orders.

GPT-6 Astra · ChatGPT

All factual claims about the current situation are taken directly from the supplied context or derived by correct arithmetic.

Respects explicit constraintsMixedRight
Gemini 3.5 Flash-Lite · Gemini

Respects word limit, includes all required sections, and randomises by user not session.

GPT-6 Astra · ChatGPT

The spec is within 900 words, includes all requested sections, and respects the form.

Identifies material uncertaintyWrongRight
Gemini 3.5 Flash-Lite · Gemini

Acknowledges interaction risk with the payments test but does not say how to resolve it, and incorrectly claims the window clears the payments test.

GPT-6 Astra · ChatGPT

It identifies the unknown sample size due to missing unique-customer data and the calendar dependency, and says how to resolve them.

Avoids unsupported claimsWrongRight
Gemini 3.5 Flash-Lite · Gemini

Presents incorrect traffic numbers as facts without labelling them as estimates.

GPT-6 Astra · ChatGPT

Hypotheses and limitations are clearly labelled, and no interpretations are presented as established fact.

Produces the required deliverableWrongRight
Gemini 3.5 Flash-Lite · Gemini

The sample size and duration are based on incorrect traffic data, so a PM would need to redo the sums.

GPT-6 Astra · ChatGPT

The experiment spec is complete in form, within the word limit, and a PM could understand the plan.

Works around the calendarMixedRight
Gemini 3.5 Flash-Lite · Gemini

Proposes a window that overlaps with the payments test and does not provide a workable plan like independent assignment or interaction check.

GPT-6 Astra · ChatGPT

Names both the payments test and the Black Friday freeze, and proposes a conditional slot with independent assignment and interaction check, not a one-week squeeze.

Doesn't let the metric flatter the changeWrongMixed
Gemini 3.5 Flash-Lite · Gemini

Primary metric is orders per checkout session, which can be flattered if users drop off before checkout; does not use orders per user reaching the basket.

GPT-6 Astra · ChatGPT

The primary metric is from basket entry and explains why last-step completion misleads, but it does not include a basket drop-off guardrail with a threshold to block rollout.

An unambiguous primary metricWrongRight
Gemini 3.5 Flash-Lite · Gemini

Does not explain why an increase is unambiguously good or include a trust check like sample ratio mismatch.

GPT-6 Astra · ChatGPT

One primary metric is named, its direction is unambiguously good, and a sample-ratio mismatch check is planned.

Guardrails with thresholdsWrongRight
Gemini 3.5 Flash-Lite · Gemini

Guardrails lack specific thresholds; only says 'drop significantly'.

GPT-6 Astra · ChatGPT

Guardrails (net revenue, payment errors, incorrect fee) are named with explicit thresholds that would block rollout.

Says why a test is worth it hereWrongMixed
Gemini 3.5 Flash-Lite · Gemini

Does not discuss whether the test is worth running given traffic and stakes.

GPT-6 Astra · ChatGPT

The output does not explain why this decision merits a test given the traffic and stakes, nor does it recommend a cheaper alternative if not.

All got wrong 1

Sized from the real trafficWrongWrong
Gemini 3.5 Flash-Lite · Gemini

Sample size and duration are derived from incorrect traffic totals, not the real data.

GPT-6 Astra · ChatGPT

The spec does not provide a sample size and duration worked out from the supplied traffic; it states the data is insufficient and requests more, without a usable calculation.

All got right 3

Addresses the actual decisionRightRight
Gemini 3.5 Flash-Lite · Gemini

Commits to a 21-day experiment starting Oct 12 with a clear decision rule.

GPT-6 Astra · ChatGPT

The output commits to a conditional launch decision and provides a clear decision rule for the test outcome.

Randomises by userRightRight
Gemini 3.5 Flash-Lite · Gemini

Randomises by user ID and cites the 31% cross-platform usage.

GPT-6 Astra · ChatGPT

Randomises by persistent account-ID across platforms, explicitly citing the 31% cross-platform usage and multiple sessions per buyer.

Decision rule written before the testRightRight
Gemini 3.5 Flash-Lite · Gemini

Maps ship, iterate, and rollback to p-value thresholds and guardrail degradation.

GPT-6 Astra · ChatGPT

The rule maps ship, retain control, and no-launch outcomes to specific conditions, including an inconclusive result.

Results

Every setup we’ve tested on this task type, across all its tasks and repeats, graded on the current checklist. Calibrated. Where our PM checked the graders by hand, they agreed on 85% of 39 checks.

#Model · HarnessTask scoreDecision modelLLM judgeRunsCritical failures
1Sonnet 5.5withAPI92.696.42None
2Haiku 5.5withAPI83.496.72None
3Opus 5.5withClaude88.779.02None
4GPT-6 AstrawithChatGPT88.976.02None
5GPT-6 LunawithAPI89.165.22None
6GPT-6.1 SolwithAPI83.169.32None
7Gemini 3.8 FlashwithAPI77.347.92None
8Gemini 3.5 Flash-LitewithGemini47.813.321 capped

What you get for the cost

No setup scores within 5 points of the leader at half its cost or less here, so the leader is also the best value.

Task score against relative cost for each setup. The table below has the same figures.20304050607080901001×3×10×30×100×Cost per output, relative to the cheapest setup (log scale) →↑ Task scoreSonnet 5.5 · API: task score 95, 33× the cheapestHaiku 5.5 · API: task score 89, 2.7× the cheapestOpus 5.5 · Claude: task score 81, 49× the cheapestGPT-6 Astra · ChatGPT: task score 79, 79× the cheapestGPT-6 Luna · API: task score 76, the cheapestGPT-6.1 Sol · API: task score 75, 13× the cheapestGemini 3.8 Flash · API: task score 60, 7.4× the cheapestGemini 3.5 Flash-Lite · Gemini: task score 29, 2.1× the cheapest, 1 critical failureSonnet 5.5 · APIHaiku 5.5 · APIOpus 5.5 · ClaudeGPT-6 Astra · ChatGPTGPT-6 Luna · APIGPT-6.1 Sol · APIGemini 3.8 Flash · APIGemini 3.5 Flash-Lite · Gemini
Nobody beats these on both score and costAt least one critical failure
Task score and relative cost by setup
SetupTask scoreRelative cost (cheapest = 1)
GPT-6 Luna · API761.0×
Gemini 3.5 Flash-Lite · Gemini292.1×
Haiku 5.5 · API892.7×
Gemini 3.8 Flash · API607.4×
GPT-6.1 Sol · API7513×
Sonnet 5.5 · API9533×
Opus 5.5 · Claude8149×
GPT-6 Astra · ChatGPT7979×

Cost is each output’s tokens at the model’s list price, shown relative to the cheapest setup. Runs done in an app have no usage meter, so theirs are estimated from the same setup’s measured runs. How we compare cost

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