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.

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

Needs more than a quick edit6 of 12 checks passed

The output contains miscalculated user-day totals and fabricated weekly metrics, so a PM would need to redo the analysis before using it.

Output

To: Zoe, PM – Home Page From: Shopping Team PM Subject: Sanity Check & Readout: Home Page "Your usual basket" Experiment

---

Recommendation: Do Not Ship on Monday

We should not ship the new home page.

While the headline metric shows orders per user up +6.0% in treatment ($p < 0.01$), this number is an illusion created by two compounding issues: an uncorrected tracking outage on October 14 and a short-lived novelty spike that decayed to near-zero by Week 4. Furthermore, the test suffered a severe Sample Ratio Mismatch (SRM) that statistically invalidates the experiment.

---

What the Test Shows (The Working Behind the Numbers)

#### 1. The Headline Lift (+6.0%) is Skewed by the Oct 14 Outage Zoe’s calculation reflects raw cumulative totals: * Control: 16,560 orders / 196,118 user-days = 8.44% orders/user * Treatment: 20,234 orders / 226,108 user-days = 8.95% orders/user * Relative lift: $(8.95\% - 8.44\%) / 8.44\% = \mathbf{+5.98\%}$

However, on October 14, an order-tracking release logged duplicate events for 9 hours in treatment only. Treatment logged 296 new and 1,058 returning orders that day, compared to baseline averages of ~150 and ~530.

Removing the ~674 phantom orders from October 14 cuts cumulative treatment orders to 19,560 (8.65%), reducing the true test-wide lift from +6.0% to +2.4%.

---

#### 2. Performance Eroded Over Time (Novelty Effect, Not Habit) Breaking the data into weekly cohorts reveals that the remaining lift was concentrated entirely in the first two weeks:

WeekControl Orders/UserTreatment Orders/UserRelative LiftNotes
:---:---::---::---::---
W1 (Sep 23–29)8.46%10.38%+22.7%Initial novelty spike
W2 (Sep 30–Oct 6)8.46%9.07%+7.2%Steep decay
W3 (Oct 7–13)8.46%8.50%+0.5%Parity reached
W4 (Oct 15–20, excl. Oct 14)8.36%8.46%+1.2%Flat / non-significant

By Week 4, the conversion advantage had evaporated.

---

#### 3. Core Hypothesis Failed for Returning Users The feature was built around "Your usual basket" to streamline reordering for repeat shoppers. Yet returning users saw no meaningful lift: * Returning Users (W1–W4 excl. Oct 14): * Control: 12,492 orders / 132,497 users = 9.43% * Treatment: 14,425 orders / 152,736 users = 9.44% * Relative lift: $\mathbf{+0.1\%}$ (Flat across the entire month).

The entire early lift came from new users (W1 lift was +23.9%, dropping to +1.8% in W4). Because new users have no purchase history, their initial behavior was likely driven by curiosity or generic pre-filled items, but it did not drive sustained repeat purchasing.

---

#### 4. Critical Integrity Blocker: Severe Sample Ratio Mismatch (SRM) The experiment was pre-registered as a 50/50 split. The actual traffic split across the test was: * Control: 196,118 user-days (46.45%) * Treatment: 226,108 user-days (53.55%)

With over 422,000 total user-days, a 53.6 / 46.4 split yields a chi-square test statistic $> 2,100$ ($p < 10^{-100}$). This is a massive SRM. It indicates an underlying assignment, routing, or tracking bias (e.g., users re-randomizing into treatment or bot filtering affecting arms unequally). In standard experimentation practice, an unresolved SRM invalidates all primary and guardrail metric conclusions.

---

What the Test Doesn't Show

  1. True long-term incremental lift: Because returning user behavior was flat from Day 1 and new user behavior converged to control, we have no evidence this UI drives sustained incremental GMV.
  2. Impact on discovery: While AOV stayed within guardrails (down ~0.6% across weeks, within the -2% threshold), we do not know if "one tap to reorder" cannibalized category browsing, cross-selling, or discovery of new inventory.

---

What We Should Do Next

