The Cognitive Unit

Once judgment becomes part of software architecture, a practical question follows immediately: where should an individual judgment live? Traditional software has long answered similar questions for computation. Functions localise operations. Modules group related behaviour. Services create independent boundaries around capabilities. These constructs make software easier to reason about because they give responsibilities a place. Thoughtware needs an equivalent unit of cognitive locality.

This paper calls that unit the Cognitive Unit, or CU.

A Cognitive Unit is a sealed component that accepts defined inputs, performs one bounded cognitive responsibility, and returns an evaluable result. Its purpose is not to represent intelligence in general. It is to own one coherent judgment well enough that the rest of the system can rely on it as a capability.

A CU might determine whether an invoice discrepancy is material, identify the intent behind a customer request, assess whether evidence supports a claim, classify the urgency of a case, judge whether a proposed answer is sufficiently grounded, or select the most appropriate option from a small set of candidates. What matters is that the responsibility can be named clearly enough that a caller understands what decision is being delegated.

This creates decision locality. Instead of allowing judgment to diffuse across a large prompt, workflow, or general-purpose agent, the architecture gives a meaningful decision a defined home. That makes it possible to ask precise questions about the decision itself: What information does it require? What result should it produce? Under what conditions should it decline to decide? What constitutes good performance? What kinds of failure are acceptable? When should its behaviour be changed?

A strong Cognitive Unit therefore has several identifiable properties. It has a clear responsibility and defined inputs. Its output has a form that the caller can understand and use. The context available to the unit is bounded rather than implicitly inherited from an entire application state. Its dependencies, such as knowledge sources or tools, can be identified. Its quality can be measured through an evaluation suite. Its likely failure modes are understood well enough for callers to respond appropriately. Its behaviour can also be versioned, so that an improvement in judgment can be introduced, compared, and, where necessary, rolled back.

These properties resemble familiar software-engineering concerns, but cognitive behaviour adds an important complication. The implementation that produces the decision may be inherently variable. A CU may rely on a foundation model, retrieved knowledge, examples, reasoning strategies, intermediate judgments, or combinations of these mechanisms. Its internals may change substantially as models and techniques improve.

This is why encapsulation becomes especially important.

The caller of a Cognitive Unit should not need to know which prompt produced the decision, which model was used, whether retrieval occurred, which examples were inserted into context, or how many internal reasoning steps were required. It should not have to understand whether the unit used a single model call, several competing attempts, a critic-and-revision pattern, or a specialist model trained for the task. Those are implementation concerns.

The caller should instead depend on the decision contract.

The decision contract states what judgment the unit owns, what information it expects, what kind of result it returns, and what guarantees or limitations surround that result. A component calling judge invoice materiality, for example, should depend on the fact that the unit returns an assessment of materiality with the required supporting information. It should not depend on the particular prompt template or reasoning method that currently produces that assessment.

This black-box property is crucial because cognitive implementations are likely to evolve faster than the surrounding architecture. A CU may begin as a simple zero-shot call to a general-purpose model. Later, it may gain retrieved policy documents. It may move from one model family to another. A single-pass judgment may become a multi-stage process. Curated examples may be introduced. A specialist model may replace a general one. The unit may eventually learn a fast path for familiar cases while retaining a more expensive reasoning process for unusual ones.

None of these changes necessarily alter the architectural responsibility of the component.

This gives rise to a core principle of Thoughtware: cognitive encapsulation.

Consumers of a cognitive capability should depend on its responsibility and result contract, not on the mechanism by which the judgment is produced.

Encapsulation matters for more than maintainability. It also changes how cognitive capability can improve. If a prompt is scattered through application code, replacing it may require modifying the surrounding product. If a judgment is sealed behind a stable cognitive boundary, its implementation can improve independently. Evaluation can compare one version of the capability with another while callers remain unchanged. The software system gains a way to evolve its intelligence without repeatedly restructuring every workflow that uses it.

The Cognitive Unit also creates a natural boundary for evaluation. Testing an entire intelligent application often produces weak information. If an end-to-end output is poor, it may be difficult to determine whether the problem came from interpretation, retrieval, reasoning, orchestration, or execution. When judgment is localised, the quality of a specific decision can be measured directly. Evaluation cases can be attached to the responsibility they test, and changes to the unit can be assessed against the same behavioural expectations over time.

This does not mean every model invocation should become its own CU.

Architectural decomposition should follow coherent responsibility, not implementation granularity. A single Cognitive Unit may internally make several tightly related intermediate choices if those choices exist only to produce one externally meaningful judgment. Conversely, a broad reasoning task should be separated when it contains decisions that have independent meaning, can be evaluated independently, or are likely to be reused elsewhere.

The boundary is therefore conceptual rather than mechanical. A CU should be as small as necessary to create a clear locus of responsibility, but not so small that the architecture fragments one meaningful judgment into arbitrary implementation steps.

A Skill Is Not a Composite Cognitive Unit

A related question arises once several judgments regularly occur together. If a sequence of decisions is always performed in the same order, is that sequence simply a larger Cognitive Unit?

It is not, and the distinction strengthens the Cognitive Unit boundary rather than weakening it. A procedure of that kind may contain several Cognitive Units, several genuinely different judgments, deterministic calculations, tool invocations, branching, retries, working state, and external effects. Those judgments may have entirely different evaluation suites, different tolerances for variability, different costs, and different owners. Treating the whole procedure as one Cognitive Unit would erase precisely the decision boundaries that the Cognitive Unit exists to preserve.

A Skill composes judgments; it does not merge them into a larger judgment.

This also allows the boundary between the constructs to be stated more precisely, in terms of what each is permitted to change. A Cognitive Unit may make internal choices in order to reach its judgment: which evidence to weigh, which reasoning strategy to apply, whether to decline to decide at all. A Skill may choose among bounded paths through a known capability. Neither of those choices, by itself, constitutes agency. Agency begins only when a component decides what work should be undertaken next.

Once Cognitive Units are sealed in this way, another consequence follows: they can be collected and reused. An organisation may gradually accumulate CUs for assessing evidence, interpreting requests, prioritising cases, checking compliance, recommending actions, or evaluating outputs. Such a collection becomes more than a set of prompts. It becomes a library of cognitive capabilities within a domain.

This possibility is significant because reusable cognition changes what larger intelligent systems can be built from. Instead of repeatedly reconstructing the same judgments inside every agent or workflow, future systems can compose from capabilities whose responsibilities and quality are already known.

But one judgment, however well encapsulated, is rarely enough to accomplish a meaningful goal. Real work requires deciding which capabilities to invoke, in what order, with what state, and when the objective has been sufficiently achieved. For that, Thoughtware needs a different architectural construct: the Agent.