Company / Venture / Product Model¶
Devonshire Digital organizes its work in three layers. Each layer narrows scope: company layer statements apply everywhere, and the venture layer adds detail specific to one part of the business without being permitted to override the layer above it (see inheritance-model.md for how conflicts are resolved). A third layer — everything a venture actually builds — is out of scope for this repository entirely; it lives in that venture's own implementation repository.
The two layers this repository governs¶
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¶
This repository's governance of a venture ends at the venture's existence as an operating brand and focus — its name, purpose, scope, target markets, positioning, and legal structure (per ADR-0017). 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 defines Shelfery's target customer, brand positioning, domain vocabulary and food-safety/trust constraints, and its legal relationship to Devonshire Digital LLC.
Example — Digital Products: venture-level documentation defines the venture's product philosophy, its Excel-specific standards baseline (tab conventions, calculation/formula rules, accessibility), and its brand identity.
Company-wide, content-agnostic standards also live here even though they constrain product content — e.g. docs/standards/product-specification-standard.md (what any product spec must cover) and docs/standards/component-specification-standard.md (how a component spec should be written, if one ever is). These are rules about content, not the content itself, and are unaffected by the boundary below.
What this repository does not govern¶
Product and component content — what a venture actually builds — lives entirely in that venture's own implementation repository, not here. This includes product specifications, decisions, lifecycle/registry status (product.json), the product backlog, and any reusable-component content. A venture's implementation repository is created per ADR-0014 once that venture is approved for implementation work; until then, product ideas exist only as unbuilt backlog entries, with no interim specification scaffold in this repository either.
Example — Shelfery: the shelfery implementation repository (formerly pantryplus) holds the app's actual specification, architecture, and decisions in its own docs/ai/.
Example — Digital Products: the devonside-labs implementation repository holds each shipped or in-progress product's specification, product.json registry record, and implementation, under products/<slug>/.
This repository keeps only a cross-venture index — portfolio/product-registry.json — mirroring what each venture repository's product.json files say, for company-wide visibility. It carries no independent judgment of its own; see registry-architecture.md.
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.