Outcomes
Whether governing the work changed anything — review delay, evidence preparation, uncovered work, exceptions and compliance at merge, each against a baseline period, every number opening its list, and never a 0 for something not measured.
Organization → Outcomes, over 30, 90 or 180 days, plus a card on each workspace's Compliance page under Coverage.
Coverage says how much of the work Madebook governs. Outcomes says whether governing it changed anything. Every number is shown against a baseline period, with the change.
What is measured
| Section | Measures |
|---|---|
| Review delay | Ready for review → first independent approval, and → merge (median and p90, per workspace and per repository). Merges with no independent approval at all. |
| Evidence preparation | Merged commit first seen → compliance first passing. How long decision gates stay open, and how many are still open. |
| Uncovered work | Merged but never evaluated; merged with no supervised session — Coverage's own categories, reused rather than re-derived. |
| Exceptions | Standard and emergency counts, time in force, emergencies reviewed late, and the share of merges that pass only because of an exception. |
| Compliance at merge | The share passed on the merged commit, failures at merge, and a weekly trend. |
"Independent" always excludes the author and every known commit author, whatever the repository's approval policy says — the measure is the wait for a second person.
The rules the page holds itself to
- Stored facts only. Nothing calls a host on read, so the same rows give the same numbers and the same lists.
- Not measured is never 0. A number whose facts do not exist says why. A change is drawn only when both sides were measured.
- Every number opens its list, from the same function — including each week of the trend and each breakdown cell. A duration's list shows the items counted and the ones in the period it could not count, with the reason, so "median over 1" never hides the 2 it could not see.
- Percentiles are nearest-rank, always a value that happened. With fewer than ten samples the p90 is the slowest one, and the page says so.
- Counts compare by rate per week, so a 90-day window compares fairly against a 4-week baseline. Durations and shares compare by value.
The timings, and how precisely they were seen
The host keeps a pull request's creation and merge times. It does not keep — in anything Madebook reads — when it left draft, when its current head was pushed, or when someone independent first approved it. Madebook records those as it sees them, each with a basis that says how precisely: a webhook is to the second, a sync is up to one interval late, and a pull request that was a draft before Madebook saw it is counted from creation, which overstates.
Pull requests mirrored before these timings existed are not backfilled; the page counts them as predates. One first seen already merged has its reviews unread as they happened, so ready → merge is measured and ready → approval is not.
The baseline
- Default: the first four weeks after the organization's first code-host repository was connected. While it is still running, its numbers are shown and nothing is compared.
- Explicit: an owner or admin sets whole UTC days — at least a week, at most a year, already ended. Setting and clearing are audited with the previous range.
- None: no code-host repository yet; every baseline number says so.
If the baseline overlaps the current window, the page warns that the change understates any difference.
Access and export
Viewers can read the report and its lists over the workspaces they reach; setting the baseline needs org.update. Export CSV gives one row per measure, then one per breakdown measure per workspace and repository — value, measured yes/no, samples, the reason, the baseline's, the change — with not-measured as an empty cell plus its reason. Cells that would run as a spreadsheet formula are quoted flat.