The six layers and the repos behind them

The architecture has six conceptual layers: Plant systems, Context, Analytics, Decision, Action and Value. The code lives in repo layers L0 to L6, which map onto those six but are not the same thing, so this stop keeps the two vocabularies apart.

How to read it.

The top row is the conceptual model from architecture section 3.3. Data flows left to right.
Dotted lines show which repo layer implements which conceptual layer, following section 3.5.
The yellow boxes cut across everything: governance applies to every layer, and SE owns the contracts every repo uses. Agents sit outside the stack.

Build now: the mapping as drawn. Later: the Plant Box fast loop, which runs pieces of L1, L3 and L5 at the plant.

View Mermaid source

flowchart TB
    %% house-style: tour-layer-repo-map
    subgraph concept["Conceptual layers"]
        direction LR
        c1["① Plant systems"] --> c2["② Context"] --> c3["③ Analytics"] --> c4["④ Decision"] --> c5["⑤ Action"] --> c6["⑥ Value"]
    end
    subgraph repos["Repo layers"]
        direction LR
        r1["L1 connectors-edge, connectors-cloud, connectors-doc"]
        r2["L2 universal-repositary"]
        r3["L3 intelligence-core, rulepacks, evals"]
        r4["L4 knowledge-reasoning"]
        r5["L5 closure-verification"]
        r6["L6 experience-integration"]
    end
    gov["Governance plane: data quality, registry, autonomy policy, budgets, audit, safety filter"]
    se["L0 SE platform pack: the ten contracts"]
    agents["Agents: read-only tools, propose only"]
    r1 -.-> c2
    r2 -.-> c2
    r3 -.-> c3
    r4 -.-> c4
    r5 -.-> c5
    r5 -.-> c6
    r6 -. "presents" .-> c5

    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 gov,se govc
    class agents agentc

What each repo layer does#

Layer ① has no repo: it is the customer's own PLCs, DCS, meters, MES and ERP, which Stamped reads. The governance plane has no single repo either; its pieces have named owners, such as the registry in L3 and the AutonomyPolicy and safety filter in L5.

L1 is three connector repos that read plant and document signals and turn them into canonical JSON envelopes. connectors-edge is the plant gateway, connectors-cloud is the cloud intake and connectors-doc handles documents such as utility bills. L1 never opens the database, and the edge agent never writes to OT registers.

L2 is universal-repositary (the repo name really is spelled that way), the store of record in TimescaleDB: readings, assets, topology, context records and, as direction, lots and genealogy. It is the only layer that opens TimescaleDB for plant truth. Everyone else reads it over HTTP with service keys.

In L3, intelligence-core, intelligence-rulepacks and intelligence-evals run jobs 1 to 5 of the seven-job chain (SPC, MSPC, residuals, estimation, prediction) and the method router that may abstain. L3 also owns the one model registry (D9).

L4 is knowledge-reasoning, the decision layer. Its DecisionRuntime turns evidence into at most one owned Prescription draft per condition, or withholds with a trace. It also runs scheduling repair and Ask, where agents answer questions through typed read-only tools.

L5 is closure-verification and owns the live card. It assigns a person, notifies through one sender, tracks the workflow, verifies against telemetry and writes the value record. In the conceptual model it covers both Action and Value, and it owns the AutonomyPolicy and the safety filter (D15).

L6 is experience-integration, the customer's control room: one action queue, cards and Ask. A backend-for-frontend composes L2, L4 and L5 over HTTP, so the browser never holds service keys.

Rules between repos#

Repos talk only through versioned contracts in the SE pack. That one rule removes most integration arguments: if a field is not in a contract, a downstream repo cannot depend on it. L4 may keep derived data of its own, such as decision traces and the situation model, but never a second record of the plant.

Each layer also has a list of things it must not do. L4 must not assign the final person or send messages, L5 must not invent recommendations, and L6 must not hold keys in the browser or show a summed rupee headline. Read the must-not list on a layer's page before you change that repo.

Go deeper: layer model · repo layers: jobs and must-nots · layer pages