Skip to content

ADR-0003: Layered Company/Venture/Product Inheritance

Status

proposed — decided during initial drafting; not yet formally ratified by a human review checkpoint.

Date

2026-07-10

Context

With multiple ventures under one company-level repository (ADR-0002), some rule is needed for how company-wide policy, venture-specific practice, product-specific specification, reusable components, and eventual implementation relate to and constrain each other. Without an explicit model, it is easy for a convenience adopted inside one venture to be silently read as company-wide policy, or for company policy to be silently weakened by a venture-level exception nobody flagged as such.

Decision

Company, venture, product, component, and implementation documentation uses a layered inheritance model: each layer may add detail and make decisions specific to its own scope, but may not override or weaken a rule set by the layer above it. The full model, with examples, is documented in docs/architecture/company-venture-product-model.md; the precedence rules for resolving apparent conflicts between layers are documented canonically in docs/governance/authority-and-inheritance.md.

Consequences

  • Prevents venture-specific practices from silently becoming company policy, and prevents company policy from being silently weakened at the venture or product level.
  • Requires discipline about where new documentation is placed — a company-wide-sounding rule written inside a venture's directory does not become company policy just because it was written broadly; it must be raised to the company layer deliberately if it should apply everywhere.
  • Adds a small amount of indirection: understanding the full rule set for a given venture or product may require reading more than one layer's documentation.

Alternatives Considered

  • Flat, non-hierarchical documentation (every venture and product documents itself independently with no formal inheritance). Rejected: with no explicit precedence, conflicts between company-wide and venture-specific practice would have no defined resolution, inviting drift.
  • Fully centralized documentation (no venture-specific standards permitted at all, everything written at company level). Rejected: given that ventures may use entirely different technology stacks and methods (see docs/architecture/company-venture-product-model.md), forcing all detail into company-level documents would either bloat them with venture-specific detail irrelevant to other ventures, or suppress necessary venture-specific guidance.

Follow-up Actions

Report an issue about this page