Tasks / Metrics & Experimentation

Analyse experiment results

Can the model separate evidence from speculation, identify decision-relevant uncertainty and recommend a sensible next action?

Task type v1.2 · 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. 63% were usable with at most a quick edit.

Reliably right

  1. Respects explicit constraints100% pass
    The note is addressed to the onboarding team, stays under 300 words, and proposes actions that would enforce the stated constraints.
    GPT-6 Astra · ChatGPT · The underpowered onboarding test
  2. Interprets power correctly100% pass
    It correctly explains that the test was designed to detect a 3pp effect, that the CI includes both harm and benefit, and that extending would detect about 2pp.
    GPT-6 Astra · ChatGPT · The underpowered onboarding test
  3. Addresses the actual decision92% pass
    The output commits to a staged rollout as the recommended action, and specifies conditions (commercial unacceptability of a 1.4pp loss or value of a 2pp improvement) that would change the call to extending the test.
    GPT-6 Astra · ChatGPT · The underpowered onboarding test

Where it slips

  1. Uses the supplied evidence correctly56% pass
    States that the change is easy to reverse, which is not supported by the supplied context.
    Haiku 5.5 · API · The underpowered onboarding test
  2. Gets the base of every number right59% pass
    The Week 1 lift figure of +4.0% is a miscalculation; the correct rate from the supplied data is about 5.6%.
    Haiku 5.5 · API · Up 6%, and significant
  3. Avoids unsupported claims59% pass
    Presents 'the change is easy to reverse' as fact without evidence from the brief or context.
    Haiku 5.5 · API · The underpowered onboarding test

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. Trusts the data before reading it

    Before interpreting effects, does the analysis check whether the result is trustworthy (sample ratio, exposure or logging issues, novelty, a surprisingly large lift) and say what it found?

    Passes when Explicitly checks at least one trust signal in the supplied data, such as the split against the intended ratio, and treats a surprising result as a reason to investigate before acting.

  2. Doesn't overread an unclear result

    Does the analysis state honestly what the data can and can't show: no win claimed from an early peek or a result that isn't significant, and no 'no effect' concluded from a test too small to detect one?

    Passes when Every claim matches the strength of the evidence, and anything unclear is called unclear, with what it can't rule out.

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 · Gets the base of every number right · 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 data-literate PM on the shopping team at Bramble. Zoe wants to recommend shipping the new home page on Monday (her note is below). Check her conclusion against the raw data and write the readout you'd send instead, in no more than 900 words: what the test shows, what it doesn't, whether we should ship, and what we should do next. Show your working.\n\nThe files are attached.

What the model was given5 items: zoe_note.md, test_design.md, daily_results.csv (users and orders per day, by user type and arm), aov_by_week.md, incident_log.md
zoe_note.md1 lines · Download
From Zoe (PM for the home page): "Orders per user are up about 6% for treatment over the 28 days, and it's significant. AOV is flat. I'm going to recommend we ship on Monday. Can you sanity-check my readout before I send it?"
test_design.md5 lines · Download
# Test design (pre-registered)

