Skip to content

Devonshire Digital

This repository is the company-level governance and documentation source of truth for Devonshire Digital LLC. It is not a product codebase, not a scratchpad, and not the only place company work happens — but for anything that qualifies as an approved rule, standard, or decision, this repository is authoritative.

What Devonshire Digital LLC is

Devonshire Digital LLC is a parent company that develops and operates multiple, independently branded digital products under separate ventures. It is not defined by a single product category — see docs/company/company-overview.md for the full description and an explicit list of what the company is not (e.g., not solely an "Excel template company," not a consulting firm, not a passive holding company).

What this repository is

  • The canonical home for company-wide policy, standards, governance, and architecture documentation.
  • The home for AI-agent operating instructions (tool-agnostic and tool-specific).
  • The home for venture-specific rules, under ventures/<slug>/.
  • A place where decisions are recorded (ADRs) so that reasoning survives past the people who made it.

What this repository is NOT

  • Not a place for casual notes, scratch files, or unreviewed personal drafts. Use work/ for structured, transient work products (see docs/ai/planning-and-work-logs.md); do not treat the repo root or docs/ as a notebook.
  • Not guaranteed to contain complete product source code. Product implementation code may live in separate repositories per venture. This repository governs rules, not necessarily all code.
  • Not a public-facing marketing site or legal filing. See NOTICE.md for the current (provisional, not legally reviewed) proprietary notice.

Company / venture / product hierarchy

Devonshire Digital LLC (parent company, legal entity)
└── Venture (independently branded or internally-named business line)
    └── Product (a specific thing sold or shipped)
        └── Component (a discrete part of a product, e.g. a workbook tab, a module)

Terminology is defined precisely in docs/company/terminology.md.

Current ventures

Venture Slug Status Notes
Shelfery shelfery Provisional Home food-storage / pantry app. Distinct customer-facing brand (terracotta #A6552E). Not branded under any "DDLabs" umbrella.
Digital Products digital-products Provisional Internal working name for a venture producing digital productivity products (Excel workbooks and similar). Public brand name not finalized.

Each venture has its own directory under ventures/<slug>/ with its own AGENTS.md, brand notes, and product specifications. Venture identities are deliberately kept separate — see docs/company/brand-architecture.md for why shared ownership does not imply shared branding.

Shelfery brand details and the Digital Products working name are provisional and not final. Do not treat them as settled facts outside this repository's own caveats.

Where company rules live

  • docs/company/ — mission, principles, product philosophy, brand architecture, trust and evidence principles, terminology.
  • docs/governance/ — authority and inheritance rules, documentation taxonomy, the assumptions register, and the open-questions log.
  • docs/architecture/ — company-level architecture guidance that applies across ventures.
  • docs/standards/ — concrete, checkable standards (naming, formatting, data handling, etc.).
  • docs/decisions/ — architecture decision records (ADRs).

Where AI-agent instructions live

  • AGENTS.md — the tool-agnostic operating contract for any AI or coding agent working in this repo.
  • CLAUDE.md — Claude Code-specific entry point (defers to AGENTS.md).
  • GEMINI.md — Gemini CLI-specific entry point (defers to AGENTS.md).
  • docs/ai/ — the deeper AI operating manual: repository context, context-loading order, planning and work-log requirements, prohibited behaviors.

Where venture-specific rules live

ventures/<slug>/ — each venture directory contains venture-specific AGENTS.md, brand notes, and product specifications that apply in addition to company-wide rules. Venture rules cannot override company policy; they can only add constraints. See docs/governance/authority-and-inheritance.md.

Git vs. Notion

  • Git (this repository) is canonical for approved documentation: policies, standards, ADRs, specifications.
  • Notion is used for day-to-day management, roadmap tracking, and informal planning. Notion is convenient but does not override Git. If Notion and this repository disagree, this repository wins unless and until this repository is updated.

How a human contributor should begin

  1. Read this file in full.
  2. Read CONTRIBUTING.md for how to propose changes.
  3. Read docs/company/ for company-wide principles.
  4. If working on a specific venture, read that venture's ventures/<slug>/AGENTS.md and any product specs under it.
  5. Check docs/governance/open-questions.md before assuming something is settled.

How an AI agent should begin

  1. Read AGENTS.md.
  2. Read docs/ai/repository-context.md.
  3. Read the applicable venture AGENTS.md, if the task touches a venture.
  4. Read applicable standards and ADRs for the area of work.
  5. Follow the context-loading order in docs/ai/context-loading-order.md.

How to propose a new venture

See the venture creation process referenced in docs/governance/ and use scripts/create_venture.py to scaffold the required directory structure. A new venture requires, at minimum: a working name, a slug, a rationale, and an entry in the portfolio (portfolio/). See docs/company/portfolio-strategy.md.

How to propose a new product

Within an existing venture, a new product requires a specification before implementation begins. Use scripts/create_product.py to scaffold it. Product specification gates are described in AGENTS.md and the applicable venture's own rules.

How to record a decision (ADR)

Material architecture or policy decisions are recorded as Architecture Decision Records under docs/decisions/, using the template in templates/. See docs/architecture/ for how ADRs relate to standards, and CONTRIBUTING.md for when an ADR is required.

How to run validation

python scripts/check.py

This runs the repository's structural and documentation checks (metadata completeness, broken internal links, naming conventions, etc.). Run it before considering any documentation change complete. Automated tests live under tests/ and can be run with:

python -m unittest discover tests

Current maturity level

This repository is early-stage and documentation-first. It establishes foundational governance before significant product code exists anywhere in the company. Expect gaps, provisional decisions, and open questions — they are tracked deliberately rather than hidden. See:

Nothing in this repository should be read as legally reviewed, finalized branding, or a commitment about future product direction unless explicitly marked status: approved — and as of this writing, nothing in the repository carries that status.

Report an issue about this page