The Improvements inbox

One inbox, one lifecycle for every improvement the Flywheel proposes — a prompt version, a model or routing change, an evaluator change — each with its offline result, live status and where it came from. Approve or reject with a reason; a refused one is archived with its evidence and never re-proposed.

Preview — not on the hosted service

The data flywheel and the learning loop run on the local stack only. They are off on the invite-only hosted gateway (the learning.enabled master switch), there is no hosted MCP endpoint, and whether learning improves a given agent is not yet demonstrated. See the evidence status.

Everything the Flywheel produces — whatever the lever, whatever the source — arrives in one place: the Improvements inbox (/improvements in the dashboard). A prompt version, a model or routing change, an evaluator change: they are all candidates, and they all reach you here, in one list, with one lifecycle.

There are not two inboxes — one for "from your evals" and one for "from your learning". That split would make you look in two places and would hide the fact that they are the same kind of thing: a proposed improvement waiting for your decision. Instead there is one list, and each row wears a provenance chip that tells you where it came from.

What each candidate shows

Every row carries the evidence you need to decide, kept honest and kept distinct:

A provenance chip — "from your corrections" or "from your eval set". The chip is derived from the candidate's own trigger evidence, never a label someone typed. A candidate proposed from the patterns in your corrections reads from your corrections; one proposed from your eval set reads from your eval set; a candidate whose source cannot be cleanly attributed says so rather than guessing.
The offline result — how the candidate did in offline screening, before any live traffic. Screening is a filter, not a verdict.
The live status — where the candidate sits in its live confirmation, if one has run. An offline screen and a live confirmation are different evidence and are shown separately; a screened candidate is never presented as confirmed.
A link to the evidence — the candidate's own run trace, so you can see the steps that produced it.
Timestamps, and, when the candidate's evidence has gone stale because the baseline changed underneath it, a plain note that it must be re-measured.

Why a candidate was refused: the deciding axis

A screen that refuses a candidate always says which axis decided it, so you can tell three very different outcomes apart at a glance:

"Helped, but over your cost budget." The module improved quality — the quality interval clears the bar — but it costs more than the budget you stated for this decision. Quality passed; cost is the deciding axis. This is a real result: the improvement is genuine, it just is not free.
"Did not help." Quality is the deciding axis — the module did not clear the quality bar (or regressed it). Whatever it did to cost is beside the point.
"Not enough evidence." The screen was inconclusive — there was not enough signal to say either way. The candidate is not refused on a specific axis; it simply needs more evidence.

Each refused candidate shows its quality interval and its cost interval, each labelled with the evidence tier it is (passed, failed, or inconclusive). These are the measured intervals from the screen — never a savings or a quality claim. The deciding axis, the intervals and the contract the screen was decided under are recorded on the candidate's own run trace, so the inbox and the API (GET /v1/flywheel/candidates) report exactly what the screen decided — nothing is recomputed after the fact.

The contract you screen under sets the bar. A product-improvement contract asks for a genuine quality gain within a stated cost budget; the same module that is refused on cost under a tight budget can screen under a more generous one. The deciding axis makes the difference legible instead of collapsing every refusal into a single, unexplained "did not qualify".

One lifecycle: approve or reject, with a reason

You act on a candidate in one place, with one action, and a required reason:

Approve adopts the candidate — but only when a live confirmation has actually recorded a superior result. If it has not, the inbox tells you why the press is not yet available (for example, not confirmed live yet or already adopted) rather than letting you adopt on a screening result alone.
Reject archives the candidate as "did not help".

Every decision is recorded as an audited receipt with your coded reason — it is never treated as a learning label. Every state you see is derived from the outcome ledger and the confirmation rows at read time; there is no writable "status" someone can flip out from under the evidence.

The "did not help" rule

When you reject a candidate, three things happen — and one thing deliberately does not:

