The Driftwise method

This page describes the model behind Driftwise: what it assumes, what it computes, what it refuses to do, and where I think it is wrong. It is written for people who know this field. If you can find an error in it, I would like you to tell me.

Last updated: 14 July 2026 · Written by Kévin Darcel, who built the engine, not by a marketing team. Corrections to contact@driftwise.io.

1. The model in short

Driftwise schedules four things across a trip: light, sleep, melatonin and caffeine. It treats jet lag as a phase problem, not a fatigue problem, and it moves the clock with a phase-response-curve (PRC) approach.

Light is the dominant zeitgeber. Every shift the engine plans is, first, a light-timing decision. Everything else is support.
Melatonin acts on a roughly mirrored curve to light, and is scheduled as a low-dose adjunct with a timing recommendation only. It is never a dose prescription.
Caffeine is an alertness adjunct. The engine gives it a cutoff so it does not eat the sleep window. It is not modelled as a phase-shifting agent, because it is not one at the doses and timings people actually use.
Sleep is scheduled, but sleep is not the clock. The behavioural schedule can snap to local time in a day. The circadian phase cannot. The gap between those two is the jet lag, and it is what the plan is actually trying to close.

2. CBTmin, and the flip point

The whole plan pivots on one estimated quantity: the core body temperature minimum (CBTmin). Driftwise estimates it as habitual wake time minus about 3 hours.

CBTmin is used as the flip point between advancing and delaying:

Light after CBTmin advances the clock (it moves earlier).
Light before CBTmin delays it (it moves later).

The flip point. Light after CBTmin advances the clock. Light before it delays the clock. The curve crosses zero at CBTmin, so the same light, an hour either side of it, moves the clock in opposite directions. The response is largest close to CBTmin and close to nothing in the middle of the biological day. This is the curve the whole plan is scheduled against.

This is why the engine will tell an eastbound traveler to wear sunglasses in the first hour after landing, and then to go and stand in the light an hour later. It is the same light. The only thing that changed is which side of the estimated CBTmin it falls on. Getting that wrong does not merely waste a day: it moves the clock the wrong way. Section 8 says more about how much that estimate worries me.

As the plan progresses, the estimated CBTmin moves with the accumulated shift, and every subsequent light and melatonin window is recomputed against its new position. The worked example in section 7 shows it moving, day by day.

3. The constants, and the ceiling

These are the numbers. They are deliberately conservative, and I would rather defend them than beat them.

Quantity	Value	Why
Advance cap (eastward)	about 1.5 h per day	Advancing is the harder direction, because the intrinsic period runs slightly long. The engine never promises more.
Delay cap (westward)	about 2 h per day	Delaying works with the intrinsic period rather than against it, so it tolerates a larger daily step.
Pre-flight pace	about 1.0 h per day	Shifting at home costs real sleep in a normal working week. A gentler pre-trip ramp is more likely to be followed.
Post-arrival pace	about 1.5 h per day	After arrival the local zeitgebers pull in the same direction, so the plan can take a full step.
Livability floor	bedtime never more than about 2.5 h before habitual	A plan a person cannot follow is a plan that does not work. This clamp overrides the pace, and it does bind in practice.
Long way round	beyond about 10 zones east	Past roughly 10 zones eastward, the engine can resolve the trip as a delay instead, because a 14 h delay is cheaper than a 10 h advance. Westward it only flips past about 13 to 14 zones.

Advance cap (eastward): about 1.5 h per day; Advancing is the harder direction, because the intrinsic period runs slightly long. The engine never promises more.

Delay cap (westward): about 2 h per day; Delaying works with the intrinsic period rather than against it, so it tolerates a larger daily step.

Pre-flight pace: about 1.0 h per day; Shifting at home costs real sleep in a normal working week. A gentler pre-trip ramp is more likely to be followed.

Post-arrival pace: about 1.5 h per day; After arrival the local zeitgebers pull in the same direction, so the plan can take a full step.

Livability floor: bedtime never more than about 2.5 h before habitual; A plan a person cannot follow is a plan that does not work. This clamp overrides the pace, and it does bind in practice.

