Architecture decisions

Dated architecture decision records and their status.

Dated records of direction-setting choices: the problem, the decision, the alternatives rejected, the consequences accepted, and what evidence would cause a revisit. A decision's status describes direction, not implementation. Supersede a record with evidence instead of accumulating contradictory guidance.

ADRDateStatus
0001 One portable model in a boundary-based monorepo2026-10-31Adopted; draft source subset implemented
0002 Shared processing semantics with target adapters2026-10-31Adopted; Rust compiler/engine and C ABI implemented; JUCE/state/legacy parity pending
0003 One Frame renderer and one authoring API2026-10-31Adopted; draft Frame bindings implemented as data
0004 Immutable releases and local recall before marketplace breadth2026-10-31Adopted; development releases and local recall exist, managed services and exporters open
0005 Executable local platform before managed deployment2026-10-31Development adapter adopted; SQLite removed, superseded by 0009
0006 AWS hosting and reusable immutable media2026-10-31Adopted at the user's request; lean pilot deployed, launch qualification pending
0007 Typed media signals, execution domains and a WebGPU video engine2026-11-01Adopted for planning in sprint v0.0.5; nothing implemented
0008 Takes as the recording model, a data cable type, and connections separate from identities2026-11-01Adopted; implemented in the browser and API with fixtures (sprint v0.0.6); live providers and native hosts unqualified
0009 PostgreSQL only, with a Drizzle schema and one baseline2026-11-01Adopted; implemented except pilot adoption and WP-H in progress
0010 One analysis engine: Rust descriptors native and WASM, Node parsers, optional CLAP on ONNX2026-11-01Adopted; implemented in sprint v0.0.8; the embedding lane unsupported until a CLAP export is pinned

| 0011 Durable node items and one channel Mixer | 2026-11-01 | Accepted; implementation and verification tracked in sprint v0.0.16 |

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#FAFAF7', 'primaryTextColor': '#1C1C1B', 'primaryBorderColor': '#1C1C1B', 'lineColor': '#64645F', 'fontFamily': 'DM Sans, Inter, system-ui, sans-serif'}}}%%
flowchart LR
  A1["0001<br/>one portable model"] --> A2["0002<br/>shared engine"]
  A1 --> A3["0003<br/>one renderer, one authoring API"]
  A1 --> A4["0004<br/>immutable releases first"]
  A4 --> A5["0005<br/>executable local platform"]
  A5 --> A6["0006<br/>AWS hosting and media"]
  A2 --> A7["0007<br/>media signals and domains"]
  A3 --> A7
  A7 --> A8["0008<br/>takes, data cables, connections"]
  A6 --> A8
  A5 --> A9["0009<br/>PostgreSQL only, Drizzle"]
  A6 --> A9
  A2 --> A10["0010<br/>one analysis engine"]
  A6 --> A10

  classDef source fill:#F0442E,stroke:#1C1C1B,color:#FAFAF7
  classDef shared fill:#DCEBDD,stroke:#1C1C1B,color:#1C1C1B
  class A1 source
  class A2,A3,A4,A5,A6,A7,A8,A9,A10 shared

Writing a new decision#

Use the next number and the shape of the existing records: Date and status, Problem, Decision, Alternatives, Consequences, and the evidence needed to revisit. Keep detailed data contracts in specs rather than duplicating them here, and link the architecture document that applies the decision.

Edit this page on GitHub

esc

↑ ↓ move↩ open⌘↩ new tabesc close