The Pattern

The Model

A Foundry keeps authorship and distribution separate. People maintain a rich, inspectable Knowledge Base; agents receive small, frozen artifacts compiled for one action. Four parts make that work: the Knowledge Base, a Mold that selects what one action needs, a Cast that builds the artifact, and Provenance that records exactly what went into it.

The four parts at a glance

Targets and validation matter, but they are not extra parts. A Target configures what the Cast produces. A domain’s external check decides whether the work performed with that artifact can be trusted. Keeping those boundaries explicit is what lets every Foundry share one substrate while different domains extend it differently.

1. Knowledge Base

The Knowledge Base (KB) is the source of truth: a human-readable corpus authored to be inspected, learned, corrected, and cited. It is plain files, not a hidden agent store. Typed frontmatter, controlled tags, and wiki-linked references give those files enough structure for tooling to act on them.

Calling that structure executable is a claim the build enforces. Every typed reference must resolve, controlled tags must exist in their registry, and generated indexes and deterministic renders are regenerated and diffed. A Mold whose source fails these checks cannot be cast. The same structure that helps a person navigate the knowledge therefore gives the compiler something it can verify.

The glossary is the highest-fan-in part of the KB. It pins coined terms once so people and models use the same vocabulary; casting carries those definitions verbatim. The full rationale belongs in the glossary, and defining that vocabulary is one of the first steps in setting-up-a-foundry.

In the running example, the KB owns the input schema and domain pattern that summarize-source will use. If either changes, the source changes in one inspectable place.

2. Mold

A Mold describes one action. It is an abstract, typed reference manifest plus a procedural skeleton: which knowledge the action needs, when each dependency should be loaded, how it should be packaged, and what the action does with it. A Mold is source, independent of any agent runtime.

The boundary is procedural. A repeatable decision-and-handoff worth executing as a unit becomes a Mold; a fact, convention, or contract that an action can cite stays a reference. One Mold may be substantial, but it should still describe one coherent unit of work—not an entire journey and not a dust of fragments.

Every declared reference carries three decisions:

• a kind — which resolver and casting rules apply;
• a load policy — upfront or on-demand, with a trigger for the latter;
• a placement mode — verbatim, or sidecar where the target permits it.

Placement, not transformation: both modes carry the reference unchanged, one as its own bytes and one as a structured artifact built from them. That is why a cast is reproducible byte for byte, and it is the whole of the vocabulary a Mold may draw from — a mode exists when some instance has written the renderer that performs it.

Common reference kinds include KB pages, schemas, CLI manual pages, prompts, and examples. Their different shapes are why the manifest is typed rather than a flat list of links.

For summarize-source, the input schema loads up front because every run needs it. The domain pattern can load on demand when the source type calls for it. The Mold declares both dependencies; it does not duplicate their content.

3. Cast

Casting deterministically compiles a Mold into a target-specific artifact. Tooling resolves typed references, selects the material the Mold declares, copies or places it according to its kind and target, renders the artifact, and writes provenance. The same source, Mold, and target produce the same bytes.

The artifact crosses an integration boundary. It comes out:

• scoped — limited to what this action declares;
• isolated — with links resolved away and no runtime dependency on the KB;
• frozen — tied to one source revision rather than silently following future edits.

The skill body is therefore never hand-maintained. If it is under-instructed, fix the Mold or its references and cast it again. The KB remains the source; the artifact is the package.

Targets change the package, not the source

A Target is an output format: one agent’s skill format, a generic skill bundle, or another frozen package. Casting is parameterized by target, so one Mold may produce several artifacts without forking the knowledge that feeds them. A new runtime should require a new target configuration, not a rewrite of the KB.

In the running example, the Cast resolves the summarize-source dependencies, copies its schema exactly, places the selected domain pattern according to the target rules, and emits a self-contained skill for the selected target.

4. Provenance

Every Cast emits Provenance beside the artifact. The consumer does not load it as instruction; it is the lineage record. It names:

• the Mold revision and content hash;
• the target identity and configuration;
• the references resolved, with their source, destination, placement, and hashes;
• the checks run at cast time.

That record makes drift mechanically detectable. Re-hash the Mold and its sources, compare them with the record, and a stale artifact announces itself. It also answers the forensic question a bare skill cannot: where did this particular claim come from?

For summarize-source, a record might look like this:

{
  "mold": { "id": "summarize-source", "revision": 4, "content_hash": "sha256:9f1c…" },
  "target": { "id": "agent-skill", "revision": 2 },
  "references": [
    { "id": "input-schema", "mode": "verbatim",
      "src_hash": "sha256:71a0…", "dst_hash": "sha256:71a0…" },
    { "id": "domain-pattern", "mode": "verbatim",
      "src_hash": "sha256:0a5e…", "dst_hash": "sha256:0a5e…" }
  ],
  "checks": ["static-validation", "references-resolved"]
}

Three useful tests fall straight out of it:

• Verbatim material proves itself. src_hash == dst_hash shows that the schema was copied unchanged.
• The build is reproducible. Re-casting the same Mold for the same target yields the same artifact bytes and content-derived hashes.
• Drift and forensics share one index. Compare hashes to find staleness; follow the same entries to find a claim’s source.

The pattern requires re-checkable lineage, not this exact filename or encoding. Both existing instances use _provenance.json; another instance may encode the same guarantee differently.

What sits outside the four parts

Compile-time grounding, not runtime retrieval

Most retrieval-first systems attach a knowledge base to an agent and search it during a task. A Foundry makes a different bet: select and compile the required knowledge ahead of time, freeze it into the artifact, and record its lineage. Runtime retrieval may augment that package, but it does not replace the compiled grounding. The fuller comparison is in comparisons.

The external check

Source validation asks whether a Mold and its references are well-formed enough to cast. A domain’s external check asks a different question: whether the work produced with the cast artifact deserves trust. The first is part of the shared machine; the second is extension surface.

Where correctness is mechanical, the check may be a parser or validator. Where it is empirical, the domain may construct a referee that runs simulations, calibration, or negative controls. Either way, doing does not get to certify itself. anatomy-of-an-instance follows that boundary end to end; guiding-principles explains the discipline behind it.