LoopRails · G0 · Trivial

Designing for a G0 (Trivial) Action

Part of the LoopRails guide series. For the full method see framework.md; for the field-guide version see playbook.md; for the evidence behind every claim see codex.md. Bracket tags like [A-17] point to the annotated source.

TL;DR — what a G0 action is

A G0 action runs autonomously and gets logged. It does not get a human gate — gating it is the wrong move and actively makes your system worse.

G0 is the lowest consequence grade in LoopRails. You earn it by passing a three-part test on the action's consequence — reversibility × blast radius × stakes — where every dimension scores low:

Dimension	What "low" means for G0
Reversibility	Nothing is changed, or any change is one-click undone / checkpointed [A-4].
Blast radius	Effect stays in your local workspace — not shared state, not third parties, not the public.
Stakes	Trivial. No money, safety, legal, security, or reputational exposure.

The grade is set by the highest dimension, so a single dimension creeping up disqualifies it. Canonical G0 examples: reading a file, running a read-only query, drafting text locally. (Jargon: blast radius = how far the effect reaches if it goes wrong; reversibility = how cheaply you can undo it.)

Is a human in the loop the answer here?

No — and this is the section that matters most, because the instinct to "just add a confirmation to be safe" is exactly backwards for G0.

A human adds essentially nothing at G0. There is nothing to catch: the action is reversible, local, and trivial, so the worst case is already contained. Worse, the evidence says a human placed in front of a low-stakes prompt is not a good detector even when it counts. Approval gates cut the occurrence of bad actions but barely improve a human's ability to catch one — the "recognition bottleneck": plan-approval drove attack occurrence down to 60–74% from ~90%, yet intervention success stayed at 9–26% across every strategy tried [A-17]. Even motivated expert developers default to shallow, heuristic review under productivity pressure and rubber-stamp [A-18, A-21]. If a human can't reliably catch a real error, asking them to "approve" a file read is pure ceremony — it manufactures accountability without producing control [C-21].

Prompting at G0 manufactures alert fatigue, and that erodes the alerts that do matter. This is the real harm, and it is quantified. Clinicians override 49–96% of drug-safety alerts, driven by poor signal-to-noise [H-10]. Indiscriminate flagging trains people to dismiss everything, including the rare valid signal. The aviation/process-control discipline is blunt: an alarm must demand a specific operator response, and the interruptive rate must be capped (EEMUA targets roughly ≤10 alarms per 10 minutes per operator) [H-21]. False-alarm-prone systems are uniquely corrosive — they damage both compliance (acting on alarms) and reliance (trusting silence), driving the "cry wolf" desensitization that makes people override even critical alerts [F-17]. Every G0 prompt you add is a false alarm in disguise: it spends a slice of a scarce, finite attention budget on something with no consequence, and it teaches the human to click through the next prompt reflexively — including the G3 one where catching the error was the whole point.

So the framework's default mapping puts G0 at L0–L1 (autonomous, silent or logged): "spending attention here is waste; it manufactures alert fatigue" [H-21, F-17]. The right posture is management by exception — handle the routine autonomously and surface only deviations [K-1]. Human review combined with AI is not free benefit either: human–AI teams often underperform the better of human-or-AI alone, especially in decision tasks [C-19]. At G0, the human is the weaker, costlier party. Leave them out.

How to design it properly

Run autonomously; log, don't prompt. G0 actions execute without a gate. The control surface is a passive log, not a dialog. Borrow the staged-automation view: automate perception and analysis (read, query, retrieve) freely, and reserve gates for the act stage where over-trust and lost authority bite — and a G0 action barely touches the act stage at all [E-6].

Budget interruptions as a scarce resource. Treat your interruptive capacity like a quota you can overspend. The G0 contribution to that quota should be zero blocking prompts. Most signals passive/logged; blocking interventions reserved for high-severity, high-precision cases [H-21, F-17]. This is the principal–agent bargain: oversight is costly monitoring, so monitor the exceptions, not everything [K-1].

What to record. Keep a queryable, append-only trace so post-hoc audit and accountability are possible without a live human in the loop:

the action taken, with timestamp and the tool/capability used;
inputs/parameters (e.g., which file, which query) and the result or a digest of it;
the cumulative tally per session — counts and rates of G0 actions, so composition is visible;
enough provenance that, if an action later escalates, you can answer "how did this get here?" [C-20].

Keep G0 truly G0 — watch for hidden blast radius and mis-grading. The danger is an action that looks trivial but composes into something bigger. Guard against it:

