When a loop must stop and ask you

What a loop must declare before you trust it named the permissions vocabulary. This guide is the policy layer on top of it: how much autonomy to grant a loop, and the short list of things that always need a human. It carries the site's trust posture. The no-hype rules apply doubly here — "fully autonomous," "set it and forget it," and "no human needed" are banned framings unless they carry a scoping clause in the same sentence.

For agents: - Honor human_gates.required_for literally — if an action matches, stop and escalate with evidence. - Never work around a forbidden action by decomposing it into allowed ones. - When blocked, report the five-part status: what changed / evidence / recommendation / confidence / awaiting approval. - Autonomy is scoped, not binary: which actions are autonomous, which are proposed, which are forbidden is the answer. - Gate and failure-policy fields live in the manifest at /spec; gates in prose but not in the manifest do not exist.

Autonomy is scoped, not binary

The useful question is never "autonomous or not" but "which actions are autonomous, which are proposed, and which are forbidden." A research-watch loop that reads the web and writes a findings report is autonomous for those two actions; it *proposes* a task when it finds something high-signal; it is *forbidden* from publishing that finding publicly without approval. Three scopes, one loop.

This is why the manifest has both permissions.allowed_actions (REQUIRED) and permissions.forbidden_actions (optional but expected wherever harm is plausible) (spec). The allowed list is credible only next to the forbidden list; a loop that "can do anything" is a loop that will.

Escalate, don't guess

When a loop hits ambiguity outside its declared scope, the correct move is to stop and surface it with context, not to pick a plausible action. An agent that guesses plausibly has not failed gracefully — it has failed invisibly, which is worse.

The five-part report from What a loop must declare before you trust it is the escalation format: what changed, evidence, recommended action, confidence and risk, and whether it acted autonomously or needs approval. A loop that hits its gate should emit exactly this and stop — not retry with a different guess. The failure_policy.escalate_after field (REQUIRED) names the condition that triggers this (spec).

What always gets a human gate

Some actions always need a human, regardless of how capable the loop is:

• Public publishing — anything a reader would see.
• Credential creation or changes — new tokens, scope changes, rotation.
• Spending — money, API spend, infrastructure cost.
• Destructive or irreversible actions — deleting user data, dropping tables, force-pushing.
• Changes to positioning or recommendations — anything that shifts what this site or product

recommends.

The worked example is this site's own discovery loop: it *proposes* resource entries autonomously and *publishes* only after approval. In the manifest this is human_gates.required_for (REQUIRED) (spec). A loop that appears to need no approval SHOULD still declare the boundary that would make it unsafe — the empty gate is a smell, not a feature.

Credential hygiene

Least privilege, scoped tokens, no shared broad credentials. The manifest declares required credentials via permissions.credential_scopes — names only, never secret values — so a reviewer can audit scope before install (spec). A loop that needs repo:write to open a PR is over-scoped; it needs pull_request:write. A loop that needs a personal access token to read a public repo is over-credentialed; it needs a read-only token or none.

Gates in the manifest

human_gates.required_for, failure_policy, and forbidden_actions are manifest fields, not prose aspirations. Gates that live in prose but not in the manifest do not exist (spec). This is the prose↔manifest consistency rule: every operational claim in prose should map to a manifest field, and every manifest field should be explained by the human or agent install docs. A README that says "this loop never publishes without approval" while the manifest's human_gates.required_for is empty is a defect, not a documentation gap.

Failure policy

Retries, escalate-after, and the rule that a loop which keeps hitting its gate is redesigned, not re-granted. failure_policy.retry (REQUIRED, integer) caps attempts; failure_policy.escalate_after (REQUIRED, string) names the failure class that triggers escalation rather than another retry; failure_policy.rollback (optional) records how to undo the last run.

The "redesigned, not re-granted" rule is the guardrail against drift: a loop that fails its gate three times in a row is telling you something about its scope, not about its luck. Bumping the retry cap is the wrong response; narrowing the scope or adding a gate is the right one. This is also what keeps "verified" honest over time — Loops rot: maintenance is part of the design's freshness cadence is what catches the loop that has silently started failing its gate.

Where to go next

• The harness: what actually does the work: the machinery that enforces all of this.
• Your first loop in 15 minutes: apply the gate vocabulary to a real install.
• What a loop must declare before you trust it and How you know it worked — the anatomy and verification this guide scopes.
• Glossary: human-gate, autonomy-scope, escalation.

Sources

• docs/research/loop-landscape.md — the landscape report behind the safety and gate findings this guide answers.
• docs/SELF-MAINTENANCE-BRIEF.md — the five-part report and escalation format.
• spec/loop-spec-v0.1.md — the manifest fields (human_gates, failure_policy, permissions) this guide is the policy for.