Company Terminology¶
A glossary of terms used consistently across this repository. When a document uses one of these terms, it means what is defined here unless the document explicitly says otherwise.
Organizational terms¶
Venture
An independently identifiable business line under Devonshire Digital LLC, with its own customer base and (usually) its own brand identity. Example: Shelfery, Digital Products. A venture lives under ventures/<slug>/ in this repository.
Product A specific, shippable thing sold or offered within a venture. Example: a specific Shelfery app, a specific Excel workbook released under Digital Products. A venture may have one or many products.
Component A discrete part of a product — e.g., a specific tab or module within a workbook, a specific screen or subsystem within an app. Components are not independently sold; they exist only in the context of a product.
Slug
The short, lowercase, hyphenated identifier used for a venture or product in file paths and identifiers (e.g., shelfery, digital-products). Slugs should be stable once assigned — changing one breaks links throughout the repository.
Governance and documentation terms¶
Specification
A document that defines what a product or component must do before it is built — inputs, outputs, business rules, and constraints. Required before implementation begins for products that meet the gating criteria described in AGENTS.md.
ADR (Architecture Decision Record)
A record of a material, hard-to-reverse architecture or policy decision, including the context, the decision, and the reasoning. Stored under docs/decisions/, using the template in templates/.
Standard
A concrete, checkable rule — e.g., a naming convention, a formatting requirement, a data-handling rule. Standards are meant to be verifiable, ideally by automated tooling (scripts/check.py). Stored under docs/standards/.
Policy
A statement of what the company requires or prohibits, generally less mechanically checkable than a standard, and more about judgment and principle (e.g., the customer trust principles). Stored primarily under docs/company/ and docs/governance/.
Guide A document that explains how to do something, without itself being a binding rule (e.g., this terminology document, or a walkthrough of a process). Guides may reference policies and standards but are primarily explanatory.
Template
A reusable starting structure for a recurring document type (e.g., the ADR template, a product specification template). Stored under templates/.
Record A document that captures something that happened or was decided, for historical reference, rather than a rule going forward (e.g., a specific ADR is a record; the ADR template is not).
document_id
A stable, unique identifier assigned to every substantive document, in the form DD-<CATEGORY>-<NUMBER> (e.g., DD-COMPANY-001, DD-GOV-001). IDs are never reused, even if a document is retired — a retired document is marked superseded, not deleted and its ID recycled. See docs/governance/documentation-taxonomy.md for the full metadata standard.
Status values¶
Every substantive document carries a status field with one of the following values:
draft— actively being written or revised; not yet proposed for adoption.proposed— considered complete enough for review, but not yet approved by the appropriate human owner.approved— reviewed and formally adopted by the document's owner (a role, not a person). Only a human can move a document to this status; seedocs/company/responsible-ai-principles.md.
At the time of writing, no document in this repository has been marked approved — the repository is in its initial, foundational drafting phase.
Ownership terms¶
Owner (role-based)
Every substantive document has an owner field naming a role (e.g., "Founder", "Repository Maintainer"), never a personal name. This keeps documents valid across personnel changes and avoids implying that governance depends on one specific individual. See docs/governance/authority-and-inheritance.md for how role-based ownership interacts with document authority.
Cross-reference¶
For the full metadata schema (all front-matter fields, their meaning, and validation rules), see docs/governance/documentation-taxonomy.md.