Skip to content

ADR-0002: Company-Level Repository Scope

Status

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

Date

2026-07-10

Context

Devonshire Digital LLC operates (or intends to operate) more than one venture — currently Shelfery and Digital Products, with more possible later. A repository can be scoped narrowly (one repository per product or venture from the start) or broadly (one repository representing the company, holding shared governance and multiple ventures' documentation). This decision needed to be made explicitly before writing any company-level documentation, since it determines where things like standards and decisions live relative to venture-specific content.

Decision

This repository is company-level: it is scoped to Devonshire Digital LLC as a whole and must support multiple, distinct ventures with their own identities, rather than being scoped to a single product or venture. Company-wide governance, standards, and decisions live at the repository root and under docs/; venture-specific material lives under ventures/<slug>/, distinct from but consistent with the company layer.

This decision is about the scope of governance and documentation. It does not decide whether product implementation code also lives in this repository — that is a separate, explicitly open question (see ADR-0007).

Consequences

  • Shared governance infrastructure (standards, ADR process, naming conventions) is written once and applies across all ventures, avoiding duplicated or drifting policy per venture.
  • Requires clear venture boundaries within one repository — the layered model in docs/architecture/company-venture-product-model.md exists specifically to prevent venture-specific practices from being mistaken for company policy or vice versa.
  • A single company-level repository is a larger, more complex space than a single-product repository would be; navigation and onboarding depend on the architecture documentation staying accurate as more ventures are added.

Alternatives Considered

  • Per-venture repositories from day one. Rejected for now: with only two ventures, neither yet at the implementation stage, splitting governance documentation across multiple repositories would duplicate effort and risk immediate drift between ventures' interpretations of shared policy, without a corresponding benefit at this scale.

Follow-up Actions

  • Maintain the ventures/_template/ directory so new ventures start from a consistent structure.
  • Revisit this scope decision if the number of ventures, contributors, or confidentiality boundaries grows enough to justify splitting (see ADR-0007 and docs/architecture/future-repository-strategy.md).

Report an issue about this page