The Autonomy Boundary: When an AI Harness Works Alone and When It Calls a Human

Before we start: a few words

forge is a harness. It is a set of skills, scripts and hooks around an AI coding agent. It takes an idea through research, architecture, planning, coding, review and merge. Most of that work happens without a person watching.

A few terms come up again and again:

Card. One unit of work. It has a goal, acceptance criteria and a list of things it must not break. One card should become one mergeable change.
Wave. A group of cards planned to run together. Cards in a wave can run in parallel unless they touch the same files. Waves are numbered across the whole project, not per run.
Run. One session of the dispatcher, the part of forge that starts cards, watches them and merges them. A run can cover several waves.
Run modes. run is interactive: the dispatcher may ask a person. run auto works alone but leaves every merge to a person. run autonomy works alone and merges on its own.
Checkpoint. A point declared in the plan where the result must be checked before more is built on top of it.
Escalation. The moment forge decides it cannot go on with a card and hands it to a person. The card is “parked”. The rest of the run continues.
ADR. Architecture Decision Record. A short document that says what was decided, why, and which options were rejected. forge has 171 of them. Most rules in this article come from one.

1. One run from the log

On 6 September 2026, at 17:17 UTC, the dispatcher started an unattended run. It had nine cards in three waves. Nobody watched. Everything we know about it comes from the run report, a log the dispatcher writes one event at a time.

The first two waves went fine. Some cards in them edited the same files, so the dispatcher ran them one after another instead of in parallel. By 03:52 the next morning the run reached its last wave, wave 33 in the project’s numbering. It had five cards, all touching the same file, so they also ran one by one.

At 09:41 the second card of wave 33 escalated. Paraphrased, the log gives this reason:

the same family of bug came back a fifth time across five review cycles; the score was good, but one serious finding still blocked the merge

In plain words: the reviewer kept finding the same kind of bug. Each fix closed one case, and the next review found a neighbouring case. After five rounds forge decided that more rounds would not help.

The run did not stop. Two minutes later the log says the next card started, and adds: “run continues without it, not a run-halting stop”. Two more cards merged. At 16:47 the last card of the wave escalated for a similar reason.

Twenty minutes later, almost a full day after it began, the run did stop. It stopped not because two cards had failed, but because wave 33 had a checkpoint. The checkpoint’s test used files from the two failed cards. Those files were never merged. So the checkpoint failed, and a failed checkpoint is one of only three things allowed to stop an autonomous run. In short, the log records:

wave-33 checkpoint failed: its test depends on work from two cards that were parked and never merged; autonomous run halted

The final count: seven cards merged, two parked, both for the same kind of problem.

None of this was luck. Every step followed a written rule:

The run went on after the first failure, because a parked card does not stop a run.
The run stopped at the checkpoint, because building on an unchecked result is not allowed.
forge did not retry the two failed cards, because a retry cannot fix this kind of problem.
When the person came back, they found two parked cards. Each had a reason, a place where the problem lives, and a suggested next command. There was no frozen prompt asking “continue?”.

This article is about those rules. The hard part of building forge was not making the agents smart enough. It was deciding, exactly and in code, where their authority ends.

2. Why “ask the user” does not work at night

Almost every agent setup has a line like “if unsure, ask the user”. In a live session this works. The agent asks, a person answers, work goes on.

In an unattended run the same line is a trap. The agent asks. Nobody is there. The run hangs until morning, with half-written code and the budget still running.

The obvious fix is to list every place where the agent might ask, and give each one a default answer. forge tried this first. It does not work, for two reasons.

The list is never complete. The requirement for autonomous mode named several such places: a failed smoke test, a checkpoint, a card taking over a neighbour’s work, a review of missed goals, “and any other branch point”. That last phrase is the real problem. The neighbour case did not even have a name when the requirement was written. It was found during a live run. New cases keep appearing.

Flags do not reach everyone. A run starts many helper agents: a coder, a reviewer, a fixer. These are separate agents. They do not read the dispatcher’s settings. So a flag that says “autonomous mode, do not ask” proves nothing about what a helper agent will do.

forge’s answer has two parts.

Part one: make asking impossible. An autonomous run works through a channel where a question simply cannot be asked. If an agent tries, that is not a pause. It is a refusal. The card is parked with the reason, and it goes to the queue like any other parked card. The rule must be built into the channel, not written as advice. forge even has a measurable target for it: the number of prompts per autonomous run must be exactly zero, tested on a run built to hit every escalation path.

