Health · the three-minute layer
Is the pipeline working, and where is it stuck?
Pick your seat: the three questions this answers for you
Outcomes first: did shipped work solve the problem
Output and flow: what it took to produce
What deserves attention this week
Trends
Features merged per week details →
Throughput, with the human-only reference line for scale
Where the hours went, by stage details →
Median wall-clock share per cycle; the packaging spike is the measured 17-touch week ●
Decision turnaround details →
Days from question raised to answered; p90 and median. Named owners on the two-business-day clock started week 33; the weekly half hour catches only what stalls.
The autonomy curve details →
Interventions per run, falling as the loop earns trust; asked-first vs interrupted
Caught before merge vs escaped after details →
Findings by the verification chain against escapes found on main
The scoreboard: closing the gap list details →
The 113 go-to-market capabilities by state. The pilot's success is this chart moving right.
How this maps to what the industry measures
DORA's four keys
Lead time and deploy frequency are here (cycle time, merges per week) but read with care: industry data shows AI inflates both. The two that stay honest in an AI pipeline lead this page: change failure rate and recovery, plus decision turnaround as our own fifth key.
DX Core 4
Speed, effectiveness, quality, impact: the four page tabs map onto them almost one to one, with the operator page carrying the experience half. Nothing exotic; a reviewer can benchmark us against published norms.
Where we go past the standards
The autonomy curve, code durability against the industry's rising AI churn, and cost per merged feature that survives 90 days. These are the measures the standards do not have yet, and where this system differentiates.
Product & outcomes · the roadmap layer
What's moving, what's stuck, and what it bought us
60 of 321 customer asks addressed by 14 shipped capabilities against the 113-item gap list; the biggest blocker is one permission-model decision, open four days, holding three tickets.
The value stream at a glance
The pipeline, by stage
Where every capability sits details →
Decisions open, by owner
Every open question with one named owner; red is past the two-business-day clock
Aging work
In flight with no movement; the reclaim rule fires at ten business days
Outcomes: customer demand addressed
Support-inbox asks addressed by shipped work details →
321 asks across 19 themes; bars show asks whose capability shipped, per theme (top 8)
Cost against demand, per shipped feature details →
Each dot one feature: cost to ship vs asks addressed. Lower-right is the good corner.
Operators · the practice layer
My runs, my bottlenecks, my process
Five operators ran 25 cycles this quarter: 14 merged, 2 abandoned with reasons logged, 9 in flight. The shared process repo adopted 28 improvements from the people running it.
Touches per cycle
Touches per run; the line is you, dashed lines are the team range.
Where your cycles spend time vs the team
Median hours by stage, you (solid) against team median (hollow)
Process iteration: who is improving the loop itself
Retrace rows opened, and how many were adopted into the shared process
Review outcomes
First-pass approvals, fix rounds, and redesigns on your PRs
Cost · the finance layer
What the machine spends, what a feature costs, which way it trends
$987 of compute this quarter, $470 of it one deliberate twice-built experiment; the median shipped feature cost $52 of compute plus about $208 of priced human time.
Trends
Compute per week details →
The W30 spike is the twice-built experiment (both lanes); steady-state weeks are the honest trend
Where the compute goes details →
Spend by purpose, last 4 weeks
The comparison leadership will ask for
First shipped feature, measured ●, against a conventional estimate for the same scope
The data behind it · the collection spec
What we'd collect, from where, and what needs building
Of 30 measures: 9 are collectible today, 13 need a one-line hook in what the loop already writes, and 8 need a new source. Four of the eight are the GA outcome measures (revenue, retention, deflection, customer signal): they unlock once a product is in the market, and they become the primary arrow the moment they do. Everything else is wired at pilot start, not retrofitted.
Feasibility: the nine source systems and their pipes
Every measure above traces to one of nine sources. The rule stands everywhere: a measure renders only once its pipe is real; until then its tile says so instead of showing a guess.
| Source | What it provides | The pipe | State |
|---|---|---|---|
| GitHub | merges, reviews, first-pass rate, review time, fix/redesign labels | merge webhook plus a nightly API pull | ready |
| ClickUp | statuses and dwell, assigned-comment decisions, work weight | existing token, nightly pull job | ready |
| The loop's metrics files | stage times, touches, final states | already written per cycle; add three row types (touch, stage-left, final-state) | small addition |
| Gate-review reports | findings with severities | structured already; add a one-line summary row per finding | small addition |
| Cloud billing | compute by ticket, stage, experiment | usage visible today; needs session tags plus an export query | small addition |
| git history | churn, durability, survival at 2 weeks and 90 days | a scheduled survival pass per merged PR (small script) | small addition |
| Support-ask corpus | themes and the ask-to-capability mapping | the 321-ask export exists; needs a quarterly refresh and the mapping kept on tickets | small addition |
| Product telemetry | usage, journeys, and outcome signals at GA | does not exist in the new build yet; must be designed in from the start, PHI-masked | build |
| Finance constants | loaded rate, human-only baselines | recorded once per feature at intake | build |
What must actually be built, in order: the three metrics-file row types (hours of work), the nightly job that joins ClickUp and GitHub into the weekly snapshot (the Friday job already planned), the git survival pass, the Board snapshot job, and, the only large one, telemetry inside the product itself, which is what unlocks the four GA outcome measures.
The bleeding edge this adopts early
- The autonomy curve. Treat autonomy as a measured property of the deployment, not a claim: interventions per run, whether the agent stopped to ask before a person stepped in, and how long it runs between stops. Falling interventions with stable quality is the single best trend this system can show.
- Code durability. Industry analyses of AI-authored code show churn roughly doubling and duplication rising; the counter-metric is what fraction of shipped lines survive 2 weeks and 90 days. Our verification chain should make this a differentiator, and if it doesn't, we want to know first.
- Durability-qualified cost. Cost per merged feature only counts once the feature survives 90 days unreverted, so speed never gets credit for shipping rework.
- The verification tax, placed deliberately. Industry data shows AI moves effort into human review (review time up ~4x, more PRs merged unreviewed). This pipeline spends that tax on machine verification before a person is asked; falling human review time with a stable change failure rate is the proof it works.
- Outcome correlation, not output worship. Output counts widgets; outcomes ask whether the widget solved the problem. Pre-revenue, the early signals are refinement rounds at review, demand addressed, failures, and durability. At GA, the financial and customer measures take over as the primary arrow, and the drill pages exist so outcome tiers can be correlated back to the output patterns that produced them.
Sources this design leans on
- DORA / State of DevOps, 2025–26: the four keys, and the published caution that AI inflates deploy counts while MTTR and change failure rate stay honest.
- DX Core 4 (speed, effectiveness, quality, impact) as the unifying frame the tabs map onto.
- GitClear's 211M-line analyses, 2025–26: AI-era churn ~7%, duplication and error-masking up; the case for durability as a first-class metric.
- Anthropic, "Measuring AI agent autonomy in practice": interrupt rate, agent-initiated stops, turn duration, auto-approve rate.
- ICONIQ's R&D reporting guide and PE reporting practice: the 3-minute / 30-minute / deep-dive layering and pairing spend with shipped outcomes.
The collection principles
- Numbers come from systems, not memory. ClickUp status timestamps, git and PR history, CI runs, the cloud bill, and the loop's own metrics files. Nobody fills in a spreadsheet.
- One event log. Each cycle appends plain rows (stage entered, stage left, touch recorded, finding recorded, cost snapshot) to its metrics file; the dashboard is a pure function of those rows plus the ticket system. No second database.
- Measured and estimated never mix silently. Estimated values render with a distinct mark, everywhere, always.
- People-comparisons show context. Operator views always show the mix of work weight alongside speed, so a hard feature is never read as a slow operator.
- Map the whole stream; treat wait as the enemy. Value-stream discipline: every stage carries work time and wait time separately, every handoff carries percent-complete-and-accurate, and the end-to-end window (ask to shipped) is the honest lead time. It is also the language PE operating teams speak.
- Collect from day one. The expensive mistake is discovering in week six that week one was never recorded.