A category, not a mechanism

People often ask what stack Thoughtware uses. The question is understandable, but it starts at the wrong level. A stack names mechanisms: models, vector stores, tool adapters, agents, and evaluators. Thoughtware names the kind of system those mechanisms are assembled into.

A mechanism says how a capability is produced. A category says what responsibilities a system has accepted. Thoughtware is a category because it is defined by the deliberate organisation of cognitive work: where judgment lives, what it may use, what remains exact, who grants authority, and how behaviour is evaluated.

Helpful context: Why the words we have fail explains why mechanism vocabulary cannot carry the whole category. What is Thoughtware gives the positive definition this page prepares.

Book grounding: Thoughtware White Paper, §02 is the primary source for the category distinction; Introduction to Thoughtware, Chs. 5–6 supplies the architectural definition and system view.

Category words appear when old questions stop sorting the work

Teams reach for mechanism words because mechanisms are visible. You can point to the model, inspect the retrieval call, count the tools, and sketch the workflow. That visibility makes the stack feel like the architecture. But a stack diagram can be perfectly accurate and still fail to say what the system is answerable for.

Category words solve a different problem. "Database" is not the name of one storage engine. It names a kind of responsibility inside software: persistence, querying, consistency, durability, and access. The specific engine matters, but the category lets a team discuss what must be true before choosing the engine. Thoughtware plays that role for cognitive responsibility. It asks what judgments are being hosted, how they are bounded, which facts have standing, where action stops, and what evidence would reveal drift.

The analogy should stay modest. Thoughtware is not a database for thoughts. It is a category word because builders need a level above the mechanisms to reason about obligations that survive changes in mechanisms.

The substitution test reveals the level of a word

Replace a model, retrieval system, or framework. If the resulting product can preserve its judgments, authority boundaries, contracts, and evaluation obligations, those things belonged to the architecture rather than to the mechanism. The system may change how it reaches an answer without changing what it is responsible for.

The Meal Companion may replace its language model next quarter. That change should not redefine a confirmed allergy, move the authority to purchase groceries, or erase the responsibility to assess whether a meal suits a busy Tuesday. Those commitments exist outside the model. They define the product as a cognitive system rather than a wrapper around a particular vendor capability.

A category name carries obligations

Calling a product Thoughtware does not mean it contains a model. It means the product has accepted obligations that a chat wrapper can avoid. Open judgments need owners and evidence. Durable knowledge needs endorsement and provenance. Consequential action needs authority. Exact work must remain exact rather than being delegated merely because a model can perform it.

These obligations make the category useful. They turn the question “does the assistant work?” into more precise questions: did it interpret the request faithfully, did it use authorised information, did a named judgment meet its standard, and did the product stop before acting beyond its grant? What is judgment defines the first of these objects; meaning, knowledge, and authority separates the sources of standing that the system must not collapse.

The obligations are also what prevent category language from becoming a badge. A team should be able to remove the word Thoughtware from a slide and still show the boundaries it implies: a named judgment, a contract, an evaluation suite, a memory policy, a deterministic guard, an authority rule. If the word disappears and nothing else remains, the term was only marketing.

The category is broader than one implementation

Two systems can use the same model and belong to different categories. One may accept a prompt, return a polished answer, and leave the responsibility for deciding and checking entirely with the user. The other may name its open decisions, protect hard constraints in code, draw on endorsed records, evaluate recommendations, and ask for approval before action. The model is shared. The architecture is not.

Conversely, a Thoughtware system may use several mechanisms across time. A bounded judgment can move to another model, gain a deterministic check, or be replaced by an exact rule as knowledge accumulates. The system remains recognisable because its obligations survive the substitution.

This is why a category name must not become a brand label. If the name does not survive a model change, it has described a product dependency rather than a system. If it survives, it gives a team a stable basis for design review, governance, and improvement.

The same distinction applies inside one product. AssessMealPracticality can be implemented by one prompt today, a decomposed evaluator tomorrow, and a cheaper model after that. The category question is whether the responsibility remained identifiable through those changes. The mechanism question is which implementation currently satisfies it. Both questions matter; they just live at different altitudes.

Same mechanism, different category	Same category, different mechanism
A model writes a recipe answer, leaving all checking to the user	AssessMealPracticality changes models while preserving its contract
Retrieval supplies relevant text with no endorsement policy	Endorsed knowledge moves from one store to another with provenance intact
A tool can place an order whenever the model asks	The purchase gate changes implementation while approval remains required

This is the practical reason to ask the category question first. Without it, mechanism choices acquire responsibilities they were never designed to hold.

Ask the category question first

Before choosing a stack, answer four questions:

1. What meaningful judgments will the product carry?
2. Which work is closed enough to keep in deterministic code?
3. What information may be treated as durable knowledge, and who endorses it?
4. Which outcomes require explicit human authority or approval?

Those answers define the system that mechanisms must serve. Only then does it make sense to choose a model, retrieval approach, library, or agent loop.

The order saves time rather than adding ceremony. A team that chooses retrieval before defining knowledge will keep arguing about which source is relevant. A team that chooses an agent framework before defining the goal will confuse loop depth with progress. A team that chooses a model tier before defining the judgment will buy capability without knowing what standard the capability must meet.

Once the category work is done, mechanism work becomes sharper. The team can ask which model meets this unit's suite, which retrieval path supplies endorsed material, which tool adapter enforces this authority boundary, and which deterministic service should never be replaced by cognition. The category does not compete with the stack. It makes the stack answerable.

A bridge to the positive definition

This page establishes the level of the word. What is Thoughtware gives the positive definition of the category itself. Thoughtware at a glance then provides the map of the system parts that carry these obligations.