Every morning it verifies that last night's data syncs actually ran, and how fresh every number the company sees really is — because in June our warehouse sync sat broken for 11 days and nobody noticed.
Quiet on green: a normal day sends no email at all. You hear from it only when something needs you — a failure, a warning, or a one-time “recovered” note when a problem clears. Monday's digest carries a one-line “data pipelines: 7/7 green.”
Found during this project's research: the warehouse sync had been failing since 27 June — 11 straight days — and every inventory dashboard silently showed stale numbers. Worse: when fixed, the warehouse turned out to have been incomplete, not just stale. This loop makes that class of silent failure impossible to repeat.
Wakes after the overnight syncs finish
Every table's load status, row counts, errors
Anything stale >26h or failed turns red
Red/amber → email with a diagnosis; green → silence
Pings the dead-man's switch on clean runs only
For implementers and the technically curious. The full build sheet — verified queries, thresholds, and build notes — lives on the specs page.
| System | Role in this loop |
|---|---|
| NetSuite warehousePostgres on our server | Our nightly read-only copy of NetSuite (ERP) data — items, stock, transactions — refreshed by the ETL sync every morning. The loop queries this copy, never NetSuite itself. |
| Company feedfeed.huxapps.com | Its publish ledger is one of the watched pipelines — the sentinel confirms today's cards actually landed. |
| GBrain timersknowledge-brain ingestion | Systemd timers that feed wiki edits into the company AI brain — checked weekly-deep, daily-shallow. |
| Hermesagent runtime on our server | The scheduler that wakes the loop up. Each loop is a cron job under a Hermes profile; the planned bizops profile will host the business digests (IT loops run under vpsops). |
| Healthcheckshealthchecks.huxapps.com | The dead-man's switch. The loop pings it only after a clean run — if the loop dies or errors, the ping stops and Healthchecks raises the alarm independently. This is how 'never silent' is enforced by machinery, not promises. |
| Email renderer + gwsrender_email.py | All digests pass through one shared renderer: Huxberry-branded HTML, tables for repeated rows, a coral 'needs your response' box when the loop has questions, and an arrow link on every record. Sent from the loops mailbox via the Google Workspace CLI. |
| Loop chassisloop_common.py | Shared plumbing every loop reuses instead of reinventing: state files, run-over-run diffing, Metabase drill-down link building, quiet-on-green notify logic. |
| Model / brain | What it does here |
|---|---|
| None at run timedeterministic script | A normal cycle is a plain Python script — no AI tokens are spent unless a diagnosis or judgment step is actually needed. AI wrote the script; the script does the rounds. |
| GPT-5.5 via Codexthe bulk-work model | Wrote and maintains the mechanical parts — SQL, diffing, digest assembly. Effectively free on our existing subscription, so routine cycles cost almost nothing. |
| Claude Opusthe judgment model | Reviews alert wording, thresholds, and anything a human will read and act on. Post-Fable, Opus owns everything that ships. |
A small JSON state file: last status per pipeline, plus the green-streak counter. That's what lets it say “day 6 of consecutive green” and send exactly one RECOVERED note.
Email via the shared renderer, only when attention is needed. The digest itself always prints to logs — the loop is never silent at the machine layer.
Read-only everywhere. The never-silent promise is enforced by Healthchecks: a dead or erroring sentinel stops pinging, and the alarm fires on its own.