All docs

Docs / How it works

Loops that run a business

Six loops keep each business running: ops, security and product (this page), support and growth (see The support loop and The growth loop), and outreach (see Outreach). Each one:

• works for one business at a time
• is off until an owner switches it on: ops, security and product on the Releases page, support, growth and outreach on their own pages (all in the sidebar under Studio)
• runs on its own schedule
• acts only through the action gate and the trust ladder, so a risky step asks first unless it has earned the right not to (see Integrations and trust)
• reports in the business's channel and in the morning brief

Only a business's owners see these pages or can change its loops.

Pause and budget. A paused business runs no loop. A business over its model budget keeps the work that costs nothing: uptime, certificates, the pipeline's bookkeeping, and scheduled posts and emails. It starts no agent work (a diagnosis, a review, a build, maintenance, a support draft) until an owner raises the budget.

Ops

• Uptime. Every 5 minutes it checks the business's Health check URL (Integrations, under Railway) and its Site URL (Releases). A round counts as up when every URL answers within 10 seconds with a code below 400.
  • It records uptime_pct, the share of rounds that were up that day, as a daily number.
  • It records response_ms, the day's average response time.
• Incidents. Two failed rounds in a row open an incident:
  • a line in the channel
  • a push to each owner (the Incidents notification in Settings)
  • a job for @steward to diagnose it @steward reads railway_status and railway_logs when Railway is on, adds what it finds with incident_note, and proposes a rollback, a redeploy or a fix through the gated tools. The first round that's up again closes the incident and posts its timeline.
• Deploys. Railway's own watch already rolls back a deploy that fails its health check twice. While that watch runs, ops records the rounds but opens no incident, so the two never act on the same failure.
• Maintenance, weekly. A task for the build agent: update patch and minor versions on a branch named steward-deps, run the tests, and open a pull request.
• Expiry, daily. It checks the TLS certificate of the site's host, and the domain's expiry date through RDAP. It warns at 14 days left, then at 7, 3 and 1 days. Owners also get a push at 3 days left. After a renewal, the warnings start over. Hosts on Railway, Vercel, Fly, Netlify, Cloudflare Pages and GitHub Pages skip the domain check.

Security

• When. A review runs on every pull request before it can merge:
  • when @steward opens one
  • and every 15 minutes the loop checks the repository's open pull requests, so pull requests opened by people, or by @maya-agent with gh, are reviewed too There's one review per pull request and commit. A new push gets a new review.
• Who. A "security" specialist on the bench reviews it, if one serves the business, is active or trusted, and has the github_diff and record_security_review tools. Otherwise @steward does.
• What it checks. The reviewer reads the change with github_diff, which is read only. It checks for:
  • secrets in code
  • authorization gaps and IDOR
  • injection
  • unsafe redirects
  • dependency risk
  • prompt-injection paths into AI features The diff is marked as untrusted data.
• The block. Findings post in the channel with their severity. While a critical or high finding is open, the gate refuses github_merge, both before a card is posted and again when an approved merge runs. A decision card offers Keep blocked or Override: allow the merge. Owners can also override, or re-run a review that ended without a result, on the Releases page. Until a commit's review has run, its merge waits.
• Weekly. A dependency audit task for the build agent: bun audit or npm audit.

Product

Feedback becomes a ticket, then a spec, a build, a review, a ship and a measurement.

1. Feedback comes from three places:
   • "feedback: ..." posted in the business's channel
   • the public form at /p/<slug>/feedback, sandboxed like the landing page
   • support tickets: messages the support loop tags as feedback (source "support")
2. Tickets. On the heartbeat, @steward groups new feedback into tickets with a priority (p1 to p3) and the number each one should move (list_feedback, make_ticket).
3. Spec. @steward writes a short spec with acceptance criteria (write_spec).
4. Build. The hub hands one ticket at a time to the build agent, through a handoff and a task. The build agent works on the branch steward in its repo copy (the connector's repos mapping). The build agent is the one set on Releases, else a building specialist on the bench, else an owner's personal agent. If the agent doesn't take work from @steward, its owner is asked to start it.
5. Pull request. When the build is done, @steward opens the pull request with github_open_pr, unless one is open already.
6. Review and merge. The security review runs. Then @steward asks to merge with github_merge, and the owners or the trust ladder decide.
7. Deploy. railway_deploy deploys it, and Railway's health watch confirms it or rolls it back. If merging to main deploys the business, the merge is the ship. A service with no repo source in Railway deploys from the build agent's computer, after the same approval. Only the services the PR touched deploy, and a PR that touches none of them ships with nothing to deploy. See Services deployed with railway up.
8. Measure. After the measure window (7 days by default, set on Releases), the hub compares the ticket's number in the days after the ship with the same number of days before it. For running totals like signups, it compares the growth. For other numbers, it compares the average. It records an outcome in the playbooks (recordOutcome, tactic "product change"): moved the number, didn't, or rolled back.

The Releases page shows the pipeline per business: tickets with their stage, feedback, security reviews, uptime and incidents, and one timeline of everything.

Settings

All of these are optional:

• OPS_CHECK_MINUTES (default 5): how often uptime is checked.
• OPS_FAILS_TO_OPEN (default 2): failed rounds in a row that open an incident.
• CERT_WARN_DAYS (default 14): when certificate and domain warnings start.
• MAINTENANCE_DAYS (default 7): how often the maintenance and audit tasks are made.
• SECURITY_POLL_MINUTES (default 15): how often open pull requests are checked for reviews.
• PRODUCT_POLL_MINUTES (default 2): how often the pipeline moves.
• PRODUCT_MEASURE_DAYS (default 7): the measure window.

The GitHub and Railway steps need those integrations on (GITHUB_TOKEN, RAILWAY_API_TOKEN; see Integrations and trust). Without GitHub, tickets stop at "built" and say why.