Part two: give defaults for the cases we already know. A failed smoke test has a policy. A checkpoint has a policy. The “should I redo this card?” question has a default. Without these, the first autonomous night would park a card at every known branch point and merge nothing.

Together the two parts give one simple behaviour. A known case takes its default and the run goes on. An unknown case refuses loudly, parks the card, and appears in the queue. In the morning a person adds a default for it, and next night the run does not stop there. The one thing the design forbids is silence: hanging on a hidden question, or quietly picking an answer nobody approved.

The first rule: in an unattended run, a question becomes a refusal, and a refusal becomes a record. Never a wait.

3. Only three reasons to stop

If a question cannot stop a run, what can? forge’s answer is a short list, and the list is closed. Nothing else may stop an autonomous run.

Stop	What happened	Why the run cannot go on
(a)	A checkpoint has no automatic test	Only a person can judge it
(b)	A checkpoint’s automatic test failed	Building more on top of a failed result is not allowed
(c)	The run breaker tripped	Something is wrong with the whole run, not with one card

The run in section 1 ended on stop (b).

Many things are not on the list. A failed card is not a stop. A review that will not converge is not a stop. A parked wave is not a stop. All of these park something and let the run go on.

The breaker

Stop (c) needs a few words. It is the only stop based on how the run itself behaves, not on any single card. It trips when failures stop looking independent: when cards in a row fail the same way, when automatic recovery keeps failing, or when the run’s money or time budget is spent. As the configuration puts it, the point is that “a third card is not burned on the same defect that already failed the first two.” When failures cluster, the problem is probably in the plan or the model, and more attempts only waste money.

One agent running too long is not a breaker case. If it has stopped sending signs of life, it is parked as “hung”. If it is still alive, the run just notes a warning.

Stopping means “no new work”, not “kill everything”

What happens to cards that are already running when a stop comes? They finish. They either merge or get parked, in the normal way. Their work is not thrown away. Only new cards do not start. The run then ends with a report: which checkpoint stopped it, and what happened to each card that was in progress.

Refusing to start is not a fourth stop

On 16 October forge got a new rule. Some projects must now have certain cost controls in place before forge will run on them. If they are missing, forge first warns, and if the warnings are ignored, run auto refuses to start.

Should run autonomy refuse too? The decision was yes. Two other options were rejected:

“Just warn.” Rejected in one line: nobody reads a warning in an unattended run.
“Make it a fourth stop.” Also rejected. The problem is known before the run begins, so it is cheaper to refuse at the start than to stop in the middle.

So the list stays at three. The decision even notes a small risk: the difference between “refused to start” and “stopped” must stay written down, “or a reader will count four stops”.

Why a closed list matters

A closed list can be tested. You can trigger each stop and check that nothing else stops the run. An open list of “things that felt serious” cannot be tested. And once it exists, every new problem becomes an argument about whether it is serious enough.

The second rule: the reasons to stop an unattended run are a short, written list, each with a reason. Adding one is a design decision, not a call made in the middle of the night.

4. An escalation is a form, not a message

When forge parks a card, it does not write a free-text note. It fills in a form with fixed fields. That form is what makes the morning after a run manageable.

Here is the idea, in a simplified shape:

# illustrative shape, not a real schema
parked:
  - card: card-42
    reason: "review stopped converging"
    station: implementation   # implementation | decompose | architect | hung | breaker
    route: "<command a human would run>"

Three fields do the work:

reason: what went wrong, in one line;
route: the command a person would run next;
station: where the problem lives. This is the important one.

The station says what is broken

A card can fail for three very different reasons:

implementation: the card is fine, the code is wrong;
decompose: the card itself is wrong. Its scope is badly cut, or its rules contradict each other, or its goal cannot be reached as written;
architect: the requirement or the design behind the card is wrong.

There are two more for run-level problems: hung (an agent stopped responding) and breaker (the run’s fuse tripped).

The station decides what forge may try alone

This is the core of the design:

implementation: the only class forge may retry on its own: once, from a clean slate, carrying forward what it learned. If that fails, the card is parked.
decompose or architect: parked at once. A retry rewrites the same card against the same requirement. If the card or the requirement is the problem, it only spends money to hit the same wall.
hung or breaker: always parked. These are not problems with the card.

