A public ledger of the automations I deliberately did not build — and the exact condition that would change my mind.
为无为，则无不治。Wéi wú wéi, zé wú bù zhì."Practice non-action, and nothing is left ungoverned."— 老子《道德经》第三章 · Laozi, Dao De Jing, ch. 3
Everyone at an AI conference is showing you what they built. This is a page about what I refused to build, on purpose, with the reason written down next to each refusal.
I keep two queues. One is the list of things to build — the backlog, the roadmap, the wishlist every builder has. The other is this one: the list of things I decided not to build, and why. The second list is younger and shorter and much harder to keep honest, and it is the one I would defend first in a governance conversation. Because the failure mode of a capable AI ecosystem is not that it builds too little. It is that it builds everything it can imagine, until the system collapses under its own surface area. The scarce discipline is restraint.
无为 is not "doing nothing"
There is a Daoist idea, 无为 — wúwéi — that a Western reader almost always mistranslates as passivity or laziness. It means the opposite of laziness. It means non-forcing: not imposing an action where the situation does not call for one, not adding structure the system will have to carry forever to solve a problem it does not yet have. The load-bearing distinction — the one that kills the misreading on contact — is 无为 ≠ 不作为: non-forcing is not dereliction of duty. The Daoist claim is that a great deal of what looks like governance is actually just intervention that made things worse, and that the harder, higher skill is knowing when not to act.
无为不是无所作为，而是不妄为、不强为——顺势而为，不横加干预。"Wúwéi is not inaction or idleness, but refusing to act arbitrarily or by force — moving with the grain of things, not imposing interference."
An automation is an action that keeps happening after you stop paying attention. That is its whole value and its whole danger. Every one I add is a standing intervention I now have to maintain, reason about, and eventually untangle from everything it touches. So the question is never only "could I build this?" — the answer is almost always yes. The question is "should this exist, and what happens to the system if it does?" Most of the time the honest answer is not yet, and here is precisely what would change that.
That last clause is the whole game. A refusal without a trigger is just a graveyard — a list of dead ideas nobody revisits. A refusal with a named trigger is a live position: it says I looked at this, I decided against it, and I know the exact signal that would make me reverse. That is what turns "no" from avoidance into governance.
The ledger
Four active refusals. Each carries a status:
held I'd build it, waiting on a trigger · declined actively chosen against · declined-approach doing the thing, but not this way · not-now a later phase, deliberately parked
1 · A central "voice broker" skill
held
The idea: one top-level service every specialist agent queries first to learn my tone, my decision-style, my voice — so nothing ships off-voice.
Why not nowThe voice rules already live in three places that cover most of it — a character file, a working-style file, and per-surface rules (my parents get one register, financial reports get another, and "don't write like an assistant" is enforced everywhere). A fourth central copy is the classic trap: it becomes a fourth source of truth that quietly drifts out of sync with the other three, and now I have a consistency problem I didn't have before. Net loss.
What would change the answer(a) a specialist visibly ships off-voice work that traces to context the other three files didn't carry, or (b) I'm already consolidating those voice rules for some other reason — at which point I fold the broker in, rather than adding it.
2 · A "Studio OS" rebuild of the whole vault
declined
The idea: a manifesto I admired describes an "operating system" for a creative studio; treat it as a mandate to restructure my entire system into a named, branded "Studio OS."
Why notMy system already works the way that manifesto only aspires to — capture, specialist agents, self-healing jobs, a portable plain-text substrate. A top-to-bottom reorg to earn a banner name would be the exact over-build the manifesto itself warns against. Renaming a working thing to match an inspiration is not architecture; it's cosplay.
What would change the answerNothing, as a blanket reorg. Only ever surgical, single-surface changes with a named gap — and those never need a "Studio OS" label to justify them.
3 · A schema change to add loop "states"
declined-approach
The idea: my task-tracking format needs a richer status vocabulary (a loop can be alive, resting, waiting on someone, or needs my decision). Build it by changing the underlying loop schema.
Why not this wayI'm doing the thing — the states are real and useful. But they ship as additive tags on top of the existing format, specifically so I never touch the load-bearing parser or the checkbox format the whole system reads. I've been bitten here before: a format that looked correct but silently broke the reader once left 44 tracked items invisible to every surface that counted them. A schema change to add a feature is not worth reopening that class of bug.
What would change the answerThe lightweight tag approach proves genuinely insufficient for a real filtering or roll-up need that tags cannot express.
4 · Broadening the test-first build rule to every script
not-now
The idea: I have a rule that new tools must be built test-first. Extend it immediately from its current scope (skills and commands) to all scripts and automation hooks.
Why not nowThe current-scope version just shipped. Broadening the mandate before the narrow version has proven itself is exactly the premature-scaling instinct this whole page exists to resist. Prove it works small, then widen.
What would change the answerThe narrow rule fires cleanly across at least three real builds with no false positives.
Graduated / reversed
(When a trigger actually fires and a refusal becomes a build, it gets logged here with the date — so the ledger keeps an honest record of its own hit rate, not just its restraint.)
None yet. The ledger is new. That the "reversed" column is still empty is not the point — the point is that it exists, and that every "no" above is written to be falsifiable.
Why a refusals ledger is the governance artifact
Governance frameworks are mostly written as permission structures: here is how we decide what we're allowed to build, here are the guardrails, here is the review gate. This is the mirror image. It is a refusal structure — a standing, public, revisable record of the things a capable system chose against, each one carrying the falsifiable condition that would overturn it.
It borrows a line from Casey Simone's "Studio OS" note, which is the thing that made me start writing these down in the first place: the refusals are not laziness — they are how the fantasy stays grounded. An ambitious system needs a brake that is as legible as its accelerator. Anyone can show you a roadmap. The harder thing — the thing that actually signals a system is under control rather than merely capable — is to show you the roads you decided not to take, and hand you the map so you can check the reasoning yourself.
That is 无为 as an engineering practice: not the absence of action, but the disciplined, documented choice of where not to act. At a conference about governing artificial intelligence, I think that is the most honest page I can put on the table.
道常无为而无不为。"The Way does nothing, and yet nothing is left undone." — 《道德经》第三十七章The most governed system is the one that knows where to stop.