Long way round: beyond about 10 zones east; Past roughly 10 zones eastward, the engine can resolve the trip as a delay instead, because a 14 h delay is cheaper than a 10 h advance. Westward it only flips past about 13 to 14 zones.

Driftwise is not faster than the competition, and it does not claim to be. The ceiling is a property of the human circadian system, not of the software. Anyone advertising a materially faster shift is either measuring something other than phase, or is wrong.

Pace control

The user picks Gentle, Balanced or Fast. The ceiling is identical in all three. What changes is how hard the plan pushes inside it: how early the pre-trip ramp starts, how aggressively it uses the available light windows, how much slack it leaves around the sleep window. Fast is not a faster adaptation. It is a less forgiving one. We say so in the app.

4. What the engine treats as a trip

A trip is not a flight. Modelling it as one is the mistake that most tools in this category make, and it is the reason the plan stops at the airport.

Multi-modal. A trip chains flights, trains, buses, cars and ferries into one continuous adaptation, not one plan per flight. Ground legs matter: they change light exposure and they change sleep opportunity, which is all the model needs from them.
Round trip. The outbound and the return are one plan, not two. The state of the clock on the way home is the state the outbound left it in.
Multi-city. With several destinations, the target is the median of the city offsets, weighted by the nights spent in each. A single night in a transit city does not get to drag the whole plan.
Short trips. When the stay is shorter than the time it would take to adapt, the engine reduces the target rather than shifting the traveler out and straight back. A full shift over a two night stay costs more sleep than it saves. The reduction is asymmetric east and west, because the return costs are not symmetric.
Working hours. The user can declare the hours they must be awake and working, and the time zone those hours are anchored to. The plan then keeps sleep, naps and melatonin clear of them. This constrains the plan; it does not change the target.

5. Time zones

IANA time zone identifiers are the single source of truth. The engine never assumes a city, and it never infers a zone from a country or an airport name. Flight legs take their zones from the flight lookup; other legs resolve through the map layer, with a small bundled offline table as a floor.

If a time zone cannot be resolved, plan generation is blocked. It does not fall back to the traveler's home zone. A silent fallback would produce a plan that looks complete and is wrong by hours, which is worse than no plan.

This is also why the same route can be a different problem in different months. Paris to Tokyo is 8 hours in November and 7 in July, because Europe observes summer time and Japan does not. The engine reads the zones, so it gets that right without being told.

6. Melatonin, stated carefully

Driftwise schedules a low dose, at a time. It gives timing guidance only, and it does not prescribe a dose. Melatonin's status as a supplement or a medicine varies by country, and so does what a traveler can legally or sensibly buy. The app says this plainly, points at a clinician, and lets the user turn melatonin off entirely, in which case the plan is rebuilt from light and sleep alone.

7. A worked example: Paris to Tokyo, 8 hours east

This is a real plan for a real itinerary. It is here so that it can be attacked. If a window looks wrong to you, it probably is, and I want to know.

Assumptions

Traveler: habitual sleep 23:30–07:30. Estimated CBTmin at baseline: 04:30. No declared working hours. Melatonin enabled. Balanced pace.
Trip: Paris (Europe/Paris) to Tokyo (Asia/Tokyo), one way, mid November, so Paris is UTC+1 and Tokyo is UTC+9. An 8 hour eastward shift.
Flight: departs Paris 13:30, 12 hours in the air, lands Tokyo 09:30 the next morning.
Direction: 8 zones east is inside the roughly 10 zone limit, so the engine resolves this as a phase advance, not the long way round.
Clocks: all times up to and including the departure day are Paris local. From the arrival onward they are Tokyo local. The departure-day row gives both where it matters.

8 hours of shift, reached on day +5, the fourth day after arrival, with three days of preparation before departure. The dashed line is the unclamped 1.0 h per day pre-trip ramp: the livability floor holds Day -1 at 2.5 h rather than 3.0 h, which is the half hour note 2 describes. The line is flat across the flight, because the clock does not move in the air. The in-flight sleep buys the arrival, not the shift.