Change: a new home page that leads with "Your usual basket" (one tap to reorder) for everyone.
Split: 50/50 by user. Primary metric: orders per user over the test. Guardrail: average order value.
Planned length: 28 days, 23 September to 20 October. Decision rule: ship if the lift on orders per user is positive and significant at the end, and average order value doesn't fall by more than 2%.
daily_results.csv (users and orders per day, by user type and arm)date,user_type,control_users,treatment_users,control_orders,treatment_orders 2026-09-23,new,2089,2400,129,184 2026-09-23,returning,4995,5799,464,559 2026-09-24,new,2079,2400,130,178 2026-09-24,returning,4900,5691,455,545 2026-09-25,new,2131,2485,134,188 2026-09-25,returning,4901,5684,465,537 2026-09-26,new,2131,2445,129,187 2026-09-26,returning,4944,5680,475,538 2026-09-27,new,2055,2357,122,180 2026-09-27,returning,4978,5744,471,527 2026-09-28,new,2080,2400,127,185 2026-09-28,returning,4819,5605,447,532 2026-09-29,new,2091,2414,130,186 2026-09-29,returning,4993,5784,483,555 2026-09-30,new,2070,2382,123,169 2026-09-30,returning,4956,5708,469,529 2026-10-01,new,2121,2432,131,170 2026-10-01,returning,5042,5820,482,560 2026-10-02,new,2041,2376,122,164 2026-10-02,returning,4954,5743,478,540 2026-10-03,new,2124,2455,131,166 2026-10-03,returning,4757,5475,453,500 2026-10-04,new,2142,2493,132,172 2026-10-04,returning,4906,5671,469,542 2026-10-05,new,2146,2464,131,175 2026-10-05,returning,5045,5845,472,554 2026-10-06,new,2115,2423,126,165 2026-10-06,returning,4830,5578,440,515 2026-10-07,new,2065,2381,124,149 2026-10-07,returning,4792,5580,458,540 2026-10-08,new,2137,2446,127,160 2026-10-08,returning,4960,5748,477,554 2026-10-09,new,2089,2409,131,159 2026-10-09,returning,4977,5717,465,525 2026-10-10,new,2138,2491,127,158 2026-10-10,returning,4787,5585,451,512 2026-10-11,new,2084,2406,131,151 2026-10-11,returning,4832,5568,461,521 2026-10-12,new,2060,2365,129,153 2026-10-12,returning,5012,5755,466,531 2026-10-13,new,2075,2408,128,154 2026-10-13,returning,4869,5664,462,528 2026-10-14,new,2038,2368,124,296 2026-10-14,returning,4988,5739,480,1058 2026-10-15,new,2078,2394,130,146 2026-10-15,returning,5047,5787,469,548 2026-10-16,new,2043,2340,124,147 2026-10-16,returning,4965,5742,478,541 2026-10-17,new,2078,2403,128,152 2026-10-17,returning,4865,5625,455,518 2026-10-18,new,2157,2472,135,152 2026-10-18,returning,4789,5530,441,526 2026-10-19,new,2046,2346,124,147 2026-10-19,returning,4775,5526,442,512 2026-10-20,new,2129,2481,129,158 2026-10-20,returning,4863,5623,444,536
aov_by_week.md8 lines · Download
# Average order value by week ($, all users)

| Week | Control | Treatment |
|---|---|---|
| 1 | 48.20 | 47.90 |
| 2 | 48.40 | 48.10 |
| 3 | 48.10 | 47.80 |
…
incident_log.md3 lines · Download
# Incident log

- 14 October: a release of the order tracking service logged some order events twice for 9 hours. Fixed the same day. Engineering believes it affected the new home page only.
What a strong answer doesThe answer key the graders mark against

Doesn't recommend shipping on this readout. Checks trust first: treatment got about 53.6% of users against an intended 50/50, a sample ratio mismatch that has to be explained before any result is trusted. 14 October's treatment orders are about double the surrounding days (the logging bug in the incident log), which inflates the headline: about 5.8% lift with it, about 2.4% without. The lift fades week by week (about 5.6%, 2.5%, 0.2%, 1.1%), a novelty pattern, so the long-run effect is near zero. All of the lift is in new users (about 11.5%); returning users, the majority, show none (about -0.1%). AOV is flat, so the guardrail holds. So the pre-registered rule (significant positive lift at the end) isn't met once the data is cleaned. Next steps: find the cause of the sample ratio mismatch, rerun or extend with the logging fixed, and consider the reorder module for new users only as a separate test.

Critical failures (cap the score at 40)
  • Recommends shipping on Monday as Zoe proposed
Task

Staff-level · v1.0

The outputs

8 setups answered this brief.

Needs more than a quick edit4 of 12 checks passed

The analysis relies on incorrect numbers and unsupported conclusions; a PM would need to redo the entire analysis from the raw data.

Output

A/B Test Readout: New Home Page ("Your Usual Basket")

To: Zoe (PM, Shopping Team) From: Data-Literate PM Date: October 24, 2026 Subject: Sanity-check readout on the Home Page A/B test (Sept 23 – Oct 20)

*

Zoe—I’ve pulled the raw data and checked the numbers against our pre-registered design. While your top-line metric looks like a win on the surface, a deeper dive into the daily breakdown reveals a major data anomaly that completely flips our conclusion.

We should not ship on Monday. Here is what the data actually shows, why your initial read is misleading, and what we need to do next.

---

