| Week | Observed SE | Action | Decision basis | Δ min | Window | Bedtime | Wake | Copy |
|---|---|---|---|---|---|---|---|---|
| {{ row.week_label }} | {{ row.observed_label }} | {{ row.action_label }} | {{ row.decision_basis }} | {{ formatFixed(row.change_minutes, 0) }} | {{ row.window_label }} | {{ row.bedtime }} | {{ wake_target }} |
| Priority | Action | Why now | Timing | Track | Copy |
|---|---|---|---|---|---|
| {{ row.priority }} | {{ row.action }} | {{ row.reason }} | {{ row.timing }} | {{ row.track }} | |
| No adjustment guidance available. | |||||
A sleep window is the planned block of time between bedtime and a fixed wake time, and sleep efficiency is the share of that block spent asleep. In cognitive behavioral therapy for insomnia (CBT-I), those two ideas are often used together to decide whether time in bed should stay the same, expand, or tighten after a run of better or worse weeks. This planner turns that review step into a week-by-week schedule built from your observed sleep efficiency values.
You start with a current window, a wake anchor, and a sequence of weekly percentages. The tool then builds a baseline row, converts each later week into an expand, hold, or compress decision, and shows the resulting bedtime for every stage of the plan. Instead of asking you to reason through the thresholds by hand, it gives you a visible trajectory, a table you can export, and a separate guidance view that explains what the pattern suggests.
This is most useful when you already have diary-based weekly sleep efficiency numbers and want a consistent rule set for follow-up planning. A clinician, coach, or self-tracker can use it to see whether one low week should trigger action, whether a two-week confirmation rule would reduce overreaction, or how a fixed 07:00 wake time changes bedtime as the window shifts.
The page is intentionally narrower than a full insomnia assessment. It does not diagnose insomnia, calculate sleep efficiency from raw diary entries, or evaluate other causes of poor sleep such as sleep apnea, shift work, medication effects, or mood symptoms. It reflects only the inputs you provide and the deterministic threshold logic defined in this package.
Because sleep restriction strategies can temporarily increase daytime sleepiness, treat this planner as a scheduling aid rather than a stand-alone treatment decision. If you have marked daytime drowsiness, a driving-safety concern, or another sleep or medical condition, use the output as material for clinician review instead of as automatic instructions.
The cleanest first pass is a plain one. Enter your current prescribed window, keep the wake time fixed, paste the weekly efficiency values in chronological order, and review the table before touching the advanced controls. That baseline run tells you whether the recent pattern is mostly stable, drifting toward expansion, or asking for repeated compression.
In practical use, the decision is rarely about one percentage alone. What matters is the pattern across weeks, the size of each adjustment step, and whether the bedtime that falls out of the calculation still looks realistic for everyday life. A mathematically tidy compression can still be a poor plan if it pushes bedtime too late or if repeated low-efficiency weeks are already paired with worsening alertness.
Confirmation weeks when your weekly percentages bounce around and you want fewer reactive changes from isolated outliers.Follow-up cadence changes how the guidance table is prioritized and timed, not the underlying expand/hold/compress math.The planner accepts a starting window in hours, a fixed wake time, and up to 26 valid weekly sleep efficiency values. The efficiency field is forgiving about separators, so line breaks, commas, spaces, and semicolons all work, but every value still has to parse as a percentage between 0 and 100. If the wake time is not a valid HH:MM clock value or any percentage token is invalid, the results panel does not render.
Week 0 is the starting prescription. After that, each weekly value is checked against the current low and high thresholds. A week at or above the high threshold adds to a high-efficiency streak, a week below the low threshold adds to a low-efficiency streak, and a week in between resets both streaks and becomes a hold. Once the relevant streak reaches the required confirmation count, the window expands or compresses by the chosen step size if the result stays inside the configured minimum and maximum bounds.
Every row carries the decision forward into clock time. The planner converts the current window into a bedtime by counting backward from the fixed wake time, so a six-hour window with a 07:00 wake anchor becomes a 01:00 bedtime, while a 6h 15m window with the same wake target becomes 00:45. That makes the weekly plan easier to judge as a real schedule instead of as a string of percentages.
The summary box is not just a recap of the last row. It counts how many expansions, holds, and compressions occurred, measures the net shift from the starting window, and labels the result with a confidence band. That confidence band is a package heuristic based on action volatility and total shift size, not a clinical certainty score, so it should be read as a signal about plan stability rather than as a statement about treatment success.
The weekly update logic can be summarized as a bounded streak-based rule set:
Here Δ is +step after a confirmed high-efficiency streak, -step after a confirmed low-efficiency streak, and 0 for a hold week. The streak counters reset when the efficiency falls into the hold zone or when a change is applied. Because the update is bounded, the planner can stop further expansion or compression even if the percentages would otherwise keep pushing in the same direction.
| Field or output | How the package uses it |
|---|---|
Start sleep window |
Initial prescribed time in bed and the Week 0 baseline. |
Fixed wake time |
Anchor used to convert every window into a bedtime. |
Weekly sleep efficiency values |
Observed percentages that drive streak counting and each weekly decision. |
Low threshold and High threshold |
Bound the hold zone and determine when low- or high-efficiency streaks begin. |
Confirmation weeks |
Number of consecutive weeks required before the planner changes the window. |
Adjustment step |
Size of each expansion or compression, in minutes. |
Adjustment Guidance |
Prioritized follow-up actions weighted by the observed pattern and the chosen cadence mode. |
Confidence band |
Heuristic label derived from volatility and total shift, not from external validation. |
The guidance table is a separate layer from the weekly plan. It ranks safety, progression, stability, and process reminders after the weekly rows are built. A cautious cadence adds weight to safety-oriented follow-up, while a fast cadence adds weight to progression checks, but neither setting changes the actual expand/hold/compress sequence.
All calculations, chart rendering, and exports run in the page. This tool bundle does not define a tool-specific upload path or server-side sleep calculation.
Weekly Adjustment Plan table from Week 0 forward. Look at the decision basis and bedtime together so you can see both the rule trigger and the practical schedule change.Adjustment Guidance after you understand the table. That view explains what the observed pattern implies for review timing and safety emphasis.If you compare several scenarios, keep the wake time and weekly efficiency list fixed and change only one rule at a time.
Start with the last row, then work backward. The final window and bedtime tell you where the planner lands, but the earlier rows explain why it got there. A stable final window after several actions means something different from the same final window reached after mostly hold weeks.
The most important distinction is between the plan itself and the package's commentary on the plan. The weekly rows are direct outputs of the threshold rules. The confidence band and guidance rows are interpretations built on top of that history. They are useful summaries, but they should not replace reading the sequence of observed efficiencies and actions.
Expand means the observed pattern has met the high-threshold rule and the next larger window still fits inside the configured maximum.Hold can mean either true stability inside the threshold band or a week that did not yet complete the required confirmation streak.Compress means the low-threshold rule was met and the smaller window still stayed above the minimum boundary.Use the package defaults: a 6.0-hour start window, a 07:00 wake time, thresholds of 85% and 90%, a 15-minute step, and weekly efficiencies of 82, 87, 91, 88, 84, and 90.
The planner compresses to 5h 45m in Week 1, holds in Week 2, expands back to 6h in Week 3, holds in Week 4, compresses again in Week 5, and expands again in Week 6. The final window returns to 6h with a 01:00 bedtime.
That sequence produces two expansions, two holds, two compressions, and a net shift of zero minutes, which is why the summary reads as a mixed but self-correcting pattern rather than a one-direction trend.
Keep the same start window and wake time, but set Confirmation weeks to 2 and enter 91, 92, 89, 84, and 83 as the weekly efficiencies.
Week 1 becomes a hold because the high streak is only 1 of 2. Week 2 then expands the window to 6h 15m. After an inside-band hold in Week 3, the planner waits through a 1 of 2 low streak in Week 4 and compresses back to 6h only when Week 5 confirms the second low week.
This is a good illustration of why the confirmation setting matters: the row history becomes less reactive, but it also delays both helpful expansions and corrective compressions.
Take any completed plan and switch Follow-up cadence from Standard to Fast or Cautious.
The weekly table, final bedtime, and chart stay the same, because the planner has not recalculated the expand/hold/compress logic. What changes is the ordering and timing language in Adjustment Guidance.
That separation is deliberate. It lets you change how aggressively you want the follow-up conversation framed without changing the underlying rule set that produced the plan.
No. You enter weekly sleep efficiency percentages directly. The package does not derive them from sleep diary timestamps or raw time-in-bed fields.
Week 0 is the starting prescription before any weekly efficiency value has triggered a change. It anchors the comparison for every later row.
The common causes are an invalid wake time or an efficiency token that is not a number between 0 and 100. The tool stops rendering until those inputs are valid again.
No. It only changes how the guidance table is prioritized and how soon certain review actions are suggested.
This bundle does not define a tool-specific server call. The planning logic, chart, JSON view, and file exports all run in the page.