Weakest Sufficient Beats Clever Process

Clever process feels smart. It also fails on Tuesday.

We run Muchiround with one human CEO and a set of Hermes department profiles. Coordination is real work: Basecamp for humans, Kanban for agents, product merge gates, Kamal deploys, shared test DBs. After two weeks of dual owners, overfit SPECs, and status comments spawning epics, we stopped asking “what is the shortest playbook?” and started asking a different question.

Among the process rules that still hold under our axioms, which is the weakest that still works on the next novel ask?

That question comes from Bennett (2023): for hypothesis selection, maximising weakness among valid models maximises the probability of generalisation — and compression is neither necessary nor sufficient for intelligence. We treated company ops the same way. This is the field note.

What “weak” means here

Weak is not sloppy. Weak means the constraint admits more valid futures without breaking the load-bearing physics of the business.

Strong (overfit)	Weak (sufficient)
14-step deploy runbook for one outage shape	One kamal owner + smoke checklist
Multi-rev SPEC thrash same day	One weak SPEC + a decision-log flip
Dual CI runs because two sessions care	Claim-first or monitor-only — never both
New Kanban epic for every status ping	Answer on Basecamp unless build is ordered
“Skip CI — urgency”	Written CEO waiver only

Weak process still has teeth. Ours still refuses: fabricated results, direct commits to product/company mainlines without PR, merge without local bin/ci + signoff, agent handoffs routed through Basecamp instead of Kanban.

The paper, without the mysticism

Bennett’s result is about hypothesis classes and prediction. The ops translation we use is blunt:

1. Delete invalid paths (Algorithm: question → delete → simplify → accelerate → automate last).
2. Among what remains valid, pick the constraints with the widest valid extension — they cover novel CEO asks without a new ceremony.
3. Do not equate shorter docs with better ops. A three-line rule that only works for one incident is strong and brittle. A slightly longer rule that covers claim races, deploy ownership, and status thrash is weaker and more useful.

We wrote this down as POLICIES/ops-generalisation.md and a charter section. Policy without enforcement is diary. Enforcement is comments on dual-owner cards, Monday brief lines, and completions that get marked process defects when they dual-ran CI against an active claim.

Five rules that survived delete

R1 — Weakest sufficient brief

Kuda prefers outcome + constraint + definition of done over implementation recipes. Agents who get an overfit brief are expected to question and propose weaker acceptance criteria before building. Product prefers one weak SPEC over same-day multi-rev thrash; material flips go in the decision log once.

If you are writing process for an agentic team, this is the highest-leverage line. Overfit briefs manufacture thrash faster than slow models do.

R2 — One owner per ship unit

This is the rule that pays rent every day.

• Webhook lands a card for the current profile.
  • CEO said ship / close / into production → claim-first in this session. No parallel dispatcher bin/ci.
  • Otherwise → monitor-only: route, comment, do not dual heavy work.
• Product merge still requires local CI + gh signoff (empty checks are not green). Weak process never waives that.
• Deploy: one Kamal owner. Default Anton after merge. Nick sole-owns only when the CEO ordered close-on-this-todo and this session claimed.

Two sessions both running RSpec on the shared test DB is not thoroughness. It is a self-inflicted flake factory.

R3 — WIP soft caps

At most two heavy running eng tasks per profile when work contends on shared test DB or deploy host. Coordination cards can stack; full CI and Kamal cannot thrash the same box.

R4 — Weekly generalisation check

Every Monday brief, three lines:

1. Novel CEO asks that landed without new policy
2. Friction that forced a more brittle process — delete candidate
3. Hard-line blockers older than seven days (keys, CEO go, contracts)

If you never measure generalisation, you only notice process when it fails loudly.

R5 — Spec and decision strength

Prefer physics-level constraints — money-gem as wallet SSOT, LNR path, one external-fiat process convention — over procedural laundry lists. Frozen non-LNR scope stays frozen until written override or proof floor.

A concrete failure mode we killed

Symptom: Basecamp comment from the CEO. Webhook Nick creates a Kanban card assigned to default. Within one gateway tick, a dispatcher worker claims it. Chat Nick also starts bin/ci. Shared Postgres test template dies. Both sessions “own” the fix. Neither finishes cleanly.

Strong fix people reach for: more locks, more status boards, more “please wait” ceremony.

Weak fix we shipped: two modes only — claim-first ship, or monitor-only route. Comment ownership on the card immediately. Linked brainstorm children under an open parent stay blocked (parents_not_done) — so for time-bound cadence (Thursday articles), unlink or lock the topic after a short window instead of stalling the publish.

Same pattern shows up on dual Kamal after a merge: one owner deploys; the other smokes only if needed. Two deploys is not high availability.

How to install this on your team

You do not need our stack. You need selection discipline.

1. List the hard lines you will not weaken. Ours: axioms, merge gate, PR-by-default, Kanban/Basecamp split, no fabricated results. Write them once.
2. For every recurring friction, draft two processes — the clever one and the weaker one that still catches the defect. Ship the weaker one.
3. Name a single owner per ship unit before work starts. Claim is a verb, not a vibe.
4. Ban dual heavy paths on shared environments. Second session comments; it does not open a second CI.
5. Run a weekly generalisation check. Three lines. Delete one brittle rule per month if you can.

// Mental model (not code)
valid = axioms ∩ hard_lines ∩ definition_of_done
candidates = processes that keep every task in valid
choose argmax extension(candidates)   // weakest sufficient
// do NOT choose argmin word_count(candidates)

What we refuse to call “weak”

• Skipping CI because the outage stopped
• Direct commit to master because the doc is small
• Routing eng handoffs through the human board “for visibility”
• Inventing results when a source is blocked
• Dual owners “just this once”

Those are not weak. They are invalid. Bennett’s selection rule only applies among valid hypotheses. Invalid shortcuts do not generalise; they teach the org that gates are optional.

Why this is a client trust signal

Consulting shops sell frameworks. We sell that we will delete ceremony that does not generalise and keep the gates that protect production money and data. Terrain-honest process is part of the product when you operate in African market constraints: shared boxes, expensive minutes, real FX rails, small teams.

If you want the dense version we run internally: one owner, weakest sufficient brief, merge gate intact, weekly delete candidates. Clever can wait.

What’s next

We still overfit. Agents still open dual paths under time pressure. The point of writing the rule is not purity — it is a shared vocabulary for “this card is a process defect” without turning every incident into a new 20-page runbook.

Next time your team reaches for a cleverer checklist, ask: is this the weakest rule that still holds when the CEO asks something we have never seen? If not, delete until it is.