Sharing judgment through libraries

Leadership settles a hard question: "When meal planning lacks allergy information, ask one targeted question, never infer." The decision lives in a workshop deck. Engineering copies a paragraph into three agents. Product tweaks wording in a fourth. Legal asks for audit trail. Six months later nobody can say which behaviour production runs, and improvement in one copy does not help the others. That is judgment sharing as Slack archaeology. It feels collaborative. It produces private dialects.

Helpful context: Sharing judgment names the organisational problem at decision level. Libraries of cognition defines the inventory. Packages, not prompts states what travels. This page connects leadership intent to library economics.

Why prompt sharing is not judgment sharing

The habit is seductive. Prompts are visible, editable, and demo-friendly. Packages require owners, suites, and release gates. Teams confuse visibility with institutionalisation.

Slack sharing	Library sharing
Template text	Contract + suite + owner
Implicit ownership	Named maintainer
Silent divergence	Substitution rules
"Works in demo"	Regression gates
Audit trail is edit history	Audit trail is semantic versioning + suite + invoke logs
Improvement is local	Improvement propagates

Judgment shared as prose becomes private dialect. Judgment shared as packages becomes organizational capability. The household experiencing meal planning across products encounters one question policy, not three wording variants that reflect which team copied the deck last.

Who publishes, who consumes, who evaluates

Sharing through libraries is a supply chain with three roles, not a single "AI team" dumping templates.

Publishers are domain owners, platform teams, and architecture guilds. They own decision sentences, applicability, placement (agent-private, domain, organisational, judge), and release gates. Publishing without ownership is a dump with semantic versioning. Consumers are product agents, Skills, and application code. They inspect, invoke, and respect authority limits rather than forking templates. Consumer teams earn velocity by importing packages, not by rewriting them under deadline pressure, as do not rediscover known work explains. Evaluators are quality and domain stewards. They maintain suites, calibration cases, and promotion criteria. Evaluators block latest when regression fails. Sharing, done well, becomes measured reuse. Evaluation as engineering develops this lane.

Publish

Contract, suite, owner, semantic versioning

Consume

Inspect, invoke, abstain when unfit

Evaluate

Regression, calibration, release

Sharing judgment is a supply chain, not a copy operation.

Placement is sharing policy

Not every judgment earns the same shelf. Sharing policy is placement.

The organisational library holds leadership decisions that cross domains. AskTargetedQuestion with materiality policy. Question discipline when authority or information is missing. One publish, many products consume. The domain library holds judgments shared across product lines that share a domain model. In meal planning, that means GenerateCandidates, AssessMealPracticality, and RecommendMealSubstitution. In invoice intake, field interpretation cognitive units. Domain owners publish. Product agents consume. The judge library holds evaluation-shaped judgments with grader suites, shared across workflows that need the same scoring contract, not production assessors invoked mid-loop without inspect discipline.

Agent-private tactics stay with the agent until deliberately promoted. InterpretWeek, ComposeWeek, and CritiquePlan remain with the Meal Planning Agent until stabilisation earns packaging. Sharing too early freezes experimental strategy. Sharing too late produces rediscovery forks. Agent-private cognitive units and domain libraries develops those placement decisions.

What this looks like in practice

In the organisational library, AskTargetedQuestion publishes once. Meal Companion, nutrition assistant, and grocery copilot invoke the same cognitive unit. Materiality policy updates propagate through semantic versioning and substitution rules. Leadership changes question policy once, not in four Slack threads.

In the domain library, meal-planning judgments are shared across product lines that share the household model. Busy-evening fit lives in AssessMealPracticality, not in each product's composer prompt. Local repair lives in RecommendMealSubstitution. Platform improves judgment. Products inherit via library ops.

At the Skill layer, when invoice extraction procedure stabilises, Extract Structured Invoice publishes once. Enterprise intake and batch reconciliation invoke the same Skill. Procedure improvements propagate. Worker scripts do not reimplement extraction each sprint. Skill library versus cognitive unit library develops the two-shelf model.

