Diagrams

The diagrams below are the ones used across this documentation and in the repository’s own README files. Each is a single SVG file under docs/diagrams/ and is published unchanged.

Layered ownership model

LAYER EXPRESSED AS

enterprise policy that applies to all of Patterson sub-org catalog scoped to a business segment department grouping owned by a function team grouping owned by a delivery group repository settings committed beside the code user individual preference Lower layers extend what they inherit by default, and may override when they know better.

Six-layer ownership model from enterprise to user, showing where each layer is expressed and that lower layers extend or override higher ones

Source: docs/diagrams/layered-model.svg. Also published at /diagrams/layered-model.svg.

Marketplace topology

ENTERPRISE CATALOG INCUBATING

patterson-corp capability true for all of Patterson engineering delivery, infrastructure, security and operations brand identity, design tokens, editorial voice patterson-labs work that has not yet earned durable status Graduates upward once an owner and a review cadence exist. promotion

SUB-ORG CATALOGS patterson-dental segment-particular capability

patterson-vet segment-particular capability

Each catalog is separately owned and separately subscribable. Segment differences are real, not flattened.

Catalog names occupy one flat global namespace — a name registered twice replaces, it does not merge.

Marketplace topology: an enterprise catalog and an incubating catalog above two sub-org catalogs, each holding groupings of capabilities

Source: docs/diagrams/marketplace-topology.svg. Also published at /diagrams/marketplace-topology.svg.

Anatomy of a capability

ALWAYS LOADED LOADED ON DEMAND

SKILL.md name · description · triggers the decision rules, and pointers to everything else

Kept lean deliberately: this is the cost paid on every invocation.

references/ the full source material, split by topic — read only when needed scripts/ executable checks — a claim the capability can prove rather than assert assets/ text artifacts the capability installs or hands to a project _SOURCES.md · REFERENCES.md where every assertion came from, and what the source did not say

Provenance is structural, not stylistic — a restated standard and an invented one read alike without it. No binaries. Originals are cited by URL, never vendored.

Anatomy of a capability: a lean SKILL.md pointing to references, scripts, assets, and provenance files

Source: docs/diagrams/skill-anatomy.svg. Also published at /diagrams/skill-anatomy.svg.