architecture

Type: noun
Register: technical
Domain: platform-wide

Definition

The shape of the system — what the entities are, how information flows, and where services run. Architecture is the HOW that enables user stories. It's expressed as three diagram notes per project: domain model (what), data flow (when), deployment (where).

Properties

• Three views — domain model (entities + relationships), data flow (runtime information movement), deployment (services + infrastructure)
• Each view is its own note — note_type: architecture, with Mermaid diagrams
• The project anchor — architecture diagrams are the stable reference that outlives individual tickets. Stories change, boards churn, architecture evolves slowly.
• Referenced by board items — items carry arch: labels that map to architecture components
• Naming convention — arch-domain-{project}, arch-dataflow-{project}, arch-deployment-{project}

Why it matters

Architecture is the constraint space. It tells you what's possible and what's expensive. When a story asks "can users do X?" the architecture answers "here's how, through these components." When a board item carries arch:westside-app, it means the work touches that component of the architecture.

Distinguishes from

Term	Difference
user story	Stories are WHAT users need. Architecture is HOW the system enables it.
board	The board connects stories to architecture. Architecture is the reference; the board is the execution.
infrastructure	Infrastructure is a subset of architecture — specifically the deployment view. Architecture also includes domain model and data flow.

Relations

• belongs-to: project
• enables: user story
• referenced-by: board items (via arch: labels)