Technology
Reinforcement learning
for cognitive scheduling
How ChronoZero models the day, estimates your changing state, and plans work and recovery as one system. Written for readers who want to know what is actually underneath the product.
A different question
Most planning tools answer one question well: what should go into this empty hour? A calendar shows free slots. A task manager sorts the list. A time-blocking app helps you assign the list to the slots. These are useful tools, and ChronoZero is happy to sit beside them. They solve a real layer of the problem.
ChronoZero works on a different layer. It asks: what kind of work is compatible with your estimated state right now, what will that choice cost later, and how should the rest of the day change as a result? Conventional planning organizes tasks in time. ChronoZero attempts to organize work and recovery around changing cognitive constraints.
That question cannot be answered with a static template, because the thing being planned around, your capacity for demanding work, moves. It moves with sleep, with the effort you already spent, with the order of what you did, and with how long you have been awake. Two identical free hours on the calendar can be completely different hours for the person living them. Time is a poor proxy for capacity, and every tool that plans purely in time inherits that limitation.
Taking the question seriously has consequences. You need a vocabulary for effort. You need a model of how effort and recovery interact over hours and days. You need a way to estimate a state you cannot observe directly. And you need a planner that can weigh what a choice now does to the remainder of the day. The rest of this page walks through how ChronoZero builds each of those pieces.
Power Zones: a small language for effort
Human days contain an almost unlimited variety of activities, but many of their consequences travel along a few shared dimensions: cognitive intensity, recovery value, distraction dynamics, and sleep. ChronoZero compresses activity into seven Power Zones, from peak focus down through steady and light work to recovery, distraction, and sleep.
This compression is what makes the whole system tractable. A demanding mathematics session and a demanding programming session differ in content while loading the person in similar ways. Because zones rather than tasks are the planning unit, knowledge transfers across activities, the simulation stays learnable, and the planner searches a space small enough to search well. A separate assignment layer maps the chosen zone back onto your concrete tasks, deadlines, and goals.
Two design decisions matter here. Recovery and sleep are first-class zones, because they change future capacity rather than merely producing zero output. And distraction has its own zone, recorded without penalty, because it carries its own dynamics and is evidence the model needs, not a failing to be punished.
DTSFSD: a simulated physiology of the working day
Underneath everything sits DTSFSD, our digital-twin simulation of cognitive physiology. It is a dynamical model of the latent quantities that shape a working day: sleep pressure that accumulates across waking hours, circadian rhythm, faster and slower forms of fatigue, attention residue from switching, motivation and reward dynamics, and the capacity that emerges from their interaction. One shared implementation of these dynamics drives training, evaluation, and the product runtime, so the model the planner learned from is the same model the app reasons with.
The twin is a structured prior, a scientifically informed starting hypothesis about how hidden state evolves between observations. It does not claim biological certainty about you. Its job is continuity: your internal state keeps evolving between the moments the app hears from you, and the simulation propagates a plausible picture across those gaps. Real observations then correct it.
Because people differ, DTSFSD is also a population. Training and evaluation sample many simulated persons with different fatigue profiles, recovery speeds, and sleep patterns, so the planner cannot succeed by memorizing one idealized human. Personal data then narrows the population prior toward the specific person using the app.
That population is not invented wholesale. The traits that govern how sleepiness degrades reaction speed and lapse rate are fitted from public human datasets of psychomotor-vigilance performance and Karolinska sleepiness ratings, so the spread of simulated people reflects measured human variation rather than parameters chosen to make the model behave. The evidence is thin in the way small open datasets always are: a handful of subjects, densely measured. We treat it accordingly.
Other traits have no dataset behind them at all. How resilient motivation is, how strongly distraction pulls, how quickly rest restores capacity: these are declared expert priors. Rather than blurring the difference, the population prior records for every single parameter where its value came from, how many subjects stand behind it, and a confidence weight. Roughly half the traits are marked as empirically supported; the rest are labeled as what they are, which is informed guesses. A model that cannot tell you which of its numbers are guesses is a model you should not trust with your afternoon.
Calibration shapes the simulated population. It is not a validation of ChronoZero in humans, and no claim on this page rests on one.
A day inside the twin
Illustrative normalized traces · one simulated day
Reconstruction: rebuilding the recent past
A state estimate is only as good as the behavior history feeding it, and nobody logs their day continuously. ChronoZero treats gaps as a designed-for case rather than a failure mode. When you return after hours away, a reconstruction pass rebuilds a plausible recent timeline, anchored by what it does know: your calendar, your sleep pattern, the last confirmed blocks, and your answers to a small number of questions that adapt to the situation and the length of the gap.
You confirm or correct the proposal, and the corrected timeline becomes the record the estimator runs on. Known anchors keep the reconstruction tied to points the system can actually rely on. The result is enough recent context to continue, bought with a few taps rather than a diary habit.
Estimated state, held as a belief
Even with a reconstructed timeline, your internal state cannot be read directly. ChronoZero therefore maintains a belief: a weighted population of candidate states propagated through the twin's dynamics along your recorded behavior. When an observation arrives, the belief updates. A quick vitality report reweights candidates toward states consistent with how you say you feel. An optional short reaction-time check, a PVT-style task, adds a small behavioral signal that helps calibrate your personal estimates over time. Neither input claims to measure cognition directly, and neither requires a wearable.
Holding a distribution rather than a single number is deliberate. It keeps the system honest about uncertainty, and it gives the planner richer input than a point estimate could.
Planning with a learned model and search
The planner is where the estimated state becomes a schedule. ChronoZero uses a MuZero-style agent: a network that learns its own internal model of how a day unfolds, paired with a search procedure that uses that model to evaluate alternatives before committing to one. The model running in the current alpha is called Brünig.
We name each shipped planner after a Swiss alpine pass, in ascending order of elevation. A pass is not a summit. It is the lowest crossing that still gets you over the ridge, which is the problem this planner actually solves: not the most work a day could theoretically hold, but the most workable way through the day you have. Brünig, at 1008 metres, is the gentlest crossing in the range, and the first one this system made.
Given a context of recent behavior and estimated state, the network proposes plausible next zones, imagines how the day may evolve under each, and estimates the long-run value of the resulting trajectories. Search expands the most promising branches: demanding work now followed by recovery, recovery first with focus later, a lighter block to preserve momentum. Each candidate future is judged on what it produces and on what it costs, including fatigue carried into the evening, pressure on tonight's sleep, and the realism of a person actually following it. A commitment layer then turns the search's rapidly shifting preferences into a stable, followable plan, so the schedule you see does not flicker with every small update.
This is the reason simulation matters so much. The cost of a choice at 10:00 may only surface at 21:00. A planner that cannot roll the day forward cannot see that cost coming, and a system that stops measuring at the end of the work block can look productive simply by ignoring the bill. ChronoZero evaluates its plans through the end-of-day recovery period on purpose.
One state, several futures
Search compares consequences before committing
Belief vector
- Performance capacity
- .73
- Sleep pressure
- .42
- Slow fatigue
- .28
- Attention residue
- .36
High near-term output · larger later cost
Strong output · contained physiological cost
Capacity preserved · useful work arrives later
The plan is also never final. New behavior, a vitality report, a finished or abandoned session, or an edited timeline reanchors the whole chain: reconstruction updates the record, the belief updates the state, and the planner replans the remainder of the day from reality rather than from the morning's assumptions.
The system closes the loop
Every lived block becomes evidence for the next plan
How the planner was trained
No dataset of perfectly scheduled human days exists, so the planner is trained in simulation. Agents live through large numbers of simulated days in the DTSFSD population, under varied sleep histories, calendar loads, and interruptions, and learn from the consequences of their choices as the simulated physiology plays them out. The training objective rewards sustainable output: meaningful work weighted by the capacity it was done with, balanced against recovery, sleep regularity, and the realism of the demanded schedule. We do not publish the exact reward composition.
Training a planner this way is an empirical discipline more than a single clever idea. Candidate models are evaluated along the full production path, from reconstructed timeline through belief, search, and committed plan, on matched scenarios with identical inputs. Checkpoints that look strong on aggregate scores are rejected when the underlying trajectories show worse sleep, hidden debt, or degraded adaptivity. Four candidate models trained after Brünig were rejected on exactly those grounds and none of them shipped. Recency does not decide what runs in the product.
One of those rejections cuts against the usual instinct, because the checkpoint came from the very same training run, later on. On most scenarios it was unremarkable. On the one where the simulated person had slept badly it produced about 50% more work, and paid about 60% more modeled physiological debt to get it. Across the set as a whole it came out behind.
More training had taught it to push a tired person harder. That is invisible in a loss curve and invisible in an average, and it is exactly the behavior this product must not have. The earlier checkpoint was frozen, and it is what runs in the alpha today.
Before a number is allowed to count
The easiest way to get a good benchmark result is to measure something that never happened. An intervention that silently failed to reach the model, a plan produced by a fallback path instead of the real planner, a trace that does not line up with the plan it claims to explain: each of these produces numbers that look fine and mean nothing. So every scenario has to clear thirteen infrastructure and causal-validity gates before its results are looked at, covering things like whether the model context was genuinely ready, whether the plan came from the production planner rather than a fallback, whether the plan trace aligns with the committed plan, and whether re-anchoring stayed inside its bounds. Any gate failing zeroes that scenario outright.
The gates only establish that a result is real. A second layer asks whether the plan is one we are willing to ship, through five behavioral contracts: safety, sleep commitment, routine quality, infrastructure, and scenario response, the last being whether the plan reacted the way that particular situation demanded. The two layers answer different questions, and a scenario can pass every gate while still failing a contract. Measuring something real is not the same as liking what you measured.
On the evaluation run for the planner now in the alpha, all ten scenarios cleared all thirteen gates, so every result below describes something that actually happened on the production path. On the contracts the picture is mixed, and the mix is the interesting part.
Safety, sleep commitment, routine quality and infrastructure held on all ten scenarios, and no scenario contained an unsafe run of high-intensity work. Where the plan met a fixed calendar commitment it honored every one, eight of eight forced blocks across the two calendar scenarios. All four adaptivity pairs passed, meaning the planner moved in the right direction when sleep, available capacity, recovery state, and calendar load were varied one at a time.
The exception is the tenth scenario, which failed scenario response: a plan-shape expectation about how a day should be rebuilt after a disruption, rather than a safety rule. Its safety and sleep contracts passed like all the others. Under our own rules one contract failure makes the whole run a failure, so the run was recorded as a failure.
The planner shipped anyway. That decision had to be argued against the raw trajectories rather than waved through, and the alternative was keeping a model with a considerably worse habit, which the next section shows. We describe it here because the reverse case is the one that should worry you: a system whose promotion is automatic whenever a number turns green will eventually ship something whose numbers are green for the wrong reason. Aggregate scores summarize. They do not decide.
Does the model's imagination match the simulator?
A planner that searches inside a learned model is only as good as that model's fidelity. If its imagined four-step rollouts drift away from the simulator, the search optimizes a fiction. So this is measured directly, on held-out data, against floors declared before the result is looked at: latent rollouts must stay within a small cosine distance of the true trajectory, decoded rewards must land within a fifth of the natural spread of real rewards, and the model must agree with the reference on the top action at least four times in five.
Brünig clears all three comfortably. Its reward error is roughly half the allowed ceiling, and top-action agreement sits above nine in ten. These floors exist because an earlier generation failed one of them: it had good latent and policy fidelity but squashed its decoded rewards toward zero, which is invisible in aggregate scores and fatal to search. That defect is what the current reward architecture was built to repair.
What Brünig changed
An earlier internal comparison model had a characteristic flaw: it was often too cautious. In ordinary simulated working days it drifted toward long stretches of light activity and rest, leaving real capacity unused. Safe, but a poor use of a good day.
Before showing the result, it helps to define the measuring stick. Every planned block has a Power Zone, which represents intended effort, and a simulated performance capacity, which represents how much useful work the state can support. Effective work combines the two across the trajectory. A demanding block undertaken at high modeled capacity contributes more than the same nominal block attempted while depleted. Recovery and sleep contribute no immediate work, but they can raise capacity in later blocks. The metric therefore asks whether the schedule places effort where it can plausibly count, not how many hours it labels as productive.
This is a simulator-derived evaluation metric—not literal hours, a disclosed reward formula, or measured human productivity.
Brünig rebalances that caution. In nine strictly matched scenario pairs, both models received the same reconstructed history and were run through the same backend. Brünig produced more effective work in all nine. The comparison model was used only internally and was never deployed. One additional pair was excluded because its reconstructed inputs did not match, which would have made the comparison unfair.
The average flatters that result. In a typical pair the improvement is around 70%, and the median across the nine is about that. The mean is roughly a doubling, pulled up by two ordinary mixed-worker days where the older model stopped working almost entirely. Reporting only the mean would sell a broad improvement that the data does not show. What the nine pairs support is a solid gain almost everywhere, and an enormous one exactly where the old model was failing outright.
What "stopped" means
First four planned hours · mixed knowledge-worker day · identical inputs
Nine pairs is a small sample. It is enough to show a direction and to rule out the specific failure we were chasing; it is not enough to pin down an effect size, and the figures below should be read as approximate.
More useful work from the same inputs
Nine matched production-path scenario pairs
Mean effective work
≈2×Effective work / observed block
≈2×The important part is what the extra work did not cost. Median modeled capacity at the end of the recovery period was essentially unchanged between the two models in the matched aggregate, a difference well inside the noise of a sample this size. The model found more meaningful work inside the day, while the simulated person ended the recovery period in a similar place.
Learning when capacity is actually available
Sleep is a useful test because a planner can fail in two opposite ways. It can ignore sleep and prescribe the same demanding day regardless of recovery. Or it can discover that sleep is safe and collapse into excessive, fragmented rest. During training, the agent first had to learn a coherent sleep architecture from the simulated consequences: a substantial, mostly monophasic overnight sleep bout rather than scattered sleep snacks. That is already a non-trivial learned behavior; it was not supplied as a finished daily schedule.
Once that structure emerged, the agent also stopped behaving as if sleep duration were irrelevant. We held the rest of a controlled input surface fixed and varied reported sleep from four to nine hours. All six levels produced distinct model contexts and distinct futures. Effective work rose monotonically from 10.31 to 19.01: more available capacity led to more useful effort, not merely more blocks marked "work." Calendar events remained hard constraints at every level.
The closer eight-hour versus five-hour comparison makes the scheduling change tangible. "Strenuous" means PZ3 or PZ4: focused or peak work that places a larger demand on the simulated state. In the first 16 planned blocks—the next four hours—the strenuous share fell from 75% to 31% after shorter sleep. The remainder is not "unproductive": it is steadier PZ2 work and recovery used to preserve capacity. Total effective work appropriately fell from 18.82 to 12.56. The model did less because the estimated person had less to safely give.
The plan changes with available capacity
Controlled sleep-duration response surface
First 16 planned blocks
Effective work: 18.82 after 8h · 12.56 after 5h
A clock-based baseline, made explicit
Comparing only with another learned model can hide whether either model beats a sensible ordinary rule. We therefore also use a transparent clock-based control: sleep from 23:00 to 07:00; light activity before work; peak-intensity work from 09:00 to 12:00; recovery from 12:00 to 13:00; strenuous work from 13:00 to 17:00; and light activity through the evening. It is a deliberately rigid approximation of a normal 9–5 day—not a claim that this is how every person works.
Both policies then live through the same simulated population and the same evaluation horizon. The fixed day produced mean effective work of 10.69. Brünig produced 13.52—2.83 additional capacity-weighted units, or about 26% more. Average sleep remained close: 7.73 hours per 24 hours for the model versus 7.95 for the fixed day. In other words, the gain did not come from simply deleting sleep. It came from placing effort and recovery in response to state, while the control repeated its clock rule even when capacity changed.
Fixed clock versus adaptive planning
Iteration-50 controlled training benchmark
Fixed 9–5 day
One clock rule for every simulated state.
- Rule
- 23–07 sleep · 09–17 work · 12–13 recovery
- Mean effective work
- 10.69
- Sleep / 24h
- 7.95h
Brünig
Effort and recovery change with estimated state.
- Rule
- Search state-dependent Power Zone futures
- Mean effective work
- 13.52
- Sleep / 24h
- 7.73h
What this evidence means, and what it does not
It means the training and evaluation pipeline can produce a planner that uses available capacity instead of hiding from it, respects calendar constraints, responds directionally to sleep, energy, and recent activity, and pays for its ambition without a measurable dent in modeled recovery, all under controlled conditions on the real production path.
It also has known costs. Brünig's extra output is not free: in the rested-focus case it spends a measurable amount of the evening above our configured sleep-pressure threshold, where the older model spent none. The exposure is small, the other modeled quantities stay far from their limits, and it clears under the recovery continuation. It is still real, and it is the direction a planner should be watched for. Brünig also switches between activities more often than the model it replaced. We do not yet have a clean way to separate useful switches from needless churn, because the current measure mixes recovery transitions and forced calendar interruptions together with genuine restlessness. Reducing evening work under high sleep pressure, and switching less without going back to under-working, is the explicit target for the next planner over the pass.
It does not mean the system is proven to make you more productive. The numbers are simulator-derived. Real people differ from simulated populations, follow plans imperfectly, and live days no benchmark anticipates. That is precisely why the product ships as an experimental alpha: recommendations carry their reasoning, every one of them can be overridden, corrected, or ignored, and your feedback is part of how the system is evaluated further.
Where this is going
We think there is a category here that existing tools were never trying to build: cognitive scheduling. Software that treats capacity as the scarce resource, plans work and recovery as one problem, carries uncertainty honestly, and keeps replanning as the day reveals itself. The calendar remains the record of commitments. ChronoZero wants to be the layer that decides what those commitments leave room for, and when.
The Power Zone plan answers what kind of work the next hour supports. The activity layer on top of it answers what, specifically, to do with that hour, ranking your concrete tasks and projects by deadline pressure, importance, difficulty fit, and available time. That separation creates room for a whole ecosystem. Studying platforms, learning apps, and university curriculums already know what needs to be practiced, read, or handed in; ChronoZero works on knowing when a person is in a state to do it well. As the recommendation engine matures, connecting the two becomes a natural step: a course could feed its units into the assignment layer, and the assignment layer could place them into the hours where they are most likely to succeed. A partner app would keep teaching exactly as it does today. What it gains is a shared language for effort, which Power Zones already provide.
The optional readiness check points at a second opportunity, and it is the one we are slowest about. Its first job stays personal: a short reaction-time signal that helps calibrate your own estimates. That is what it does today, and it is part of running the product for you.
The second possibility is different in kind. A reaction-time signal recorded alongside the model's own prediction, on a real day, is a rare thing to have, and pooled across many days it would show where these models hold up and where they drift. That is research rather than service, so permission is asked separately and plainly, off by default, and refusing it costs no part of the product. The web app's Readiness research setting can be withdrawn at any time. Only closed-month, contributor-thresholded aggregates are released: no individual row, account or session identifier, exact timestamp, or lookup table. The privacy notice sets out the boundary, including the part we cannot undo: once an aggregate has been made anonymous it can no longer be traced back to one person. Any improvement it produces gets claimed only after surviving the same evaluation as everything else on this page.
The system described on this page is running today, for real days, in a guarded alpha. If you would like to live with it and push on it, we would like that too.
Already approved? Sign in
All quantitative results on this page are from controlled simulator and production-path evaluation on matched scenarios. Effective work is a simulator-derived, capacity-weighted metric, not measured human productivity. The planning model is a custom MuZero-style reinforcement-learning architecture trained by us in simulation; it is not a large language model and does not use one. ChronoZero does not diagnose or measure any medical condition.