1. Working & Data Breakdown

Let’s aggregate the 28-day totals from `daily_results.csv` by summing total users and orders across the test window:

  • Control Arm:
  • New Users: ~58,698 user-days | 3,556 orders
  • Returning Users: ~137,367 user-days | 12,949 orders
  • Total Control Orders: 16,505
  • Treatment Arm:
  • New Users: ~67,820 user-days | 4,505 orders
  • Returning Users: ~158,837 user-days | 15,084 orders
  • Total Treatment Orders: 19,589

If we simply take the aggregate ratio of orders to user-days, treatment appears to show a healthy lift. However, two critical factors invalidate a straightforward shipping decision: the October 14 data contamination incident and a sharp downward trend over time.

#### The October 14 Incident (The Smoking Gun) Check the `incidentlog.md` and `dailyresults.csv` for October 14: * Control: 124 new user orders, 480 returning user orders. * Treatment: 296 new user orders, 1,058 returning user orders! (More than double normal volume).

An engineering bug logged order events twice for 9 hours on October 14, exclusively affecting the treatment arm. If we remove October 14 from the dataset and recalculate the totals: * Treatment orders drop by 1,354 (296 $\rightarrow$ ~155 for new; 1,058 $\rightarrow$ ~530 for returning). * Adjusted Treatment Orders: ~18,235.

When you control for this logging artifact, the apparent 6% overall lift vanishes.

#### The Trend Line (Novelty vs. Fatigue) Even more concerning than the incident is the trajectory of the test. Let’s look at the treatment vs. control order lift week-by-week (normalized by user-day volume): * Week 1 (Sept 23–29): Treatment orders per user-day ran ~11.5% higher than control. * Week 2 (Sept 30–Oct 6): Lift compressed to ~6.5%. * Week 3 (Oct 7–13, pre-incident): Lift compressed further to ~2.8%. * Week 4 (Oct 15–20, post-incident): Lift hovered near +1.2% to +2.0%.

The treatment experienced a massive novelty effect. Users loved the "one-tap reorder" novelty in week one, but engagement steadily eroded every single week until it flatlined near zero by the end of the test.

