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.
Two axes, kept separate
Section titled “Two axes, kept separate”- Design certainty (“is this decided?”) lives inline on each page as
Open questionasides. 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.
Badge legend
Section titled “Badge legend”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.
| Badge | Meaning |
|---|---|
| Design | The model is specified; little or none of it is coded yet. |
| Partial | Some capabilities on the page are built and tested; others are still Design. |
| Built | Every capability the page describes is implemented and tested. |
| Diverged | Built, 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.
The grid
Section titled “The grid”| Capability | Status |
|---|---|
| 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 |
Build progress
Section titled “Build progress”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.