What is still open: the decisions board

Twenty-one architecture choices are tracked on one board. Three are decided, one is deferred, and seventeen carry a recommendation that is waiting for Vinayak. Until he decides, the architecture follows each recommendation, and every entry says how to reverse it.

How to read it.

The three boxes are the three statuses on the board. The recommended ones are grouped by what they shape.
The yellow box is where the open work is.
When a decision changes status, the change is logged in the architecture changelog as a minor version.

Build now: follow the recommendations. Later: each decision's trigger, as written in its entry.

View Mermaid source

flowchart TB
    %% house-style: tour-decisions
    subgraph decided["DECIDED, 7 Oct 2026"]
        direction LR
        d13["D13 Evidence labels"]
        d14["D14 Calibration thresholds"]
        d19["D19 MHE solver: offline benchmark first"]
    end
    subgraph deferred["DEFERRED"]
        direction LR
        d18["D18 Probabilistic stack: choose with the first C15 template"]
    end
    subgraph rec["RECOMMENDED, awaiting Vinayak"]
        direction LR
        store["D1 context store, D20 L2 hosting"]
        plant["D3 twin runtime, D4 Plant Box, D10 writer protocol, D17 NE 178 depth"]
        flow["D2 contracts, D15 safety filter owner, D16 message budgets, D7 fast-loop channel"]
        models["D5 value method, D6 MSPC, D8 foundation models, D9 registry, D11 TabPFN pin"]
        rules["D12 client numbers, D21 LLM gateway"]
    end
    cl(["A status change is a changelog entry and a minor version"])
    rec --> cl
    deferred --> cl

    classDef govc fill:#fff4d6,stroke:#c99a2e,color:#000
    classDef agentc fill:#e8f0ff,stroke:#5b7bd5,color:#000
    classDef loopc fill:#eef7ee,stroke:#4f9a4f,color:#000
    class rec govc
    class cl loopc

What an entry looks like#

Each entry in DECISIONS.md has the same fields: status, options, trade-offs, what uses it, the recommendation, why, the evidence, whether and how it can be reversed, and what it blocks. That last field is the useful one when planning work. D18, for example, blocks only the C15 template that needs Kennedy–O'Hagan calibration, so deferring it costs nothing today.

The three that are settled#

D13 fixes the evidence labels: Measured, Estimated, Assumed or Unknown, plus calibrated or uncalibrated, attached at Evidence and PlantState and carried through to Prescription and ValueRecord. D14 sets calibration thresholds per model class. Estimators and forecasters need 85 to 95% empirical coverage for nominal 90% intervals on unseen data. These are targets, not results. D19 says MHE is benchmarked offline in the cloud first, and a solver and Plant Box placement are chosen only if it beats the Kalman filter on restart episodes.

The open ones that shape the build most#

A few recommendations decide what the first code looks like.

D1 keeps plant context as relational plus event tables in L2, with a link method and confidence on every genealogy edge, rather than a graph database.
D2 drafts all ten contracts now as 0.x.
D3 and D4 put a Python twin on a fanless Linux Plant Box, with a compiled core only if the heartbeat gate fails.
D15 gives the safety filter one owner in the L5 autonomy package, run as edge and cloud copies.
D20 keeps self-managed Postgres and Timescale on EC2 until about 10 plants, then moves to Tiger Cloud.
D21 routes every LLM call through one gateway with a low-cost default model and no plant data sent to a provider the customer has not approved.

If you disagree with one of these, the entry is the place to argue it. Write down the evidence, and the reversal note tells you what changing it would cost.

Go deeper: decisions board · D1 plant context store · architecture changelog