Summary
Today Stamped runs a slow loop: read connectors at the plant, a TimescaleDB store in the cloud, engines, a shadow decision runtime and a card machine that sends WhatsApp messages. The fast loop at the plant exists only on paper. The architecture keeps the five-layer thesis from the brief with four changes: two loops instead of one stack, governance as a plane, experiments as a first-class action, and agents as clients rather than a layer. Finalising added one owner for every shared piece, a scope cut for the first three plants and the operating rules.
The code is spread over eleven product repos plus the website repo, which is out of scope here; stamped-external holds docs, contracts and ADRs only. What runs today is a slow loop: read connectors at the plant, a TimescaleDB store in the cloud, energy and equipment engines, a shadow decision runtime, and a card machine that sends WhatsApp messages and checks outcomes against telemetry. Nothing runs in seconds at the plant. The fast loop in ADR-033 to ADR-038 (twin, writer, fast read, Plant BoxPlant-side computer for the fast loop (direction; D4) sync, genealogy) exists only on paper, plus offline prototype scripts on one customer's exported data.
The five-layer thesis in the brief holds up, with four changes:
- Two loops, not one stack. A plant-side fast loop (seconds) and a cloud-side slow loop (minutes to weeks) share contracts but run in different places with different failure rules.
- Governance is a plane, not a layer. Data quality, model registry, autonomy policy and audit cut across every layer.
- Experiments are a first-class action. A planned step test or switchback is how the analytical layer earns the right to recommend a set point. It sits in the action layer with its own policy.
- Agents are clients, not a layer. LLM agents read from the context, analytical and decision layers through typed tools and propose; deterministic code and people dispose.
Evening stress-test additions (same day; detail in section 3.3b):
- Seven-job analytics chain as the spine of analytical → decision work: SPC → MSPC → residuals → estimation → prediction → optimisation → control, with a method-selection router that may abstain.
- Predictive safety filter as an outer shell around every proposal source (rule, advisor, human, RL) before closed loop or write-back.
- Write path framed by NAMUR Open Architecture (NE 175) and NE 178 Verification of Request — additive M+O channel, not a bypass of core process control.
- Sustainment as part of the governance plane — benefit tracking, re-ID and model health ship with any advisor or control mode (E11).
The rest of this document gives the evidence for each.
Finalising added three things a builder needs: one owner for every shared piece (store, ingest path, registry, sender, ledger enum, safety filter), a scope cut that says what the first three plants get and what waits for a named trigger (section 10), and the operating rules (security, degraded modes, observability, deployment, cost) in sections 11–16.
1.1 Names used in this document#
| Name | Means | Not to be confused with |
|---|---|---|
| Layer 1 to Layer 6 (①–⑥ in diagrams) | The conceptual layers: Plant systems, Context, Analytics, Decision, Action, Value | Repo layers |
| L0 to L6 | Repo layers (SE, connectors, L2 store, L3 intelligence, KR, L5 closure, L6 experience); mapped in section 3.5 | Conceptual layers |
| AL0 to AL5 | Autonomy levels (section 6) | Either kind of layer |
| measured, confirmed, modeled, unknown | Contract tier of a claim (section 5.2). "Confirmed" is used only in this sense | Evidence labels |
| Measured, Estimated, Assumed, Unknown | Evidence label of one quantity, plus calibrated or uncalibrated (D13) | Contract tiers |
| supported, refuted, untested | State of a causal hypothesis after an experiment | Contract tiers |
| verified | Only a counterfactual M&V result that passed its model-fit checks; never a bill claim | ops_confirmed |
| operating envelope | Tag limits, steps and rates inside an AutonomyPolicy | The Envelope contract (message header, section 5.10) |
| Plant Box | The plant-side computer that runs the fast loop (D4) | The edge-agent, which only reads |
1.2 Target state for the first three plants#
What "built" means before the fourth plant, so the scope cut in section 10 has a goal:
- Slow loop live. Read connectors feed one ingest path into L2; L3 findings and KR prescriptions reach people as L5 cards through one sender; outcomes land in a multi-KPI ValueRecord with switchback or adjusted-baseline method (D5).
- Fast loop in shadow. The Plant Box reads fast tags, runs the estimator and the safety filter, and logs what it would have written. AL1Autonomy levels (direction; fast-loop stages 1–3 = AL1–AL3) messages are live; AL2 confirmed writes stay in shadow until the ledger shows same-condition wins.
- One of each. One context store (D1), one registry (D9), one sender (D16), one ledger enum (D2), one safety filter (D15), ten 0.x contracts (D2). These follow the RECOMMENDED positions in
DECISIONS.mduntil Vinayak decides. - Honest numbers. Every client-facing number has a script and commit (D12); every quantity carries an evidence label (D13).
- Running cost about ₹6,000 a month for one plant and about ₹2,900 per plant at 100 plants, base case (section 16).
Page history: last 5 changes
- docs(research): retire stale research to archive/research-2026-10 with a register
ab84821 - docs(technical): rewrite fast-loop/; all architecture diagrams in house style
7330f47 - docs(technical): archive archify; add SYSTEM_VIEWS.md house diagrams; check_docs --min
1e190b6 - docs(technical): carry product sections; rewrite README and pointers
ee1e818 - docs(technical): split decision board into DECISIONS.md
b4db9d4