Autonomous, but blind
My automation system has self-improvement gates. When conditions are met, a gate fires and candidates worth reworking get added to a repackage list. That part ran fine without me.
The problem was what came after. A gate would fire, candidates would accumulate, and nothing happened. More precisely, something happened and nobody knew. The only way to see it was for me to open the dashboard myself.
In the commit message I called this state "autonomous but blind." It acts on its own, but none of that action is visible from the outside.
In your own automation, who finds out when an important state change happens, and through what path? If it only shows up when someone opens a dashboard, isn't that close to nobody knowing at all?
Why not just send alerts?
The easy answer is to send the gate status as a message on every run. But then the same state arrives again and again. Gates that already fired and candidates I already know about keep getting re-announced, and eventually I stop reading the alerts. An alert that has become noise is no better than a dashboard.
So the real question wasn't "should I alert?" but "what counts as new?"
What would you do: send the full current state every run, or only what changed since last time?
Alert on transitions only
I went with the second option. The script I added is simple:
- Read the current gate status.
- Compare it with a saved snapshot from the previous run.
- Send a Telegram message only for newly fired gates (○→●) and newly added repackage candidates.
- If nothing changed, send nothing.
It stays silent in steady state and speaks only at the moment of change. I didn't touch the firing logic at all. This change only adds observability.
Credentials follow the existing convention. If the alert token and chat ID aren't configured, it sends nothing and only writes to the log. That matches how the rest of my system behaves: do nothing until configured.
I wired the watcher into the shorts autopilot script with a single line. I also split the part that computes "what newly fired" from the part that reads and writes the snapshot. With the diff logic as a pure function that doesn't depend on files or the network, I could write tests for it separately. The change came to three files and 156 added lines.
Self-check
- Can you learn about decisions your automation makes on its own (firing, promoting, adding candidates) without opening a dashboard?
- Are your alerts based on "change since last time" rather than "current state"? Is the same content being sent over and over?
- When alert credentials are missing, does the system at least leave a log instead of failing silently?
The honest part
All I changed was making things visible. This does nothing to verify that the gates fire at the right moments, or that the accumulated repackage candidates are actually worth anything. Because it relies on snapshot comparison, I can't tell you from this record how it behaves on the first run if the previous state file is missing or corrupted. And getting an alert doesn't guarantee I'll act on it in time. I gave the system eyes, but who handles what those eyes see, and how, is still the next problem.