Every product declares what Startup OS may do in its manifest, STARTUP-OS.yaml, under capabilities. Each entry names one kind of action and sets it to one of five values. Nothing Startup OS does can widen these settings. You change them with a pull request that you merge.
The five values
| Value | Meaning |
|---|---|
allowed |
Startup OS may do this without asking. |
approval-required |
Startup OS may prepare the change. Execution needs the applicable explicit approval and supported action route. |
draft-only |
Startup OS may draft the content. A person publishes it. |
board-only |
You decide. Startup OS may propose with evidence, and no autonomy level ever grants it. |
denied |
Startup OS never does this. |
true and false are accepted as shorthand for allowed and denied, but write the words. Some checks compare the literal strings.
The permissions
| Permission | Whether Startup OS may… |
|---|---|
issues |
file GitHub issues |
comments |
comment on issues and pull requests |
branches |
push branches |
labels |
apply labels |
projects |
create GitHub Projects for initiatives and keep them current |
pullRequests |
open pull requests |
workflows |
add or change GitHub Actions workflows |
deployments |
run deployments |
productionDeployment |
deploy to production |
landingPageChanges |
change the public landing page |
contentPublishing |
publish written content |
socialPublishing |
post to social channels |
communityParticipation |
take part in third-party communities |
lifecycleEmail |
send lifecycle email to customers |
customerCommunication |
contact customers directly |
paidAdvertising |
spend on paid advertising |
pricingChanges |
change pricing |
partnerships |
enter partnerships |
legalClaims |
make legal claims |
dataCollection |
collect new data about people |
analyticsInstrumentation |
add analytics instrumentation |
A new product opens the first six: issues, comments, branches, labels, projects, and pull requests. Onboarding in the browser is slightly stricter and sets labels to approval-required. Everything customer-facing, public, or financial starts closed: approval-required, draft-only, board-only, or denied. Opening one is a decision you make, not a default.
Operating modes
A product’s operating mode says, in one word, how far it may go on its own. You do not set it. It is worked out from the permissions, so it can never disagree with them.
| Mode | What it means |
|---|---|
| Observe | Reads, reviews, proposes. |
| Prepare | Drafts and opens pull requests. |
| Operate | Acts within limits. |
| Paused | Preserves state, does nothing. |
| Archived | Stopped, history kept. |
Seven permissions are preparatory: their effects stay inside your repositories or organization. They are issues, comments, branches, labels, projects, pullRequests, and workflows. Every other permission reaches someone outside your team.
The mode is the first of these rules that matches:
- Every permission is
denied, and no cadence is on: Archived. - Every permission is
denied, and at least one cadence is on: Paused. - Any permission outside the preparatory seven is
allowed: Operate. - Any permission is
allowed: Prepare. - Otherwise: Observe.
A new product derives Prepare. There is no separate switch for Paused or Archived. You reach them by denying every permission and setting the cadences.
When you change a permission from the dashboard, the review screen tells you in words whether the mode will change, before anything is proposed. See Your product’s settings.
Decision rights and autonomy
Permissions say which actions are possible. A second set of rules says who decides which kinds of decision. It lives in the platform’s governance, and the manifest can narrow it but never widen it.
| Decision class | Examples | Who decides |
|---|---|---|
| Strategic | market, pricing, positioning, quarterly bets | You decide. Startup OS proposes with evidence. |
| Financial | spending, contracts, refunds above a threshold | You only, at every autonomy level. |
| Legal and compliance | terms, privacy, regulatory posture | You only. Startup OS may draft and flag risk. |
| Security | access control, secrets, vulnerabilities | You approve. Startup OS may prepare fixes. |
| Customer-affecting | anything a paying customer sees | You approve, unless the manifest grants it. |
| Editorial | public copy, announcements | Startup OS drafts. You approve publication. |
| Product | scope inside an approved plan | Startup OS decides. Scope beyond the plan escalates. |
| Technical | architecture, dependencies, refactors | Startup OS decides reversible changes and records them. Irreversible ones escalate. |
| Operational | maintenance, docs, tests | Startup OS decides and reports. |
Each class runs at an autonomy level, from L0 (observe and report) to L4 (act within an explicit budget). New products run at L1: propose. When the class is unclear, the more restrictive answer wins. An allowed permission still needs level L2 or higher before the platform performs the action itself.
A decision that is costly or impossible to undo always escalates to you, however confident Startup OS is. If you do not answer an escalation, Startup OS takes the safe default: no action, with the escalation kept open. Silence is never approval.
What Startup OS never does
Startup OS acts on GitHub through the Startup OS GitHub App. Some actions are refused before any permission is read, for every product:
- merge a pull request
- delete or transfer a repository
- force-push, or delete a protected branch
- read or write secrets
- administer an organization or repository
- widen its own permissions or rewrite a product’s manifest
Merging is left out on purpose. The merge is where you say yes, so there is no code that performs one for Startup OS.
Experiment registration and approval
A GTM thesis acceptance or registered experiment supplies business context, not new permissions. Registration and start require accepted decisions tied to the retained test definition; autonomous execution also needs current, verifiable L2+ authority for its class and the permission for each action. A standing allowed grant within scope needs no repeated approval. Draft-only and denied actions cannot be enabled by approving the test. Internal maintenance authority cannot be reused for customer acquisition.
Paid tests require founder authorization of the exact immutable plan, fixed total budget, dates and approval expiry, even when a learning parent exists. Pricing, market and strategic changes remain your decisions. Sends and publication retain their product-specific surface rules. See the GTM approval table.