On May 6, the L4 Calendar_Index prototype reported 14.92 wall-clock hours and 64.33 attention hours for the day. A 4.31x parallel ratio. That is the honest description of what happened.
The work log I had been keeping was chronological. Session opens, ticket gets touched, session closes, repeat. That shape assumes a single thread of attention moving forward in time. On May 6 it was not even close. I had sessions running on ITEM-6873 (cart wiring and checkout fixes), ITEM-6917 (a one-click Champion trial hotfix), and ITEM-6920 (Dev Home and PM Home cleanup). A Manus re-review pass came back the same morning with pushback on most of the archive architecture, which spawned HQ-23 through HQ-27. Somewhere in there I traced a network problem on this machine down to a half-disabled IPv6 stack. Four and five threads at a time. None of it sequential.
The chronological entry for that day would have been three lines of shipped tickets and a footnote about networking. True. Useless.
what a calendar index measures that a work log doesn’t
The L4 Calendar_Index prototype covers May 5 and May 6. I calibrated on May 5 because the numbers were saner and it was easier to trust the math before seeing anything absurd. The calculation is not complicated. Sum all session durations from the session manifests to get attention hours. Measure first session start to last session end to get wall-clock. Divide for the parallel ratio.
What that calculation tells you is not “I worked 64 hours.” It tells you 64 hours of work happened inside 14.92 hours of real time. For a solo operator with agents, that distinction matters. If you look at a 15-hour day and think “about normal,” you are missing the actual throughput. You are also missing the harder question underneath: whether you were in any position to verify what the agents produced.
the pieces that had to exist first
The prototype needed supporting work before it could output anything I would trust. Session manifests needed cleaner labeling so the index could tie a session to a ticket without guessing from filenames. Task-state filters had to exist so the timeline could show whether a ticket was active, blocked, or closed at a given hour. A JIRA history day view helped too. Without some way to reconstruct ticket state at a specific moment, the timeline labels were based on what I remembered, which is not a data source.
The forward-flow refresh skill landed in the same pass. Session state had been drifting between the manifest files and the actual git record, and a calendar index built on stale manifests is worse than no index at all. The numbers have to trace back to something real or they just replace one kind of fiction with another.
where the ratio breaks down
I do not have a clean answer for what a healthy parallel ratio looks like. 4.31x is interesting. It is not inherently good. More parallel sessions mean more output. They also mean more review surface, more places where a wrong assumption in one thread quietly contaminates a downstream thread, and a higher chance that some of those attention hours represent work that shipped without sufficient verification.
The ratio is only useful up to the point where you can validate what came out. Past that threshold, the parallel ratio starts lying too. Some fraction of those sessions may have produced output that never got checked. The wall-clock number and the parallel ratio are both downstream of the real metric, which is how much of what shipped was right.
That is the question I do not yet have good instrumentation for. Timeline reconstruction automates up to a point. Causality flattens when you compress it too much, and some of that compression happens at the moment the summary is written, not at the moment the work happened. I want a record that distinguishes “agent ran this” from “agent ran this and Ben reviewed the output.” The calendar index is the first layer. That distinction is the second.
Once you can run work in parallel, wall-clock stops being the interesting number, and the record of what happened becomes fiction unless you build the instrumentation for concurrency before the day you actually need it.