Day-by-day Driftwise plan for a Paris to Tokyo trip, an 8 hour eastward shift
Day	Sleep window	Seek bright light	Avoid light	Melatonin	Caffeine stop	Est. CBTmin
Baseline	23:30–07:30	none	none	none	none	04:30
Day -3	22:30–06:30	06:30–08:30	21:30 to bed	20:30	16:30	03:30
Day -2	21:30–05:30	05:30–07:30 ¹	20:30 to bed	19:30	15:30	02:30
Day -1	21:00–05:00 ²	05:00–07:00 ¹	20:00 to bed	19:00	15:00	02:00
Flight day	wake 05:00 on board 15:00–23:00 ³	05:00–07:00	20:00–02:00 ⁴	13:00 ⁵	09:00	02:00 Paris = 10:00 Tokyo
Day +1 lands 09:30	22:30–06:30 nap 14:00–14:30	10:00–13:00	09:30–10:00 ⁶	20:30	16:30	10:00
Day +2	23:00–07:00	08:30–11:30	07:00–08:30 ⁷	21:00	17:00	08:30
Day +3	23:15–07:15	07:15–10:15	none while awake	21:15	17:15	07:00
Day +4	23:30–07:30	07:30–10:30	none while awake	21:30	17:30	05:30
Day +5	23:30–07:30	normal daylight	none	none	normal	04:30 ⁸

Baseline (habitual)

Sleep: 23:30–07:30
Estimated CBTmin: 04:30

Day -3 (Paris time)

Sleep: 22:30–06:30
Seek bright light: 06:30–08:30
Avoid light: 21:30 to bed
Melatonin: 20:30
Caffeine stop: 16:30
Estimated CBTmin: 03:30

Day -2 (Paris time)

Sleep: 21:30–05:30
Seek bright light: 05:30–07:30 (note 1)
Avoid light: 20:30 to bed
Melatonin: 19:30
Caffeine stop: 15:30
Estimated CBTmin: 02:30

Day -1 (Paris time)

Sleep: 21:00–05:00 (note 2)
Seek bright light: 05:00–07:00 (note 1)
Avoid light: 20:00 to bed
Melatonin: 19:00
Caffeine stop: 15:00
Estimated CBTmin: 02:00

Flight day (Paris 13:30 to Tokyo 09:30)

Sleep: Wake 05:00 Paris. On board 15:00–23:00 Paris, which is 23:00–07:00 Tokyo (note 3)
Seek bright light: 05:00–07:00 Paris
Avoid light: 20:00–02:00 Paris, which is 04:00–10:00 Tokyo (note 4)
Melatonin: 13:00 Paris, which is 21:00 Tokyo (note 5)
Caffeine stop: 09:00 Paris
Estimated CBTmin: 02:00 Paris, which is 10:00 Tokyo

Day +1 (Tokyo time, lands 09:30)

Sleep: 22:30–06:30, plus an optional nap 14:00–14:30
Seek bright light: 10:00–13:00
Avoid light: 09:30–10:00 (note 6)
Melatonin: 20:30
Caffeine stop: 16:30
Estimated CBTmin: 10:00

Day +2 (Tokyo time)

Sleep: 23:00–07:00
Seek bright light: 08:30–11:30
Avoid light: 07:00–08:30 (note 7)
Melatonin: 21:00
Caffeine stop: 17:00
Estimated CBTmin: 08:30

Day +3 (Tokyo time)

Sleep: 23:15–07:15
Seek bright light: 07:15–10:15
Avoid light: none while awake
Melatonin: 21:15
Caffeine stop: 17:15
Estimated CBTmin: 07:00

Day +4 (Tokyo time)

Sleep: 23:30–07:30
Seek bright light: 07:30–10:30
Avoid light: none while awake
Melatonin: 21:30
Caffeine stop: 17:30
Estimated CBTmin: 05:30

Day +5 (Tokyo time)

Sleep: 23:30–07:30, aligned to local time
Seek bright light: normal daylight
Melatonin: none
Estimated CBTmin: 04:30, aligned (note 8)

