Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Libraryoutcomes and systems / 2026-08-04

Define Done as Thinking

Defining the outcome is not a form you fill in after you open the chat. It is how you decide what the work is.

8 parts / Hover to explore. Click to read.

Defining the outcome is not a form you fill in after you open the chat. It is how you decide what the work is.

What must exist?
        +
What evidence would prove it?
        +
What would make you reject it?
        |
   acceptance conditions
        |
      build -> check
Defining done makes a result recognisable and rejectable. Choose evidence that supports the actual claim, rather than treating one kind of check as proof of everything.
Context Pack (for agents)

“Make it feel premium.” Fine. What would that look like when we open it?

Would you recognise it from the type, the spacing, the way it moves? Is there a reference? Are there things that would immediately make you say no?

Those questions are already part of the build. I want to answer them before I ask a model to start making things.

This essay is about deciding what the work is. For a sequence you can practise with a real product, there's Define outcomes, then build digital products.

Start with a result you can recognise

“Write me a landing page.” “Fix the auth.” “Make it feel premium.” They all tell you roughly where to go. They leave quite a lot for someone else to decide.

I treat defining done as the first bit of craft. A director needs to know what the shot is meant to achieve before asking everyone to make it. The same applies here.

You don't need to describe every keystroke. You do need to know what you're going to accept.

If you can't explain that yet, spend a bit longer on it. You are doing the work. You're giving the next stage something useful to act on.

Answer three questions

What must exist? Name the thing or the behaviour you expect. A file, a route, a render, a working sign-in. Something another person can open, use, or inspect.

What would prove it? Decide what you'll check. That might be a test result, a screenshot, a measurement, a diff, or walking through the actual page. Pick evidence that matches the claim. A screenshot cannot prove a sign-in works.

What would make you reject it? Write down the failures that matter. The wrong audience. Copy that sounds nothing like you. A green report and a black screen. A tiny fix that has somehow become a new product.

What exists, what proves it, and what you won't accept. Those three questions are enough to get started.

Try it on an ordinary request

Say you're fixing sign-in. “The auth works” still leaves room for a lovely misunderstanding.

You could make it checkable: an existing user can sign in and reach their dashboard; a signed-out visitor is sent to sign-in when they open a private page; signing out ends that access.

Then actually try those paths. Check what happens when sign-in fails, too. Decide whether the result works from what you observe.

The point is to make the judgement available before the model does the work. It shouldn't have to guess the test after it has already chosen the answer.

Let the definition shape the job

A template can help you organise this. Filling one in doesn't automatically make the thinking happen.

The useful bit is being able to say, “I can accept or reject the result now.” That changes what you ask for, which files you provide, and where you stop.

If the definition only appears at the end, it hasn't helped direct the work. It has given you something tidy to attach to it.

A clear result often makes the prompt shorter. You can ask for the work directly because the project already explains what good looks like.

When you keep rewriting the prompt

You add another adjective. Then “make sure”. Then another paragraph explaining what you really meant. Maybe you try another model.

Have a look at the missing decision first.

The model may have made a perfectly reasonable interpretation of an unclear request. That can still waste your evening. A junior on a set could make the same wrong shot from the same brief.

Write down what you expected and what made this result fail. Give that back as a concrete correction. It is much more useful than asking for “better” again.

Keep the wider project in view

This is the first part of Context Is King: decide the outcome before you polish the prompt.

The other part is Hold the System. Once you know what the result should be, work out the inputs, saved state, feedback, and judgement that will get you there.

The earlier version of this idea is Stop Prompting. Start Defining Outcomes.. For ordered practice, use the product-building course.

Before you start

Write three short lines: what must exist, how you'll check it, and what would make you reject it.

If someone else can use those lines to assess the work, you're ready to give them the job. That includes Claude.

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 10