How we built Standing Watch

The incident: a fix that was real on one machine and silently absent on the other for 12+ days

Our AI estate runs across two machines — a MacBook and a Mac Mini — talking to five different backends. Security-watch exists because of a specific, real failure mode we hit before it existed: an authentication fix was applied and verified on one machine, and quietly never made it to the second. Nobody was lying about the state of the system; nobody was even looking at the second machine specifically. It just drifted, unauthenticated, for more than 12 days before anything caught it — because nothing was checking both machines identically on a schedule.

That's the exact class of gap security-watch is built to catch: the same behavioral probe — make the real unauthenticated call, read the real HTTP status, don't trust a config file or a dashboard — run identically against every machine in scope, on a schedule, not just against whichever one someone happens to be looking at. The Aug 10, 2026 run in the demo below is a live instance of that same pattern: the JARVIS gateway's authentication was found open again, on schedule, and fixed and re-verified the same day — because the check runs everywhere, every time, not because anyone remembered to look.

Every automation here only proposes. None of them apply their own fixes.

Router-watch and security-watch both produce a dated report and stop. Nothing in either pipeline has write access to the router registry, the SSH config, or the firewall rules it reports on. Every finding is a proposal a human reads and applies by hand — the router-watch report's own footer says it plainly:

This report is a PROPOSAL. No file was modified by this job.
To adopt a swap, hand-edit the router config, run the test suite,
and restart the gateway.

Security-watch works the same way: on the Aug 10 run, 8 of 10 flagged findings were fixed — but each fix was a person reading the finding, applying the change by hand, and then running the same probe again to confirm it actually closed. The automation's only two states are "here's what I found" and "here's what I re-verified after you fixed it" — never "here's what I changed for you."

POOL_WEIGHT: pricing budgets that aren't the same currency

Our router spans a free local model, a Google-billed tier, an OpenRouter credit pool, and a flat-fee Claude subscription — four backends, three genuinely different kinds of money. Comparing them on raw dollars is meaningless: a $0 local call and a $0.03 OpenRouter call aren't equally "free," and a Claude Max call that's already paid for by a flat subscription isn't the same kind of spend as metered OpenRouter credit. The registry prices every model in true dollars, then multiplies by a separate weight for selection only — real cost is never faked:

POOL_WEIGHT = {
    "free": 0.0,          # local hardware; electricity only
    "google": 0.05,       # linked Google billing / free tier
    "openrouter": 1.0,    # real money out of the $30 / 30-day pool
    "claude_max": 1.0,    # flat subscription, but scarce + rate-limited
}

Selection compares cost * POOL_WEIGHT; budgets and logs always record true dollars, never the weighted number. An earlier version of this router faked the comparison a different way — repricing one backend to 5% of its list price to express "this one's cheap to us" — and that corrupted the registry's real prices, fought the price-refresh job, and silently flipped the tier ordering so a premium model auto-won by default. POOL_WEIGHT exists to keep that preference explicit and separate from the number everyone actually gets billed. The enterprise version of this is the same problem at a different scale: bundled SAP AI credits, a Databricks compute commitment, a Workday per-seat add-on, and direct API spend are not the same currency either, and "which platform should run this workload" stays an ungoverned default until something prices them on one basis.

NEVER_COMPARE: the policy checks its own scope, every run

The router's premium, subscription-billed models (Claude Haiku, Sonnet, Opus, Fable) are markedforced_onlyin the registry — a stronger exclusion than "expensive, so deprioritize it." The candidate filter that builds the auto-routing shortlist drops every forced_only model before cost is ever compared, at any complexity or value setting: they simply never enter the contest, and are reachable only by a deliberate, explicit call. Internally we call this discipline NEVER_COMPARE — the policy doesn't just rank those models last, it asserts they were never candidates at all, and the assertion is checked against the registry's live flags rather than assumed to still hold from when the code was written. The client-facing version of the same idea is discipline 3 in Standing Watch (Gate): the highest-blast- radius action category — payment release, master-data change, access grant — isn't "requires approval," it's structurally invisible to the automation layer until a human invokes it on purpose. A guardrail that only ever deprioritizes a dangerous option is one bad default away from picking it; a guardrail that structurally excludes it can't drift there by accident.