Packages, not prompts

The fastest "library" a team builds is a Notion page: best prompts by squad, copy when needed. It feels like sharing. It ships in an afternoon. Stakeholders see a link and assume the organisation now has reusable AI architecture. Architecturally it is divergence risk, with no contract identity, no bound suites, no substitution proof, and no owner when behaviour shifts. Three months later, four forks exist. Each "works" in its local demo. None can prove sameness. Improvement in one fork does not transfer. Finance asks what AI costs and nobody can attribute spend to a named judgment, because nothing was named.

Helpful context: Libraries of cognition defines the inventory model. A contract, not a prompt applies at cognitive unit level. Sealed, evaluated, searchable covers discovery without exposing innards. This page is the supply-chain argument that blocks Notion pages from counting as architecture.

Supply chain, done seriously

Organisations already expect supply-chain discipline for code dependencies. Nobody deploys a library because someone said it worked on their laptop. The expectation includes semantic versioning so that identity changes when behaviour-bound identity changes, evaluation artifacts so that evidence ships with the version, ownership so that someone patches and approves release, rollback paths so that substitution rules apply when a replacement fails thresholds, and a manifest so that callers can read what they are about to invoke. Cognition deserves the same discipline, arguably stricter, because fluent outputs hide failure until consequence arrives.

Publishing AssessMealPracticality v2.1 means callers depend on a suite-measured package, not on paragraph 3 of a Slack thread. The prompt is inside the package. The package is what the organisation owns. This is not bureaucracy for its own sake. Packages are how the organisation stops paying twice for the same judgment. They are how incident response narrows to one owner. They are how platform teams earn the right to swap model tiers without every product team rewriting prose.

What separates packages from prompt libraries

Prompt libraries feel like progress because they make sharing visible. Packages make sharing accountable. The difference shows up in every operational dimension.

Prompt library habit	Package habit
Share template text	Publish contract + suite + profile
"Works on my machine"	Measured on declared distribution
Fork silently	Substitute behind identical interface
Search by emoji folder	Search by judgment type, domain, authority
Owner is "whoever edited last"	Named maintainer with release gates
Version is the edit date in Notion	Semantic versioning bound to contract identity

Teams resist packages because contracts feel slower on day one. Prompt docs feel like immediate velocity. The crossover point arrives with the first model swap, the second product line that needs the same judgment, or the first production incident where nobody can name what failed. At that moment the Notion page becomes archaeology rather than a reusable asset.

A folder of prompts is a dump. A package creates an asset.

Introduction to Thoughtware · Ch. 18

What a package contains

A package is more than a zipped prompt. At minimum, a published library entry exposes a contract summary (the decision sentence, input and output shapes, abstain and refer branches), evaluation evidence (suite identity, scores on declared distributions, regression status, calibration age), an operational profile (cost per call, latency percentiles, purity level, known failure modes), ownership and limitations (who maintains it, what terrain it covers, what authority it requires, what it must not be asked to do), and substitution guarantees (when v2 may replace v1 for callers on the same interface, as substitution rules develops).

Prompt text, few-shot examples, internal routing, and wrapper chains live inside the sealed package, not in the catalog row. Sealed, evaluated, searchable explains why that separation matters for discovery. Callers and catalog search depend on the contract layer. It must be readable without executing judgment.

Evidence binds to version identity. A package without evidence is a promise, not an asset. Agents composing under budget need the operational profile before invocation, not after the token spend reveals a surprise.

The Meal Companion example

JudgeWeekdayPracticality in the judge library ships as a package, not as a grader prompt someone copied from a workshop deck. Its contract summary is inspectable before the call: assess practical fit across the schedule for a complete week representation. Grader scores from the weekday practicality suite sit on declared busy-week distributions. Applicability requires a complete week representation, and the package is not for partial plans or single-day edits. The owner is the meal-planning platform team. Limitations note that it is not for medical diet interpretation and is not a substitute for AssessMealPracticality on single candidates. The semantic version reads v1.4, with substitution compatibility notes for v1.3 callers.

Callers discover whether to invoke by reading metadata and evidence, not by reading chain-of-thought. Contrast that with searching Slack for "busy Tuesday prompt," which returns four forks with no suite pointers, no owner, and no semantic versioning. That is a collaboration tool pretending to be architecture, not a library.

The same discipline applies to domain-library packages. GenerateCandidates v2.0 publishes with meal-schema compatibility declarations, candidate diversity suite results, and operational cost, not with "here is the prompt we used in the Q3 demo."

Packages and semantic versioning

Semantic versioning for cognition is not cosmetic. Major version bumps signal contract change: the decision sentence moved, holes changed shape, abstain branches differ. Minor and patch bumps signal implementation change behind a stable contract, such as a model tier swap, template refinement, or wrapper tuning, after suite re-run.

Teams that treat every prompt edit as a silent deploy train drift, not substitution. Packages force the question: did behaviour-bound identity change? If yes, require a major semantic version bump and callers must consciously migrate. If no, substitution rules may allow transparent swap. Evidence dies when the template changes applies when teams confuse the two, shipping a new decision under the old name because "we only changed the prompt."

Packages enable platform economics

Package thinking connects libraries to cost per decision. Named packages are meterable. Anonymous prompt prose hides spend inside features until finance asks questions nobody can answer. Package thinking also connects to maturity moves work out. Agent-private tactics earn promotion to packages when they stabilise. Packages that fail eval gates return to experimentation, not to silent Slack forks.

Common mistakes

The most frequent failure is publishing a contract without a suite, because reviewers cannot approve what was not measured. A close second is indexing prompt bodies for search, where embeddings over templates hide contract drift and eval staleness. Shared drives treated as registries produce files without manifest endpoints, which is not callable infrastructure. Packages that hide terrain ceilings in the limitations field cause wrong-package selection downstream.

What this looks like in practice

When the pattern works correctly, the platform publishes AskTargetedQuestion v1.2 to the organisational library. Meal Companion, nutrition assistant, and grocery copilot invoke the same package. Materiality policy updates propagate through semantic versioning and substitution rules. One owner improves everyone.

When the pattern fails, each product embeds its own "ask smart questions" block. No suite. No semantic versioning. Product A and Product B diverge on what "material" means. The organisation pays for the same judgment three times under different names.

Manifest schema discipline

Manifest fields need validation at publish time, not optional prose in a README. Required fields include identity, contract hash, decision or capability sentence, suite pointer with last run date, owner, limitations, and substitution band. Invalid manifests block publish. Partial manifests are how dumps sneak into catalogs with semantic version labels attached. Continuous integration can enforce this gate: a cognitive unit that ships without sealed identity, contract hash, and suite pointer fails the pipeline before reaching production.

What to do next

The first practical step is to stop awarding architecture credit for shared Notion prompts. Packaging one cognitive unit with contract and suite before scaling "library" talk grounds the conversation in evidence rather than aspiration. Substitution rules need defining before broad autonomy, because packages without swap policy become frozen forks. Separating domain libraries from agent-private tactics clarifies what placement warrants publication. Every publish path benefits from required manifest fields, a concern runtime inspectability develops.

See libraries of cognition for placement, substitution rules for safe upgrades, and sealed, evaluated, and searchable for catalog design.

Read next: Sealed, evaluated, and searchable.