Thoughtware at a glance

A team draws its architecture on a whiteboard before a design review: a box for the web application, a box for the database, a box for the job queue, and one large box in the middle carrying a vendor's name. Someone asks where the household's confirmed cashew allergy is enforced, and someone else asks who decides that the week's plan is finished. Both answers point at the same box.

The drawing is accurate about what the team built and misleading about how many separate responsibilities that one box has absorbed. A Thoughtware system keeps them apart, and this page is the pocket map of the separation. The map is worth carrying for a reason that has little to do with memorising a handful of names. Each part owns a responsibility that does not disappear when the part is missing: the responsibility migrates instead, into whichever neighbour has the loosest boundary, which is almost always the model.

Helpful context: What is Thoughtware owns the category definition and is the page to read first. This one is the parts list, and the Thoughtware system is the whole-system tour that walks a complete architecture end to end. Nothing here is taught to primer depth.

Who owns which piece of the work

Everything on the map hangs from an outcome, which is the domain result the system exists to produce together with the boundary drawn around it. For the Weekly Meal Companion the outcome is an accepted weekly dinner plan for a household, and the boundary says the system does not diagnose diets and does not buy groceries without approval. An outcome of that size is larger than any single decision, so something has to hold the goal while other parts hold the pieces.

The goal is held by an agent. It keeps the current picture of the work, chooses what to do next, observes what came back, revises, and stops when the plan is good enough or when the household has to be asked. What it chooses among are cognitive units, each owning one bounded judgment with declared inputs and a structured result. AssessMealPracticality answers whether a candidate meal fits one busy evening and then stops, because finishing the whole week is a different responsibility.

Some work is neither goal pursuit nor judgment. A skill packages a known procedure so the agent need not rediscover it every Monday. Deterministic code handles closed work such as allergy enforcement, portion arithmetic, plan versioning, permission checks, and purchase gates. A library of cognition makes named judgments reusable by letting them travel with contracts and evaluation history.

What the owners need in order to run

Named owners still need something to work from, and the map sorts that material by how much standing it carries rather than by where it happens to be stored. "Tuesday is busy this week" is context, true for one run and gone afterwards, while "Leena has a confirmed cashew allergy" is endorsed knowledge the system may act on until somebody corrects it. Between them sit experience from previous runs and expertise such as "Busy Week Pattern v0.2". Collapsing all four into one store lets a passing remark acquire the standing of a confirmed medical fact, and the memory forms exist to make that promotion explicit.

Material tells the system what is true. It says nothing about what the system may do, which is why granted authority is a separate row rather than a property of the agent. The Meal Companion may propose a grocery order and may not complete one, and that limit holds no matter how confident the proposal is or how capable the model behind it becomes.

What holds the parts to account

With ownership placed and material supplied, two questions remain, and neither can be answered by the parts that do the work. The first is whether the work was any good. Evaluation answers it by attaching evidence to each named responsibility, so a suite fails on AssessMealPracticality when spinach timing regresses instead of the team reporting that the product feels off.

The second question is how the system conducted itself while working, which is a different axis from correctness and often the one users actually feel. That axis is cognitive posture: whether the system asks a focused question when information is missing, preserves meals already accepted, refuses medical inference, and behaves consistently enough that trust can accumulate.

Read as a pocket map, the system is ten responsibilities and the parts that hold them. The names matter less than the separations. If two rows collapse into one box, the review question becomes whether the missing row is genuinely absent or merely hidden.

Part	Responsibility it owns	In the Meal Companion
Outcome	The domain result, with its boundary	Accepted weekly dinner plan, no diagnosis, no unapproved purchase
Agent	The goal and the loop that pursues it	Meal Planning Agent, running until the plan is sufficient or the household is asked
Cognitive unit	One bounded judgment, with inputs and a structured result	AssessMealPracticality: does this meal fit this evening
Skill	A procedure whose shape is known before it runs	The stabilised busy-week procedure, invoked as one capability
Deterministic code	Work that is closed and must stay exact	Allergy enforcement, portion arithmetic, plan versioning, purchase gate
Library	Packaging that lets a judgment be reused with its evidence	Meal-planning domain library holding GenerateCandidates
Memory	What may cross runs, and with what standing	Busy Tuesday as context, the cashew allergy as endorsed knowledge
Authority	What the system may do without asking	May propose a grocery order, may not complete one
Posture	How the system conducts itself while working	Ask when the answer changes the plan, preserve accepted meals, refuse medical inference
Evaluation	Evidence that each responsibility is still being met	A suite that fails when spinach timing regresses

Removing a part does not remove its work

A parts list this long invites the reasonable objection that a small product does not need ten of anything. The objection is right about the parts and wrong about the responsibilities. Leaving a part out never leaves the work undone; it relocates somewhere with no name and no owner.

Take the evaluation row away and the claim it carried is still made, because somebody still has to say the judgment is good enough to ship. With no suite attached to a responsibility, that somebody is whoever ran the last demo, working from whichever cases came to mind that morning. What that row held, then, was the difference between a measured claim and a remembered one.

The same substitution happens wherever a row goes missing. Allergy enforcement without a deterministic row survives as a sentence inside a prompt, which works until a model refresh reads the sentence differently. A household's "avoid pasta, we had it recently" without the separation between context and knowledge is still stored, and it then outlives the week it was actually true for.

Thoughtware is not any one of the components in the diagram.

Introduction to Thoughtware · Ch. 6

The surrounding argument matters too: the category is the architecture through which the parts participate in judgment together. That is what makes the map useful after something goes wrong. An incident review can ask which part should have stopped this, and the map either names a part with an owner or it does not. If the honest answer is the model every time, the diagram on the whiteboard was accurate and the architecture never existed to be drawn.

How to use the map

The productive use of the map is to read it against your own product one row at a time and find the rows you cannot point at.

1. Name the outcome the system is pursuing and the boundary around it.
2. Point to the owner of each open judgment, not only the component that calls a model.
3. Separate what the system knows from what it is merely considering this run.
4. Mark which permissions are granted, withheld, or returned to a person.
5. Attach evidence to the named responsibility that would fail if the behaviour regressed.

A row you cannot point at is not automatically a defect, because plenty of good software has no business owning a library or an expertise store. It becomes a defect the moment you notice that the responsibility is being met anyway, somewhere unnamed, by whichever part had room for it.

Where the map stops

The map is a snapshot of responsibility at one moment, and it is silent about how a system changes. Nothing on it says which judgments improved after evaluation, which repeated trajectory hardened into expertise, or which stable behaviour was eventually compiled into a faster path. Those belong to the lifecycle view.

The map is also deliberately shallow. Contracts, purity, library economics, and the design of evaluation suites each need their own treatment, and this page gives you the row to follow rather than the depth behind it. That is the trade a pocket map makes.

Once you know which rows are real in your system, the next question is whether the ones you do have amount to the category at all, which is a harder test than counting parts.

Read next: What does not qualify for the exclusion test that separates useful cognition from organised cognition.