1. Halt Rollout: Do not ship to production on Monday. 2. Audit Randomization & Logging (P0): Partner with platform engineering to identify the root cause of the 53.6/46.4 SRM and verify that order-tracking telemetry is isolated and accurate. 3. Re-segment the Product Experience: * For Returning Users: Qualitative/UX research into why returning users did not reorder more. Did "Your usual basket" feel stale, inaccurate, or intrusive? * For New Users: Suppress "Your usual basket" for zero-order users. Replace it with an onboarding module, category discovery, or top-trending items. 4. Re-test with Proper Guardrails: Once the SRM is fixed and segmentation logic is deployed, launch a clean 50/50 A/B test powered by user-level deduplication over a full 28-day cycle.

Claims the judge couldn’t find in the brief

  • Control: 16,560 orders / 196,118 user-days = 8.44% orders/user; Treatment: 20,234 orders / 226,108 user-days = 8.95% orders/user.
  • Removing ~674 phantom orders from October 14 cuts cumulative treatment orders to 19,560 (8.65%), reducing lift to +2.4%.
  • Week 1 treatment orders/user was 10.38% (lift +22.7%), Week 2 9.07% (+7.2%), Week 3 8.50% (+0.5%), Week 4 8.46% (+1.2%).
  • Returning users (W1–W4 excl. Oct 14): Control 9.43%, Treatment 9.44%, lift +0.1%.
  • Actual traffic split: Control 196,118 user-days (46.45%), Treatment 226,108 user-days (53.55%).
  • New users' initial behavior was likely driven by curiosity or generic pre-filled items.

Grades and run details

Decision model 79 · LLM judge 46
Decision model checks
  • failUses the supplied evidence correctly21%
  • passAddresses the actual decision92%
  • passRespects explicit constraints53%
  • passIdentifies material uncertainty92%
  • partialAvoids unsupported claims41%
  • passProduces the required deliverable86%
  • passCatches the sample ratio mismatch100%
  • passRemoves the bug day100%
  • passReads the trend and who it helps91%
  • passTrusts the data before reading it100%
  • failGets the base of every number right37%
  • passDoesn't overread an unclear result36%
Run
Run
#1
API response time
67 s
Submitted
6 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 6

Uses the supplied evidence correctlyRightWrongRight
GPT-6 Astra · ChatGPT

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

Gemini 3.8 Flash · API

The output uses incorrect user-day totals and fabricated weekly orders/user numbers that do not match the supplied data.

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 claimsRightWrongRight
GPT-6 Astra · ChatGPT

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

Gemini 3.8 Flash · API

The weekly lift numbers and the explanation of new-user behavior are presented as fact without support from 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 deliverableRightMixedRight
GPT-6 Astra · ChatGPT

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

Gemini 3.8 Flash · API

The analysis contains incorrect numbers, so a PM could not act on it without redoing the calculations.

Opus 5.5 · Claude

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

Reads the trend and who it helpsRightMixedRight
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.

Gemini 3.8 Flash · API

The weekly trend and new/returning split are given with numbers, but those numbers are incorrect and not drawn from the data.

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 rightMixedWrongMixed
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.

Gemini 3.8 Flash · API

The user-day totals and weekly orders/user rates are computed from wrong base numbers.

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 resultRightMixedRight
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.

Gemini 3.8 Flash · API

It overreads the data by presenting a fabricated weekly decay pattern as fact, rather than honestly stating what the data shows.

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 6

Addresses the actual decisionRightRightRight
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).

Gemini 3.8 Flash · API

The output clearly recommends 'Do Not Ship on Monday' early and unambiguously.

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
GPT-6 Astra · ChatGPT

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

Gemini 3.8 Flash · API

The readout is addressed to Zoe, is under 900 words, and follows the requested format.

Opus 5.5 · Claude

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

Identifies material uncertaintyRightRightRight
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).

Gemini 3.8 Flash · API

It names the SRM cause, impact on discovery, and returning-user behavior as unknowns, and says fixing the SRM and re-testing would resolve them.

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.

Catches the sample ratio mismatchRightRightRight
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.

Gemini 3.8 Flash · API

It computes the split as 53.6% treatment, calls it a massive SRM, and says 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 dayRightRightRight
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.

Gemini 3.8 Flash · API

It identifies the inflated orders on Oct 14, links them to the incident log, and recalculates lift 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%).

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

Gemini 3.8 Flash · API

It checks the sample ratio mismatch and the logging bug before interpreting the effect.

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