The setting

Larkspur sells tickets for concerts and festivals. When a big show goes on sale, tens of thousands of fans hit the site in the first minute, so performance is the difference between a sellout and a meltdown.

Every mission on this path happens at the same company, so context carries over the way it does in a real job: the data you cleaned in mission two is the data the finance lead questions in mission four.

The missions

1. load scenariostarter

Design the load scenario for Larkspur's festival on sale

A major festival on sale is three weeks out and marketing expects the biggest rush of the year. Before anyone runs a test, you need to define what the load test should actually simulate.

You deliver: A load test scenario design with a workload model, concurrency, pacing, and pass criteria.

Scored on: Concrete numbers, Funnel weighting, Realistic pacing, Pass criteria.

Working from: traffic_forecast.md, user_journey.md.

2. baselinestarter

Establish the performance baseline for Larkspur's API

Before the festival load test you need a trustworthy baseline: how the site performs today under normal traffic. Without it, nobody can tell whether a change helped or hurt.

You deliver: A performance baseline report comparing current percentiles to the SLO and flagging at risk endpoints.

Scored on: SLO comparison, Breaches flagged, Baseline recorded, Interprets the data.

Working from: baseline_latency.csv, slo.md.

3. bottleneckcore

Find the bottleneck in Larkspur's checkout latency

The last load test rehearsal fell over: checkout p99 blew past 4 seconds while the rest of the site was fine. You have the stage level timings and a sample trace to find where the time goes.

You deliver: A bottleneck analysis naming the dominant stage, the tail behavior, and the likely cause.

Scored on: Names the bottleneck, Tail reasoning, Secondary versus primary, Quantified.

Working from: checkout_stage_latency.csv, trace_excerpt.md.

4. remediationcore

Write the remediation plan for Larkspur's seat hold contention

The bottleneck analysis is done and engineering wants a plan. The seat hold path buckles under load because of lock contention and an exhausted connection pool, and the next rehearsal is in a week.

You deliver: A remediation plan for the seat hold contention tied to the utilization data and pool config.

Scored on: Evidence tied, Pool exhaustion found, Sequenced, Verification named.

Working from: contention_findings.md, utilization.csv, pool_config.md.

5. capacity summarystretch

Write the capacity summary for Larkspur's festival on sale

The remediation shipped and the final load test is done. Leadership needs one page before the festival on sale: can we handle the rush, and if not, what do we add?

You deliver: A capacity summary stating safe capacity, the breaking point, and a provisioning recommendation for the on sale.

Scored on: Finds the knee, Safe capacity stated, Compares to forecast, Provisioning recommendation.

Working from: capacity_results.csv, infra.md.

How the scoring works

Each deliverable is graded against the rubric written for that mission. Separately, every mission on every path is graded on how you used AI, against the same four criteria:

  • Understood the task. The learner framed the goal for the assistant clearly instead of pasting the brief and hoping.
  • Grounded in the material. The learner directed the assistant into the provided files and based the work on them, not on invented facts.
  • Verified the output. The learner checked claims, numbers, or coverage against the source material before submitting.
  • Iterated with judgment. The learner refined weak parts of the draft with specific follow-ups rather than accepting the first answer.

Both scores, with the work behind them, go on your proof profile. That is what makes a claim like "I can use AI for performance testing" something an employer can check.