It is stored with its evidence. The candidate, its run trace and your reason are kept whole. Nothing is deleted or hidden.
It stays visible on the knowledge surface. The archive on this screen links straight to the "tried and did not help" tab of your knowledge DB, which reads the very same refused candidates — the inbox links there rather than keeping a second copy.
It is excluded from re-proposal. The Flywheel's producer will not re-run a candidate you already refused; the refused version is fed into the same deduplication the producer already uses, so it is skipped before any model call.

What does not happen: the evidence is never destroyed to make the refusal "stick". Excluding a candidate from re-proposal and preserving its record are two different things, and the inbox does both.

Two goals, one surface

Cutting cost is table stakes, so the product pursues both goals for every call type — without you asking. For each call type with enough traffic it computes two reads at once:

Spend less here — where a cheaper model is enough, from the Router/Evals recommendation evidence (the same migrate/keep decision the recommendation engine produces).
Get better here — where quality can improve, from the Flywheel's candidates and learning plans (the same evidence this inbox already shows).

Each read is one of a small, closed set of states, and each carries its own evidence tier and a single next action:

evidence — a real result exists (a recommendation, or a screened/confirmed candidate): its source row, its tier, and, where the figure is a projection, an estimate label. A spend-less projection is an estimated monthly figure, clearly labelled and never shown as a realized saving; a screened candidate is shown as screened, never as confirmed.
collecting — not enough evidence yet, shown as n of the floor using the floor the owning engine already sets (the eval funnel's minimum golden-set size for spend-less; the Flywheel's benchmarkable minimum for get-better). No new threshold is invented here.
needs confirmation — the Flywheel proposed a learning plan; the next action is to confirm it.
keep incumbent — the Router/Evals evidence says your current model is the best trade-off. This is a result, shown as one, not a gap.
unavailable — there is no qualified evidence yet, with a named reason. Missing evidence is never presented as "fine".

Your improvement goal is reported alongside each get-better read. The default is improve quality (product_improvement); when you stated a different intent when you confirmed a plan, that intent is reported as-is and never overridden. A spend-less read is, by its nature, the cost-optimization decision.

This surface is a composition over the existing engines — it computes no new statistic and ranks nothing new; it only reads what the recommendation and Flywheel engines already decided. The same composition is available over the API (GET /v1/improvement-reads).

Two lenses, one surface

In the dashboard the inbox shows these reads as two lenses over the same /improvements page — a segmented control, not two separate pages:

Spend less here lists, per workflow, where a cheaper model is enough. Every figure here is an estimate drawn only from your recommendations — it is labelled Estimate — not yet realized and is never shown as, or added to, a realized saving on your ledger. The exact projected amount lives in the recommendation itself; the lens links you straight to it.
Get better here lists, per workflow, where quality can improve, with the Flywheel candidate's own evidence tier (screened offline, confirmed live, and so on). A screened candidate is shown as screened, never as confirmed.

Both lenses are shown for every workflow with traffic, without you asking, and neither is hidden by default. Which lens leads follows your reported goal: with the default improve quality, Get better here leads and the cheaper-model option is one tab away; if you stated a cost goal for a workflow, Spend less here leads. You can switch lenses with the mouse or the arrow keys.

An estimate is exactly that: a projection from your evaluation evidence, not a realized figure. It is always labelled, and the realized savings on your ledger are a separate, differently-styled number elsewhere — the two are never mixed.

A workflow can honestly show collecting in either lens. In Spend less here that means the evaluation set has not yet reached the eval funnel's minimum size, shown as n of the floor. In Get better here it means outcomes are still being gathered before a quality change can be proposed — and because no per-workflow resolved-outcome count exists yet, the lens says collecting evidence without inventing a number. Neither state claims an opportunity that is not there, and neither is presented as "nothing to do here".

Where this sits

The inbox is the only place a candidate is acted on. Your knowledge DB is read-only and links here; the Flywheel overview explains the loop that fills this list; and holdout and lift explains why a live confirmation — not a passed check or a merged change — is what "it worked" requires before you can adopt.