From experimenting to governing

An enterprise finishes its second year of language-model pilots with impressive demos and uncomfortable production. Support built a copilot that drafts replies. Operations built a document summariser. Product built a meal-planning prototype for a partnership pitch. Each team has Slack screenshots and token bills. None of them can answer: which judgments are shared, who owns regression when a library version changes, what conduct standards apply across products, or how autonomy is measured portfolio-wide.

Helpful context: Evaluation and libraries of cognition supply the infrastructure governing requires. Behavioural standards across teams carry conduct once cognitive units are shared. The Thoughtware specification becomes organisational policy rather than a team notebook. This page is the maturity ladder between them.

The stages

Enterprises move through stages that each answer a different question. Experimenting answers whether useful cognitive capability exists in a bounded scenario. Models, prompts, demonstrations, isolated retrieval, and early use cases characterise this phase. Structuring answers where judgments live and which links are exact: Thoughtware Maps, Judgment Chains, named cognitive units, deterministic boundaries, and initial evaluation emerge. Composing answers how multiple cognitive units cooperate under authority, with agents coordinating tools, memory, state, and loops. Reusing answers whether the next team can adopt yesterday's work without rebuilding it, producing shared cognitive units libraries, judge libraries, tool adapters, memory services, and expertise primitives. Governing answers who owns outcomes when team membership changes: ownership, provenance, behavioural standards, approval, versioning, rollback, and audit. Scaling answers whether the portfolio remains observable and improvable as it grows.

Progress is uneven by design. A support team may be governing shared refusal templates while a research team remains in experimenting mode. The mistake is claiming scaling because executives saw demos while structuring artifacts never existed.

What this looks like in practice

The Meal Companion story shows the ladder on one product line. During experimenting, one prompt produces impressive plans on Tuesday. Capability is visible. Locality, endorsement, and ownership are unnamed. During structuring, framing produces outcome, boundary, Judgment Chain, terrain, and Thoughtware Map. AssessMealPracticality exists as a named cognitive units with a first suite. During composing, the Meal Planning Agent coordinates interpretation, assessment, composition, critique, and repair under declared authority and working state. During reusing, AssessMealPracticality, GenerateCandidates, and RecommendMealSubstitution publish to the meal-planning domain library with semantic versioning and substitution rules, while AskTargetedQuestion publishes to organisational library. During governing, behavioural standards attach to promotion, conduct cases gate library versions, and ownership and audit trail survive team changes. During scaling, portfolio observability covers cost, autonomy rates, eval regression, and cross-product learning alongside token bills.

Concrete gates per stage

Gates between stages are checkable, not ceremonial. "We have AI governance" is not a gate. "No domain library promotion without conduct suite pass" is.

Stage transition	Gate (example)
Experimenting to Structuring	Thoughtware Map with named judgments exists
Structuring to Reusing	At least one cognitive unit has suite, semantic versioning, and owner
Reusing to Governing	Behavioural standards attached to library promotion
Governing to Scaling	Portfolio observability: cost, autonomy, eval regression

The distinction between experimenting and governing marks the distance between "useful output exists" and "useful output is named, owned, shared, and observable when consequences grow." Between structuring and scaling, three artifacts matter most: a Thoughtware Map, a knowledge layer with endorsement, and an evaluation record that ties behaviour to cases rather than to model releases alone. Missing any one of them produces scale without reuse or reuse without trust.

Signs of premature scaling

Teams sometimes jump from a polished demo to portfolio rollout without the middle stages. Symptoms follow predictably: duplicate cognition across services, conflicting memory policies, no shared evaluation, autonomy rates nobody measures, and incident reviews that end at prompt edits.

Premature discipline is the opposite failure: full apparatus before composition pain justifies it. Governing earns its cost when consequences grow and cognitive units cross team boundaries. Experimenting earns its freedom when the decision map is still moving.

Department coexistence

Progress is uneven by design. Legal may experiment with contract summarisation while operations governs invoice extraction. Platform may reuse judge libraries while a product team still prompts without names. The ladder is a diagnostic: which artifacts exist here, which gates would fail if this capability promoted tomorrow?

Honest stage naming prevents expensive mistakes. Claiming governing because a policy document exists when no library has owners or suites is one failure mode. Staying in experimenting because demos still feel exciting when production already shows reliability walls is another. The question to ask is which stage question the team cannot answer today. That answer suggests the next stage. Cross-referencing the answer against the consequence level of the product reveals whether the gap is tolerable at current scale or urgent before the next release.

When to stay in experimenting longer

Governing too early produces standards without stable judgments. Staying in experimenting longer is correct when the decision map still moves every sprint, when no suite exists for the judgment being considered for publish, or when only one team uses the capability and reuse pressure has not arrived. The freedom to experiment is legitimate when naming reveals that boundaries are still moving. Even experimenting teams benefit from inventory: one sentence per model call, one outcome sentence, one boundary refusal the demo would have shown.

Experimenting ends when consequences grow: household trust, clerk liability, portfolio cost, or cross-team reuse. Those triggers are observable. Executive enthusiasm for scale is not sufficient if structuring artifacts are missing. A demo that impressed leadership without a Thoughtware Map is still experimenting regardless of calendar quarter.

Governing artifacts that survive turnover

Governing earns its cost when artifacts survive team changes. A Thoughtware Map with named owners, library entries with semantic versioning and suite history, behavioural standards attached to promotion, and audit trails for knowledge endorsement mean the next engineer can regress behaviour without reading last year's Slack. Without those artifacts, governing is theatre: policy documents that describe a system nobody can reconstruct.

For Meal Companion, governing means a new hire can answer which version of AssessMealPracticality production uses, which conduct cases gate promotion, and which human node owns purchase approval. For invoice intake, governing means legal can trace which field interpretation cognitive unit classified a disputed line and which deferral template fired. Those answers require artifacts, not the original author.

Experimenting

Capability visible

Structuring

Judgments named

Governing

Ownership and standards travel

Scaling

Portfolio observable

Capability without governing produces demos that cannot survive team changes.

Portfolio observability at scale

Scaling adds portfolio questions experimenting never needed. Which products share which library versions? Where are autonomy rates rising without eval regression coverage? Which teams rebuilt the same cognitive unit under different names? Observability without named judgments devolves into token dashboards. With named judgments, portfolio review becomes architecture review.

Enterprise scale begins when cognitive capability becomes reusable, governable, and observable.

Introduction to Thoughtware . Ch. 34

Common mistakes

Confusing executive enthusiasm with structuring. Approval to build is not a Thoughtware Map. Enthusiasm without artifacts leaves locality unnamed.

Publishing libraries before judgments stabilise. Semantic versioning on unstable boundaries freezes learning. See premature discipline.

Governing models instead of judgments. Model release notes are not architecture regression tests. Governing attaches to named decisions, not vendor changelogs.

Attaching behavioural standards after complaints. Conduct gates promotion, not post-mortems. Standards that arrive only in incident review teach nothing preventable.

What to do next

Naming which stage a team is actually in, not which stage the slide deck claims, is the first diagnostic move. Structuring cannot be skipped because the demo impressed executives. Behavioural standards attach before library promotion, not after conduct failures accumulate. Adopting cognitive units in existing code provides the incremental migration path rather than big-bang rewrite. The Thoughtware specification becomes organisational policy as libraries mature and consequence grows.

See the Thoughtware specification for the durable record governing attaches to, and the Thoughtware architect for who owns the map and gates.

Read next: Adopting cognitive units in existing code.