CAC: an ad hoc alarm channel
18/10/2026
numerunique now runs a small team of Grok bots. One sorts the mail, one keeps an eye on security advisories, one simulates milling toolpaths, and the most important one, the Chief Executive Bot (ceb, hence the Ceb Alarm Channel), is the single interlocutor of numerunique's lead programmer.
The bots work every day; so does everyone at numerunique, who turns off as many notifications as he can.
So how does a bot raise the alarm when something is really urgent, without becoming a nuisance?
Email was the straightforward simple and obvious answer.
But it failed: the bot platform insists that every outgoing email be approved by the user first. An alarm that waits for your approval is not much of an alarm :-/
The answer came in the form of a tiny web intake, designed with the DIP strategy and the SIC tactic.
Data
A local file holding the times of the alarms accepted during the last hour. Nothing more. Period.
Interface
A single HTTP (HyperText Transfer Protocol) POST, behind a login. The body is the payload, capped of course: enough to trigger attention, while the details wait in the chat. Two possible answers: 200 "Sent" or 429 "Flooded", a limited number of alarms per hour. One is never cautious enough in matters of possible flooding.
Program
About twenty lines of PHP. flock() serialises concurrent requests. Obsolete times are dropped each time the file is rewritten. The payload is forwarded at once; queueing is the destination's business.
What is not there matters as much. There is no POST check, since the login is enough; no spool and no database:
Simple, Intelligible and Concise.
One last catch: the worst failures are the silent ones. If the relay breaks, the bot still gets its "Sent" and nobody knows. Hence a weekly heartbeat, every 7th Workday ;-)
Beware of the San Pablo syndrome: let the bots work, but keep your hand on the alarm bell.