Kill criteria for the parallel arm

A parallel research arm is easier to start when you've already decided how to stop it. That sounds backward. It isn't. The reason most operators never start the arm at all is that starting feels like a permanent commitment, and a permanent commitment to a side project is a thing the operator's gut correctly resists. Kill criteria invert the math. Once you've written down the conditions under which the arm goes dormant, starting becomes a tractable decision rather than an open-ended one.

I wrote Parley's kill triggers into the project material on day one, before any notebook. The arm has run for several months on those rails and has not tripped them. That's not luck. It's the rails working as intended — they tell me, in real time, whether the arm is still serving its purpose or has quietly become a different thing.

The claim

Kill criteria are what make a parallel arm psychologically safe to start. Without them, starting a side research project commits you to an unbounded future obligation, and the unbounded version of that obligation is what your operator brain refuses to take on. With them, starting commits you only to the rails you wrote down.

This is the opposite of the common framing, which treats kill criteria as a sad eventuality to plan for. They aren't sad. They're the enabling condition. The first useful thing a kill-criteria document does is let you say yes to the project at all.

Three triggers, named up front

Parley runs on three explicit pause triggers. Other arms will need their own list. Three is roughly the right number — fewer and you'll miss a class of failure, more and the list stops being something you re-read.

The first trigger is cadence failure. Two consecutive months with no notebook published, for any reason. Not a single missed month — life happens, calendars compress, the first miss is a signal but not a kill. Two in a row means the arm has lost the publishing loop, and the publishing loop is what was making it real (see Lesson 7 on why the public loop is load-bearing). When the loop fails twice, the arm is on ice.

The second trigger is cannibalization of the main work. The Parley brief is explicit: any QC [URGENT] heat (Crave, the patent, the SBA loan, the smart-board demo) pauses the arm without guilt. The threshold is that the main venture slipped *because* of cycles spent on the arm. Not that the main venture slipped at all (that has many causes). That the arm took the cycles that should have closed the gap. If you find yourself defending evenings spent on the arm against deliverables that didn't ship, the trigger fired and you missed it.

The third trigger is scope drift toward productization. The signal is concrete: you opened a document titled something like "should we productize this?" That document is the trigger. You don't need to finish writing it. The fact that you started writing it means the arm has stopped being an arm and is now in a different mode, and the right move is to put the arm on ice while you decide what the new mode is. Lesson 3 in this track (the "won't become a product" rule) covers why this matters; the kill criterion is what enforces it when enthusiasm forgets.

What "kill" actually means

The word kill is wrong for what the document does. The arm goes on ice. Dormant. The repo stays where it is, the published notebooks stay published, the wiki pages stay in the substrate. Nothing is destroyed. The active publishing cadence stops, and a decision log entry records why.

The Parley decisions log is the place that record goes. The log is a chronological list of one-paragraph entries, each dated, each citing the reason and the artifacts that triggered it. If a kill fires, the entry would read something like "2026-Q4 — arm on ice. Trigger: two consecutive months missed (September, October). Cause: Crave install consumed September weekends; October consumed by patent filing. Restart allowed when QC heat clears." The format is mundane on purpose. A kill that is logged like any other decision is a kill that can be reversed when conditions change.

Restart is allowed. That's the part of the rule that does the most psychological work. The arm is not over because it goes dormant; it's resting. When the conditions that triggered the pause clear (the urgent main-venture work lands, the cadence becomes possible again, the productization question gets decided one way or the other) restart is a fresh decision logged the same way. Most arms that go dormant in operator portfolios never restart, and that's fine too. The point is the option exists, written down, instead of being a vague feeling about whether the project is "dead" or not.

Why writing it down up front matters

At the moment the trigger fires, you will not be in a clean position to evaluate the trigger. You will be inside the situation that created it. The patent filing will feel like the exception that justifies a third missed month. The "should we productize?" document will feel like prudent strategic thinking. The cannibalization will be invisible to you because every individual evening on the arm felt productive in isolation.

This is the operator's version of a known cognitive trap. Decisions made under pressure, with skin in the game, by the person whose recent choices created the situation, are reliably worse than the same decisions made cold by the same person at a quieter moment. The advance commitment is the third-party check. It's the past version of you, who had no enthusiasm to defend and no sunk cost to honor, telling the present version of you what the trigger looks like.

Parley's brief and roadmap together name all three triggers in plain text. When the moment comes (and on a multi-year arm it will come) the document does the noticing for me. I don't have to be the one who realizes the second month has slipped. The roadmap's monthly check-in catches it. I don't have to be the one who flags the productization drift. The brief's "NOT in scope" block flags it the moment I notice myself writing the wrong kind of document. The advance commitment is doing the cognitive work that the in-the-moment version of me is structurally unable to do.

This is the same logic as a sprint contract: pre-commit to what done looks like before any code is written, because the version of you writing the evaluation later cannot be trusted to grade the version of you that wrote the work. The kill-criteria document is the sprint contract for the arm itself.

Apply this

Open your arm's project brief and your roadmap. If they don't exist, build them before you write a kill-criteria block — the kill criteria reference the cadence and the scope, so those documents have to exist first.

Write three triggers. Pick from this menu or substitute your own:

Cadence failure with a specific count (two missed months, three missed quarters, whatever your cadence implies). Be concrete about what counts as a miss.

Cannibalization of the main work, with the test being that the main work slipped *because of* the arm's cycles — not that it slipped for any reason. Name the venture, name the heat that would qualify, name the deliverables that would be the evidence.

Scope drift toward productization, with the signal being a specific artifact (a "should we productize?" doc, a pitch deck draft, an outbound email to a potential customer). Pick the artifact that fits your domain.

Then commit the block alongside your scope rails. Date it. Cite it on day one in your decision log so future you can find it without searching. The next time one of the conditions fires, the document is the answer. The cost of writing it now is twenty minutes. The cost of not writing it is the half a year you'll spend pretending the arm is still healthy when it isn't.