Hold the System

Done answers what. Systems thinking answers what I'm standing inside.

You can name a checkable finish line and still run the work as a lonely chat turn. Wish in. Text out. Hope the window held enough truth. That is not holding a problem. That is renting a room for one conversation and throwing the key away when the tab closes.

This essay is about the other spine: treat the problem as a system before you ask a model to labour inside it. Not a pipeline checklist. Not a tool tour. An approach to the room.

Done is not the room

Define Done as Thinking is spine one of this cluster. Exists. Evidence. Reject. That contract tells you what success and failure are.

It does not tell you where the state lives, what feeds the work, how you know you moved, or who is allowed to say yes. Those are system questions. If you only define done, you still drop the model into fog and hope clarity arrives in the reply.

I hold a problem as a system so the model fills a room I already designed. I do not ask it to invent the room.

A small honest map

You do not need a diagram library. You need four answers you can write in plain language.

Inputs. What must enter the work: briefs, references, constraints, prior decisions, the files that already exist. If an input is missing, you are not "under-prompted." You are under-packed.

State outside the chat. Chat forgets. Disk remembers. What must outlive this window: notes, boards, folders, decisions logged where the next session can read them. If the only memory is the transcript, the system resets every time you open a new thread.

Feedback. How you know you moved: a test, a screenshot, a review pass, a measurement, a human gate that can fail. Feedback is the signal loop. Without it, labour is motion without proof.

Seat of judgement. Who says yes. You, a second model with a narrow brief, a checklist, a client, a QC bar that is not optional. If judgement is "the model seemed confident," you have no seat. You have a vibe with credentials.

Inputs. State outside chat. Feedback. Seat of judgement. That is enough of a map to stop treating a problem as one clever message.

Context is the system you pack

Context Is King is not a slogan for longer prompts. It is the tone of this cluster: models swap, prompts are cheap, context is the moat.

Context is the system made portable. The references you bring. The constraints you refuse to re-negotiate every turn. The taste and prior decisions the labour must inherit. The workspace shape that keeps state readable. When people say "context engineering," I hear "pack the room," not "inflate the system message."

If the output is thin, do not start with a cleverer prompt. Start with what you failed to bring into the room. Thin output is a packing failure before it is a wording failure.

That is why context is king is not "paste more." Pasting more without a map is still a slot machine with a fatter ticket. Packing means the four answers above live where agents and future-you can find them, not only in the scrollback of one chat.

Approach, not pipeline

People hear "systems" and reach for a flowchart: step one, step two, handoff, deploy. Pipelines have a job. This page is not that job.

Approach is a stance: I will not buy labour until I know the room. What feeds it. What outlives the window. How we know we moved. Who judges.

Pipeline is sequence. Approach is how you face the problem before sequence matters. Workflow recipes live under workflows. Workspace layout lives under essays like Build Your Workspace Once. Here we stay on mentality: hold the system so labour has somewhere honest to stand.

When the map is clear, the prompt gets short. When the map is missing, the prompt tries to smuggle architecture into adjectives. Architecture does not travel well as adjectives.

How this sits in the cluster

This is spine two of Context Is King: systems thinking and the room you pack.

The sibling spine is outcome as approach: Define Done as Thinking. Done first. Then the room. Then labour.

Library here. Course there. Mentality and free roam in outcomes-and-systems. Ordered product practice at /courses/define-outcomes-build-products. Shared thesis. Separate jobs. No lesson dump on this page.

The move, one line

Hold the problem as a system: inputs, state outside the chat, feedback, and the seat of judgement. Pack that room. Then run labour. If you only define done and skip the room, the model invents structure you never agreed to.