So there is exactly one path from a failed card to a merged card without a person, and only for coding problems. Everything else waits for a human. That is a narrow autonomy, and it is narrow on purpose.

The queue holds only cards

A person reads the queue of parked cards, which a script rebuilds from the dispatcher state. Every entry is a card the person can act on: redo, unblock or abandon.

Other things a run notices, like “this bug pattern should become a project rule” or “this requirement may have been misunderstood”, do not go into the queue. They go into the run report as suggestions. The queue stays a to-do list, not a mix of tasks and ideas.

The “special case” that went wrong

One story shows why the form matters. When forge first handled hung agents, it made them a special kind of record with their own rules. It could only be removed by a special command.

The result: every part of forge that dealt with parked cards had to learn about the special record. The list of such places had 24 entries: crash repair, resume, redo, abandon, unblock, skip, run abort, the report, the queue, and more. Each review found one more place that had been missed. After three rounds the card itself escalated.

The fix was to drop the special case. A hung agent became an ordinary parked card with station hung. It now lives and leaves like every other parked card. Only one extra rule was kept, for the real risk: the hung agent may still be writing files. So any action that would restart the card or delete its folder first checks whether the agent is still alive, and refuses if it is. Twenty-four special cases became one rule.

The third rule: a parked card carries a reason, a next step, and a station. The station names what is broken, and only the station decides what forge may try before calling a person.

5. A hint is not a decision

Several forge decisions follow the same pattern. A simple rule that used to make a decision is turned into a hint. The hint stays visible. The decision moves somewhere else.

Card size. When forge plans cards, it estimates their size against a fixed limit. At first, a card over the limit was split automatically. Measurements showed the splits did not help: they doubled the checking work and gave nothing back. So the automatic split was removed. Now a big card only triggers a hint. Whether to split it is decided by a clear test (“is it one independent change?”) or by a person. The decision record says it well: the hint stays “without false authority over a decision it cannot justify”.

Missed goals. After a wave, forge checks whether the merged code meets the requirements. If a requirement is not met, there are two possible causes. Either the code is incomplete, or the requirement was misunderstood. In an interactive run a person picks one. In an autonomous run, forge picks neither. It writes both possible causes into the report and marks the item “untriaged”. Choosing between “the code is wrong” and “the requirement is wrong” is exactly the kind of judgment the boundary keeps for a person.

Turning a bug into a project rule. When a card fails, forge may notice that the bug belongs to a wider pattern. Should the pattern become a rule for the whole project? In an autonomous run the default is “keep it as a lesson for this card only”. If the pattern looks strong, forge writes a suggestion into the report. It never applies it on its own.

Extra review rounds. Review has a limit on rounds. forge may go past it only while review is visibly converging, while the serious findings are actually going away. When progress stalls, the card is parked. Whether a card deserves even more rounds is a person’s call. The logs show people making that call 13 times in the period reviewed.

In all four cases a cheap signal stays, because it is cheap and often useful. But the decision goes to something that can justify it: a clear test, a measurement, or a person.

The fourth rule: automation may give hints anywhere. It may decide only where a mistake costs less than waiting for a person, and the decision record says where that is.

6. Autonomy is earned, not switched on

So far we looked at one repository. forge also has a coordinator, the conductor. It drives planning and delivery across several services that make up one feature. The conductor is where the question “how much freedom does the system get?” is answered in general.

Four levels of readiness

forge’s readiness plan defines four levels:

Level	What it means
L1, prototype	The pipeline goes from idea to code on a demo
L2, internal alpha	The author uses it on own projects, under supervision
L3, pilot	Other teams use it, in supervised mode; every check has fired at least once on their code
L4, production	Autonomous modes on real projects beyond the author’s own; a person approves the result instead of rescuing the run

The plan rates forge at L2 today. The L4 line is the core of this whole article: a person approves the result instead of rescuing the run.

L4 is not a feeling. It has entry conditions fixed in advance: real pilots, a set of metrics that must hold across repeated measurements with a known cost per card, and a ceiling on how often the orchestrator may skip a required step.

The conductor gets no more freedom than the dispatcher has earned

By default the conductor starts work in each service in run auto mode. Every finished card waits for a person to merge it. Waiting merges show up in one shared queue, so the person does not have to visit every repository.