The invoice parallel reinforces the same logic. Field interpretation cognitive units are shared across AP workflows. The extraction Skill composes them for enterprise intake. Invoice intake overview describes this architecture.

Organisational design questions

Before scaling "we have a library" claims, leaders and architects benefit from answering several questions explicitly. Which judgments are org-wide versus domain-local versus agent-private? Who may publish a new package version, and who approves major semantic version bumps? What eval floor blocks promotion to latest? How do consumers discover packages without prompt reading, as sealed and searchable covers? How do substitution and rollback work when shared packages change, as substitution rules defines? What inspect discipline do consumers follow, as runtime inspectability explains? Unanswered questions produce libraries that are folders with extra steps, not organisational capability.

Sharing and trust

Shared packages carry authority limits. Consumers inspect before invoke rather than assuming org-wide means unconstrained. AskTargetedQuestion shares question policy, but it does not grant diagnosis authority. Domain cognitive units share meal judgments, but they do not override endorsed allergy knowledge in the deterministic shell.

Sharing judgment without sharing authority clarity produces trust failures. Products invoke packages outside terrain because "org library" sounded safe. Limitations fields and inspect discipline exist to prevent that. Shared cognition packages benefit from trust tiers: team, org, public. Each tier carries endorsement requirements and substitution policies before callers invoke across boundaries. Legal review may be required before org-wide promotion of packages that touch regulated decisions. Trust tiers make that review scoped and repeatable.

Sharing and adoption maturity

From experimenting to governing describes how teams move from prompt improvisation to published inventory. Sharing through libraries is the institutional form of that maturity, not a day-one requirement for every judgment, but the destination for settled policy.

Early experimentation stays agent-private. Leadership decisions that repeat across products earn publish. Domain judgments that stabilise earn domain library placement. The mistake is skipping the middle (never publishing) or skipping the beginning (publishing before contracts exist).

Economics of shared packages

Shared packages amortise eval cost. One suite maintains AssessMealPracticality. Ten product lines benefit. Shared packages amortise improvement cost. One owner patches question policy. Three copilots inherit on semantic versioning.

Unshared forks multiply cost linearly with product count and divide measured quality by fork count. Finance may not see the duplication until cost per decision attribution exposes the same judgment billed under different prompt homes. Shared libraries turn that hidden duplication into one line item and one improvement path.

Common mistakes

The most frequent failure is publishing without consumer onboarding, where the package exists but products never import and forks continue. Shared drives treated as libraries produce files without catalog, inspect, or suite gates. Org-wide placement for domain judgments freezes meal logic at the leadership layer with the wrong owner and wrong eval. Sharing prompts in "library onboarding" teaches rediscovery rather than inspect-invoke discipline. Missing retirement paths for Slack forks mean the library supersedes the fork but the fork stays in production because nobody removed it.

Fork retirement and publish authority

When a library version supersedes a Slack fork, running a short retirement ceremony, identifying consumers, cutting over to manifest invoke, removing the fork from production, and logging semantic versioning in the change record, keeps the sharing economics clean. Forks that survive "just in case" undermine sharing economics and duplicate eval cost. Retirement is part of sharing discipline, not optional cleanup.

Domain owners publish domain judgments. Platform publishes organisational conduct packages. Leadership approves authority-bearing standards. Publish authority benefits from being explicit in the spec so teams know who can semantic versioning AskTargetedQuestion versus who can semantic versioning AssessMealPracticality. Ambiguous authority produces either duplicate publishes or publish paralysis.

What to do next

The practical starting point is to inventory judgments repeated in multiple prompts, because those are the candidates for a first publish. Assigning owners before publish rather than after drift prevents the ownership vacuum. Requiring suite green before cross-team consumption ensures quality. Retiring Slack forks when library versions supersede them closes the duplication loop. Answering placement and publish-authority questions explicitly for each shelf makes the sharing policy concrete.

See Skill library versus cognitive unit library for packaging granularity, substitution rules for safe upgrades, and from experimenting to governing for adoption maturity.

Read next: Memory as architecture.