A portfolio of experiments with a death criterion declared in advance
Teams keep ideas alive because nobody decides they are dead. We track initiatives as a population: each states its success metric and the fact that would kill it before it starts, there is a cap on running trials, and an overdue trial must be decided, not left hanging.
π― For A team lead who runs many parallel ideas, experiments or side projects
- A registry where every initiative has a fitness metric and a cull criterion
- A cap on parallel trials and a rule against leaving them to hang
- What the real numbers look like, including where the rules strain
π± The problem with ideas that never die
Every team has a list of ideas in progress. Most of them are still there months later, because no one wrote down what would count as a failure. Without that, effort goes to the loudest idea and nothing is ever stopped.
π The laws
Our registry treats initiatives as a population that moves through states: hypothesis, trial, then selected or culled. Four laws apply.
- Success metric and kill criterion are written before the start, not after the result.
- At most eight trials run at the same time. A ninth needs a written exception from the operator, with a name and a date.
- A trial older than its maximum age is overdue and must be decided: selected or culled. "Let it hang" is not an outcome.
- A culled initiative must leave an autopsy. Nothing is deleted from the registry.
The decision to cull always belongs to a person. The registry produces the list, and a weekly report names what is overdue.
π What it looks like today
On 3 November 2026, 21:53 UTC the registry held 142 initiatives: 122 hypotheses, 9 trials, 4 selected and 7 culled. Among those that have reached a decision, 4 of 11 were selected, a survival rate of 36.4 percent. All 142 entries have a fitness metric and 136 have a cull criterion.
The numbers also show where the rules strain. There are 9 trials, one above the cap of eight. That is the single named exception recorded by the operator on 13 September 2026, and the validator accepts it. And the weekly report lists 7 trials as overdue, waiting for a decision. A rule that says "decide or cull" produces a list of undecided cases when nobody decides, and showing that list is the point.
π οΈ Practice: start a registry
- Create one file with one record per initiative: key, title, birth date, state, spec link.
- Add three required fields: fitness metric, fitness target and cull criteria. Refuse records without them.
- Add a maximum trial age in days, with a default.
- Write a validator that fails on a missing field, an unknown state, more than the allowed number of trials, and a deleted record.
- Produce a weekly report of overdue trials and put it on the agenda of a standing meeting.
- When something is culled, write a short autopsy: what we expected, what happened, what we learned.
β Check yourself
- Add a record with no kill criterion. The validator fails.
- Move a ninth initiative to trial. The validator fails unless an exception is named.
- The weekly report lists overdue trials by name and age.
- You can show three culled initiatives with an autopsy each.
π§ When this does NOT work
- Metrics chosen after the fact. If the metric is edited once results arrive, the registry is theatre. Freeze it at the start.
- Overdue lists nobody reads. The report must be discussed in a meeting, or it is a graveyard.
- Population of hypotheses. Most entries sit at the first state. Many hypotheses and few decisions means the intake is too easy.
- Vague kill criteria. "If it does not work" is not a criterion. Name a number and a date.
- Small teams. For five people a registry may be too heavy. A shared page with the same three fields is enough.
π Evidence
| What we measured | Initiatives by state, entries with metric and kill criterion, overdue trials, and the trial cap |
| When | 3 November 2026, 21:53 UTC |
| Artifact | Our evolution registry file, its validator and weekly report in our private repository; the validator has 9 tests |
| Limit | Survival rate is computed over decided initiatives only. It is a small sample and not a promise about any new idea |
β‘οΈ Next
Write the spec for an idea with Spec-driven development with existing task packets, and see how we judge results in AI judging.
Sources
- Spec-driven development with existing task packets: specs.
- AI judging: why βit says it is doneβ is not acceptance: judging results.
- Costs, budgets and limits: budgets.
- An AI usage policy and register a small team can enforce: registers.
π Article connections
Open the full knowledge graph βPublished article links. Select a node to open its article at the heading.
Article links Β· keyboard / text view
Same topic
- A vector base is a map, not a source: what we learned from retrieval
- When you cannot tell what a model call cost: freeze, then reconcile
- Splitting a big task for a cheap model: the 24,000-byte lesson
- Skills, MCP tools and rules: three ways to give an agent capabilities
- Eight shell and git mistakes our agents made, and the rule for each
- Several agents, one repository: ownership rules from real incidents
Next steps
Related reading
A vector base is a map, not a source: what we learned from retrieval
A vector base finds passages that are close in meaning to your question. It does not know which are true or current. Treat every hit as a pointer: open the file it names, check the hash, and take numbers from the artifact, never from the retrieved paragraph.
AI agents and MCP explainedWhen you cannot tell what a model call cost: freeze, then reconcile
Sometimes a model call times out and you do not know whether the provider charged you. Never record that as zero. Mark it uncertain, stop new paid calls, and let a named person reconcile it with the provider's statement. Refusals before generation are the exception.
AI agents and MCP explainedSplitting a big task for a cheap model: the 24,000-byte lesson
A cheap model does well on one small, well-defined job and badly on a big pile. We cap a task at 24,000 bytes and refuse larger ones before any model is called. Split by unit, one file or one country per task, and check the size before you start.
AI agents and MCP explainedSkills, MCP tools and rules: three ways to give an agent capabilities
Agents get abilities in different ways. A rule constrains what they do, a skill tells them how to do a job, and an MCP tool lets them call a function. Each has its own risk, so declare all three in a register and test that nothing exists unlisted.
π¬ Comments