Metrics platform (spec)
The build specification for the platform the metrics framework feeds: one build, many views — not eleven dashboards. Every measure is auto-fed from systems of record; nothing is hand-reported. Baselined during StudyBuddy so "velocity compounds" is measured against a real denominator, not asserted. The build itself is pending; this spec is what it must satisfy.
One build, many views
The same underlying data, filtered per audience. If two audiences see different numbers for the same question, the platform has failed.
| View | Audience | Answers |
|---|---|---|
| STOP progress & burn-down | Leadership, Delivery | Is the remediation backlog shrinking on schedule? What's blocked? |
| Savings vs AI spend | Leadership, Finance | Is the FinOps savings plan funding the token spend as promised? |
| Engineering / DORA | Squads, Delivery | The four keys vs the legacy baseline — the compounding-velocity evidence. |
| Quality | Test, Squads | Escaped-defect rate by root-cause category, mutation score, regression-pack growth, first-time gate pass rate. |
| Security & compliance | Security, Leadership | Gate pass rates, open findings by severity, waivers and risk acceptances approaching expiry. |
| AI cost & usage | AI, Squads | Token cost per shipped change, agent first-pass acceptance rate, rework rate on agent PRs. |
| Toolkit adoption | AI, Engineering | Which prompts/skills/playbooks are actually used; capital-deposit rate per loop (governance). |
| Commercial proof-points | Commercial | Client-safe evidence: release frequency, fix SLAs met, uptime — feeds the transparency pack. |
Data sources — no manual reporting
| Source | Provides |
|---|---|
| git | Commit/PR flow, provenance tags (human/agent/mixed), docs-updated-with-code compliance |
| CI/CD pipeline | DORA four keys (emitted by the pipeline itself), gate pass/fail, coverage and mutation scores, scan findings |
Registers (toolkit/registers/) | Remediation and security-debt burn-down, waivers, risk acceptances and expiries, signal dispositions |
| Agent telemetry | Token spend by project / phase / environment tag, first-pass acceptance, rework, capital deposits |
| Product telemetry | Adoption and funnel events per the product telemetry standard |
The rule: if a metric requires a human to fill in a spreadsheet, it is not on the platform. Either the source system emits it or the metric is redefined until one does. Manual reporting is the overhead RAPID removes, not a data source.
Baselined during StudyBuddy
The DORA legacy baseline is the denominator; StudyBuddy is instrumented from its first loop, so the velocity, quality and cost curves exist from day one. This ordering matters: a platform stood up after the first build has no before-picture, and the commercial case rests on the comparison.
Rules inherited from the framework
- Metrics inform, never rank individuals — every view aggregates at squad or product level. This is enforced in the platform's data model, not left to dashboard etiquette.
- Definitions live in the framework (metrics standard and
toolkit/metrics/); the platform computes them. One source of truth for what "lead time" means.
Whether this is assembled (warehouse + BI tool) or bought (an engineering-intelligence product) is a tech selection decision not yet made — recorded as an ADR when taken. This spec is deliberately tool-agnostic so the selection can be scored against it.
Standards referenced: DORA, SPACE, DX Core 4.