portal · Current reference
Understand Foundry
Learn the product model, architecture, terminology, and repository boundaries.
Applies to v1.1.3
Component pins for v1.1.3
| Component | Role | Version |
|---|---|---|
| core | runtime | v1.1.3 |
| theme-shield | theme | v0.1.15 |
| docs | reference | v0.1.6 |
| distribution | tooling | v0.3.20 |
Use this section to build the mental model before choosing implementation details. Architecture explains the layer boundaries; the product model explains how reusable pieces fit together.
The durable distinction is simple: portable build and render contracts belong to Foundry Core and the site repository. Accounts, permissions, approvals, provider credentials, and managed operations belong to Foundry Control.
The v1 product boundary
Foundry v1 is the portable foundation: a professional can move from brief to distinctive site, prove the result, and keep normal Hugo source that can be edited, hosted, extended, upgraded, or taken elsewhere. That promise is about speed, creative range, safe evolution, ownership, and migration—not about being locked into a hosted editor.
Core and Control work together
| Portable Foundry Core | Managed Foundry Control |
|---|---|
| Hugo templates, Markdown, assets, tokens, blocks, validators, and build contracts | Accounts, roles, private context, approvals, review history, previews, publishing, integrations, and service state |
| Works from an ordinary repository and can be hosted elsewhere | Adds a safer team cockpit around repositories and release workflows |
| Remains useful without a Control account | Must not be silently credited to Core or required for a portable build |
Boundary note: If a requirement includes identity, permissions, persisted workflow state, provider credentials, approval, publishing, or operational recovery, look to Control. If it describes rendering, source, contracts, validation, or portability, look to Core and Distribution.