Skip to content

Inheritance Model Summary

This document summarizes, at a structural level, how the five layers described in company-venture-product-model.md inherit from and constrain one another. It exists so that someone reading the architecture documentation does not need to jump immediately to governance material to understand the basic shape of the model.

The canonical, authoritative statement of this model — including the full precedence order used when two layers appear to conflict — is docs/governance/authority-and-inheritance.md. This document does not restate that precedence order and should not be treated as a substitute for it. If this summary and the governance document ever appear to disagree, the governance document controls.

The basic idea

Each layer (company, venture, product, component, implementation) can add detail and make decisions specific to its own scope, but cannot override a rule set by a layer above it. A venture can be stricter than the company baseline; it cannot be laxer where the company has set a firm rule (for example, a security or privacy minimum). A product can extend a venture's specification template; it cannot omit sections the venture or company baseline requires.

This is intentionally similar to how a style guide, a team's local conventions, and a single document's exceptions might relate to one another in an ordinary organization — each layer narrows, none of them silently override upward.

Why this matters in a multi-venture company

Devonshire Digital's ventures may differ completely in technology, method, and market. Without an inheritance model, a practice adopted for convenience inside one venture (e.g., "Digital Products doesn't need accessibility review because it's just spreadsheets") could silently be read as company policy by someone working on a different venture, or vice versa. Keeping the layers explicit, and keeping precedence rules in one canonical document, prevents that kind of drift.

Where to look next

Report an issue about this page