lisa-delivery-effectiveness

name	lisa-delivery-effectiveness
description	Measure whether the work the factory delivers was worth shipping — gate rejection, rework, escape, first-pass yield and cost per delivered item — so autonomy rate cannot stand alone as a success measure.
allowed-tools	["Read","Grep","Glob","Bash"]

Delivery Effectiveness

Autonomy rate answers how much ran without a human. It says nothing about whether any of it should have shipped, and on its own it rewards exactly the wrong thing: a factory that produces rejected work faster scores better.

The five measures

Each needs a stated numerator, denominator and window, or it is a number-shaped opinion.

Measure	Counts	Reads as
Gate rejection rate	Work the pipeline refused, over work submitted	How much effort is spent producing output the standards reject
Rework rate	Items reopened or returned after being declared complete, over items completed	How often "done" was not done
Escape rate	Defects reaching production, over items released	What the gates did not catch
First-pass yield	Items reaching terminal state with no rework, over items started	The one number that moves only when the whole line works
Cost per delivered item	Metered spend, over items reaching terminal state	What a unit of accepted output actually costs

First-pass yield is the summary measure worth watching, because every other failure shows up in it. The other four exist to tell you where it went.

Where the numbers come from

Prefer the systems of record over anything self-reported: the tracker for state transitions and reopenings, CI history for gate rejections, the release record for escapes, the billing or gateway boundary for spend. An agent's account of its own rework rate is the least reliable source available and the easiest one to reach for.

Say which source each measure came from. Two measures drawn from different systems with different definitions of "complete" cannot be compared, and that mismatch is invisible in the result.

Set targets that can only tighten

Targets are yours to declare — this says nothing about what a good rejection rate is, because that depends on the standards being enforced and the work being attempted. But declare them, disclose them, and let them move in one direction only. A target quietly loosened to match the current number is a redefinition dressed as an improvement.

Read it against autonomy, never instead of it

Report both, together, always. The pairing is the point:

• High autonomy, high first-pass yield — the thing everyone is aiming for.
• High autonomy, low first-pass yield — an unattended process producing work its own gates reject. Reporting autonomy alone would conceal exactly this, which is why the pairing is not optional.
• Low autonomy, high first-pass yield — humans are carrying the quality. Honest, and expensive.
• Low autonomy, low first-pass yield — the machinery is not the problem yet.

Output

## Delivery Effectiveness

**Window:** dates · **Autonomy rate over the same window:** %

| Measure | Value | Numerator / denominator | Source of record | Target | Trend |
|---|---|---|---|---|---|
| Gate rejection rate | | | | | |
| Rework rate | | | | | |
| Escape rate | | | | | |
| First-pass yield | | | | | |
| Cost per delivered item | | | | | |

**Reading:** which of the four autonomy/yield quadrants this window sits in
**Uncollected:** any measure not gathered, and why — never an estimate in its place
**Filed:** work items raised for measures outside target