This is the honest problem with the pre-trip days. Sunrise in Paris in November is after 08:00, so a 05:30 light window cannot be daylight. The plan asks for bright indoor light or a light box, and the engine credits the shift as if the traveler complied at an effective intensity. It has no way to know whether they did. See section 8.
The livability floor binds here. An unclamped 1.0 h per day ramp would have asked for a 20:30 bedtime on Day -1. The floor holds it at 21:00, which is 2.5 h before the habitual 23:30. So the plan reaches departure with 2.5 h of advance banked, not 3.0 h. The floor costs half an hour of shift and buys a plan the traveler will actually follow.
The in-flight sleep window is chosen in Tokyo time, not Paris time. 15:00–23:00 Paris is 23:00–07:00 Tokyo: a full Tokyo night, taken in the air. This is the single highest-value block in the plan, and it is why the traveler lands able to stay awake through the local day.
Only part of the avoid-light window is phase-critical. Estimated CBTmin on the flight night is 02:00 Paris, so light in the roughly six hours before it (20:00 Paris to 02:00 Paris, which is 04:00 to 10:00 Tokyo) would delay the clock, which is the wrong direction. The traveler is asleep for most of that. The part that matters in practice is the end of it: keep the mask on when the cabin wakes up for breakfast, and keep sunglasses on from the moment you leave the plane until 10:00 Tokyo.
Melatonin is placed about two hours before the target sleep window, which puts it in the advance region of the melatonin curve for this traveler's current phase. On the flight day that lands at 13:00 Paris, before boarding.
The first thirty minutes on the ground are a trap. The traveler lands at 09:30 Tokyo with an estimated CBTmin of 10:00. Bright Tokyo morning light in that half hour falls before CBTmin and would push the clock the wrong way. So: sunglasses on as you leave the plane, then light from 10:00. This is the clearest case of the flip point doing real work, and the clearest case of what an error in the CBTmin estimate would cost.
Same logic, one day later. The traveler wakes at 07:00 but CBTmin is at 08:30, so the first ninety minutes awake are still on the delaying side. Dim until 08:30, then bright light.
Total: 8 hours of shift, reached on the fourth day after arrival, with three days of preparation before departure. That is what an 8 hour advance costs. We do not claim faster.

The trap in note 6. The traveler lands at 09:30 with an estimated CBTmin at 10:00. For that first half hour, bright Tokyo morning light falls on the delaying side of the flip point (indigo) and would push the clock away from Tokyo. So: sunglasses on as you leave the plane, then bright light from 10:00 (amber). It is the same light, thirty minutes apart. This is what an error in the CBTmin estimate would cost.

What this table does not show

The prescribed sleep window snaps to local time faster than the estimated CBTmin does. On Day +2 the plan asks for sleep at 23:00 while the circadian estimate says the body would rather sleep at about 02:00. That gap is the jet lag. Light and melatonin are the only levers closing it; the sleep window is a behavioural anchor, not a shift in itself. The app also dims and prompts a wind-down before each sleep window, which is sleep hygiene rather than a phase move, so it does not appear in the avoid-light column.

8. Where I think this is weakest

I would rather hear it from you than find out from a bad review. Here is where the model is thin, in roughly the order that worries me.

The engine assumes a light dose. It does not measure one.

When the plan says "bright light from 10:00 to 13:00", it advances the clock in its internal state as though that light had been received at an effective intensity, for an effective duration. It has no idea what actually reached the retina. An overcast Tokyo morning, a window seat with the shade down, sunglasses the traveler forgot to take off, an office at 200 lux: the model scores all of these the same as three hours outdoors. Every other weakness on this list is downstream of this one. It is the single biggest gap between the model and reality, and I do not have an honest fix for it. Wearable lux data is the obvious candidate and, for an app that keeps everything on the device and has no account, the obvious problem.

CBTmin is estimated, not measured.

Habitual wake time minus three hours is a population rule of thumb standing in for the one quantity the entire phase logic pivots on. Individual variation is real, and it is not modelled. If a traveler's true CBTmin sits ninety minutes away from the estimate, the engine can place a light block on the wrong side of the flip point and push the clock in the wrong direction, confidently. The conservative caps and the livability floor bound the damage when that happens. They do not prevent it.

Everyone gets the same curve.

Inter-individual variation in the shape and amplitude of the phase-response curve is not modelled. Chronotype is collected and used lightly, but I have no defensible way to scale a person's actual responsiveness to light or to melatonin from anything I can reasonably ask them in a form. So one curve shape serves everybody. I know that is wrong. I do not know by how much, and I would like to.

