The operating loop is how Startup OS works on a product: observe what is true, decide what is worth doing, propose it, and check whether it worked. It runs as GitHub Actions workflows in the product’s Operations Instance, on a schedule, without anyone starting it.
The first run
A new product’s first run is started by you, not by the schedule. Once its configuration is merged and your model credential is in place, choose Run first assessment and plan on the product’s dashboard page. It runs the first-run.yml workflow once, which reads the product’s context and writes an assessment and a proposed operating plan. The dashboard treats onboarding as complete only once it has found both, committed to the Instance by a successful run. The first run prepares recommendations; it does not grant permission to act on them.
The steps
The weekly loop has nine steps. Each runs as its own scheduled turn and reads the files earlier steps committed, so a step that fails can be retried on its own without repeating the rest.
| Step | Does | Writes |
|---|---|---|
| 1. Observe | Collects the evidence the product has authorized. Uses no model. | 01-observations.jsonl |
| 2. Understand | States the goal, what is known, and what done looks like. | 02-understanding.md |
| 3. Research | Finds candidate actions, with evidence. Skipped when there is no open question. The only step allowed on the web. | 03-recommendation.md |
| 4. Review | Attacks the reasoning before anything is decided. | 04-review.md |
| 5. Decide | Commits to one candidate, or to doing nothing. | 05-decision.md |
| 6. Plan | Turns the decision into the smallest action that tests it. | 06-plan.md |
| 7. Act | Proposes exactly one action, or records why there is none. | 07-proposed-action.json or 07-no-action.md |
| 8. Verify | Observes again, to see whether the action did what it should. | 08-verification.jsonl |
| 9. Learn | Compares what was predicted with what happened. | 09-learning.md |
Every file lands in runs/<run-key>/, where the run key is the product and the ISO week.
When a step cannot proceed honestly, it declines and says why rather than guessing. The loop then resumes at the next scheduled cycle. A declination is a valid result, not a failure.
The weekly schedule
These are the defaults, in UTC, from config/schedule.json. You can change the timezone, each turn’s times, and whether it runs at all from the dashboard’s configuration page.
| When | What runs |
|---|---|
| Monday | The nine loop steps, from Observe at 09:07 to Learn at 21:07, ninety minutes apart |
| Tuesday | The weekly digest, at 15:00 |
| Wednesday | Content topics |
| Thursday | Development, and a content draft |
| Friday | Development review, and the weekly business review |
| Every day | Refreshing evidence, sweeping issues, filing and closing initiatives, a marketing heartbeat, a social checkpoint, and sitemap submission |
| Weekdays | Pull request sweeps, twice a day, and social publishing |
| Monthly | The newsletter draft, on the 1st |
| Quarterly | Quarterly planning, on the first day of January, April, July, and October |
One workflow, dispatch.yml, checks the schedule every fifteen minutes and starts whatever is due. It is the only workflow with its own timer. A turn that is switched off in the schedule never runs.
The credential audit ships switched off. Turn it on once you have looked over what it checks.
What lands for you
| What | Where | Why |
|---|---|---|
| The weekly digest | An issue labelled digest in operations, every Tuesday |
A summary of the week, with a queue of open items. Last week’s digest closes when the new one opens. |
| Pull requests | operations, labelled startup-os |
Proposed edits to the context notes, adoptions of new platform releases, and other changes. Each waits for you to merge. |
| Escalations | An issue labelled escalation in your product’s repository |
A decision that is yours to make. |
| Initiatives | A parent issue per bet, with sub-issues in the repositories the work changes | The one-off work an approved quarterly plan’s bets need. Closed again when a bet stops. |
| Proposed actions | Issues labelled proposed-action in your product’s repository |
Work Startup OS has proposed and cannot do itself. |
| Health alerts | An issue labelled loop-health in your product’s repository, at most one a week |
A scheduled workflow failed. |
| Commitments | Issues labelled commitment in operations |
A dated commitment has come due. |
A sweep checks pull requests twice each weekday. When a pull request’s checks pass, it adds the label ready-for-founder. When they fail, it tries at most two fixes, then marks it agent-stuck for you. The sweep never merges.
What you do
- Merge, or close. Nothing Startup OS proposes takes effect until you merge it.
- Answer escalations. If you do not, Startup OS takes the safe default: no action, with the escalation kept open and raised again in the next review. Silence is never approval.
- Fill in what only you know. Onboarding leaves
TODO(founder)markers wherever a fact about your business is needed, such as your stage, customers, and objective. - Open things up deliberately. Turning on a guarded turn, or granting a permission, is a change you make on purpose. See Permissions and operating modes.
Budget and health
Each run has a budget of model sessions, set in the manifest under spec.governance.budget. Every model-bearing step counts once, whether it produced a result or declined. When a run would exceed the budget, the next step refuses before starting a model and raises a health alert. Retries do not count twice.
If any watched workflow fails, including the scheduler itself, a loop-health issue opens in your product’s repository, and a daily sweep keeps those issues triaged.
Beyond the weekly loop
Some turns stand apart from the weekly loop and take no input from it:
| Turn | Produces |
|---|---|
| Weekly business review | What changed this week, and whether the bets still hold |
| Content topics | Up to three topics worth writing about |
| Content draft | A draft, as a pull request. It never publishes. |
| Development | One proposed technical step |
| Development review | A review of a development pull request |
| Launch | A judgment on whether something shipped is worth announcing. Runs when a release happens. |
| Newsletter | A monthly newsletter draft |
| Quarterly planning | Falsifiable bets for the quarter |
Development turns ship closed: until you allow code paths in config/development.json and the kinds of proposal the act step may make in config/loop-steps.json, they can only decline.
How GTM changes the next run
For an adopted product, the existing weekly review relates evidence to accepted motions, hypotheses and registered tests. It can prepare a complete decision and state proposal to continue, complete, stop or modify a test, or request your strategic decision. Current canonical state and execution authority are checked before later actions; a stopped test cannot keep running through an old prepared proposal. A modified successor stays designed until separately registered and started. Independent sourced operating duties can continue. See Go-to-market workflow.