Making the specification executable

The workshop ended with a strong Thoughtware Map on the whiteboard. Outcome and boundary are written. The Judgment Chain names InterpretWeek, AssessMealPracticality, ComposeWeek, and neighbours. Leadership is allocated. Memory forms are sketched. Two weeks later, the map is a photo in a slide deck. Engineering built a prompt chain from memory. QA tests fluency. Production behaves differently every release, and nobody can say whether the gap is framing, implementation, or evaluation.

Helpful context: The Thoughtware specification defines what belongs in the document. Abstraction does not remove responsibility insists that generation does not transfer ownership. This page is the construction bridge: what must be derived, what must return to people, and what proof looks like when framing survives build.

Why diagrams are not contracts

Product teams already know the difference between a diagram and running code for ordinary software. Thoughtware needs the same discipline for judgments. A box labelled "assess practicality" on a map is not a cognitive unit. A bullet that says "respect allergies" is not a deterministic gate. A note that says "ask when unsure" is not Cognitive Posture with evaluable conduct.

Executable specification ties four things together. Contracts name the judgment, inputs, outputs, abstain paths, and purity level. Sample working states show what the system looks like mid-loop: interpreted week, candidate list, provisional plan version, unresolved gaps. Expected judgments state what a named cognitive units returns on stratified cases, with explicit pass, fail, abstain, and refer outcomes. Checks run automatically: CI on exact gates, scheduled suite runs on cognitive units, trajectory gates before authority rises.

When those four exist, framing became construction. When they do not, the team is still debating prompts while calling it architecture.

What must be derived

An intelligent Thoughtware environment must be readable at several levels: domain outcome, agent goals, bounded judgments, exact operations, memory categories, behavioural stance, authority, and evaluation. Construction must preserve the architecture of judgment. Natural language in the specification is not a request to produce code and hope the rest sorts itself out.

The derivation process begins with outcomes, boundaries, and goals authored in the specification by people who own the domain. From those, Intent Compilation derives named cognitive units, agents, deterministic gates, and memory routes. Evaluation and authority attach before treating generation as complete. Traceability from executable pieces back to human-authored meaning remains explicit at every step. When compilation hits contested values, the correct output is a return ticket rather than an invented default: unresolved meaning goes back to the people who own it rather than becoming quiet policy.

Derivation is partial by design. Some instructions are incomplete until a domain owner clarifies them. Some standards stay ambiguous until conduct cases exist. Intent Compilation combines generation with inspection: create what can be derived safely, and return unresolved meaning to the people who own it. A generator that fills gaps with invented policy creates fluent wrongness.

1. 01Outcome and boundaryHuman-authored framing
2. 02cognitive unit and agentsNamed judgments and goals
3. 03Deterministic gatesExact operations and permissions
4. 04Memory routesForms, endorsement, write policy
5. 05Evaluation suitesBehavioural and decision-class tests

Each layer should trace back to something a person authored or explicitly approved.

What this looks like in practice

Two hooks from the Meal Companion specification show what executable means in concrete terms.

The first hook is straightforward: given a busy-week working state with Tuesday and Thursday flagged, AssessMealPracticality must return fail for a candidate requiring sixty minutes of active effort. CI runs that check weekly. A regression is a spec violation, not a subjective complaint.

The second hook addresses deterministic enforcement: when Leena's cashew allergy is in endorsed knowledge, no candidate containing cashew may reach ComposeWeek. Enforcement belongs in deterministic gate code, not in hoping the cognitive unit remembers. The gate traces to the knowledge endorsement policy in the specification.

Executable also means conduct is testable. If the specification requires targeted questions only when material, the suite includes cases where a vague question should not fire and cases where abstain must trigger AskTargetedQuestion. Answer quality without conduct quality recreates the pilot problem inside production.

Traceability and return paths

Contract, not prompt is the recurring standard. Every cognitive unit declares what it decides, what it may read, and what it returns when grounds are thin. Every gate declares which knowledge or schema it enforces. Every agent strategy declares stop conditions and escalation paths tied to authority in the specification.

When compilation hits contested values, the correct output is a return ticket, not a guess. Whether temporary "avoid pasta" should become durable knowledge is a household approval question, not a template decision. Whether the system should challenge a week that is technically possible but practically miserable is a posture and authority question, not something generation should invent to unblock a build.

The Thoughtware architect receives these return paths. Specialists implement substrate. The specification remains the human-authored layer both groups align against.

From workshop map to running checks

The path from Thoughtware Map to executable architecture passes through the specification. The map holds the workshop agreement. The specification holds durable sections with evaluation hooks. Intent Compilation derives contracts, adapters, and suite scaffolds from those sections.

Each derived artifact carries lineage metadata: which specification section, which human owner, which version of endorsed knowledge or authority policy. Lineage is what makes abstraction and responsibility operational rather than aspirational. When a gate fails in CI, the failure message points to a spec clause and a named owner, alongside the stack trace.

Teams sometimes treat executable specification as a one-time code generation event. In practice it is a loop. Framing changes when the domain is understood better. Spec sections update. Derived artifacts regenerate or patch. Suites expand. Authority ceilings move only when evidence supports them. Executable specification is living alignment between meaning and behaviour.

Conduct and trajectory hooks

Executable architecture includes conduct as well as decision-class outputs. If posture requires targeted questions when material, the suite includes cases where spurious questions must not fire and cases where abstain must invoke AskTargetedQuestion. If authority forbids purchase without approval, trajectory tests assert the agent stops at proposal. Trajectory gates belong before authority rises. A cognitive unit that passes isolated cases may still fail when composed under loop pressure. Executable specification names which trajectory tests must pass before the agent may act with higher consequence.

CI and release integration

Executable hooks belong in the same release process as application code. A cognitive unit contract change without suite update fails the build. A gate change without spec traceability update fails review. Trajectory tests may run nightly rather than on every commit, but they must run before authority rises in staging environments. Regression in conduct cases carries the same urgency as regression in exact gates. An allergy leak is catastrophic. So is an escalation failure that erodes trust, even when answers read fluently.

Intent Compilation is the transformation of a Thoughtware specification into executable cognitive architecture.

Introduction to Thoughtware . Ch. 31

Common mistakes

Treating generation as sign-off. Generated files are drafts until traceability and suites exist. Templates that pass review without spec lineage become technical debt in cognitive form.

Running eval only on end-to-end demos. Named judgments need decision-class tests. Trajectory tests come later, once cognitive units pass in isolation.

Skipping deterministic gates because the model usually gets allergies right. Usually is not exact. Exact work belongs in code so a safety property never depends on probabilistic recall.

Losing the map after compilation. The Thoughtware Map is the workshop artifact. The specification is the durable record. Both must stay linked to executable pieces as versions change.

What to do next

One named judgment from the map, three stratified cases with expected outputs, and the contract and gate that enforce them form the minimal proof that framing survived construction. Wiring CI before expanding scope keeps executable specification honest as the decision map grows. The path from that proof to full compiled architecture passes through the Thoughtware specification for document structure, through the Thoughtware architect for ownership, and through adopting cognitive units in existing code for migration from legacy prompts.

A diagram is not a contract. Executable architecture is the honest proof that framing survived construction.

Read next: The Thoughtware architect.