The plan does not re-plan itself for a live delay.

It is built from the itinerary as entered. If the flight goes four hours late, the light and melatonin windows do not move on their own. The traveler can edit the leg and regenerate the plan, but that is the traveler noticing, not the app noticing. This one is engineering rather than science, and it is on the list.

Adherence is assumed.

The engine computes the plan as if it were followed. I have no measurement of what fraction of a plan a real traveler actually completes, and I suspect the honest number is well under half. A model that is right about a plan nobody follows is not right about anything. This is the reason the livability floor exists, and the reason the pre-flight ramp is gentler than it could be. I would rather be slower and followed than faster and ignored. Whether that trade is set correctly, I genuinely do not know.

Two known oddities I have not yet resolved

On some itineraries the engine can emit two melatonin recommendations on a single day, one in the morning and one in the evening, when the target phase moves across the day boundary. It is not harmful, but it is not right either, and it is queued for a chronobiology pass.
The melatonin timing rule (roughly two hours before the target sleep window) is a simplification. It approximates the advance region of the melatonin curve well for the phases most travelers are actually in, and less well at the extremes. If you think it should be anchored to the estimated DLMO instead, say so, and say where you would put it.

If you can see a sixth thing, or you think one of the above is the wrong thing to worry about, please write to me: contact@driftwise.io. I will read it, I will reply, and if you are right I will change the engine and say where the correction came from. I am not looking for an endorsement and I will not quote you as one.

9. What Driftwise does not claim

Driftwise is not a medical device. It does not diagnose, treat, cure or prevent anything.
It makes no efficacy claim. There is no clinical trial behind it, and this page is not evidence of one.
Individual results vary, for all the reasons in section 8.
Melatonin guidance is timing only, never a dose, and melatonin is regulated differently in different countries.
Consult a qualified clinician before changing your sleep, your light exposure, or any medication, including melatonin. The full medical disclaimer is here.

10. The concepts, if you want to check them

This section defines the terms this page uses. It is deliberately not a bibliography. I would rather describe a concept accurately than paste a citation I have not read carefully, and a fabricated reference on a page like this one would be unforgivable. If you want to know which specific result a given constant leans on, ask me and I will point you at it, one number at a time.

Zeitgeber. An external time cue that entrains the circadian clock. Light is by far the strongest in humans. Meals, exercise, and social schedules are weaker.
Phase response curve (PRC). A curve describing how the size and direction of a clock shift depend on the circadian time at which a stimulus is applied. The light PRC and the melatonin PRC run in roughly opposite directions, which is why the two are scheduled at nearly opposite times of the biological day.
CBTmin. The core body temperature minimum, near the end of the biological night, conventionally used as the reference point that separates the delay region of the light PRC from the advance region.
DLMO. Dim light melatonin onset, the rise of endogenous melatonin in the biological evening. It is the reference point most often used for melatonin timing, and it is measured, which is precisely the problem for an app.
Phase advance and phase delay. Moving the clock earlier and later respectively. Eastward travel requires an advance, which is the harder direction; westward requires a delay.
Intrinsic period. The free-running period of the human clock, slightly longer than 24 hours on average, which is the structural reason delays come more easily than advances.

11. Privacy, since it constrains the model

Everything above is computed on the device. There is no account and no tracking, and there are no third-party analytics. Trips sync only through the user's own private iCloud, never our servers, and we cannot read them. The one network call the app makes is an optional flight lookup, which sends a flight number and a date and nothing else.

This is a product decision with a scientific cost, and it belongs on this page rather than on a marketing one. It is the reason I have no adherence data, no light-exposure data, and no cohort to validate against. I chose that, and I would choose it again, but I am not going to pretend it is free.

12. Write to me

If you work on circadian rhythms and you think a number here is wrong, an assumption is unsafe, or a window is on the wrong side of the flip point, I would like to hear it, plainly and without hedging. contact@driftwise.io.

There is no form, no newsletter, and nothing to sign up for. Just an inbox.

Kévin Darcel
Driftwise · driftwise.io