We run Statis on Statis: 100+ governed actions, 0 incidents

Every CI merge, deploy, release, Linear ticket, and Slack notification in this repo goes through our own policy engine. Twenty days in, here’s the ledger.

There’s a kind of infrastructure company that builds a trust product, ships it, and then quietly merges its own PRs the way it always did. We didn’t want to be that. So on April 4th we pointed five agents at our own GitHub, Linear, and Slack, seeded eleven policy rules, and started routing every internal automation through the same API we hand to customers.

What’s actually governed

Five agents, each with a narrow allowed-action list and an hourly rate limit:

1. 1ci-gate-agent — Proposes every PR merge. Escalates to a human if CI hasn’t passed or there are no approvals.
2. 2deploy-agent — Staging deploys auto-approve; production deploys escalate; anything else is denied.
3. 3release-agent — Tags and publishes GitHub releases, but only with an operator attestation.
4. 4issue-triage-agent — Creates and updates Linear issues from CI failures and user reports.
5. 5notify-agent — Posts and edits Slack notifications — deploys, incidents, weekly retros.

The rules live in dogfood/policies.yaml. They’re not secret, they’re not bespoke, they’re the same primitives anyone gets from pip install statis-ai.

The ledger, April 4 – April 24

GET /analytics/summary?days=30

{
  "actions_total":     111,
  "actions_approved":  110,
  "actions_escalated": 1,
  "actions_denied":    0,
  "approval_rate":     0.991
}

One hundred and eleven actions. One hundred and ten auto-approved. One escalation. Zero denials.

What “zero incidents” means here

We’re being specific about this on purpose, because the word gets abused. Over those twenty days:

1. 0FAILED executions — Every APPROVED action that reached the worker also reached its target system and returned a receipt.
2. 0Policy bypasses — No action skipped evaluation. No agent went around the contract. The engine is fail-closed.
3. 0Kill-switch activations — We never had to pull the emergency brake. It still works — we test it weekly.
4. 0Threat-log entries — No anomaly detector tripped. No exfiltration pattern matched. No rate-limit breach.

The one escalation isn’t an incident — it’s the product. Earlier today ci-gate-agent proposed a merge on PR #15 before CI had posted a green status. The dogfood_merge_defaultrule routed it to a human. It’s still sitting in the escalation queue as of this writing. That’s exactly what we want.

What this proves, and what it doesn’t

It proves the engine works under the specific load of a small infra startup’s own CI/CD. It does not prove Statis can take a thousand agents writing to Salesforce at once — that bar is higher, and customers are the ones pushing it. What we can say is that the internal team stopped asking for exceptions. There is no “oh but just this one merge can skip” side channel. The console is the console, the receipts are the receipts, and when something needs a human the queue makes that visible.

We also gave up nothing. Deploy latency didn’t change. No engineer has filed a “Statis is in the way” ticket. Approving an escalation is one click. The trade we thought we’d be making — safety for speed — didn’t materialize.

How to run it on your stack

pip install statis-ai

# register agents, seed policies, verify with simulate
STATIS_API_KEY=st_... ./dogfood/bootstrap.sh

The agents file, the policy YAML, and the bootstrap script are in the repo. Fork them, swap our agent IDs for yours, and you have the same setup running against your GitHub inside of ten minutes.

We’ll publish this ledger monthly. When the number gets bigger and the incidents are still zero, we’ll tell you. When something breaks, we’ll tell you that too — with the receipt hash.