Skip to content

Keeper Scheduling Architecture

Keeper scheduling is a proposal system, not an autonomous scheduler.

Boundaries

  • Keeper tasks remain owned by the canonical Keeper HTTP API.
  • The scheduler reads canonical task metadata supplied by Keeper.
  • Calendar data is read-only busy-window evidence.
  • Scheduler output is an artifact containing suggestions, conflicts, and workload calculations.
  • The scheduler does not patch tasks, create calendar events, reschedule meetings, or run background planning loops.
  • Any future write must be explicit, human-approved, and routed through an approval-gated executor outside the proposal module.

Inputs

  • Due dates and scheduled dates.
  • Priority and priority score.
  • Estimated effort.
  • Energy level, context, project, tags, and today focus.
  • Dependency and blocker relationships.
  • Availability windows.
  • Calendar busy windows.
  • Workday constraints supplied by the caller.

Outputs

  • Human-readable proposal summary.
  • Structured proposal_id artifact.
  • Suggested task time blocks.
  • Busy and free window evidence.
  • Workload totals and overload minutes.
  • Conflict artifacts.
  • Suggested reshuffling.
  • Focus-session recommendations.
  • Blocked and unscheduled task evidence.

Governance

Proposal artifacts include a mutation policy declaring that task and calendar mutation are false. This is a fail-closed boundary: downstream clients must not infer permission to write from a schedule proposal.

Lich integration, when added, should present approval choices only. It must not become a planner, calendar writer, or hidden execution loop.