Ask most engineering dashboards how productive a team is and they answer in motion: commits a day, merges a day, pull requests a day. Our own public metrics page did exactly that. None of those three counts whether the work that shipped was any good — a fleet of agents can quadruple all three overnight and tell you nothing about whether a quarter of what merged came straight back through the review gates.
The ask that started this was blunt: give a group one number it can compare itself on over time, the way a credit score gives a household one. Do it for agentic delivery, where the unit of work is a brief carried by a fleet of worker agents rather than a person's day at a keyboard. The catch is that a single number is exactly the shape that invites gaming, and the industry's existing one-number answer hides the very thing that would let you check it. The rule that came out of this — a number nobody can rerun is a claim; a number anyone can rerun is a measurement — is the whole design, and everything below is what it costs to honor it.
one number, and no way to check it
By 2026 the field had stopped arguing about which productivity framework to adopt and started stacking them. DORA's delivery metrics — deployment frequency, lead time, change-failure rate — read a repeatable pipeline well (dora.dev). SPACE argues, correctly, that productivity does not reduce to a single metric at all (Forsgren et al., ACM Queue, 2021). DX Core 4 goes furthest toward the one-number ask: it rolls speed, effectiveness, quality, and impact into a single composite index (getdx.com).
That composite is the closest thing on offer to what we were asked for, and it is also the part you cannot check. Its weighting and aggregation are proprietary and largely survey-derived: you are handed the number, not the formula, and you cannot rerun it against your own raw data to see why it moved. A number you cannot reproduce is a claim about your productivity, not a measurement of it — and a claim is a poor thing to run a team by.
the construct: AssayScore
AssayScore keeps DX Core 4's four-dimension shape and drops the part that made it opaque. Each dimension is re-derived from something a brief-based agentic pipeline already emits on its own — no survey, no self-report — and normalized to a 0–100 sub-score:
| Dimension | Key metric | What it measures |
|---|---|---|
| Speed | brief lead time, authored → done (median) | how long a unit of work takes to clear the pipeline |
| Flow | flow efficiency (touch time ÷ touch + wait time) | how much of that time is real work versus sitting in a queue |
| Quality | first-pass yield | the share of briefs that ship with zero review-rework and no verify-fail |
| Value | weighted throughput ÷ human-decision-hours | delivered work per unit of the scarcest resource — a person's attention |
Two of the four are already bounded ratios: flow efficiency and first-pass yield are percentages, so they become sub-scores by multiplying by 100. The other two — lead time and throughput-per-decision-hour — have no natural ceiling, so each is normalized against the organization's own trailing-90-day reference band: the 10th and 90th percentiles of that metric's recent observations. A dimension with fewer than five observations in that window does not get normalized against noise; it reports could-not-check and drops out, which matters in a moment.
The composite is the geometric mean of the available sub-scores:
AssayScore = (Speed · Flow · Quality · Value) ^ (1/4)
the demonstration, run this session
The formula ships in the codebase as a dependency-free function with a golden-value test, so the construct can be exercised with no live data at all. Run against the test's fixture — Speed 62.5, Flow 75, Quality 90, Value 70 — the composite resolves like this:
(62.5 × 75 × 90 × 70) ^ (1/4) = 29,531,250 ^ 0.25 = 73.717…
That is the golden test passing on the reference implementation this session
(go test -run TestAssayScoreGoldenComplete → PASS, asserting
73.71747608146279). The number itself is a fixture, not a reading off
anyone's board. It exists to pin the one property that is the whole point: the
aggregation is a geometric mean, not an arithmetic one. The arithmetic mean of the same
four sub-scores is 74.375 — close enough to look interchangeable, different enough to
matter. That gap is where Goodhart's law gets answered. A geometric mean is a product,
so one low factor drags the whole score down no matter how high the other three run: you
cannot buy a good AssayScore by maximizing Speed while Quality collapses. The resistance
to gaming is built into the aggregation function, not bolted on as a rule someone has to
remember to enforce.
The missing-data case is pinned the same way. Drop Flow to could-not-check — thin data, say, before a pipeline has accumulated enough work-start events — and the composite is the geometric mean of the three that remain:
(62.5 × 90 × 70) ^ (1/3) = 393,750 ^ (1/3) = 73.295…
Not zero. The obvious wrong implementation coerces a missing dimension to 0, which zeros
the entire product and reports a catastrophe where there is only a gap in the data. The
golden test asserts 73.29486044391187 precisely to forbid that: a missing
input degrades the score to "computed over three dimensions," flagged incomplete, never
a confident, misleading zero. When every dimension is missing, the function refuses to
emit a score at all rather than render 0 — the geometric mean over nothing is undefined,
and saying so is more honest than printing it.
published with its parts
DX Core 4's problem was never that it uses surveys — surveys are a legitimate input. The problem is that the weighting and aggregation are sealed, so a reader cannot tell why the number moved. AssayScore is defined to never ship as a bare figure. The formula is public; the composite is emitted with its four sub-scores, the raw inputs behind each one, and, for any dimension that dropped out, an explicit incomplete flag naming what could not be checked. If the number looks wrong, its parts are printed beside it, and a wrong normalization shows up as visibly inconsistent with its own published inputs instead of hiding inside a sealed index. A construct that hides its parts is not offering itself to be checked.
prior art, and what we did not rebuild
The sweep is short and honest. DORA and SPACE were not replaced: their metrics are inputs, and SPACE's argument — that productivity is multi-dimensional — is one AssayScore accepts rather than refutes. DX Core 4's four-dimension shape was adopted wholesale; the novelty is not the shape. AssayScore changes exactly two things: it re-derives every input from pipeline artifacts instead of surveys, and it publishes the formula and the parts. If the objection is "this is just DX Core 4 with the lid off," that is precisely the claim — the lid was the problem.
the hedge
SPACE's core argument survives all of the above: productivity is not one number, and AssayScore does not pretend otherwise. It is a legible handle onto four real sub-scores and their raw inputs — useful because people reach for a single figure whether or not one is sufficient, not because delivery actually reduces to one. The framing we were handed said as much: the score is part vanity, and humans like a measuring contest. The transparency is what keeps the vanity honest — you can always drop to the four parts and the numbers behind them.
Two limits, stated as plainly as the powers. First, AssayScore is self-relative: it normalizes against an organization's own trailing 90 days, so it compares a team to its own recent self and nothing else. Cross-company benchmarking is not built, and we are not implying it exists by putting a number on a page. Second, it measures a delivery system, not a person. The unit is the brief and the aggregate is a team's flow over a quarter; pointed at individuals it would hand everyone a reason to game their own sub-score instead of doing the work the sub-score was meant to describe — the same Goodhart concern the geometric mean resists, this time in how the number is used rather than how it is computed.
how to break it
This is v0.1 of a construct, not a settled metric, and the useful response to it is an attack. Three that would land. One: the trailing-90-day band makes the score sensitive to its own window — a team that was chaotic last quarter has an easy band to beat this quarter, and whether that flatters or punishes a recovery is untested. Two: first-pass yield and flow efficiency are only as honest as the pipeline's own status transitions; a team that records a rework loop as a fresh brief would inflate both, and nothing in the formula catches that — it is upstream data integrity the score inherits rather than enforces. Three: the geometric mean's imbalance penalty is a design choice, not a theorem; a team could reasonably argue that for their work a low Flow score should not drag down a genuinely high Quality and Speed, and there is no proof the product is the right aggregation rather than a defensible one.
Each of those is a way the number could mislead, and each is checkable against the published parts — which is the only property being claimed. A productivity number nobody can rerun is a claim about a team. A productivity number anyone can rerun, and argue with on its own printed inputs, is at least a measurement you can fight about. We would rather ship the second kind and be told where it breaks.