Skip to content

Component Catalog

Digital Products builds its workbooks from reusable, specified building blocks called components — things like a KPI status tile, a validation framework, a Gantt timeline, a dashboard layout pattern, or a themed print report. The intent is that products should be able to adopt a proven, documented component instead of reinventing the same navigation panel, calculation pattern, or dashboard layout from scratch every time — while never sacrificing the quality of the individual Excel workbook to force-fit a component that doesn't actually suit that product.

Nothing here is implemented unless its status says so

Every component currently in this catalog has status proposed. Proposed means specified-as-an-idea, not built. No component in this directory tree should be treated as available for a real product to depend on for a real build until its status is explicitly advanced (and that advancement itself must be a reviewed, human decision — not an AI agent unilaterally marking something implemented).

Structure

  • component-catalog.md — the authoritative list of proposed components across every category, with capability, purpose, inputs, outputs, configuration, compatibility target, known limitations, candidate products, and status for each.
  • _template/ — the scaffold used to specify a new component in detail (component.json, component-specification.md, interface-contract.md, implementation-notes.md, compatibility.md, test-plan.md, examples.md, changelog.md).
  • Category directories (navigation/, configuration/, input-validation/, calculations/, dashboards/, forecasting/, timelines/, reporting/, theming/, documentation/, quality/) — each contains a short README pointing back to the relevant rows in component-catalog.md. Individual component specification directories, once a component is developed past a single catalog row, would live inside the matching category directory using the _template/ scaffold.

How a product should use this catalog

  1. Read component-catalog.md and identify candidate components for the product being specified.
  2. Record the dependency in that product's component-dependencies.md, including the component's current status.
  3. Do not assume a component's behavior beyond what its specification says. If a product needs a variant, document that as a proposed adaptation, not a silent deviation.
  4. If no existing component fits, propose a new one by adding a row to component-catalog.md rather than building an undocumented, one-off solution inside a single product.

This README establishes no policy beyond describing the catalog's structure and status conventions; see component-catalog.md for the actual proposed components.

Report an issue about this page