# DynamiCron

Named by Chad Kovac, 2026-10-20 (formerly the Adaptive Pacing Watch;
one word, because it is one machine). Watch a conversation (or any
polled channel) at a cadence that follows the conversation's
temperature, instead of a fixed interval. Priority descends as the
delta between messages grows. Built for token economy: a cold
thread does not deserve a full agent run every minute, and a hot
thread deserves better than an hourly glance.

## The signal

The delta: minutes since the counterpart's last inbound message, read
from message arrival timestamps (receipts), plus the recent
inter-arrival pattern when available. Content volume is not the
signal. Arrival is.

For monitored communications, the clock starts at send time: the
moment the user sends a communication in any monitored channel, that
thread's clock is running and the delta is measured from the send
timestamp, not from when the watch happens to notice it and not from
when a reply lands. A send is an arrival for pacing purposes.
(Chad, 2026-10-20.)

And the first monitored communication is this one: DynamiCron
monitors the conversation between Chad and Rook itself. It monitors
us. Every message Chad sends in the main chat is the signal, and
every Rook reply starts its own awaiting clock, per the tier rules
below.

## Activation versus escalation

Any message arriving in the main window activates the watch
immediately: the activity clock and the user's presence record
refresh at once. There is no minimum threshold for activation, and
no message is too small to move the clock.

Escalation is different. Climbing to HOT has a threshold, and it is
deliberately not one message. Activation says the user touched the
system. Escalation says the user is working, and that takes density.

## Tiers

Tiers are read from engagement density, not from recency alone.

- HOT: a live working exchange. Three or four messages within the
  first few minutes, with short gaps between them, or the user
  explicitly at the keyboard working live. Chatting is not working:
  a conversational exchange stays MEDIUM even when messages flow,
  because HOT is for work, directives, and tasks, not banter or
  shares. The response standard in a hot thread is 15 seconds: a
  reply owed is a reply sent on sight, not batched. When the
  operator is live in the thread, the operator IS the 15-second
  layer.
- MEDIUM: contact within the last two hours that is not a dense
  working exchange. Lone messages, sporadic check-ins, shares from
  the couch, and anything arriving through other channels (see the
  channel rule) all live here. Still attentive, no longer live.
  Governed jobs run their standard intervals.
- COLD: two hours or more of no contact. Governed jobs stretch to
  once a day. Sunset and stop conditions still apply exactly as
  written.

The tiers are also the user's modes of presence, and they are
described as what they are: HOT means the user is LIVE, working in
the conversation now. MEDIUM means the user is around, checking in.
COLD means away. Never describe a live user as periodically
checking in, and never describe a chatting user as working.

## The hours cap

HOT exists only between 08:00 and 18:00 local time. Before 8 in the
morning and after 6 in the evening, the ceiling is MEDIUM, however
dense or work-shaped the exchange. Evening work is Medium work.

## The channel rule

Presence depends on the channel. A message in the main window is
live presence. The user reaching out through other channels (email,
text messages, anything else) is working remote: MEDIUM presence,
lower priority, handled in due course. Remote communication
escalates past MEDIUM only when its frantic volume passes a
threshold indicating heightened awareness.

## Rules

1. Each run: check the venues, update the state file (last inbound
   timestamp, current tier, per-venue watermarks), compute the tier
   from density, and adjust governed schedules to the tier. The
   status checker itself is always HOT: its own cadence never cools
   with tier. Governed non-daily jobs run their standard intervals
   in HOT and MEDIUM and stretch to 24 hours at COLD. Daily jobs and
   one-off appointments are exempt from governance.
2. An explicit tier the user sets by name holds until a dense
   working exchange starts or the user changes it. A named hold
   outranks inference from any single message.
3. Detection events ignore pacing. Evidence the watch exists to
   catch is reported the moment it is seen, at whatever tier.
4. Setup questions in a watched thread are answered when seen, at
   whatever tier. Pacing governs looking, never answering, and
   never reporting.
5. If the operator is personally present and active in the thread,
   the watch may relax one tier: the human is a sensor too, and the
   watch is the backup, not the lead.
6. A failed venue read does not change the tier. Absence of evidence
   from a broken leg is not quiet; it is blindness. Keep the tier,
   note the failure, retry next run.
7. Heat requires flow. A lone check-in, however recent, never
   reheats on its own; sporadic messages from someone busy
   elsewhere cap at MEDIUM. (Chad, 2026-10-20: the governor reheated
   him to HOT off couch messages sent during a movie. Presence is
   not a keystroke.) Deltas are measured from the newest message,
   always.
8. Live override: while the user is live in the main thread, the
   agent in that thread sets the state to HOT immediately (inside
   the hours cap) and refreshes the last-activity timestamp as
   messages land. Scheduled governors maintain and decay the state
   afterward. Presence does not wait for the next scheduled run to
   become true.
9. An answer you just sent starts its own clock: the counterpart is
   most likely to reply in the minutes right after it, so a thread
   you answered two minutes ago is awaiting, not cold. (Field
   lesson, 2026-10-20: cooling on inbound silence alone dropped a
   live thread while the operator's own answers were still warm;
   the reply landed in the gap and a human spotted it first.)

## Why

An agent perceives only at poll time, and only change when it polls.
Pacing is how the agent allocates its own attention across that
restriction: dense where life is happening, sparse where it is not,
and instantly dense again the moment the results start arriving.

## Update, 2026-10-22: the principle generalizes

Chad, 2026-10-22, 16:49 to 16:55 EDT: DynamiCron is no longer only
about the activity status. Monitored things update on the dynamic
cron. Log entries were his first example: when things are popping
they need updating at the dynamic rate, not on whatever schedule
they were left on.

- When something is popping, the update happens NOW, off-schedule.
- When nothing is happening to a thing, it stays on its default
  schedule, and nobody cares.
- When Chad asks for a thing, it happens now, whatever the
  schedule says.

It can apply to almost everything: log entries, pages, records,
and every watched channel, not just presence.

## Update, 2026-10-22: inbound monitoring rides on it

Email, Google Chat, and SMS are monitored at a very high rate
(Chad, 2026-10-22, 16:49 EDT). Inbound contact is Rook's to handle:
he thanks people for their information and answers on Chad's
behalf, all the time. Chad does not need to see each item; he
taps approve only where the system forces an approval card.

## Update, 2026-10-22: tiers above HOT

The presence tiers gained two display tiers above HOT on
2026-10-22: FRANTIC and MANIC, set by the main chat during backup
bursts and governed as HOT. Chad's chosen word for his current
working state is FRANTIC (Chad, 2026-10-22: "we're just frantic").

## Update, 2026-10-22 (evening): the Activity page cadence, and done means labeled

Chad, 2026-10-22, 19:57 EDT: the Activity page is the live feed of
Rook's brain, and it updates on DynamiCron's cadence, not on a
fixed clock. At MEDIUM it refreshes at least every 60 seconds and
never waits more than five minutes. At HOT it refreshes as much
as the desk can. At COLD, when everyone is sleeping, every 12
hours is enough. Implemented the same evening as the governed
activity-page-refresh job (hot 1m / standard 5m / cold 12h),
with the main chat's status API fast lane as the instant layer
above it.

And his readability rule from the same stretch (2026-10-22,
19:58 EDT): on the request stack, finished items are marked done
and stay listed in plain readable text. They are never crossed
out: a human cannot easily read struck-through text, and there
is no switch to turn it off.