Concept
The shift
Why ordinary software vocabulary is no longer enough, and what Thoughtware names.
Cover for The shift20 concepts in this section.
All sections
Illustration for The Intelligence AgeWhen cognition got cheap
11 minThe Intelligence Age
Software can now interpret, draft, and revise as well as calculate. This page explains what changed, what became scarce when cognition got cheap, and why building now means organising judgment instead of picking a better model.
Illustration for From computation to cognitionTransformation was not enough
8 minFrom computation to cognition
Software used to transform inputs into outputs by fixed rules. Intelligence-age products also interpret, weigh, and revise, and that work is structured, bounded, and owned rather than random.
Illustration for Software executes. judgment does notExecution and judgment diverge
8 minSoftware executes. judgment does not
Code can enforce, calculate, and apply patches. It cannot silently own open decisions whose wrong answer has real cost. This page separates execution from judgment so you know what to build where.
Illustration for What is judgmentWhen the steps cannot be written down
7 minWhat is judgment
When more than one answer could be defensible and someone must own the result, you are looking at judgment rather than model output, confidence, or retrieval. This page gives the operational definition the rest of the collection builds on.
Illustration for The ladder of cognitive workName the kind of work first
7 minThe ladder of cognitive work
When someone says the AI does X, this ladder asks what kind of cognitive work X actually is, from calculation to consequence. Misplacing a rung breaks architecture and trust.
Illustration for Where does a decision live?One home for each judgment
7 minWhere does a decision live?
Every open decision should have one primary home in the architecture, not smeared across prompts, UI, and middleware. This page explains why locality errors make systems untraceable and unmaintainable.
Illustration for Meaning, knowledge, and authorityThree words teams confuse
7 minMeaning, knowledge, and authority
Understanding a request, possessing information, and having permission to act are three different things. Collapsing them produces systems that sound confident while overstepping.
Illustration for Where rules stop workingWhen exact rules fail
8 minWhere rules stop working
Rules excel where outcomes are exact and verifiable. They fail where context rewrites the question, goals trade off, or reversibility is low. This page shows how to detect that boundary and exit rule sprawl.
Illustration for Language is the abstraction above thinkingWords coordinate thinking work
8 minLanguage is the abstraction above thinking
Language is how we coordinate about thinking work. When software operates inside that medium, imprecise words hide design errors until production, so new vocabulary is earned, not marketing.
Illustration for Fluency is not evidenceSmooth text is weak proof
7 minFluency is not evidence
Clean grammar and confident tone are weak signals of sound judgment. Systems can sound authoritative while wrong. Design must separate persuasion from proof.
Illustration for Why the words we have failVocabulary gaps hurt design
8 minWhy the words we have fail
Teams can name models, prompts, retrieval, agents, and tools, and still be unable to say what kind of system they built. This page diagnoses why AI product conversations go in circles, and why Thoughtware vocabulary is precision tooling rather than rebranding.
Illustration for A category, not a mechanismName the category before the mechanism
9 minA category, not a mechanism
Thoughtware names a class of systems defined by how judgment is structured, not a single algorithm, framework, or model family. Learn the category before you ask which stack to use.
Illustration for What is ThoughtwareSoftware that hosts judgment
6 minWhat is Thoughtware
Thoughtware is software architecture for hosting cognitive work explicitly: bounded judgment, granted authority, durable memory, libraries of cognition, and deterministic shells where decisions close. This page is the canonical positive definition.
Illustration for Thoughtware at a glanceThe map before the depth
11 minThoughtware at a glance
A pocket map of the parts (agent, skill, cognitive unit, library, memory, code, evaluation) before you dive into primers. One example each from the Weekly Meal Companion, with links forward.
Illustration for What does not qualifyCategory boundaries
11 minWhat does not qualify
A chat wrapper, a RAG demo, or a prompt pipeline without explicit judgment boundaries, authority, and evaluation does not qualify as Thoughtware, even when it is useful. This page states the architectural test, not a taste verdict.
Illustration for The model is not the systemSubstrate is not architecture
10 minThe model is not the system
The model produces candidate judgments inside bounded calls. System behaviour comes from orchestration, state, deterministic rules, authority, and evaluation. If your diagram is one model box, you drew the wrong diagram.
Illustration for Cognition as materialJudgment becomes buildable
11 minCognition as material
Cognitive work can be packaged, bounded, reused, and substituted inside declared contracts. That materiality is what makes libraries, cognitive units, and trustworthy systems possible at scale.
Illustration for Intelligence beneath the surfaceWhat users should not see
11 minIntelligence beneath the surface
Good Thoughtware feels ordinary on the surface while intelligence is structured underneath. Users get outcomes and trustworthy conduct, with scaffolding inspectable when trust requires it.
Illustration for Lessons from software architectureBorrow structure, not organs
12 minLessons from software architecture
Bounded contexts, encapsulation, and separation of concerns solved composition for deterministic systems. Thoughtware extends those lessons to judgment, with one critical divergence around evaluation.
Illustration for The ten principles (overview)Ten commitments in one view
12 minThe ten principles (overview)
Ten architectural principles that stay useful after models and frameworks change. This page indexes them with teaching prose and summary tables, linking to dedicated notes for each principle.