Scheduling products are judged on a single invariant: the calendar equals the contract, always — and when it can't, a human is told. Everything else (drag-and-drop, colour coding, route maps) is furniture. This page explains how biloh enforces that invariant, what "loud" means in practice, and — honestly — which parts are enforced today versus being built to a published design.
What is the invariant, exactly?
For every combination of client site, service, and scheduling period: the live visits on the calendar equal what the active contract lines prescribe, minus explicitly recorded exceptions. Any write that would break this either passes through logic that classifies it, or produces a card a human sees. Nothing about the schedule is created, collapsed, dropped, or resurrected silently.
The operating principle behind it: real operators schedule first and do paperwork later, and a good engine doesn't forbid that — it notices and reconciles loudly. Silence is the only failure mode treated as unacceptable.
How does "loud" work in practice?
Three channels, all live today:
- Decision cards. When the platform hits a state only a human can resolve — a signed visit whose sold date has already passed, for example — it files a card on the operator's Decision Queue with the situation in plain language, the consequence of doing nothing, and concrete options (one marked recommended). The card is the record; it doesn't expire into silence.
- Registered events. Every loud moment also writes a machine-readable domain event (idempotent, so a standing condition signals once rather than nightly). Agents and audits query the same stream the cards are built from.
- The attention digest. Connected AI agents are instructed at connect-time to check an attention digest around their operations — decisions awaiting, staged sends, untriaged requests, stale amendment proposals, and recent loud schedule signals — and relay anything outstanding to the operator in a sentence or two. A dashboard card that never enters an agent's conversation effectively doesn't exist for an operator who runs their business through agents; the digest closes that gap. See The attention digest.
What does the engine refuse to do silently?
- Drop signed work. An accepted proposal containing a visit dated in the past raises a sold-visit decision card instead of quietly never scheduling it. (Signed work never disappears.)
- Double-fill a period. The nightly scheduler will not place a visit into a period that already holds a live committed visit for the same contract line — it records a loud skip instead. This is what makes a mid-amendment schedule safe: the old committed visit and the proposed new date can coexist as one live visit plus one pending proposal, never two bookings.
- Rebook committed work. Changing a recurring series proposes new dates to the contractor for visits they're already booked on; those visits hold their current dates, visibly badged, until the contractor confirms. (Change a recurring series safely.)
What's enforced today, and what's still being built?
Honesty matters more in an integrity story than anywhere else. Live today: the period guard, sold-visit decision cards, series change-control with contractor confirmation, the attention digest, and per-line uniqueness on live visit dates at the database level. Being built, to a published phased design: a persistent exception ledger (so a cancelled visit's "stay cancelled" intent survives every regeneration), a projection-based conflict gate at every contract-line creation door, and a nightly cross-tenant integrity sentinel that turns the four canonical bad states — duplicate lines, visits on dead lines, lines with no visits, signed lines never scheduled — into standing detectors. The design goal for the finished layer is simple to state: the system cannot silently disagree with what was sold.