How it runs

These are diagnostic, not a target. The emitter says so in its own output, and it is repeated here because it is the whole basis on which these numbers are publishable. A delivery measure that becomes a target stops being a good measure; any one of these numbers starting to drive behaviour is itself a finding to be raised, not a score to be improved.

They are derived from agent-authored artifacts with consistency linting, not measured from ground truth. The lifecycle states these metrics are computed over are written by the same automated sessions that do the work. Consistency linting makes contradictions machine-visible; it does not make the underlying claims true, and a state recorded by whoever did the work is not independent evidence that the work was done. Treat every figure here as the system's account of itself.

A count is not a claim. The methodology overview states that no productivity multiplier, output-per-agent figure or tier comparison gets published, because there is no baseline against which such a figure could be recomputed. That still holds, and this page is not an exception to it. What is published here is the raw count of our own activity — commits in a window, changes merged, bugs filed — each recomputable by anyone holding the same command, the same window and the same commit. None of it asserts that the work was faster, cheaper or better than any alternative, and no figure here should be read as making that assertion.

This is one repository, over one window, at one instant. It is not a fleet roll-up, not a benchmark, and not a comparison against anybody. Counts move while they are being taken — the corpus changes during the measurement — so every number on this page is stamped with the instant and the source commit it was taken at, and means nothing without them.

Each metric is in exactly one of three states. measured means the emitter computed it from a complete input. partial means it computed it from an input it itself declares incomplete — the caveat travels with the number. could-not-check means it could not compute it at all. A could-not-check metric is never shown as zero and never dropped from the table: a zero for a probe that did not run is a false claim, and a dropped row hides that this page's coverage is partial.

A trend view rolls the recorded lifecycle transitions up into a time series. Its state for this snapshot: loading…

loading…

Some inputs are list calls with a hard result cap. A count taken from a capped list call becomes a silent undercount the moment the cap binds — the call still reports success, and nothing downstream can tell the difference. The emitter's output does not state its own caps, so they are recorded explicitly when the snapshot is refreshed and published here alongside the numbers they bound.

• One repository only. The toolkit's own development repository. No other repository contributes a single number here, and nothing on this page should be read as a fleet-wide or organisation-wide figure.
• One window only — the dates stamped at the top. Nothing before the window start is counted; a longer or shorter window would produce different numbers, and no window here was chosen to flatter a result.
• Deployments are not production deployments. The throughput figure counts commits and merges in the repository, which is what the emitter can see. It is not a count of releases reaching users, and should not be read as one.
• Change failure is a partial signal. It is computed from bug-labelled issues against merged changes. It does not include failures that were never filed as a bug-labelled issue, so it is a floor rather than a rate.
• No code-level, register-level or bottleneck metrics. The toolkit emits those too; this page deliberately renders only the delivery snapshot and the trend, so that everything shown has one declared source.
• No per-person anything. These are system-level aggregates. Nothing here is attributed to an individual, and the toolkit's own framing forbids using any of it as an individual scorecard.

Every number above is derived from one declared source and nothing on this page is typed by hand. That source is published as metrics.assay.guide/metrics.json — the emitter's raw output, verbatim, plus the snapshot's commit, window and probe caps. This page carries no numbers of its own: it is a static shell that fetches that feed live and renders it in your browser, so a fresh snapshot appears without redeploying the site. If the live feed cannot be reached it falls back to the copy committed next to the page.

The snapshot is regenerated on a schedule by the toolkit's own emitter and uploaded to the feed; the site itself is not rebuilt to move the numbers. A check re-renders the page shell and requires it to be byte-identical to what is published — proving no number was hand-typed into the markup — and separately requires the published snapshot to be well-formed. This is the same stance the toolkit takes everywhere else: one writer, one source, and a script that can tell when the two have drifted.

The emitter's own framing, verbatim: loading…