The Pattern

Anatomy of an Instance

A Foundry is an inspectable, human-readable knowledge base of deep domain knowledge whose structure makes it executable: the knowledge is decomposed into typed units that compile into frozen artifacts carrying provenance. That sentence names the part that is the same in every instance. This page separates that shared substrate — the invariants — from what each instance adds for its domain — the extension surface. The thing to take away is not a checklist of required slots but a posture: the pattern is a substrate you extend, not a template you stamp.

Where the-diff earns the abstraction comparatively (hold the two instances side by side; what survives the diff is real), this page earns it descriptively: walk the anatomy once, and mark each part shared or domain-added. For the underlying model and term definitions, see the-model and the glossary.

The invariants — the substrate

These are the same in every instance. Remove any one and the thing stops being a Foundry — so each is stated with what breaks without it.

The knowledge base / reader’s surface. The source of truth is authored to be read and learned by a human, not merely stored for an agent to retrieve. It renders as a navigable site with links, backlinks, and progressive disclosure. Without it, the knowledge is only ever machine feed — you lose the human’s ability to scrutinize, correct, and trust the source, and the project collapses into the very skills-as-source pattern the Foundry exists to invert.

The Mold (typed reference manifest). The unit of the KB is an abstract action description whose frontmatter declares the references it depends on — other KB pages, schemas, CLI manual pages, prompts, examples — by type. The Mold is a source artifact, independent of any runtime. Without typed structure, “make the KB executable” has nothing to grab: a prose page can be read but not compiled, resolved, or drift-checked. The types are what let the compiler dispatch.

The Cast (deterministic-first, LLM-second compilation). Casting turns a Mold into a target-specific skill artifact, doing as much as possible deterministically (verbatim copies, sidecars, schema serialization) and reserving the LLM for the few kinds where condensation adds value — in that order of trust. Casting is the integration boundary: artifacts come out condensed, isolated, and frozen, with no links back to the KB. Without the deterministic-first discipline, you cannot reproduce or diff a cast, and “compiled” becomes a synonym for “regenerated by a model each time” — untraceable by construction.

Provenance. Every cast emits a record beside it: which Mold revision, which model and prompt version, which references resolved, which checks ran. Without provenance you cannot tell a real-and-verified claim from a plausibly-confabulated one, drift is undetectable, and the corpus becomes model output fed back as ground truth — the degenerative loop the pattern is built to break. This is the one durable, non-commodity asset the package carries no matter the domain (developed in the-two-assets).

Corpus-grounding. Abstractions trace back to real exemplars in an external corpus, cited by URL/reference and not mirrored in. Without grounding, the KB is invented top-down — restated canonical knowledge with no anchor, exactly the commodity a frontier model already regenerates on demand.

Progressive disclosure. Molds disclose the action; typed references disclose the dependency surface; load policy distinguishes up-front material from on-demand. Where an instance composes ordered journeys, those disclose the journey too. Without it the reader’s surface drowns and the runtime over-loads context; disclosure is what keeps both the human and the agent oriented.

The extension surface — what each domain adds

Here is where instances differ, and the difference is the point: applying the pattern means bringing real domain knowledge and extending the substrate with what the domain needs. None of these is a required slot the abstraction demands of you — they are the extensions the two current instances happened to need, and a third will need its own.

The domain knowledge itself. What the Foundry actually knows — the patterns, methods, references, and hard-won procedure of one field. This is the real work and the real asset; the substrate exists to carry it, not the other way around. One instance curates workflow-construction knowledge; another, statistical-method validity.

The grounding corpus. Which external corpus anchors the knowledge — a curated workflow set in one instance, established-methods literature plus cautionary negative examples in another. The grounding discipline is invariant; the corpus is the extension.

The target format(s). What a cast produces — one runtime’s skill format, a generic bundle, a web payload. The KB stays the source of truth; the target is one output, and an instance may have several. The integration boundary is invariant; which side(s) it compiles toward is the extension.

Composition / orchestration. Where a domain’s work is an inherently multi-step journey, an instance composes Molds into ordered end-to-end tasks and may orchestrate them with a harness. The galaxy-workflow-foundry builds pipelines for exactly this — workflow construction is sequential by nature. A domain whose actions stand alone may need no such layer at all. Composition is an extension, not a universal requirement.

The domain’s external check. Both current instances put something external to the model between authored knowledge and a trusted result — an honoring of the principle that the model must not be the only judge of its own work (see guiding-principles). But what that check is differs completely by domain, and the two instances sit at opposite ends:

• In the galaxy-workflow-foundry, correctness is parseable, so the check is a deterministic CLI validator (“the rails”): gxwf parses and validates the workflow format and tool steps; hallucinated identifiers, dropped revisions, and bad state are caught mechanically, the same way every time. Fast and total over what it covers — but it only covers what a parser can decide.

• In the statistical-genomics-foundry, “is this method valid?” has no mechanical oracle, so the check is itself authored knowledge cast into a skill — an empirical referee running an analyze → referee → revise loop, which both reasons about known invalidity patterns and constructs and runs the empirical test the field trusts. There the check is a deliverable you produce, not a tool you call.

These are not two settings of one universal knob. They are two domains solving “what does correct even mean here, and what can decide it?” their own way. A third Foundry might check with a human review queue, a proof assistant, or something none of these resemble — and that freedom is the pattern working as designed, not a gap in it.

Substrate vs. extension, at a glance

How to read this

If you are building a third Foundry, the substrate is given — you inherit the KB-as-source-of-truth, the typed Mold, deterministic-first casting, provenance, grounding, and disclosure essentially for free (that inheritance is what makes deriving from the pattern cheaper than starting fresh). The real work is the part the substrate cannot do for you: bring genuine, deep domain knowledge, and extend the base with what your domain needs — the composition its journeys require, the external check its notion of “correct” admits. The pattern hands you a foundation and a discipline, not a finished shape. It is meant to be applied and extended, not stamped out. See guiding-principles for the commitments that hold across every extension.