The fully autonomous mode is allowed only when a readable readiness check says the dispatcher has reached L4. If the check says no, or cannot be read, the conductor refuses and says which check failed. It never quietly falls back to another mode. Right now nothing can make this check true. So autonomous mode across services is simply unavailable, and the decision record says so openly.

The rejected option was “full autonomy from day one”. It had a fair argument: with many services, waiting for human merges is the main bottleneck. It was rejected because a wrong mode in one repository is a bad night, while a coordinator would spread that same mistake across every service at once.

Merges are checked by a script, not by a promise

Even in autonomous modes, cards do not go straight to the main branch. They collect in a staging branch for the wave, and at the end of the wave a script checks the whole wave against a fixed set of conditions: every card truly finished, nothing forced through, nothing still parked, tests green, a clean merge. By default even an all-green wave waits for a person to sign it off. A project may opt in to auto-merge for all-green waves; anything red goes back to a person.

The same script runs in two places: at the end of the run, and in the git hook that guards publishing. This matters. forge’s threat model names the risk directly: rules written as text “yield to consent”. An agent can be talked out of a sentence. It cannot be talked out of a script that the publishing hook runs again on its own.

A small example of the same idea: forge has an override that marks a card done despite failed checks. It needs a written reason. And it is always forbidden in autonomous modes. Overrides exist only for a person at the keyboard, and each one is recorded.

The fifth rule: how much freedom the system gets depends on how mature it has proven to be. That level is written as a check the system can read. Going up a level is a change of setting behind that check, never a shortcut because someone got tired of approving merges.

7. The person’s answer is a form too

Most writing on escalation stops when the person is called. forge goes further. The other half of the boundary is just as easy to get wrong. If a person answers in free text, and the system has to act on that answer by itself, the answer can become a new reason for the run to hang.

The architect that never asks

When the conductor runs forge’s architecture pipeline, it uses a mode in which the pipeline asks nothing. When it reaches a step that needs a person, like a design decision, a stakeholder review or a brainstorm, it stops and leaves exactly one signal: “this is waiting for a human”.

These steps are human by design, even in normal use: the skills that own them refuse to skip them, however simple the feature looks. The no-questions mode does not weaken such gates. It just makes the waiting visible from the outside.

Answers have a fixed vocabulary

The conductor keeps one queue of everything that needs a person. Two kinds of entries come from the conductor itself:

stuck: a step failed too many times;
breaker: a feature went over its budget.

For these two, free-text answers are refused. Only a few fixed answers are accepted:

stuck: retry, or stop;
breaker: raise the budget to a new figure, acknowledge the current overspend once, or stop.

Why so strict? Because of a loop found during design. Imagine a person “closes” a budget alarm with a comment like “ok, noted”. The budget is still exceeded. On the very next check the alarm fires again. The answer changed nothing.

With fixed answers, the act of answering also fixes the cause. Raising the budget writes the new budget. Acknowledging once records the current overspend, so only a further rise fires again. Stopping writes a stop record that only an explicit resume removes. In the decision’s words: the act that closes the alarm “also removes or acknowledges its cause, so there is no immediate re-raise loop.”

A rejected option was a separate “close” command. It meant two commands for one act. And if the person closed the alarm without first raising the budget, it would fire again at once. Correctness would depend on the person remembering the right order.

Is the wait still real? Check the facts, not the notes

This is the most useful story in the group, because the first version was wrong and it took three review rounds to see why.

The question: when the architecture pipeline stops and waits for a person, how does the conductor know the wait is still real?

First version. Every wait was written as an entry in a waits file. For each kind of wait, one specific step was responsible for deleting the entry once the person answered.

What went wrong. Every review found another way the wait could be resolved without passing through the “responsible” step. A decision could be resolved by just changing its status. A person could run the brainstorm skill directly, skipping the pipeline. A “reject” answer needed its own path. Each missed path left a stale entry, and a stale entry kept the alarm open forever.

Second version. The logic was turned around. A wait is real as long as a certain fact is missing on disk. For a brainstorm wait, the fact is that the vision and stories files exist. For a design review wait, it is an approval mark in the design brief. For a contract dispute, it is a newer contract version or a recorded rejection. If the fact exists, the wait is over, no matter what the file says. Anyone may clean up old entries. Nobody has to.

In the decision’s words: “Who physically deletes an entry, and whether it is deleted at all, does not affect correctness.”

Waits that already have their own document, like an open design decision, are not copied into the waits file at all. Their own document is the signal.

