Reference — generated from the toolkit
Source of truth: toolkit/templates/pilot-charter.md. Edit it there; this page is regenerated on build.
Pilot charter — {pilot: StudyBuddy}
- Pilot: StudyBuddy — legacy → RAPID rebuild Squad: {per squad charter}
- Charter period: {start} → {end} Status: Draft until signed
What the pilot must prove
The pilot exists to prove the pattern, not just to ship a product. A good StudyBuddy delivered by heroics is a failed pilot. The transition it feeds is the CXsmart scale-up gate, which reads this table as its evidence thresholds.
| # | Measure | Baseline (legacy) | Target | Evidence |
|---|---|---|---|---|
| 1 | Lead time for change | {from DORA baseline} | {TBD — Leadership + Delivery} | Metrics platform |
| 2 | Deployment frequency | {from DORA baseline} | {TBD} | Metrics platform |
| 3 | Change-failure rate | {from DORA baseline} | {TBD} | Metrics platform |
| 4 | MTTR | {from DORA baseline} | {TBD} | Metrics platform |
| 5 | Defect escape rate | {from legacy defect data} | {TBD} | Defect taxonomy reports |
| 6 | Capital-deposit rate | n/a (legacy captured nothing) | 100% of loops deposit | Flow-state checklist |
| 7 | Token spend vs earmarked STOP savings | n/a | Within the earmarked budget | FinOps reconciliation |
Before/after measurement plan
The comparison is legacy-vs-RAPID against the DORA baseline — the before-photo taken during STOP. Rules that keep it honest:
- Baseline first. The legacy baseline for rows 1–4 is captured and signed before any rebuild work starts. No baseline, no pilot.
- Same keys, instrumented. The rebuild's CI/CD instruments the same four keys automatically from day one — the "after" is measured the same way as the "before", not reconstructed from memory.
- A defined window. The "after" measurement covers {N} weeks of the Flow-state ⇄ Production loop after first production release — long enough to include real fixes, not just the honeymoon.
- Full-cost accounting. Token spend, shared-specialist time and SME hours are counted in the RAPID column. The claim is "faster and cheaper, honestly costed" — not "faster if you ignore the inputs".
- Reported, not curated. The before/after delta is a standing view on the metrics platform, visible while the pilot runs — not a chart assembled at the end.
Friction log
The squad keeps a friction log from day one — it is an obligation of this charter, not a nice-to-have:
- Log everything that slowed the loop: a toolkit gap, an unclear standard, a guardrail false positive, a handoff delay, an agent failure mode.
- Triage weekly in Flow-state — every entry dispositioned: fixed, accepted (with reason), or escalated to the Toolkit Guild.
- It is gate evidence. The "named toolkit gaps" the CXsmart scale-up gate requires closed come from this log; an empty log at gate time is treated as an unkept log, not a frictionless pilot.
The log lives in the pilot repo alongside the code and is summarised into the operating-model retro.
Artefacts the pilot must produce or validate
The pilot's second deliverable is the toolkit itself, proven on real work:
- First stack playbook — produced in Tech selection (template); the reusable output future squads start from.
- PFD exemplar — the StudyBuddy PFD becomes the worked example the handbook points to.
- First squad charter — the StudyBuddy squad completes the template; it doubles as the worked example.
- Gate cards validated in anger — every pipeline gate run for real, with friction-log entries for any criterion that could not be checked in minutes.
- Operating-model retro — completed at pilot end (template); findings feed the scale-up gate.
Sign-off
| Role | Name | Date | Signature |
|---|---|---|---|
| Leadership (approves charter + targets) | … | … | … |
| Delivery (owns the measurement plan) | … | … | … |
| Product (owns StudyBuddy outcomes) | … | … | … |