Definition of Shipped
Your spring grade’s largest partner-evaluation facet (Verification and Validation, 40%) is scored against outcomes: is the thing in production, merged upstream, reproducible, in real use? Those bars are hard. This document is how you stop them from being a surprise: a short, explicit agreement with your project partner about what “shipped” means for this project, written while there is still time to act on it.
With AI tools, building is rarely the long pole anymore. The external world is: maintainer review latency, app store review, IRB and data access, partner IT security review, real-user recruitment. Every one of those clocks is measured in weeks. This document plots them on the calendar.
What It Must Contain (1 to 2 pages, in docs/shipped.md)
Section titled “What It Must Contain (1 to 2 pages, in docs/shipped.md)”- The target rung: your outcome type, and which rung of the outcome ladder you are committing to, in your own words, specific to your project.
- Success metrics: 2 or 3 measurable signals of “it worked” (users completing a task, benchmark result, uptime, merged PRs), and how at least one will be instrumented for real before the final release.
- Prerequisites and lead times: everything the target rung requires that your team does not control (accounts, reviews, approvals, recruitment), each with an owner and a start-by date. See the Shipping guide for your outcome type’s known lead-time bombs.
- User access plan: who the real users or evaluators are and how you will reach them by the winter real-user gate.
- Partner agreement: evidence the partner has seen and agreed to this definition (meeting note, email, or survey confirmation).
Start from the Definition of Shipped template.
Rubric (100 points)
Section titled “Rubric (100 points)”| Criterion | Points | Outcome |
|---|---|---|
| Target rung explicit, project-specific, and honest about ambition | 25 | SO2 |
| Metrics measurable, with a concrete instrumentation plan for at least one | 25 | SO2 |
| Prerequisites and lead times complete, owned, and dated (nothing discoverable in week 8 of spring should be missing) | 25 | SO1 |
| Partner agreement evidenced | 15 | SO3 |
| Writing: brief, unambiguous, usable as a checklist | 10 | SO3 |
AI use: AI may draft the document from your Lean Canvas, your requirements, and the Shipping guide’s lead-time tables. It must not invent the partner agreement, a named user, or a lead time nobody checked. A fabricated partner confirmation or a made-up start-by date fails the assignment, because this document is a commitment other people will hold you to.
Activities That Prepare This
Section titled “Activities That Prepare This”Identify Success Metrics for the metrics and instrumentation criterion, and Dependency Mapping or Critical Path Analysis for prerequisites and lead times. User Story Mapping from fall feeds the target rung.
By outcome type, because what “shipped” costs in lead time differs completely:
| Outcome type | Activities |
|---|---|
| FOSS | Analyze an Existing Codebase to find out what this project’s maintainers actually require before a merge |
| Research | Identify Success Metrics for the target rung; Map Your External Approvals and Complete an IRB Application for prerequisites and lead times |
| Consultancy | Analyze an Existing Codebase when the system already exists; Map Your External Approvals and Stakeholder Mapping: your top rungs describe actions the partner takes, so the prerequisites are mostly theirs |
| New Product or Game | Hypothesis Testing and Find Users, since strangers take weeks to recruit and the channel must exist by winter |