The wait format is a contract

The conductor reads these signals from other parts of forge with a simple script. So their format is treated as a public contract. If the architecture pipeline or the dispatcher changes the format, that is a contract change, and the conductor’s reader must keep working.

Every surprise becomes one “stuck”

The conductor treats its own surprises the same way. A step that runs too long. A launch with no recorded process. An answer that was delivered but did not end the wait. A service whose state is unclear. For every one of these the rule is the same: record one “stuck” entry with a reason, and let a person decide. The conductor never kills a process. A process exiting is never taken as success. Only a fact on disk moves a service forward. And the conductor never edits a service’s code itself. It only starts a session inside the service and reads the result afterwards.

The sixth rule: the boundary has two sides. forge must wait in a form a script can read. The person must answer in words a script can act on. Whether a wait is still real is decided by a fact on disk, not by a note someone was supposed to delete.

8. What the numbers show

Rules are cheap. Here is how they behaved on forge’s own development, where forge builds itself. Numbers are from the process review of 4 October unless marked otherwise.

Measure	Value
Run reports available (since 6 September)	13
Escalations / different cards escalated	57 / 30
Cards unblocked by a person	5
Declared run stops	3
Logged “user decision” entries	11
Extra review rounds granted by a person	13
Cards closed with no human touch, before 6 September	84–94%
Cards closed with no human touch, after 6 September	47–61%
Merged cards later reverted, out of 158 closed	0
Cards done as of 18 October	182

Where escalations came from (categories overlap): repeated bug family 25, bad card cut 15, out of review rounds 8, build or test failure 7, scope check 3, holds 2, architecture 2, guardrail 1.

Why fewer cards close without help

The biggest change is the drop from about nine in ten cards closing alone to about half. The data supports two explanations, and the review does not pick one:

The checks got stricter. Around 6 September new checks were in force: one for recurring bug families, one that lets a single serious finding block an otherwise good review, as the run in section 1 shows. Stricter checks mean more escalations.
The cards got harder. The work moved from simple delivery features to the multi-service conductor and the readiness plan.

Git cannot tell them apart: the history does not separate human work from pipeline work. Either way, the trend goes against what a demo would show. And it is exactly the number the L4 level talks about. At L2, a person still rescues the run about half the time.

A busy morning

On 22 September, between 04:22 and 11:38, two cards were parked and unblocked again and again. Every escalation named the station, the review scores over time, and three options, A, B and C, with one marked “recommended”. Every answer was short: a card, a chosen option, and a few words of why. One card went through nine fix rounds and two extra rounds approved by a person.

Five human decisions in one morning is a lot. But each was a choice between ready options on a card that already carried its diagnosis. The person did not have to rebuild what the agent had been doing.

Escalations that should not have happened

On 3–4 October two cards were parked for purely budget reasons. A single retry counter was counting several different kinds of event, real failures, flaky tests and routine procedural steps, as if they were the same. Two cards ran out of attempts with no real problem found. Each still cost a human decision, an unblock and a new review. This is the boundary drawn wrong the other way: not too much freedom, but an alarm raised by a counter that mixed things a person would never need to see.

What the data cannot tell us

The review is open about its gaps. There are no run reports before 6 September. A card’s start time resets on redo, which spoils duration numbers. Some fields are free text. Retrospectives stop at wave 38. And only 51% of forge’s own rules, 85 of 167, are enforced by code. The rest are text.

9. Where the boundary broke

Most decisions quoted above are second versions. Read together, they show four mistakes that keep coming back. Each has the same kind of fix.

A list instead of a closed set. Three cards in one session finished only after a decision that changed the rule itself. In each case the rule was a list: of rivals, of consumers, of dangerous patterns. Every review found a new item. The review sums it up: “An enumeration does not close until it is replaced by a closed set.” This is also why forge’s stop list and station list are closed.

Someone must clean up, instead of checking the facts. The first waits-file design is the classic case. A wait was real while its entry existed, and one step had to delete it. Every path that skipped that step left a stale wait. The fix: decide from a fact on disk, so nobody has to remember to clean up.

A special case instead of the normal form. The hung agent with its 24 special handlers. The fix: make it a normal parked card with one extra guard.

A warning instead of a refusal. In an unattended run a warning is a message to nobody. The fix: a clear refusal that names the cure, as early as the problem is known.

Holes that were still open

The review also listed gaps in the boundary as of 4 October:

