What problem it solves
A schedule isn’t a list — it’s a dependency graph wearing a list’s clothes. A flight landing late invalidates the morning block; a trip to another timezone quietly turns a “reasonable” 9pm call into 3am against sleep; a cancelled commitment frees three hours nothing will claim. Calendar tools store the nodes and ignore the edges, so every ripple effect becomes a human’s job to notice — usually too late. This segment makes the edges first-class: the system derives what an event implies, watches the implications, and surfaces the collision before it happens.
The thesis
Consequences should be data, not vigilance. If the logic “this condition being active implies these blocks shouldn’t exist” is written down as a structured statement, a deterministic engine can re-evaluate it every time anything changes — and a human only needs to see the conclusions. And because inference about someone’s life is fallible, the whole engine is propose-only: it drafts the ripple, I approve it.
Key features
- Conditions as a grammar. IF/THEN statements over the schedule are structured, typed objects — captured from plain language, shown back as exact-change cards, superseded cleanly when a newer statement replaces an older one.
- A deriver that keeps conditions honest. When an event changes, its derived conditions re-derive; the cascade engine re-runs consideration so downstream implications update instead of going stale.
- Implication execution, gated. An active condition can imply block removals or additions — every implication becomes a propose-only card with the reasoning attached, never a silent change.
- Timezone-aware conflict detection. Recurring commitments get checked against sleep in the condition’s own timezone — the class of failure where travel makes an old commitment quietly hostile is detected, not discovered at 3am. (Sleep windows live in the Health domain; this engine defends them.)
- Freed-time fills. When a condition frees a window, ranked fill proposals (drawn from priorities and overdue work across every life domain) arrive as one card; approving places blocks that each carry a plain-language “why this exists” receipt and a conditional release note.
- Deconflict guards and a lookahead sweep that drop passed windows, catch double-bookings, and keep the near future coherent.
How conditions drive the calendar
The month view is where this becomes visible. A multi-day condition — a trip, a recovery week, a field exercise — renders as a band across its days, and the band isn’t decoration: it’s a live logic object managing the time-blocks beneath it.
While the band is active, its implications hold: commute blocks drop, calls get judged against sleep in the condition’s timezone, protected blocks stay protected. When the condition changes or ends, the cascade re-evaluates — and any window it frees becomes input to the scheduler’s gap-filler, which proposes ranked uses with a reason attached to each. That’s the whole model of agentic time management here: conditions carry the rules, the cascade enforces them continuously, the gap-filler exploits what they free, and every consequence arrives as a card I can approve, correct, or dismiss.
Highlights
- The full chain — condition captured from plain language → derived → an upstream event changes → the cascade re-derives → a propose-only card lands with the implication spelled out — runs end-to-end today.
- The design choice that matters most is the quiet one: idempotence biased toward silence. A dismissed proposal stays dismissed; the engine never nags. Trust in a proactive system is spent in nag-units.
Development log
July 8, 2026
Page created. The conditions engine matured over the past two weeks from grammar (capture, exact-change cards, supersede) through derivation, cascade-on-change, implication proposals, timezone-vs-sleep conflict detection, and freed-window fill proposals — all live, all propose-only.