§1 — Why this exists

Effort is currently a letter mapped to a weight — a doubling series consumed only for critical-path arithmetic. That gives it internal consistency and no external meaning: nothing ties a letter to anything observable, so two authors can size the same work four levels apart and no check will notice. Every downstream number built on it — remaining effort, critical path length, sprint capacity — inherits that ungroundedness.

A worker fleet changes what is possible, because dispatching work generates the missing measurement for free. Every completed run records when it started and when it finished, so effort can be stated in a unit that is checkable against reality and corrected by it.

The unit is neutral worker-hours: the expected wall-clock a capable worker takes. Deliberately not anchored to any model tier — a tier-anchored unit would put a routing claim into plan state, which repository policy forbids, and its meaning would drift silently as capability improves, rebasing every historical estimate. Improvement instead appears where it belongs, as a rising per-agent speed factor, leaving the size of the work unchanged.

§2 — The unit, and a nearly free migration

Read the existing weights as hours and they are already plausible: with a worker burst budgeted around twenty-five minutes, S is roughly two bursts, M four, XL sixteen. So the letters map to 1.0, 2.0, 4.0, 8.0 hours as legacy defaults and no plan needs re-estimating by hand.

Add plan-effort-hours as a float with quarter-hour granularity. Where both it and a legacy letter are present, the explicit hours win and the letter is reported as redundant. Where only a letter is present, the mapping supplies the value and the plan is listed as uncalibrated so it can be revisited once real data exists. Critical-path and remaining-effort arithmetic switch to hours, which finally makes their output a duration rather than a unitless score.

§3 — Two calibration loops, never one

This is the part that quietly breaks if built naively. Predicted-versus-actual mixes three error sources: the estimate was wrong, the worker was faster or slower than baseline, or the scope changed. Feeding actuals straight back into a plan's estimate bakes agent speed into the plan's size, and the number stops answering "how big is this work".

So the loops are separate and each feeds the other:

plan estimate   ←  actual_hours ÷ agent_speed_factor        (normalised, per plan)
agent speed     ←  aggregate of actual_hours ÷ predicted    (across many runs)

Scope change is the third source and must be excluded rather than absorbed: a run whose node scope was widened mid-flight is marked and withheld from both loops, because it measures neither the estimate nor the worker.

Cold start is a real circularity — with both unknown, neither is identifiable. Resolve it by convention: a newly configured agent begins at a speed factor of one, estimates are authored as normal, and the two co-calibrate as runs accumulate. Report the confidence in each figure alongside it, because an agent with three runs and an agent with eighty should not present the same number with the same authority.

§4 — Capabilities, and the competence horizon

Per agent configuration — the pairing of a concrete worker and an effort level — accumulate success rate, speed factor, and the distribution behind each rather than only the mean. A boss selecting a worker needs the tail as much as the average, because a node that fails at the ninetieth percentile costs a redispatch and a wasted worktree.

Condition success rate on task size. A scalar success rate is nearly useless for routing because every agent succeeds on trivial work. Success rate as a function of estimated hours is the useful object, and the size at which it crosses a configured threshold is that configuration's competence horizon. That number closes the dispatch problem with a measurement instead of a judgement: a boss compares the node's estimate, divided by the agent's speed factor, against the horizon, and splits when it exceeds it.

node 4.0h  ÷  speed 1.4  =  2.9h   vs  horizon 2.5h   →  SPLIT
node 1.5h  ÷  speed 0.9  =  1.7h   vs  horizon 2.5h   →  dispatch

The capabilities record is a derived cache, not an authored file. It is computed from the run ledgers every mounted project already commits, cached under reckon's config home, and rebuildable with a single command. Authoring it would store computable state, which is the very thing derived-gate-state exists to remove; a cache is an artifact and may be deleted at any time without loss.

Record lines-changed, but never rank on it. Changed-line counts come free from the scoped diff each run already reports, and are a weak covariate for duration — worth having as a feature. They must not become a tracked agent metric: ranking workers by lines produces a gradient toward verbose code, and the measure would corrupt the behaviour it claims to observe. Tests added and gate outcomes are the honest quality signals; lines are descriptive only, and the schema should make that non-negotiable rather than leaving it to discipline.

§5 — Surfacing

State the unit wherever effort appears, because an unlabelled number invites the reader to assume the old scale. Plan reads carry estimated hours, hours spent, and remaining hours derived from implementation fraction; the roadmap reports paths in hours; the SPA shows estimate against spend; sprint capacity becomes an hours total that can be compared against real availability. Skills state the unit in their effort guidance so an authoring agent produces hours rather than a letter.

§6 — Evidence gates

§7 — Constraints

No concrete model identifier or provider name enters plan state, the schema or this plan's prose. A capabilities record keys on an agent configuration whose identity is user data in a cache, never a constant in source.

The final gate can fail honestly. If hours-based prediction does not beat the letter weights on the available sample, that is a finding about sample size or about the unit, and it is recorded as a negative result. Do not tune the weights until the comparison passes — that would fit the measure to the conclusion and destroy the only external check this plan has.

§8 — Ranked completion-time sources

Reading the finish time from the worker's terminal event assumed the event carries one. This backend's stream does not: every event in it carries only a type, an item or a usage block, and a scan of a full stream for any timestamp-shaped key returns nothing. The token half of that fold works on real runs because usage is on the terminal event; the clock half falls back to promotion wall-clock every time, which leaves the original inflation in place — measured at +43% and +127% on the two runs that first exercised the new code.

The inflation is worse than noise because it is not random. It equals the interval between a worker finishing and the orchestrator reaching that worker's landing beat, so it grows with wave width and would bias exactly the runs dispatched in the widest waves. A speed factor fitted on these numbers learns the orchestrator's promotion latency and charges it to the worker.

The finish time is recoverable with no backend cooperation, because the last write to a run's event stream is its terminal event's wall-clock, and the run directory outlives promotion. So completion time resolves from three ranked sources rather than two — the event's own timestamp where a backend supplies one, else the stream's last-write time, else the wall-clock at promotion — each recorded under its own distinct source name so that a proxy can never be read as a measurement, and so a later reader can tell which figures are safe to calibrate on.

This also governs the backfill: the six inflated historical records must be repaired from whichever source their surviving stream supports, and records whose stream is gone stay marked as unusable for calibration rather than being silently averaged in.

§9 — Re-measure the prediction question once authored hours exist

Trigger: at least 10 plans carry an independently authored plan-effort-hours and have accumulated calibration-usable runs. Until then this section is deliberately not executable, and nothing here should be attempted.

The closing comparison returned an exact tie — 2.625391 worker-hours by both predictors over 64 usable records — because every plan in the sample resolved its hours through the legacy 1/2/4/8 fallback. Two identical predictors cannot separate. The tie therefore demonstrates that the migration is lossless and says nothing about whether authored hours predict better, which is the question the plan actually asked.

The measurement becomes possible once authoring produces hours rather than letters, which the updated guidance now asks for. Re-run the same comparison at that point, on the same reconstruct-at-base_sha method so predictions still carry no hindsight, and report the two errors and the sample size whichever way it falls. A second tie, or a loss, remains a legitimate answer: the point of the external check is that it can fail.

Do not anticipate the result by adjusting the letter weights in the meantime. They are a compatibility mapping, and tuning them toward the conclusion would destroy the only independent check this plan has.

/reckon-ship effort-calibration

/reckon-ship effort-calibration

/reckon-ship effort-calibration