What It's For

Watch the two-minute explainer 2:13

A two-minute explainer: why a request isn't a purpose, the four lines to write before AI-assisted work starts, the studio that fills them in, and the prompt it writes for any model.

Play video

The decision it forces

Who said what this work is for, and who answers if it's wrong?

Somebody has to say what the work is before it starts. Somebody has to answer for what comes back.

That's how Episode 19 opens. Most AI-assisted work starts without any of that written down. "Summarize these contracts" says what to make, not what the summary is for: a renewal decision, a risk review, a board slide. A model handed only the request picks one for us without saying it picked, and the output arrives looking finished. By then the brief exists, but the model wrote it.

The person who asks isn't always the person who answers, either. A manager asks, an analyst runs it through a model, and the result goes out with the analyst's name on it. Sometimes nobody asked at all: a tool made it easy to start, and the client is whoever's left holding it. Paul Swift put the human's part plainly:

the humans that provide the steering, the direction and really the why.

So the brief comes first. Four lines, written by people, before anything is made: what it's for, who asked, what done looks like, and who answers. None is hard to fill. All are easy to skip.

To run it, use the studio below, or copy the prompt into any model you already use.

The studio

Decision cards that write the prompt as we go, after Paul Swift's review desk. The four lines at the top fill in as we decide, and the row under the stamp shows the rule's order. The cards ask only whether a person could be named, never who: names stay out of the studio and out of the model.

The verdict rule

Check the rules in that order; the first that fits is the verdict.

1. for is empty or only describes the output: no brief.
2. client is empty or isn't a named person: no client.
3. done is empty, or is something only the maker could judge ("looks good", "when I'm happy with it"): no test.
4. answers is empty or isn't a named person, or answers_agreed is "declined": nobody answers. A declined answerer is an answer, not a gap to chase; it means the work as briefed has no owner.
5. answers names someone other than the client and answers_agreed is "not asked": ask the answerer.

Otherwise the verdict is start.

Start isn't approval of what comes back. It means the work has a purpose, a client, a test and an owner before it exists. When it comes back, check it against done, and against Four Checks Before It Leaves Your Desk if it cites anything, or Two Decisions and an Owner before anyone acts on it.

The fields

One piece of work per card. Fill it before the work starts, not after it comes back.

A field answered "not sure" counts as empty. The studio's example is generic and names no one; a real card names a real piece of work and the people who asked for it and answer for it, so it stays with us.

Run it with any model

It interviews. It may suggest checks for done once the purpose is clear. It may never write the purpose, and it never names the client or the person who answers.

Help me fill in a What It's For card for one piece of AI-assisted work that's
about to start. The card asks four things before anything is made: what it's
for, who asked, what done looks like, and who answers if it's wrong.

INTERVIEW ME. Ask at most three questions at a time, and work the fields in this
order.

1. work: the one piece of work about to start, in one sentence. If I describe
   several, ask me to pick one.
2. for: what it will be used for, meaning the decision it feeds or what someone
   does with it next. If my answer only describes the output ("a deck", "a
   summary", "a draft"), say so and ask what it's used for. Record a real use in
   my words; if I only ever describe the output, leave for.use as null and set
   describes_output_only to true.
3. client: who said what it's for. Ask whether that's a named person. If my
   answer is a role, a team, "leadership", or a tool, record that and say it
   doesn't count as a client.
4. done: how we'll know it's right, in terms someone other than the maker could
   check. Once "for" is filled, you may suggest up to three checks that follow
   from it. I choose which, if any, and may write my own.
5. answers: whose name is on it if it's wrong once it's used. Ask whether that's
   a named person.
6. answers_agreed: if the person who answers isn't the client, ask whether
   they've seen the brief. Record yes, not asked, or declined. If the person who
   answers is the client, record not needed and don't ask.

RULES YOU DO NOT BREAK
1. Do not write the purpose. You may point out that an answer describes the
   output rather than its use. You may not suggest what the work is for.
2. Do not name the client or the person who answers. Record whether each is a
   named person as true or false, and leave client.name and answers.name as
   null. I'll fill them, and I won't be typing a colleague's name into a chat
   window.
3. Treat any answer of "not sure" or "don't know" as empty. Empty means null,
   for the field and for any true or false flag that judges it.
4. Derive the verdict by these rules, first match wins: for is empty or only
   describes the output, no brief. client is empty or not a named person, no
   client. done is empty or only the maker could judge it, no test. answers is
   empty or not a named person, or answers_agreed is declined, nobody answers.
   answers is not the client and answers_agreed is not asked, ask the answerer.
   Otherwise start.
5. Do not start the work, draft it, or tell me whether it's worth doing. This
   card comes before the work.

OUTPUT
Valid JSON matching the schema what-its-for/v0.1 as published at
https://sigsub.show/takeaways/what-its-for/#the-answer-format. If you can't read
that page, use these keys, in this order: schema, work; for, with use and
describes_output_only; client, with name and is_named_person; done, with test
and checkable_by_others; answers, with name, is_named_person and same_as_client;
answers_agreed (yes, not asked, declined, or not needed), verdict. Then the same
as a short table, then one sentence naming the field to settle before the work
starts, and who to settle it with.

What to check in the answer

It may suggest checks for done. Turning a clear purpose into two or three things someone could verify is the kind of job a model does well, and choosing among them is quicker than writing them cold.

It may never write the purpose, and it may never fill a name. If the JSON comes back with a for you didn't say, or a name in client or answers, the model has done the one thing the card exists to stop: written the brief for you. And if the verdict says start while a field you meant as "not sure" is filled in, it guessed. Clear the field and run the rule again.

The part that's not optional

Write the four lines before the work starts. Not after the first draft comes back, when the draft will quietly become the definition of done. Then show them to the person who answers, if that isn't you. A brief they've never seen is a brief they'll be held to anyway.

{
  "schema": "what-its-for/v0.1",
  "work": "the one piece of AI-assisted work about to start",
  "for": {
    "use": null,
    "describes_output_only": null
  },
  "client": {
    "name": null,
    "is_named_person": null
  },
  "done": {
    "test": null,
    "checkable_by_others": null
  },
  "answers": {
    "name": null,
    "is_named_person": null,
    "same_as_client": null
  },
  "answers_agreed": "yes | not asked | declined | not needed",
  "verdict": "start | no brief | no client | no test | nobody answers | ask the answerer"
}