Company / Venture / Product Model¶
Devonshire Digital organizes its work in five layers. Each layer narrows scope: company layer statements apply everywhere, and each subsequent layer adds detail specific to a smaller part of the business without being permitted to override the layer above it (see inheritance-model.md for how conflicts are resolved).
The five layers¶
1. Company¶
Devonshire Digital LLC's own governance, principles, and company-wide standards — mission, operating principles, naming and writing standards, security and privacy baselines, and ADRs. This layer is venture-agnostic: it must make sense whether it is read by someone working on Shelfery or on Digital Products. Lives under docs/company/, docs/governance/, docs/standards/, docs/decisions/, and docs/architecture/.
2. Venture¶
Context, standards, decisions, and AI instructions specific to one venture — Shelfery or Digital Products. A venture layer may add rules the company layer does not have an opinion on (e.g., "Shelfery uses a specific color token system") but cannot contradict a company-level standard. Lives under ventures/<slug>/.
Example — Shelfery: venture-level documentation might define Shelfery's own product taxonomy (pantry items, storage locations, expiration tracking), its house style for in-app copy, and any Shelfery-specific decisions about mobile-first design.
Example — Digital Products: venture-level documentation might define conventions for how workbook-based products are structured (tabs, named ranges, protected sheets), and a richer product specification template suited to spreadsheet tools rather than apps.
3. Product¶
Specifications and implementation records for one specific, shippable thing within a venture. A product follows the baseline structure in docs/standards/product-specification-standard.md, optionally extended by a venture-specific template.
Example — Shelfery: a specific released or planned app, such as a household pantry-tracking mobile app, with its own specification covering target customer, use cases, and acceptance criteria.
Example — Digital Products: a specific Excel workbook product, such as a household budgeting workbook, specified using Digital Products' workbook-specific template extending the company baseline.
4. Component¶
Reusable pieces that exist only in service of one or more products, specified per docs/standards/component-specification-standard.md. Components are documented at whichever layer they are actually reused: a component shared across all of a venture's products belongs in that venture's shared area; a component with company-wide reuse potential (rare, since ventures may differ completely in technology) belongs at the company/shared layer.
Example — Shelfery: a reusable "expiration date input" UI component used across several screens or products within the venture.
Example — Digital Products: a reusable Excel macro-free formula pattern (e.g., a rolling-average calculation block) reused across multiple workbook products.
5. Implementation¶
Where applicable, the actual repository or directory containing runnable/executable product code, as opposed to its specification. This layer is intentionally the least prescriptive: some products may be implemented inside this repository, others in a fully separate repository, depending on the outcome of the open decision described in docs/decisions/ADR-0007-implementation-repository-boundary-remains-open.md.
Example — Shelfery: an app codebase, whether housed under ventures/shelfery/ or in a separate implementation repository referenced from the registries.
Example — Digital Products: the actual .xlsx workbook files and any build scripts used to generate them.
Not every venture looks the same¶
Ventures are not required to converge on a shared technology stack, product-development method, design language, or commercialization channel. Shelfery may be a mobile/web app built and shipped through app stores; Digital Products may be Excel workbooks sold through a marketplace such as Etsy or Gumroad. Company-level standards set baselines (naming, writing quality, security/privacy minimums, commercial-claims honesty) that apply regardless of format — they do not mandate a single technical or creative approach. See docs/company/portfolio-strategy.md for the business rationale.
Where this model is enforced¶
This model is descriptive of intended structure. The authoritative rule for how layers inherit and constrain each other — including the precedence order used to resolve a conflict between layers — is docs/governance/authority-and-inheritance.md, summarized in inheritance-model.md.