Systematise Decisions, Not Actions

I spent an afternoon building a personal knowledge system. By the end I had: a memory file, a vault note, three prospective triggers, a new step in my wrap-up routine, and a published blog post. Five layers of persistence for a single insight.

The insight was about career direction. One conversation, one realisation, five systems.

Then my AI assistant asked: “Are we doing real things or just looking useful?” And the honest answer was: mixed.

The wrong instinct

Builders systematise. That’s the instinct — if something matters, build a system for it. Automate, schedule, trigger, review. The instinct is good when applied to the right target. The problem is what we choose to systematise.

Most systems target actions: how to file notes, how to format commits, how to run deployments. These are mechanical. They benefit from consistency, but the cost of doing them wrong once is low. You redo it and move on.

The expensive mistakes are decisions: where to save an insight (one layer or five?), whether to build a tool or use an existing one, which tasks to prioritise, when to stop researching and start building. These recur constantly, have compounding consequences, and — critically — have wrong defaults that feel right in the moment.

The pattern

After building those five persistence layers, we stripped three. Then we noticed: the decision about how many layers to build was the thing worth systematising, not the layers themselves.

This keeps happening. The action is obvious. The decision buried inside the action is invisible:

  • Filing a note is an action. Deciding whether this note duplicates an existing one is a decision.
  • Writing a test is an action. Deciding whether this scenario is worth testing is a decision.
  • Building a tool is an action. Deciding whether this problem recurs enough to justify a tool is a decision.

The actions are cheap. Run them again tomorrow, no damage done. But a bad filing decision means you search three places and trust none. A bad testing decision means you maintain tests for impossible scenarios. A bad tooling decision means you maintain a system that exists to maintain itself.

What to systematise

The test: have I gotten this decision wrong more than once, and would seeing five heuristics at the decision point change the outcome?

If yes, put the heuristics where the decision happens — not in a reference document you’ll forget to check, but wired into the workflow at the exact moment you’re about to decide.

If no, it’s either a one-off (learn and move on) or an action (make it consistent, but don’t overthink it).

The instinct to build systems is correct. The instinct about what to build them around is usually wrong. We systematise the mechanical parts because they’re visible. The judgment calls that actually compound stay invisible — made on gut feel, reinforced by habit, never reviewed.

Actions are cheap to redo. Decisions compound. Systematise accordingly.