Is what I did today enough for where I said I'd be?

01The problem

Trackers record what you did. None of them will tell you whether it was enough. A habit app can report a 40-day streak while the goal that streak was supposed to serve drifts out of reach, because nothing in it holds a target, a deadline and a rate at the same time.

The failure is worst exactly where it costs most. A CGPA, a savings target, a degree — these are slow and high-inertia, and by the time any tracker shows them as behind, they are often unrecoverable. Semesters do not rewind. The signal was visible months earlier, but it was visible in a place nobody looks: not in the goal that failed, in where the effort actually went instead.

The pattern is common enough to be unremarkable. A student goes deep on competitive programming for a semester and the CGPA slides. Someone training for a race stops putting anything aside for savings. A person takes on a demanding project and sleep is the thing that gives. In each case the trade was real, and it may well have been the right one — but nobody chose it deliberately, because nothing was measuring it. It was never hidden. It was just never counted.

02The claim

Status is a lagging indicator. Attention allocation is a leading one. Time is conserved: hours spent on one goal are unavailable to the others, so a persistent skew in the split mathematically guarantees that something starves. That is computable from the logs a tracker already collects, and it fires while the levers still work.

Two distributions over the same goal set — the share of capacity each goal requires, and the share of effort each goal received. The signed difference between them, in hours, is the whole feature.

The system never says which goal matters. It says: at this split, your CGPA lands here in June; at a different split, there. Show the consequence, offer the trade, let the person choose. The moment it holds an opinion about which goal deserves the hours, it becomes the guilt machine this exists not to be.

03Showing the arithmetic

The design rule is that every number on screen has its derivation reachable. Nothing is asserted that cannot be followed by hand. The strongest thing the system can say looks like this:

04How it works

Four layers, each an established formalism borrowed from a field that already solved its part. No novel mathematics is claimed.

L1

Estimation

Recovers the true rate from bursty, gap-ridden logs. Kalman local linear trend

L2

Status

Works in the time domain, so it does not break as a goal nears completion. Earned Schedule

L3

Feasibility

Conservation of time, against a ceiling measured from your own observed capacity. Σ Uᵢ ≤ C_safe

L4

Allocation

Which goal gives, and which is protected from starvation. lexicographic + MINMAX

A language model sits outside all four. It turns a vague sentence into a structured goal and puts engine output into plain words. It never authors a status and never produces a number that feeds back into one. That constraint is what makes the system testable: the whole engine runs, and the whole test suite passes, with every model call disabled. That is enforced in continuous integration, not promised in a document.

05What already exists

This is not a blank proposal. The model was specified, then hand-computed against twelve scenarios before any code was written, then implemented and measured.

That last row is the one I would defend first. A person works hard for 25 days and then stops completely. Accumulated progress is still exactly on plan, so every earned-value index reports no problem at all. The engine catches it because it watches the current rate, not the accumulated total — the same leading-versus-lagging idea as the attention claim, applied inside a single goal.

06Objectives

1. Formalise sufficiency. Define, for a typed goal and a log history, a status that two people computing by hand from the specification arrive at identically.
2. Detect misallocation early. Report the signed hours gap between required and realised effort per goal, and demonstrate it firing before the neglected goal degrades.
3. Keep the judgment deterministic. Guarantee by construction, and prove in CI, that no model output can reach the status computation.
4. Validate against known outcomes. Replay a real period whose result is already known and measure whether the misallocation signal would have arrived in time to matter.
5. Ship something usable. A finished local-first application — logging in three taps, the confidence band visible, endings designed rather than deleted.

07What this does not claim

Stating the limits is part of the argument, not a disclaimer attached to it.