Skip to content

Implementation status

The architecture pages describe the target model in present tense: the design, not a snapshot of the code. This page is the other axis, what is actually built, tracked per capability. The split is deliberate: the architecture stays a stable reference, and build progress lives here instead of rotting the design prose with “shipped in vX” notes.

  • Design certainty (“is this decided?”) lives inline on each page as Open question asides. A page can be almost fully settled yet still carry a few open points.
  • Implementation state (“is this built?”) lives here, and as each page’s status badge. A page can be fully designed and entirely unbuilt, or anywhere in between.

Neither axis is page-binary, and they do not move together.

A third surface carries history and direction, which neither badge captures: the decision log records why a call was made or reversed and where the build diverges from a page, and the roadmap indexes the epics and the architectural arc ahead.

Each architecture page carries one status badge, and the grid below is sourced live from those badges, so it never drifts. The badge is the page’s floor: a page is only Built once every capability it describes is shipped, so a page with one unbuilt corner stays Partial.

BadgeMeaning
DesignThe model is specified; little or none of it is coded yet.
PartialSome capabilities on the page are built and tested; others are still Design.
BuiltEvery capability the page describes is implemented and tested.
DivergedBuilt, but the implementation differs from the design on this page. The page carries a note pointing to what shipped and why; this is a proposed architecture, and building it sometimes changes it.

The repository is public and published ahead of the code, and the build has converged over most of the spine: 23 of the 30 architecture pages are Partial, the data model is Built, and the pages still at Design are the automation and read tier ahead (templates, calculations, expressions, time, views, and AI), plus design-only corners inside Partial pages (for example group scope beyond principal groups). As a page’s badge flips, the grid below follows automatically, because it reads the badges directly.

A Partial page can also carry a divergence in one of its built corners, where the shipped code differs from that part of the prose. The page flags it inline and the decision log records why and when; the Diverged whole-page badge is reserved for a page that is otherwise Built. So the grid shows each page’s build floor, and the inline note plus the decision log carry any per-capability drift above it.

CapabilityStatus
AI Design
Alarms and actions Partial
API Partial
Audit Partial
Calculations Design
Cascade Partial
Commands Partial
Config, secrets, and variables Partial
Core entities Partial
Data collection Partial
Data model Built
Events Partial
Expressions Design
Files and blobs Partial
Groups Partial
Health, KPIs, and service levels Partial
Identity and access Partial
Messaging Partial
Metrics and properties Partial
Nodes Partial
Scaling and deployment Partial
Settings Partial
Storage Partial
Tags Partial
Templates Design
Time Design
UI Partial
Views Design
Workers Partial

The code is built one vertical slice per PR, each a thin cut through the whole stack rather than a horizontal layer. The slice-by-slice history (one entry per merged PR, oldest first) lives on the build log; a page’s badge only flips once all of its capabilities ship, so an early slice can prove a seam without moving any page off Design.