The shell-boundary trap [A-4]. Checkpoint/undo typically covers an agent's structured edits but not shell side effects. A "read" that is actually a Bash command with side effects, or a "query" that hits a write endpoint, is not G0. Grade by actual reversibility, not by whether your framework has a rewind button.
The lethal trifecta [A-23]. A read becomes dangerous the moment it combines private-data access + untrusted content + an external-communication path — that combination is near-guaranteed exfiltration via prompt injection. Reading a file is G0; reading a file and then being able to send it externally is not. Detect the combination and escalate/forbid.
Accumulated blast radius. Many small G0 reads can compose into a G2-scale effect (e.g., scraping an entire private codebase). Escalate the level automatically when accumulated reach crosses a threshold — that is the same dynamic trigger the framework applies to scope creep.

If any of these fires, the action was never G0. Re-grade it; don't paper over it with a prompt the human will rubber-stamp anyway.

Worked example — a coding agent reading files and running read-only queries

A Claude Code–style agent exploring a repo before making changes:

Map / Grade. read file, grep/search, git log, git diff (no write), a SELECT against a read replica — all G0: nothing changed, local workspace only, trivial stakes.
Match the mode. L0–L1: the agent reads and queries freely and silently; each action lands in the run log. No confirmation dialog, ever. (Contrast: an edit to a local file is G1 — act
- notify with cheap undo; git push is G2 — confirm-before with a diff. G0 sits below all of that.) [E-6, K-1]
Instrument. Run in a sandbox/branch with no prod credentials, so even a mis-graded read can't reach anything that matters [A-23]. The log records every file touched and every query run, with a running count.
Keep it G0. Two tripwires: (1) the read replica is genuinely read-only at the database level, not just by the agent's intent — a "read-only query" that can mutate is mis-graded [A-4]; (2) if the agent gains the ability to send what it reads anywhere external, the trifecta fires and the action class is re-graded and gated [A-23].
What you get. The agent does the high-volume, low-stakes work — exploring, grokking, drafting — with zero interruptions, and your human's attention is preserved intact for the git push and the prod migration, where catching a mistake is real and possible.

Anti-patterns

Over-gating trivial actions → alert fatigue. Putting a "Allow read of config.json?" prompt in front of a G0 read is the single most common way oversight dies in practice. It is the Alert-Fatigue Spiral: too many low-value prompts, so the human dismisses all of them — including the valid ones [H-10, F-17]. You cannot fix this later by muting the noisiest category, because rare-but-critical cases hide in high-override buckets — the only safe fix is to not over-alert in the first place, by tiering [H-10/H-11]. Symptom to watch for: a global "ask everything" switch (maturity level 0 — "Binary"). The cure is grading, so trivial work just runs.

Phantom oversight. Mandating a review step that is illusory in practice — the human "approves" G0 actions they can't and needn't evaluate — legitimizes the system with a façade of accountability while delivering no control [C-21]. At G0 this is pure theater: there is no error to catch and no authority that's meaningfully exercised. It also quietly creates a moral crumple zone if anything ever does go wrong, because a human's name is on an approval they never truly made. The antidote is honesty: if oversight here can't pass the four A's (Authority, Awareness, Ability, Accountability), don't claim it — change the design and log instead.

The Confirmation Reflex. Reaching for a warning prompt where cheap reversibility would do. Habituation sets in by the second identical prompt; undo beats confirmation. For G0 there isn't even anything to undo — so the only correct amount of confirmation is none.

Sources

[H-10] van der Sijs et al. (2006), Overriding of Drug Safety Alerts in CPOE — clinicians override 49–96% of alerts; the empirical heart of alert fatigue.
[F-17] Dixon, Wickens & McCarley (2007), On the Independence of Compliance and Reliance — false alarms uniquely corrosive; alert volume/precision are safety parameters.
[H-21] EEMUA Publication 191 — every alarm must demand a defined response; cap the interruptive rate; everything else is a passive log.
[E-6] Parasuraman, Sheridan & Wickens (2000), Types and Levels of Human Interaction with Automation — automate perception/analysis freely; gate the act stage.
[A-2] Anthropic (2026), Configure Permissions (Claude Agent SDK) — risk-tier tools; auto-run the trivial, gate the consequential.
[K-1] Taylor (1903/1911), Scientific Management — management by exception: handle the routine autonomously, surface only deviations.
[C-19] Vaccaro, Almaatouq & Malone (2024), When Combinations of Humans and AI Are Useful — human–AI teams often underperform the better of either alone.

Also drawn on: [A-17] recognition bottleneck (gates cut occurrence, not catching); [A-18, A-21] rubber-stamping under pressure; [A-4] the shell-boundary / undo trap; [A-23] the lethal trifecta; [C-21] illusory oversight / moral crumple zone.

LoopRails guide — G0 (Trivial). Companion to framework.md, 2026-06-22.