Learning to Think in Terms of Ideal State Articulation

How many goals did you write down this year? How many of them could you prove you finished? And how many could be satisfied by, honestly, almost anything?

I’ll go first. For most of my life, nearly everything I called a goal lived in that third bucket. “Get in shape.” “Be more present.” “Fix onboarding.” They felt productive to write. They read like decisions.

They were wishes.

I’ve been working on a practice that fixes this, and it has a name that sounds fancier than it is: ideal state articulation. The idea is simple to say and surprisingly hard to do: describe the future you want in terms specific enough that the description can fail. This post is my attempt to teach the practice the way I wish someone had taught it to me.

A goal that can’t fail can’t finish

The clearest lens I’ve found for this comes from David Deutsch, a physicist at Oxford, in his book The Beginning of Infinity. Deutsch asks what separates a good explanation from a bad one, and his answer is that good explanations are hard to vary.

His example: the ancient Greeks explained winter with a myth. Persephone is taken to the underworld for part of each year, her mother Demeter grieves, and the world goes cold. The interesting problem with the myth isn’t that it’s wrong (it is). The problem is that it’s easy to vary. Swap the goddess, swap the grief, swap the underworld for a sabbatical, and it “explains” winter exactly as well as before. A story you can rearrange freely isn’t explaining anything.

The real explanation, the tilt of the Earth’s axis, is the opposite. Every part is load-bearing. Change any detail and it stops matching what we observe, starting with the fact that winter in Greece is summer in Australia (a test, by the way, that the myth flunks: Demeter’s grief would chill both hemispheres at once).

Now hold your goals up to that same light. “Get in shape” is Persephone. It can be satisfied by three gym visits in January, or by a pants size that changed because of the dryer. Nothing about it can fail.

And a goal that can’t fail can’t finish, either.

Describing the world after it works

I picked up the repair from Daniel Miessler, a security researcher who has spent years building open-source systems for running your life with the help of AI. Strip away the tooling and his core practice is older than any of it: write down, in plain words, the ideal state of each thing you care about. What does your health look like when it’s right? Your product? Your Saturday? Improvement, in any domain, is then one repeatable move: describe the ideal state, describe the current state honestly, and work the gap.

Ideal state articulation is that first step done with Deutsch’s standard applied to it. You’re not listing tasks, and you’re not writing an affirmation. You’re writing an explanation of “done” that’s hard to vary: specific enough that changing any sentence would change what you’re actually pursuing.

Three properties separate a real articulation from a wish.

You can name the failure. Every claim in the articulation should be testable. “I sleep better” is decoration; “I’m off screens by ten, six nights out of seven” is a claim, because you can say exactly what falling short looks like. Testability and hard-to-variability turn out to be the same property viewed from different angles: a sentence you can’t test is a sentence you can vary freely, which means it isn’t holding anything up.

It says what the thing must not become. I think of this as the anti-vision, and it’s half the work. The home gym that must not become storage. The new feature that must not add a login step. The side business that must not eat Saturdays. Naming the failure modes you refuse, in advance, is what keeps the ideal state from quietly mutating into whatever you happened to get. An articulation with zero named failure modes isn’t finished being written.

It tightens as you pursue it. Your first articulation is a guess. That’s fine; it’s supposed to be. You’ll start moving toward it, reality will push back, and you’ll discover that one sentence was naive and another mattered more than you knew. Revising the articulation isn’t a failure of planning. It’s the point. You’re improving your description of done until you’d recognize done on sight.

There’s a pocket-sized test for all three: could a stranger, reading only your articulation, judge a year from now whether you got there? If the honest answer is “sort of, depends,” you wrote a wish. Rewrite until the answer is yes or no.

Isn’t this just a PRD?

If you build software for a living, an alarm may be going off right now. Is this just a product requirements document (a PRD, the spec sheet that kicks off most software projects) wearing a philosophy degree?

Not quite, and the differences are where the value lives.

The trouble with the PRD as a genre is threefold. It’s written once, at the beginning, which is the moment you know the least. It mostly describes what will be built (features, behaviors, deliverables) rather than what will be true once it works. And its verification lives somewhere else, in a test plan or a QA checklist that ships separately and drifts independently. Every working engineer has watched a team satisfy every line of a requirements doc and still miss the point, while the doc went quietly stale by week three. Not because product managers are bad at their jobs; because the genre never asks for falsifiability.

Spec-driven development gets closer, and I respect the move. In SDD the spec is meant to be a living source of truth: code and tests are held to it, and increasingly generated from it, so the document and the system can’t silently drift apart. That fixes the staleness problem. But it inherits two limits. It only lives where code lives (you can’t spec-drive your health), and its unit is still the feature list, so “passes every spec, misses the point” remains an open door.

Ideal state articulation keeps the best idea in SDD (the document is the harness, not a memo) and generalizes it. The unit isn’t a feature set; it’s the ideal state of anything: a product, a body, a budget, a garage. Every sentence carries its own test. And the document is explicitly an instrument for learning: you expect to revise it on contact with reality, which nobody expects of a contract.

Put the three side by side. A PRD describes what to build. A spec describes how to verify what you built. An ideal state articulation describes the world after it works, in terms that can fail.

Say it out loud first

Now, the part that changed how I actually practice this: the first draft of an articulation should be spoken, not typed.

Speech forces you to linearize. On paper you can leave a flabby phrase sitting mid-paragraph forever; out loud, you hear the hand-waving the moment it leaves your mouth. Programmers know this effect as rubber-duck debugging (explain your bug to a duck on your desk, solve it mid-sentence). The same trick works on your future.

So the loop I’m building my practice around is: verbalize, capture, process, refine. Speak the articulation the moment the thinking is hot, wherever you are. Capture the raw words. Process them later at a desk, when the editor in you is available. Refine over weeks, as pursuit teaches you what you actually meant.

When I verbalize one, I aim for four beats:

• The friction. What specifically is broken? Not “I should sleep more” but “three nights a week I’m up past one, and the next morning is a write-off.”
• The felt end-state. What would it be like if this were right? What would genuinely surprise me with delight?
• The verifiable done. One to three sentences a stranger could judge later.
• The refused failure mode. What this must not turn into.

Ninety seconds of talking. That’s a complete rep. (This practice, incidentally, is why I’m about to start talking to a necklace.)

Reps

That’s the whole practice, and I won’t pretend I’m an expert at it yet. My earliest use is in building software, but I’m beginning to expand the practice to the rest of life. That said, this process trains exactly like a muscle, because that’s what it is. Each spoken articulation is one rep, each refinement is one more, and the standard (could this description fail?) never changes while the skill slowly does.

Pick one thing today. Your product, your health, your garage. Say what done looks like, out loud, in terms that could fail.

Then go make it true.