Architecture Decision Records (ADRs)

What is an ADR?

An ADR documents a significant architecture decision: what was decided, why, and what the alternatives were. Dash creates a new ADR whenever a non-obvious technical decision is made.

ADR Template

## ADR-XXX: [Decision Title]

**Status:** Proposed | Accepted | Deprecated | Superseded  
**Date:** YYYY-MM-DD  
**Deciders:** [Names]

### Context
_What is the issue that motivated this decision?_

### Decision
_What was decided?_

### Rationale
_Why this approach vs. alternatives?_

### Consequences
_What are the trade-offs? What becomes easier/harder?_

Decisions Log

ADR-001: PostgreSQL 15 as primary database

Status: Accepted
Decision: Use PostgreSQL 15 (via Supabase) as the only database. No Redis, no Mongo.
Rationale: Simplicity. RLS (Row Level Security) handles multi-tenancy cleanly. Full SQL for LLM SQL generation.

ADR-002: Azure OpenAI over direct OpenAI API

Status: Accepted
Decision: All LLM calls go through Azure OpenAI, not api.openai.com directly.
Rationale: Data residency, enterprise compliance, and rate limit management.

ADR-003: Twenty CRM as company CRM

Status: Accepted (Mar 11, 2026)
Decision: Twenty-CRM is the ONLY CRM. Local JSON files deprecated.
Rationale: Central source of truth, API access, relationship tracking.

ADR-004: Twill Brain Obsidian Vault (Mar 21, 2026)

Status: Accepted
Decision: All agent memory and company knowledge lives in the Obsidian vault at Morty021/twill-brain.
Rationale: Shared context across Morty, Dash, Remi. Git-versioned. Web-accessible via vault.twill.biz.

Dash adds new ADRs here when significant decisions are made during implementation.