Technology
Reinforcement learning
for cognitive scheduling
How ChronoZero models a day, estimates your changing state, turns your calendars and notes into planning items, and plans work and recovery together. It's written for readers who want to know what's underneath the product.
A different question
Most planning tools answer one question well: what should go into this empty hour? A calendar shows the free slots, a task manager sorts the list, and a time-blocking app helps you put one into the other. They solve a real part of the problem, and ChronoZero is happy to sit next to them.
ChronoZero works on a different part. It asks what kind of work suits your estimated state right now, what that choice will cost later, and how the rest of the day should change as a result. Conventional planning arranges tasks in time. ChronoZero tries to arrange work and recovery around cognitive limits that keep changing.
A static template can't answer that, because the thing being planned around moves. Your capacity for demanding work shifts with sleep, with effort already spent, with the order you did things in, and with how long you've been awake. Two identical free hours on a calendar can be very different hours for the person living them. Time is a poor stand-in for capacity, and any tool that plans purely in time inherits that weakness.
Taking the question seriously has consequences. You need a vocabulary for effort and a model of how effort and recovery interact over hours and days. You need a way to estimate a state nobody can observe directly, and a planner that can weigh what a choice now does to the rest of the day. Because that planner only knows kinds of effort, you also need a layer that turns your actual commitments and tasks into something it can plan with. The rest of this page goes through each piece.
Power Zones: a small language for effort
People fill their days with an almost unlimited variety of activities, but the consequences mostly travel along a few shared dimensions: how demanding the work is, whether it restores you, how distraction behaves, and sleep. ChronoZero compresses all of it into seven Power Zones, from peak focus down to sleep.
That compression is what makes the system tractable. A hard mathematics session and a hard programming session differ in content but load a person in similar ways. With zones as the planning unit, what the model learns carries over between activities, the simulation stays learnable, and the planner searches a space small enough to search well. A separate assignment layer, described further down, maps a chosen zone back onto your concrete tasks and deadlines.
Two design decisions matter here. Recovery and sleep are full zones because they change future capacity, even though they produce nothing in the moment. Distraction also has its own zone and is recorded without penalty. It follows its own dynamics, and the model needs it as evidence.
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 hidden quantities that shape a working day. Sleep pressure builds across waking hours and interacts with the circadian rhythm, faster and slower forms of fatigue, the attention residue that switching leaves behind, and motivation and reward. Capacity emerges from how those interact. One shared implementation of these dynamics runs in training, in evaluation and in the product, so the model the planner learned from is the model the app reasons with.
The twin is a structured prior: a starting hypothesis, informed by research, about how hidden state evolves between observations. It makes no claim of biological certainty about you. Its job is continuity. Your state keeps changing between the moments the app hears from you, and the simulation carries a plausible picture across those gaps until real observations correct it.
People differ, so DTSFSD is also a population. Training and evaluation sample many simulated people with different fatigue profiles, recovery speeds and sleep patterns, which keeps the planner from succeeding by memorizing one idealized human. Personal data then narrows that population prior toward the person using the app.
The population isn't invented wholesale. The traits that govern how sleepiness slows reaction speed and raises the lapse rate are fitted to public human datasets of psychomotor-vigilance performance and Karolinska sleepiness ratings. The spread of simulated people therefore reflects measured human variation, and nobody picked those parameters to make the model behave. The evidence is thin in the way small open datasets always are, with a handful of subjects measured densely, and we treat it that way.
Other traits, like the resilience of motivation or the pull of distraction, have no dataset behind them at all. They are declared expert priors. For every parameter, the population prior records where its value came from, how many subjects stand behind it and a confidence weight. Roughly half the traits are marked as empirically supported, and the rest are labeled as informed guesses. If a model can't tell you which of its numbers are guesses, you shouldn't trust it with your afternoon.
Calibration shapes the simulated population. It does not validate ChronoZero in humans, and no claim on this page depends on such a validation.
A day inside the twin
Illustrative normalized traces · one simulated day
Reconstruction: rebuilding the recent past
An estimate is only as good as the behavior history behind it, and nobody logs their day continuously. ChronoZero treats gaps as a normal case. When you come back after hours away, a reconstruction pass rebuilds a plausible recent timeline around what it does know: your calendar, your usual sleep, the last confirmed blocks, and your answers to a few 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 estimate runs on. The known anchors keep the reconstruction tied to points the system can rely on. A few taps give the system enough recent context to continue, without anyone having to keep a diary.
Estimated state, held as a belief
Even with a complete timeline, your internal state can't be read off directly. ChronoZero keeps a belief instead: a weighted population of candidate states, each carried forward through the twin's dynamics along your recorded behavior. Observations update that belief without ever overwriting it.
The first observation is Vitality, a slider for how energetic you feel. Moving it shifts weight toward the candidate states that fit your answer.
The second is the readiness check, a short task modeled on the psychomotor vigilance test (PVT) that sleep researchers use to measure alertness. A circle on the screen lights up after a random wait of two to six seconds, and you tap as soon as you see it. After three practice taps, a normal check records sixteen responses in about 45 seconds; the onboarding check records thirty-two. The server scores the median reaction time, lapses (responses slower than 500 milliseconds), taps that come before the circle appears, and how much the responses vary. A slow result doesn't set a label like "tired." It raises the weight of the states and personal traits that would make a slow result likely. The app suggests a check about every four hours, and you can skip it.
Neither input claims to measure cognition directly, and neither needs a wearable. Keeping a distribution instead of a single number keeps the uncertainty visible, and it gives the planner more to work with than a point estimate would.
From connected sources to planning items
The planner needs to know what the day already contains and what still has to get done. That context comes from the tools people already use. Google Calendar and Google Tasks connect directly, as do Outlook Calendar and Microsoft To Do. The iOS app reads Apple Calendar and Reminders on your iPhone and syncs what you allow. ICS files and CalDAV calendars are other ways in, and so is ChronoZero's own Journal. Each connection keeps its own permissions, and you choose which calendars and lists it may read.
Every incoming item first becomes a provider-neutral record that points back to its source. A language model then fills in a closed form for it. The form holds a weight for each of the seven Power Zones, the kind of cognitive work, its difficulty, the expected duration, whether the work can be split, and what sort of deadline it has (hard, soft or only a target). The answer contains no free text. Each judgement has to cite the part of the source it came from, and the model may abstain when it can't tell.
Whether something can move gets stricter treatment, because moving the wrong thing is worse than moving nothing. The model may suggest that a block is flexible, but it can never declare an event fixed or shared with other people. Those classes come from the structure of the event. An event with attendees counts as coordinated with others and stays put. An event controlled by a third party stays fixed, and so does any event whose evidence is incomplete. Only a solo block with complete evidence can become movable, and tasks without a time are placed by the planner.
Items the classifier is unsure about wait for review before they enter the plan. You can accept a classification, pick a different zone, mark an item fixed or flexible, or lock your decision so a later reclassification can't undo it. A plan can suggest moving a block, but that suggestion is separate from changing a connected calendar, which ChronoZero only does after asking you.
Journals and Paths
The Journal is for writing about your work in your own words. A note is saved immediately, and the system never replies to it. Later, in the background, the note goes through the same classification as any other source. When it describes work still ahead of you, it can produce a draft Path.
A Path is a small dependency graph of work, and it can also start from a learning goal or a project brief. A language model proposes between two and twelve steps. Each step has a concrete next action, an outcome you could check, an effort estimate between 15 and 120 minutes, and the steps that have to come before it. Before you see the draft, the graph is checked for cycles and for prerequisites that point at nothing.
A draft adds nothing to your plan. You can rename steps, change durations and prerequisites, or throw the draft away. Accepting it turns the steps into planning items, and even then a step only becomes eligible once everything it depends on is marked complete. A timer running out doesn't count as completing a step, and neither does archiving it. If the note behind a draft changes or is deleted, the stale draft can no longer be accepted.
Planning with a learned model and search
The planner is where the estimated state turns into 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 compare alternatives before committing to one. The model in the current alpha is called Brünig.
Each planner we ship is named after a Swiss alpine pass, in ascending order of elevation. A pass is the lowest crossing that still gets you over the ridge, which matches what the planner is for: the most workable route through the day you have, instead of the most work a day could theoretically hold. Brünig, at 1008 metres, is the gentlest crossing in the range and the first one this system made.
Given recent behavior and the estimated state, the network proposes plausible next zones, imagines how the day could unfold under each, and estimates the long-run value of the resulting trajectories. Search then expands the most promising branches. One branch might put demanding work first and recovery after, while another starts with recovery and saves focus for later. Each candidate future is judged on what it produces and on what it costs: fatigue carried into the evening, pressure on tonight's sleep, and how likely a person is to follow it. Fixed calendar commitments are locked into the search, so no candidate can plan through them. A commitment layer turns the search's fast-moving preferences into a stable plan, which keeps the schedule you see from flickering with every small update.
This is why simulation matters so much. The cost of a choice at 10:00 may only show up at 21:00. A planner that can't roll the day forward won't see it coming, and a system that stops measuring when the work block ends can look productive simply by leaving that cost off the books. 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 never final. Whenever new evidence arrives, such as a Vitality report or a session that ended early, the whole chain re-anchors. Reconstruction updates the record, the belief updates the state, and the planner replans the rest of the day from the updated estimate.
The system closes the loop
Every lived block becomes evidence for the next plan
Placing the work
Brünig's output is a forecast of capacity: which Power Zones the coming hours can support, with fixed commitments already locked in. Turning that into a plan of concrete tasks takes two more layers.
The first decides how far ahead to look. There is no fixed horizon. The distance comes from the work in play, so a deadline tomorrow afternoon pulls the plan out to tomorrow afternoon, while a day without deadlines keeps a short one. This layer also checks feasibility. If the movable work can't fit before its deadlines, the plan says so and marks what should wait for a later day.
The second layer places movable work into the forecast with a constraint solver. It uses each task's full Power Zone distribution, so a task that suits focused work but could also be done as steady work has more than one acceptable home. The solver also accounts for deadlines, minimum chunk lengths, whether a task can be split, and the cost of switching between tasks. It solves the placement under several objectives, including one that protects deadlines and one that protects recovery, and records what each would gain.
Within a window, assignment chooses the task. It ranks eligible work by deadline pressure, importance, how well the difficulty fits the zone, and the time available. A hard deadline limits what's feasible, while a target date only adds urgency. When a daily budget or a short window cuts a task off, the plan shows only the portion that fits, and a partial block doesn't mark the task complete.
On the desktop, Insight explains the result by drawing your calendar and the rearranged one on the same time axis. A block the planner moved appears twice: faint and dashed where it sits now, and in full color where the forecast would put it, with a line between the two. Fixed commitments are drawn solid in both tracks, because they were planned around and never up for moving. The written explanation may only restate decisions the planner recorded, such as what moved, how far, and into what kind of window. When a generated explanation can't be checked against those records, the product shows fixed wording instead.
Language models have three narrow jobs in this chain: filling in the classification form, drafting Paths, and phrasing explanations. Planning itself, from the capacity forecast to the placement of tasks, uses no language model.
From a connected calendar to a rearranged afternoon
The path every source takes · illustrative items
- 01 · connectRead the sources you choosecalendars · task lists · Journal
- 02 · classifyFill a closed form per itemzone weights · duration · deadline type
- 03 · rigidityDecide what may moveattendees or missing evidence keep an event fixed
- 04 · placeFit tasks into the forecastcapacity forecast · constraint solver · assignment
- 05 · explainShow the trade-offyour calendar next to the rearranged one
Write draft · solo block, complete evidence, moved three hours earlier. Design review · has attendees, stays put.
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, with 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. That means meaningful work weighted by the capacity it was done with, balanced against recovery, regular sleep and how realistic the demanded schedule is. We don't publish the exact reward composition.
Training a planner this way is mostly empirical discipline. Candidate models are evaluated along the full production path, from the reconstructed timeline all the way to the committed plan, on matched scenarios with identical inputs. A checkpoint that looks strong on aggregate scores is rejected when its underlying trajectories show worse sleep, hidden debt or less adaptivity. Four candidate models trained after Brünig were rejected for exactly those reasons, and none of them shipped. Being newer doesn't decide what runs in the product.
One of those rejections goes against the usual instinct, because the checkpoint came from the same training run, only later. On most scenarios it was unremarkable. On the scenario 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 whole set it came out behind.
More training had taught it to push a tired person harder. A loss curve doesn't show that, an average doesn't either, and it is exactly the behavior this product must not have. The earlier checkpoint was frozen, and that 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 is one example. A plan produced by a fallback path instead of the real planner is another, and so is a trace that doesn't match the plan it claims to explain. Each of these produces numbers that look fine and mean nothing. So before anyone looks at a scenario's results, it has to clear thirteen infrastructure and causal-validity gates. They check, among other things, that the model context was ready, that the plan came from the production planner, that the plan trace matches the committed plan, and that re-anchoring stayed within its bounds. If any gate fails, that scenario scores zero.
The gates only establish that a result is real. A second layer asks whether it's a plan we're willing to ship, through five behavioral contracts: safety, sleep commitment, routine quality, infrastructure, and scenario response. The last one asks whether the plan reacted the way that particular situation called for. The two layers answer different questions, and a scenario can pass every gate while still failing a contract. A real measurement can still show something we don't like.
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. The contract results are 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. Wherever the plan met a fixed calendar commitment it honored it, eight of eight forced blocks across the two calendar scenarios. All four adaptivity pairs passed. When sleep, available capacity, recovery state and calendar load were varied one at a time, the planner moved in the right direction each time.
The exception is the tenth scenario, which failed scenario response. That contract encodes an expectation about how a day should be rebuilt after a disruption, and it is not a safety rule. The scenario's safety and sleep contracts passed like all the others. Under our own rules a single contract failure makes the whole run a failure, so the run was recorded as failed.
The planner shipped anyway. That decision had to be argued from the raw trajectories, and the alternative was keeping a model with a considerably worse habit, shown in the next section. We describe it because the reverse case is the one to worry about. If promotion happens automatically whenever a number turns green, sooner or later the system ships something whose numbers are green for the wrong reason. Aggregate scores summarize a run, and the decision stays with the people reading the trajectories.
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 is optimizing fiction. So fidelity is measured directly on held-out data, against floors declared before anyone looks at the result. 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 about half the allowed ceiling, and top-action agreement is above nine in ten. The floors exist because an earlier generation failed one of them. Its latent and policy fidelity were good, but it squashed decoded rewards toward zero, which aggregate scores hide and which breaks search. The current reward architecture was built to repair that defect.
What Brünig changed
An earlier internal comparison model had a characteristic flaw: it was often too cautious. On ordinary simulated working days it drifted into long stretches of light activity and rest, leaving real capacity unused. That was safe, and it made poor use of a good day.
The result needs a measuring stick first. Every planned block has a Power Zone, which is the intended effort, and a simulated performance capacity, which is how much useful work the state can support. Effective work combines the two across the trajectory. A demanding block at high modeled capacity counts for more than the same block attempted while depleted. Recovery and sleep add no immediate work, but they can raise capacity in later blocks. So the metric asks whether a schedule puts effort where it can plausibly count, and it ignores how many hours the schedule labels as productive.
This is an evaluation metric derived from the simulator. It is not literal hours, a disclosed reward formula, or measured human productivity.
Brünig corrects that caution. In nine strictly matched scenario pairs, both models received the same reconstructed history and ran through the same backend, and Brünig produced more effective work in all nine. The comparison model was only ever used internally and never deployed. One more pair was excluded because its reconstructed inputs didn't match, which would have made the comparison unfair.
The average overstates the result. In a typical pair the improvement is around 70%, and the median across the nine is about the same. The mean is roughly a doubling, pulled up by two ordinary mixed-worker days on which the older model stopped working almost entirely. Reporting only the mean would suggest a broad improvement the data doesn't show. The nine pairs support a solid gain almost everywhere and a very large 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's enough to show a direction and to rule out the specific failure we were chasing, but not to pin down an effect size, so read the figures below as approximate.
More useful work from the same inputs
Nine matched production-path scenario pairs
Mean effective work
≈2×Effective work per observed block
≈2×What matters most is what the extra work didn't cost. Median modeled capacity at the end of the recovery period was essentially the same for both models in the matched aggregate, with a difference well inside the noise of a sample this size. The model found more useful work inside the day, and the simulated person still ended the recovery period in a similar place.
Learning when capacity is available
Sleep is a useful test, because a planner can get it wrong 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 pattern from simulated consequences alone: one substantial, mostly unbroken overnight sleep instead of scattered short naps. Nobody handed it that as a finished daily schedule, which makes it a learned behavior worth noting.
Once that structure had emerged, the agent also stopped acting as if sleep duration didn't matter. 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, and the additional capacity went into useful effort, which is different from labeling more blocks as work. Calendar events stayed hard constraints at every level.
The eight-hour versus five-hour comparison makes the change concrete. "Strenuous" here means PZ3 or PZ4, focused or peak work that puts a larger demand on the simulated state. In the first 16 planned blocks, which cover the next four hours, the strenuous share fell from 75% to 31% after shorter sleep. The rest of those blocks went to steadier PZ2 work and to recovery that preserves capacity. Total effective work fell from 18.82 to 12.56. The model did less because the estimated person had less to give safely.
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 one learned model only with another can hide whether either beats a sensible ordinary rule. So we also use a transparent clock-based control. It sleeps from 23:00 to 07:00 and does light activity before work. It works at peak intensity from 09:00 to 12:00, recovers from 12:00 to 13:00, and does strenuous work from 13:00 to 17:00, followed by light activity through the evening. It is a deliberately rigid version of a normal nine-to-five day, and we don't claim everyone works like that.
Both policies then live through the same simulated population over the same evaluation horizon. The fixed day produced mean effective work of 10.69, and Brünig produced 13.52, which is 2.83 more capacity-weighted units or about 26%. Average sleep stayed close, at 7.73 hours per 24 hours for the model and 7.95 for the fixed day. The gain came from placing effort and recovery according to state with sleep nearly unchanged, while the control kept repeating its clock rule even when capacity changed.
Fixed clock versus adaptive planning
Iteration-50 controlled training benchmark
Fixed nine-to-five day
One clock rule for every simulated state.
- Rule
- sleep 23 to 07 · work 09 to 17 · recovery 12 to 13
- 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
The evidence shows that the training and evaluation pipeline can produce a planner that uses available capacity instead of hiding from it. That planner respects calendar constraints and responds in the right direction to sleep, energy and recent activity. It also delivered more work without a measurable dent in modeled recovery, under controlled conditions on the real production path.
The evidence also shows known costs. Brünig's extra output has a price: in the rested-focus case it spends a measurable part 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 during the recovery continuation. It is still real, and it's the direction a planner should be watched in. Brünig also switches between activities more often than the model it replaced. We don't yet have a clean way to separate useful switches from needless churn, because the current measure mixes recovery transitions and forced calendar interruptions with genuine restlessness. The explicit target for the next planner is less evening work under high sleep pressure and fewer switches, without slipping back into under-working.
It does not show that the system makes you more productive. The numbers come from simulation. Real people differ from simulated populations, follow plans imperfectly, and live days no benchmark anticipated. That is why the product ships as an experimental alpha, where every recommendation shows its reasoning and you can override it, and where your feedback is part of how the system gets evaluated further.
Where this is going
We think there is a category here that existing tools weren't trying to build: cognitive scheduling. It means software that treats capacity as the scarce resource, plans work and recovery as one problem, carries uncertainty honestly and keeps replanning as the day unfolds. The calendar stays the record of commitments. ChronoZero wants to be the layer that works out what those commitments leave room for, and when.
The pieces for that are now connected. The Power Zone plan says what kind of work the next hour supports, and the placement and assignment layers turn it into specific tasks from your own calendars, task lists and Paths. The same separation leaves room for other products to plug in. Study platforms and university courses already know what has to be practiced or handed in, while ChronoZero works on knowing when a person is in a state to do it well. A course could one day feed its units into the assignment layer, which would place them into the hours where they are most likely to go well. The partner app would keep teaching exactly as it does now and gain a shared language for effort, which Power Zones already provide.
The optional readiness check points to a second possibility, and it's the one we're moving slowest on. Its first job stays personal: a short reaction-time signal that helps calibrate your own estimates. That's what it does today, as part of running the product for you.
The second possibility is different in kind. A reaction-time signal recorded next to the model's own prediction, on a real day, is rare data. Pooled across many days, it would show where models like this hold up and where they drift. That is research and not a service, so permission is asked for separately and plainly, it's off by default, and declining costs you no part of the product. You can withdraw it at any time with the web app's Readiness research setting. Only closed-month aggregates with a minimum number of contributors are released, with no individual rows, account or session identifiers, exact timestamps or lookup tables. The privacy notice sets out the boundary, including the part we can't undo: once an aggregate has been made anonymous, it can't be traced back to one person. Any improvement it leads to will only be claimed after it survives the same evaluation as everything else on this page.
The system on this page is running today, on real days, in a guarded alpha. If you'd like to live with it and push on it, we'd like that too.
Already approved? Sign in
All quantitative results on this page come from controlled simulator and production-path evaluation on matched scenarios. Effective work is a capacity-weighted metric derived from the simulator, not measured human productivity. The planning model is a custom MuZero-style reinforcement-learning architecture that we trained in simulation, and it is not a large language model. Separate language-model services fill in the classification form for connected items, draft Paths and phrase explanations. ChronoZero does not diagnose or measure any medical condition.