Vertical blueprint
Design the pursuit, suite, evidence, progression, presentation, creator story, and proof before writing package code.
The blueprint is the product contract for a deep vertical. It prevents a valid SDK implementation from becoming a shallow collection of unrelated modes.
1. Map the real ecosystem
Document the community's accepted practice methods, specialist tools, common metrics, creator workflows, overlays, terminology, failure modes, and gaps. For each existing tool, choose deliberately:
| Choice | Use it when |
|---|---|
| Integrate | The tool is trusted and emits useful evidence through a safe boundary. |
| Complement | It executes practice well, but goals, progression, story, or creator context are missing. |
| Build | No good tool exists, or an owned mode creates a materially better experience. |
| Defer | Evidence would require brittle, invasive, anti-cheat-sensitive, or unsafe access. |
2. Define the Pursuit-native promise
Name the people served, the progress they care about, and the reason the suite belongs together. The Pursuit is the shared community; the Experience Suite is the coherent toolset recommended inside it.
The ordinary member should not assemble implementation primitives. Joining a Pursuit can provision its reviewed default Suite, and every included mode should have one immutable package-owned preset that works immediately.
3. Shape the Practice Modes
For every mode, specify:
- the real-world exercise and terminal boundary;
- one primary result contract and any supporting Measurements;
- comparison direction, units, precision, and evidence policy;
- valid goal shapes: improve a metric, reach a target, or complete once;
- manual interaction and accessibility;
- accepted semantic observation protocols;
- correction policy and replay consequences;
- meaningful Story Events and presentation states.
Avoid one enormous configurable mode when practitioners understand the exercises as independent skills. Separate modes preserve honest history and make rankings intelligible.
4. Design source-neutral rules
portable player command ────┐
├── normalize → domain action → pure reducer
reviewed observation ───────┘Manual and automatic input should differ only before normalization. Equivalent fixtures must finish with the same package state, status, Measurements, Story Events, and presentation.
5. Design progression without inventing truth
Progression is a rebuildable projection over comparable Attempts. Fix the metric, aggregation window, evidence minimum, levels, ordering, and definition version. Never silently mix a changed metric, default, observation meaning, or threshold policy into an old lane.
6. Design the audience experience
The player helps the member act. The overlay helps someone else understand. Define goal, current state, stakes, meaningful change, next milestone, stale or disconnected evidence, and terminal outcome. Emit a small semantic story vocabulary rather than raw telemetry.
For Creator use, explain how Story Events align with a capture clock, how gaps are represented, and what an editor receives in the sealed evidence handoff.
7. Decide what belongs where
| Concern | Correct artifact |
|---|---|
| Pure rules, schemas, fixtures, reusable UI primitives | Domain Kit |
| Modes, engines, player, overlay, progression, story policy | Portable package |
| Native/local source discovery and translation | Station connector |
| Identity, authorization, persistence, clocks, routing, OBS, recovery | Chasing Mastery host |
8. Write the acceptance story first
Keep one representative end-to-end journey concrete: discover the Pursuit, receive its Suite, choose a mode, record a manual Attempt, record an equivalent automatic Attempt, see progression, use a Sprint, inspect the overlay, anchor a Story Event to media, and seal creator evidence. Add failure injection for duplicates, reconnect, unavailable consumers, revocation, and corrections.