Building Blocks
Menu
SystemFoundationComponentsPatternsThemesIncluded
CatalogsLive catalogsHow catalogs work
GuidesDocs
Overview

Building Blocks is the shared structure—not the shared look.

A complete foundation to start from. A living catalog to build with. Eventually, a governance layer so product interfaces stay coherent as they evolve.

Foundation → Adaptation → Catalog → Governance → Adoption

One system model across different products.

Building Blocks exists to reduce repeated design-system setup without flattening every Baskerville & Co. product into one house style. The shared layer should be strong enough that common jobs, system rules, and documentation do not have to be rediscovered from scratch.

01Foundation

Principles, product decisions, semantic roles, interaction rules, accessibility, and baseline components.

02Adaptation

Product theme and expression mapped onto stable semantic jobs.

03Catalog

The product-local living view of what that product actually specifies, designs, and ships.

04Governance

Contribution, gaps, document homes, review, and change paths. Centralized operations are planned—not presented as already live.

05Adoption

New product, From Prototype, migration, and Engineering Foundation workflows that make the system usable in real work.

What it is not

Not one component library only

The source checklist includes product intent, content, responsive meaning, navigation, operating contracts, 31 component jobs, and six patterns.

Not one visual style

The semantic system stays stable while product themes change expression. The existing Building Blocks icon/brand is the docs brand, not a mandatory product theme.

Not a Storybook replacement

Storybook is better at executing implemented component states, controls, responsive previews, and tests.

Not a central Catalog replacement

The product-local Catalog remains the real view of the product. A future Building Blocks layer may aggregate across products without taking over product truth.

Four design-system layers underneath the operating model.

01Principles & platformLayer 1 questions and product intent. A prototype is evidence, not an automatic answer.
02TokensPrimitive values feed semantic roles; component tokens are used sparingly. Components should not couple directly to raw primitives.
03Components & patternsReusable jobs, complete applicable states, accessible behavior, responsive meaning, and composed flows.
04DocumentationPurpose, variants, states, when not to use, accessibility, implementation reference, source lineage, and operating guidance.

Building Blocks separates baseline truth from product truth.

The central docs can say what the baseline should contain and how it should work. A consuming product’s Catalog says whether that product has specified it, designed it, and implemented it. Those statuses should never be inferred from the existence of this website.

Read the product-local Catalog contract →

What this site covers — and what it does not.

  • Claims: a deeper information architecture, source-aligned coverage model, component/foundation/pattern documentation structure, theme model, Catalog contract explanation, and guide structure.
  • Does not claim: a published Building Blocks package, final token API, CLI, centralized governance service, connected Storybook, or cross-product Catalog aggregation.