(Note on AOV: As you noted, AOV remained flat across all 4 weeks at ~$48.00–$48.30 for both arms, successfully passing our guardrail criteria—but a flat AOV doesn't save a primary metric that is dying out).

---

2. What the Test Actually Shows

  1. A Severe Novelty Effect: The home page redesign generated short-term excitement, but long-term sustained engagement for the "Your Usual Basket" feature is weak. By week three and four, the feature stopped driving incremental orders.
  2. Zero Net Long-Term Lift: Once you excise the duplicate logging events from October 14, the actual organic lift over 28 days is negligible and statistically insignificant.
  3. AOV Guardrail Passed: The feature did not cannibalize basket sizes. Customers ordering via the one-tap shortcut spent roughly the same per order as control users.

---

3. What the Test Does Not Show

  • It does NOT show a permanent 6% increase in orders. That figure is an artifact of combining uncleaned incident data with outsized first-week novelty behavior.
  • It does NOT show user frustration or churn. AOV is flat and user counts remained stable in treatment, meaning the feature isn't hurting the experience—it's just failing to create a lasting habit.

---

4. Recommendation: Do Not Ship on Monday

We should hold off on shipping the new home page. Launching it now would mean shipping a feature that currently provides zero net business value after the initial novelty wears off, while locking in UI space for a component that isn't pulling its weight.

---

5. Next Steps

  1. Clean the Data & Re-run Stats: Have data engineering pull a properly deduplicated user-level dataset for the 28 days (excluding the Oct 14 telemetry glitch entirely) to get the true p-value on the clean sample.
  2. Segment Analysis by User Frequency: "Your Usual Basket" assumes users have a habitual, repetitive basket. Let's slice the data by user tenure and order frequency. Did it work brilliantly for high-frequency weekly buyers while failing for monthly/new buyers? If so, we might have a targeted personalization play.
  3. UX Iteration: If high-frequency users did retain value, consider a hybrid home page where one-tap reordering is surfaced dynamically only to returning users with high purchase frequency, rather than the blanket "for everyone" treatment tested here.

Claims the judge couldn’t find in the brief

  • Control Arm totals: ~58,698 new user-days, 3,556 orders; ~137,367 returning user-days, 12,949 orders; total 16,505 orders.
  • Treatment Arm totals: ~67,820 new user-days, 4,505 orders; ~158,837 returning user-days, 15,084 orders; total 19,589 orders.
  • Adjusted Treatment Orders after removing Oct 14: ~18,235.
  • Week 1 lift ~11.5%, Week 2 ~6.5%, Week 3 ~2.8%, Week 4 +1.2% to +2.0%.
  • The apparent 6% overall lift vanishes after removing Oct 14.
  • The actual organic lift over 28 days is negligible and statistically insignificant.
  • The home page redesign generated short-term excitement (novelty effect) and long-term engagement is weak.
  • By week three and four, the feature stopped driving incremental orders.

Grades and run details

Decision model 54 · LLM judge 31
Decision model checks
  • failUses the supplied evidence correctly53%
  • passAddresses the actual decision65%
  • passRespects explicit constraints32%
  • partialIdentifies material uncertainty69%
  • failAvoids unsupported claims36%
  • passProduces the required deliverable28%
  • failCatches the sample ratio mismatch98%
  • passRemoves the bug day97%
  • partialReads the trend and who it helps99%
  • passTrusts the data before reading it88%
  • failGets the base of every number right76%
  • partialDoesn't overread an unclear result35%
Run
Run
#1
Time to output
7 s
Submitted
5 Oct 2026

Usable with a quick edit11 of 12 checks passed

The readout is complete, logically sound, and requires only minor wording tweaks to address Zoe directly; no evidence re-checking or reasoning redo is needed.

Output

Readout: don’t ship the new home page on Monday. The logged data reproduce Zoe’s roughly 6% lift, but they do not yet establish a valid, durable improvement in the pre-registered metric. We have a treatment-specific measurement incident, an unexplained arm imbalance, and a lift that weakens substantially over time.

1. What the headline shows—and how I calculated it

I summed orders and reported daily users within each arm, then calculated:

\[ \text{Lift}=\frac{\text{treatment orders}/\text{treatment users}} {\text{control orders}/\text{control users}}-1 \]

Logged totals, all 28 daysControlTreatment
------:---:
Sum of daily users196,173226,652
Orders16,56020,234
Orders / summed daily users0.084420.08927

Thus, the logged lift is 5.75%, consistent with “about 6%.”

However, summed daily users are not necessarily distinct randomized users. If users recur across days, this is orders per user-day, not the pre-registered orders per user over the test. If these are active or exposed users, the denominator may itself be affected by treatment. We need the denominator definition and assignment-level data before accepting the primary result.

Nor can these aggregates validate Zoe’s significance claim. For illustration, treating orders as independent Poisson counts gives:

\[ SE(\log RR)=\sqrt{1/20{,}234+1/16{,}560}=0.01048 \]

That produces a nominal 95% lift interval of approximately +3.6% to +8.0%. But it ignores repeated-user dependence, potentially treatment-dependent denominators, and corrupted order counts. It is not a valid substitute for inference at the randomized-user level.

2. The tracking incident materially inflates the result

On 14 October, treatment logged 1,354 orders, versus roughly 700 on surrounding days. Control logged 604. This aligns with the incident report, although we cannot identify the exact duplicate count from these aggregates.

As a sensitivity check, removing that entire day from both arms, including its denominators, gives:

Excluding 14 OctoberControlTreatment
------:---:
Sum of daily users189,147218,545
Orders15,95618,880
Orders / summed daily users0.084360.08639

Lift becomes 2.41%, less than half the headline. This does not prove there is no effect; equally, dropping a day is not a repaired primary analysis. We should deduplicate against authoritative order IDs, not halve the day’s orders or discard inconvenient observations.

3. The remaining signal is concentrated early and among new users

Using the same rate calculation within each week and segment:

WeekAll usersNew usersReturning users
------:---:---:
1+5.6%+24.0%+0.5%
2+2.5%+14.3%−0.8%
3+0.2%+4.7%−1.0%
4, excluding 14 October+1.1%+1.7%+1.0%

Across all non-incident days, new-user lift is approximately +11.5%, while returning-user lift is −0.1%.

This is not evidence of a broad reorder benefit for everyone. The pattern is consistent with novelty, changing cohorts, or another time-dependent effect—not proof of any one explanation. These are exploratory comparisons, not statistically established segment differences or grounds to ship only to new users. Calendar-week results also do not measure persistence since each user’s first exposure.

4. Allocation and AOV require qualification

Treatment accounts for 53.6% of reported user-days, despite the planned 50/50 user split; the imbalance appears throughout the test. Repeated daily users prevent a valid assignment-level sample-ratio test here. It could reflect assignment problems, logging, filtering, or treatment-driven activity. We must reconcile it against unique randomized users, rather than assume either harmless imbalance or broken randomization.

Weekly AOV is down approximately 0.2–0.6%, not literally flat. Those point estimates are within the −2% guardrail, but weekly averages provide neither uncertainty nor assurance that duplication did not distort order weighting.

Decision and next steps

The pre-registered shipping rule should stand—but we have not established that it was met with valid data.

  1. Reconcile assignment, eligibility, exposure, and user counts; investigate the imbalance.
  2. Rebuild orders and revenue from authoritative transactions; verify the incident’s scope in both arms.
  3. Recompute 28-day orders per randomized user, including zero-order users, with user-level uncertainty; recompute AOV and its uncertainty.
  4. Examine pre-treatment segments and exposure-age cohorts to investigate persistence without treating exploratory findings as confirmatory.
  5. If the original test cannot support a trustworthy decision, run a repaired, newly pre-registered test. Do not silently extend this fixed-horizon test until significance returns.

Grades and run details

Decision model 92 · LLM judge 100
Decision model checks
  • passUses the supplied evidence correctly16%
  • passAddresses the actual decision95%
  • passRespects explicit constraints53%
  • passIdentifies material uncertainty98%
  • passAvoids unsupported claims68%
  • passProduces the required deliverable64%
  • passCatches the sample ratio mismatch99%
  • passRemoves the bug day100%
  • passReads the trend and who it helps97%
  • passTrusts the data before reading it100%
  • failGets the base of every number right24%
  • passDoesn't overread an unclear result81%
Run
Run
#1
Time to output
77 s
Submitted
5 Oct 2026

Usable with a quick edit11 of 12 checks passed

The readout is thorough, evidence-based, and directly actionable. A PM could use it with minor wording tweaks and no need to re-verify the data or logic.

Output

Readout: new home page test (23 Sep – 20 Oct)

Recommendation: don't ship on Monday. The +6% headline comes from three things:

  • A broken 50/50 split.
  • A day of double-counted treatment orders.
  • A new-user bump that faded to about zero by week 4.

Returning users are the people "Your usual basket" is built for, and they show no lift. None of the three problems is a reason to kill the page. They are reasons not to trust this result yet.

1. Reproducing Zoe's number

Totals across 28 days, using `daily_results.csv`, both user types:

Users (user-days)OrdersOrders/user
Control196,17316,5600.0844
Treatment226,65220,2340.0893

The lift is +5.8%, which matches "about 6%". The arithmetic is right. The problems are in the data underneath it.

2. The split isn't 50/50 (sample ratio mismatch)

The test was pre-registered as 50/50. Treatment has 53.6% of users (226,652 of 422,825).

  • A chi-square test against 50/50 gives χ² ≈ 2,200. The chance of that happening randomly is effectively zero.
  • The gap is steady: treatment has about 15.5% more users every day, in both segments (new 1.154×, returning 1.156×).
  • The new/returning mix is the same in both arms (about 30% new), so this isn't a mix-shift artefact.

A constant 15% surplus usually means assignment or exposure logging is broken. For example, treatment could be logging users that control drops, or redirects or caching could differ between arms. Until we know why, we can't assume the two groups are comparable. On its own, this fails the test's validity check, whatever the lift.

3. The 14 October incident doubled treatment orders

On 14 Oct, treatment orders roughly doubled while control stayed normal:

  • New users: 296 orders in treatment, against about 150 on the days around it. Control: 124.
  • Returning users: 1,058 orders in treatment, against about 530. Control: 480.

This matches the incident log: order events were logged twice, on the new home page only. That day adds about 680 phantom orders to treatment.

Excluding 14 Oct from both arms:

ControlTreatmentLift
New3,464 / 56,594 = 0.06124,455 / 65,268 = 0.0683+11.5%
Returning12,492 / 132,553 = 0.094214,425 / 153,277 = 0.0941−0.1%
All15,956 / 189,147 = 0.084418,880 / 218,545 = 0.0864+2.4%

The overall lift drops from 5.8% to 2.4%. A naive z-test on that is about 2.3, but it treats each user-day as independent, which overstates confidence. The same user appears on many days, and the split itself is suspect.

4. The remaining lift is a fading new-user effect

New users, orders per user by week (week 4 excludes 14 Oct):

WeekControlTreatmentLift
10.06150.0762+24%
20.06070.0694+14%
30.06120.0641+5%
40.06140.0625+2%

Returning users by week: +0.5%, −0.8%, −1.0%, +1.0%. That is flat, which is what noise looks like.

Overall lift went from +5.6% in week 1 to +1.1% in week 4. Two things stand out:

  • The effect is decaying towards zero. That pattern looks like novelty, not a lasting change in behaviour.
  • It shows up in new users, who mostly have no "usual basket" yet. It is absent in returning users, who are who the feature is for. That doesn't fit the mechanism we expected, and we should understand it before acting.

5. Average order value guardrail

Treatment AOV is $0.30 lower in weeks 1–3 (−0.6%) and $0.10 lower in week 4 (−0.2%). That is inside the 2% guardrail, so "flat" is fair.

Two caveats:

  • Week 4 may include the duplicated orders.
  • AOV only matters alongside order volume. With clean data, revenue per user is roughly +2.4% × 0.995 ≈ +1.8% overall, and about −0.7% for returning users.

What the test shows

  • The new page probably raises early ordering among new users, at least for a couple of weeks.
  • It doesn't hurt order value by enough to trip the guardrail.
  • No breakage or disaster is visible.

What it doesn't show

  • A valid comparison. The sample ratio mismatch means the arms may not be comparable.
  • A lasting lift. By week 4 the effect is about 1%, inside the noise.
  • Any effect on returning users, the target audience.
  • The pre-registered metric. The test design specifies orders per user, but this file holds user-days. We need user-level data to compute it properly. The current significance claim relies on treating user-days as independent.
  • That the incident only hit treatment. "Engineering believes" isn't confirmation. If control was also affected at a lower level, the 14 Oct correction above is off.

Should we ship?

No, not on this evidence.

The decision rule technically passes on the raw numbers. But it assumed a valid 50/50 split and clean order counts, and we have neither. Shipping now would lock in a 6% claim that is mostly a logging bug, an assignment bug and novelty.

Next steps

  1. Find the cause of the 15% user surplus (owner: eng + analytics, this week). Compare assignment logs against exposure logs, and check bot filtering, redirects and caching per arm. Run an A/A check once it's fixed.
  2. Deduplicate 14 Oct using order or event IDs, rather than dropping the day, and confirm control was unaffected.
  3. Pull user-level data and recompute orders per user as pre-registered. Use proper per-user variance, or bootstrap by user.
  4. Rerun once the split is fixed, for at least 4 weeks. Report results by week and by new vs returning users, with returning users as the key read. If returning users still show nothing, rethink the feature (e.g. show "usual basket" only once a user has one) rather than shipping it to everyone.
  5. Investigate the new-user effect: what do new users see in the "usual basket" slot, and what are they ordering? If it's real and durable, a new-user variant could be worth its own test.

Zoe: the analysis was a reasonable first pass and the headline maths checks out. Happy to pair on the rerun plan so we can bring a clean answer back.

Grades and run details

Decision model 92 · LLM judge 100
Decision model checks
  • passUses the supplied evidence correctly21%
  • passAddresses the actual decision100%
  • passRespects explicit constraints42%
  • passIdentifies material uncertainty100%
  • passAvoids unsupported claims43%
  • passProduces the required deliverable88%
  • passCatches the sample ratio mismatch100%
  • passRemoves the bug day100%
  • passReads the trend and who it helps100%
  • passTrusts the data before reading it100%
  • failGets the base of every number right5%
  • passDoesn't overread an unclear result66%
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 8

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

Multiple key numbers (user-days, orders, adjusted totals, weekly lifts) are invented and do not match the supplied data.

GPT-6 Astra · ChatGPT

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

Opus 5.5 · Claude

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

Avoids unsupported claimsWrongRightRight
Gemini 3.5 Flash-Lite · Gemini

It presents the novelty effect, the feature stopping incremental orders, and statistical insignificance as established facts without labelling them as hypotheses.

GPT-6 Astra · ChatGPT

Interpretations like novelty are clearly labelled as possibilities, not established fact; confident claims are backed by the data.

Opus 5.5 · Claude

Interpretations like 'novelty effect' and 'probably raises early ordering' are clearly labelled as hypotheses, not established facts.

Produces the required deliverableMixedRightRight
Gemini 3.5 Flash-Lite · Gemini

The readout contains incorrect numbers, so a PM cannot act on it without redoing the analysis; it is not usable as-is.

GPT-6 Astra · ChatGPT

The readout is complete, within the word limit, and usable by Zoe with at most light edits.

Opus 5.5 · Claude

The readout is complete, in the right form, and a PM could act on it with light edits.

Catches the sample ratio mismatchWrongRightRight
Gemini 3.5 Flash-Lite · Gemini

The output never computes the user split or mentions the sample ratio mismatch (treatment got ~53.6% of users).

GPT-6 Astra · ChatGPT

The output computes the 53.6% treatment split, notes it deviates from 50/50, and states the cause must be found before trusting the result.

Opus 5.5 · Claude

The output computes the split (53.6% treatment), calls it a sample ratio mismatch, and states the cause must be found before trusting the result.

Removes the bug dayMixedRightRight
Gemini 3.5 Flash-Lite · Gemini

It identifies the Oct 14 bug but the recalculation is wrong and it does not state the corrected lift falls to about 2-3%.

GPT-6 Astra · ChatGPT

The output identifies 14 October's inflated treatment orders, links them to the incident log, and recalculates the lift as 2.41% without that day.

Opus 5.5 · Claude

The output identifies 14 October's inflated treatment orders, links them to the incident log, and recalculates the lift without that day (drops to 2.4%).

Reads the trend and who it helpsWrongRightRight
Gemini 3.5 Flash-Lite · Gemini

It gives weekly trend numbers but does not show the new vs returning split or that the lift comes only from new users.

GPT-6 Astra · ChatGPT

The output provides weekly lift numbers (5.6%, 2.5%, 0.2%, 1.1%) and new vs returning split (11.5% vs -0.1%), concluding the lift fades and is concentrated in new users.

Opus 5.5 · Claude

The output provides weekly lifts for new and returning users, shows the effect fading, and correctly concludes the lift is a novelty pattern concentrated in new users.

Gets the base of every number rightWrongMixedMixed
Gemini 3.5 Flash-Lite · Gemini

Derived figures (totals, weekly lifts, adjusted orders) are not computed correctly from the supplied data.

GPT-6 Astra · ChatGPT

All derived percentages and rates use the correct denominators, and ambiguous bases (e.g., orders per user-day vs per user) are stated.

Opus 5.5 · Claude

All percentages and rates are computed from the correct denominators, and the output notes that the data is user-days, not unique users.

Doesn't overread an unclear resultWrongRightRight
Gemini 3.5 Flash-Lite · Gemini

It claims the lift is negligible and statistically insignificant without a proper test, overreading an unclear result.

GPT-6 Astra · ChatGPT

The output does not claim a win or no effect; it states the data cannot yet support a valid conclusion and that the pattern is not proof of any single explanation.

Opus 5.5 · Claude

The output states what the test can and cannot show, calls the week-4 effect 'inside the noise', and does not claim a win or a conclusive null.

All got right 4

Addresses the actual decisionRightRightRight
Gemini 3.5 Flash-Lite · Gemini

The output clearly says 'We should not ship on Monday' and states that a clean dataset and true p-value would change the call.

GPT-6 Astra · ChatGPT

The output commits early and unambiguously to 'don't ship the new home page on Monday' and states what would change the call (reconciled, valid data meeting the pre-registered rule).

Opus 5.5 · Claude

The output clearly recommends not shipping on Monday, addresses Zoe directly, and specifies what would change the call (fixing the split, deduplicating, rerunning).

Respects explicit constraintsRightRightRight
Gemini 3.5 Flash-Lite · Gemini

The readout is addressed to Zoe, is under 900 words, and includes the requested sections.

GPT-6 Astra · ChatGPT

The readout is under 900 words, addresses the decision for Zoe, and respects the requested form.

Opus 5.5 · Claude

The readout is under 900 words, shows working, and is written for Zoe as requested.

Identifies material uncertaintyRightRightRight
Gemini 3.5 Flash-Lite · Gemini

It names the need for a deduplicated dataset, segment analysis, and UX iteration to resolve unknowns.

GPT-6 Astra · ChatGPT

The output names specific unknowns (denominator definition, arm imbalance cause, duplicate count, persistence) and says how to resolve them (reconcile assignment, rebuild from authoritative transactions, examine cohorts).

Opus 5.5 · Claude

The output names specific unknowns (cause of SRM, whether control was affected, need for user-level data) and says how to resolve them.

Trusts the data before reading itRightRightRight
Gemini 3.5 Flash-Lite · Gemini

It checks the Oct 14 logging incident as a trust signal before interpreting the effect.

GPT-6 Astra · ChatGPT

Before interpreting the effect, the output checks the sample ratio mismatch, the logging incident, and the denominator issue, treating them as reasons to investigate before acting.

Opus 5.5 · Claude

Before interpreting the effect, the output checks the sample ratio and the bug day, treating the surprising split as a reason to distrust the 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 63% of 40 checks.

#Model · HarnessTask scoreDecision modelLLM judgeRunsCritical failures
1GPT-6 AstrawithChatGPT95.8100.02None
2Sonnet 5.5withAPI88.395.52None
3Opus 5.5withClaude80.886.42None
4GPT-6.1 SolwithAPI89.280.82None
5Haiku 5.5withAPI88.371.02None
6GPT-6 LunawithAPI88.864.72None
7Gemini 3.8 FlashwithAPI69.645.82None
8Gemini 3.5 Flash-LitewithGemini54.651.72None

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.4050607080901001×3×10×30×100×Cost per output, relative to the cheapest setup (log scale) →↑ Task scoreGPT-6 Astra · ChatGPT: task score 98, 107× the cheapest (1 of 2 outputs estimated)Sonnet 5.5 · API: task score 92, 35× the cheapestOpus 5.5 · Claude: task score 84, 95× the cheapest (1 of 2 outputs estimated)GPT-6.1 Sol · API: task score 83, 14× the cheapestHaiku 5.5 · API: task score 78, 1.8× the cheapestGPT-6 Luna · API: task score 75, the cheapestGemini 3.8 Flash · API: task score 55, 12× the cheapestGemini 3.5 Flash-Lite · Gemini: task score 53, 3.1× the cheapest (1 of 2 outputs estimated)GPT-6 Astra · ChatGPTSonnet 5.5 · APIOpus 5.5 · ClaudeGPT-6.1 Sol · APIHaiku 5.5 · APIGPT-6 Luna · APIGemini 3.8 Flash · APIGemini 3.5 Flash-Lite · Gemini
Nobody beats these on both score and costCost partly estimated (app runs with no usage meter)
Task score and relative cost by setup
SetupTask scoreRelative cost (cheapest = 1)
GPT-6 Luna · API751.0×
Haiku 5.5 · API781.8×
Gemini 3.5 Flash-Lite · Gemini533.1× (partly estimated)
Gemini 3.8 Flash · API5512×
GPT-6.1 Sol · API8314×
Sonnet 5.5 · API9235×
Opus 5.5 · Claude8495× (partly estimated)
GPT-6 Astra · ChatGPT98107× (partly estimated)

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

Reading a test readout and deciding what to do next.

Why it matters

Experiment readouts are where false confidence is cheapest to produce and most expensive to act on. A model that declares a winner on conversion while retention quietly falls will ship the wrong thing.

What good looks like

  • Checks the result can be trusted before interpreting it
  • Reports effects with their uncertainty
  • Checks guardrail metrics before declaring a winner
  • Separates what the data shows from plausible explanations
  • Recommends a next step proportionate to the evidence

Deliberately not measured

  • Re-running the statistics from raw data
  • Chart production
Capability tested

Interpreting results within their limits

The failure we’re looking for

Claims causality, ignores guardrails or recommends arbitrary testing

Grading

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