The only path from a parked card to a merged one without a person is one retry for coding problems. There is no automatic re-planning.
Some human actions on parked cards were not yet fully reflected in the run’s own state, so a resumed run could misread them.
The parked-card queue did not yet survive cleanly across runs.
Crash recovery assumed an unattended run; resuming an interactive one could still ask a question nobody was there to answer.

All four were open at the time of the review, and not all of them have closed since. They are here because an article about a boundary that hid its holes would be an advertisement.

10. What it adds up to

The sections above describe forge. This one steps back and asks what the material says about autonomous AI development in general. Each thesis is short enough to argue with, and each is backed by something shown above.

The main work is designing the stops, not the agents. Most of forge’s 171 decisions are not about how agents write code. They are about when an agent must stop, how it reports, and how a person answers. The run in section 1 went well not because the agents were brilliant, but because every failure had a defined place to go. Strong agents with vague stops will hang. Average agents with precise stops will park, report and keep going.
Autonomy is a property of the channel, not of the agent’s good behaviour. You cannot make an agent reliably “not ask” by telling it. You make asking impossible and turn every attempt into a record. Silence is the one forbidden outcome: a hung prompt or a quiet guess is a defect.
Closed lists beat judgment calls. The reasons to stop, the kinds of escalation and the answers a person can give are all short, fixed lists, and changing them is a recorded decision. Open lists never close: every review finds one more item.
Know what is broken before you retry. A generic “retry three times” spends money on problems a retry cannot fix. forge retries once, and only when the code is the problem. A wrong card or a wrong requirement goes straight to a person. This one rule saves both budget and attention.
A hint is not a decision. Cheap signals may speak anywhere. They decide only where a mistake costs less than a person’s time. Where two diagnoses fit, forge records both and picks neither.
Stopping means no new work, not destroying work. Running cards finish. Hung agents are parked, not killed, and their files are protected while they might still be writing.
Facts on disk, not bookkeeping. A step is done when its result exists on disk, not when its process exits. A wait is over when its resolving fact appears, not when someone remembers to delete a note.
A rule in text is a wish. A rule in code is a law. The merge check is a script that the git hook runs again, and overrides are forbidden in autonomous modes by code, not by advice. forge’s own count shows the gap: only half its rules are enforced by code. That half is the part you can trust at 3 a.m.
The person’s answer needs a grammar. Free-text answers caused loops: an alarm “closed” by a comment fires again on the next check. Fixed answers whose effect removes the cause ended the loop. The person is part of the system, and their input needs a format like any other input.
Freedom is earned and measured. Each level of autonomy has measurable entry conditions, and the coordinator never gets more freedom than the part it drives has proven. That makes “more autonomy” a decision backed by data, not by impatience. It also makes the current limit honest: forge is at L2, and says so.
Autonomy has a price, so publish it next to quality. The useful measure is not how much code the AI wrote, but the share of work that reaches the finish without a person, at a fixed level of quality. forge’s share fell from 84–94% to 47–61% after its checks got stricter (harder cards may explain part of it), while zero merged cards were reverted. You can raise autonomy by loosening checks. forge chose not to, and an honest harness shows both numbers side by side.
The person approves the result. They do not rescue the run. This is the L4 goal and the test for every design choice. A good unattended run is judged by what the person finds when they come back: parked cards, each with a station, a reason, ready options and a recommended one. The busy morning of 22 September cost five decisions, but none needed detective work.
Every rule keeps its reason. Each boundary rule comes from a decision record that names the rejected options. When a rule fails, as many first versions above did, the record shows what was assumed and what to change.

What remains unknown

Whether forge works as well on other teams’ code. The L3 and L4 pilots have not happened yet.
Which explanation of the drop in untouched cards is right: stricter checks or harder cards.
How much the remaining text-only rules are actually followed. forge plans to measure this, with a fixed ceiling on skipped steps.

Afterword

forge’s boundary is narrow today. One automatic redo, three ways to stop, human merges by default, and a person still needed for about half the cards. That is not a weakness to hide. It is the current position on a scale that forge defines, measures and publishes. The goal is not to remove the person. The goal is to move them from rescuing runs to approving results, one measured step at a time, without giving up the zero on the revert counter.

Every rule above comes from a written decision record in forge’s repository, each naming the options it rejected. The run logs and process review quoted here are internal; the numbers are reproduced as recorded.