ES-STRUCTURE-001 — Engineering Standard Layout

Purpose

Define the canonical directory structure for Engineering-Standard/ so that every document has exactly one correct placement and agents can resolve placement without human guidance.

Top-Level Directories

Directory	Contains	Placement rule
architecture/	System design, component models, boundary maps, capability models	How systems are structured
authority/	Identity, authority, capability, and obligation contracts	Who owns what and who can do what
decision-records/	ADRs (Architecture Decision Records)	Why a decision was made
governance/	Constitutions, ownership matrices, rule inventories, classification	Organizational governance artifacts
indexes/	BLU-BIBLE, knowledge maps, cross-reference indexes	Finding other documents
infrastructure/	NAS, backup, deployment topology, Terraform, operational models	Physical and cloud infrastructure
integration/	Adoption guides, migration plans, integration patterns	How systems connect
operating-model/	Factory contracts, agent lifecycle, execution rules, Beads ownership, board models	How work gets done
reference/	API schemas, terminology, architecture snapshots, catalogs	Lookup material that is not normative
rules/	Operational rules, execution protocols, CI rules, git hygiene	Enforceable operational constraints
standards/	Normative technical standards organized by domain	What the rules are
templates/	Document and repository templates	Reusable starting points
tools/	Scripts, importers, and utilities that support the standard	Automation for governance
verification/	Evidence, audit reports, receipts, convergence audits, ledgers	Proof that standards were met

Standards Subdirectories

Subdirectory	Contains
standards/core/	Domain-independent standards (git, evidence, naming, auth, execution, Cedar, receipts)
standards/drupal/	Drupal-specific standards
standards/drupal/ddev/	DDEV-specific standards
standards/gas-city/	Gas City worker contracts and runtime standards
standards/platforms/	Platform-specific standards (Apple, runtime, security)
standards/architecture/	Architecture standards (capability convergence, inference topology)
standards/protocols/	Protocol definitions
standards/schemas/	Schema files (YAML, JSON)

Placement Rules

1. Every document belongs in exactly one directory. If a document could live in two places, use the placement rule column above to resolve.
2. Standards go in standards/<domain>/. Never leave standards flat at the standards/ root.
3. Evidence and verification go in verification/. Not in decision-records/.
4. Decision records go in decision-records/. Only ADRs. Not evidence, not verification, not templates.
5. Templates go in templates/. Not embedded in the directory they template.
6. Architecture documents describe structure. Operating-model documents describe process. Do not mix.
7. Doctrine and lifecycle documents go in operating-model/. Not in standards/core/.
8. Each directory MUST have a README.md that states what belongs there and links to this standard.

Anti-Patterns

• Flat file dumps at standards/ root → move to standards/<domain>/
• Evidence buried in decision-records/ → move to verification/
• Architecture docs in governance/ → move to architecture/
• Doctrine docs in standards/core/ → move to operating-model/
• Templates embedded in feature dirs → move to templates/<feature>/
• Wrong-level directories (e.g. Runtime/, platform/) → consolidate into canonical dirs