Waterschap Brabantse Delta · R&D lab · architecture artifact

One platform, many disciplines — the modular blueprint

Claude (Fable 5) · R&D-lab first version 2026-08-09 last updated 2026-08-11 version 2.3 draft
Every engineering discipline in our work — electrical, ICT/networking, infrastructure, physical installations, process technology, instrumentation, mechanical — is one facet of the same asset. The blueprint keeps them modular yet lets them meet in one picture: each tool becomes a versioned module (a package, or a container once it owns a port), tools talk only over versioned contracts, and the same modules run in both estates — thegoldenbasket.nl at home and pass.wbd-rd.nl at work. Since v1 this stopped being a plan: elecIO exists as the second core (the electrical engines, extracted verbatim with behaviour-neutral proof), the flowio service (document API, append-only versions) runs live, and the master application — one shell, one visual language, built apart from both host apps — is a decided track (2026-08-11), not a horizon.

The whole chain in one picture — from intake to RESOLV

One asset, one journey. Specs enter once; arrival cannot proceed unless the type exists; the drawings put the asset in its process and electrical context; the runtime binds on PT → UUID and telemetry follows the tag. RESOLV is the one window over every station. Facts live in the register, behaviour lives in the engine packages, values live in telemetry — one source per fact, joined by the tag.

6 RESOLV — one window over all three threads and the spine view · draw · operate; every station below opens in the same shell no matching type → it does not proceed 1 the type — intake specs via the form (manual) or supplier API asset-catalog the type-truth: specs · datasheets 2 the device — purchasing goods arrive from the supplier · scan at the door 3 the position — design the drawings mint the PT-tag: where it sits, how it is wired procesIO · P&ID topology · position-vs-parent → register elecIO · schema & cabinet supply & wiring: group · terminals · channel nets/phase + NEN checks BEFORE energising the threads meet type + position (tag) + device (uuid) become ONE asset in the register spec match · dedup · mint · QR · custody the three threads run on their own clocks — usually design first, then purchasing — they co-exist, and only have to meet here ▸ 4 EVOLV — bind PT→UUID: pulls identity + measurement profile from the register 5 telemetry FROST Thing per tag · live values · the line keeps running → thread 1 · the type thread 2 · the device (purchasing) thread 3 · the position (design) a gate that ends the line the register carries all three threads — passport + asset-catalog identity = tag (the position, minted by design) · occupancy = uuid (the device, minted at the door) · types & specs = the catalogue. Every station reads and writes here over /v1; the meet-station is nothing more than these three keys becoming one row.
Figure 1 — Three threads, three clocks: the type (intake → catalogue), the device (purchasing) and the position (design — the two drawings) each run on their own timeline; usually design leads and purchasing follows, but they co-exist. They only have to meet at the meet-station — no matching type and the line ends there. Only after all three are one does the spine continue: EVOLV binds PT→UUID and telemetry follows the tag. The register is the ground under all of it; RESOLV the window over it.

The module view — who ships what

Every module ships one thing and is consumed over one contract. Two kinds of cargo exist: shapes plug into the drawing canvas (flowio), rules plug into the engine that owns them — elecIO for everything wired (electrical and network cabling), general-functions for process/runtime. Facts never travel as code: they live in the register and are read over /v1.

modulewhat it isshipsconsumed by
@wbd-rd/flowioTHE CANVAS — select · drag · relate · insert; the editor grammar every screen must matchnpm 0.1.1 + the flowio service (document API, append-only versions, render.svg) — live on both estatesgoldenbasket process tab · RESOLV · Node-RED viewer (next) · passport adoption (next)
@wbd-rd/elecioTHE WIRING ENGINES — shape language, nets/phase, NEN checks, wire router, rail layoutnpm 0.1.0 · 28 gates · verbatim from goldenbasket with behaviour-neutral proofgoldenbasket installation and network tabs (PR open) · RESOLV cabinet screen (M2)
@wbd-rd/general-functionsPROCESS/RUNTIME BEHAVIOUR — domains, S88 command registry, units, curves, reconcilenpm 1.1.0 on the registry13 EVOLV node repos · dashboards
passportTHE REGISTER — tag = position, uuid = device, custody, QR resolver, measurement tree/v1 REST + field app (arrival, scan, mint)arrival flow · atlas · coresync/EVOLV · RESOLV assets screen (M3)
asset-catalogTHE TYPE-TRUTH — specs, datasheets, validated writes/v1 REST (/asset-spec)intake form & supplier API · passport spec-match · RESOLV
EVOLVTHE RUNTIME — Node-RED palette, ISA-88, binds PT→UUIDimage-based palette (registry)plants & edge · FROST
FROST + historianTELEMETRY — one Thing per tag, live values and historySensorThings /v1.1 · Z-info bridgedashboards · RESOLV live screen (M4)
RESOLVTHE MASTER SHELL — one window, one visual language; imports all of the above, rebuilds none of itapp per estate, behind its own SSOpeople

Reading rule: a row never reaches into another row's store — it consumes what that row ships. That single rule is what keeps the whole table modular.

The disciplines, as modules

Each discipline is not a separate program — it is a domain pack: a shape catalogue plus a thin adapter that projects the host's own records onto the shared model. Same core, different vocabulary.

Electricalbreakers, DIN rails, terminal strips → elektra shapes on the canvas; nets/phase, checks, wire router and rail layout are the elecIO engines
ICT / networkingswitches, ports, VLANs → netwerk shapes on the canvas; cabling & routing ride the elecIO wiring engines (today: the network tab already routes with the same router as the electrical tab)
Process technologypumps, valves, exchangers → proces pack (ready today)
Instrumentationmeasurements and their position vs equipment → the assets derivation
Mechanicalrotating machines, S88 state → general-functions equipment modules
Infrastructurethe stacks, contracts and deploy model themselves → RnD/infra
Physical installationsthe built asset a passport points at → identity by tag (device is just occupancy)

The master application — one shell, one visual language

Decided 2026-08-11: the master application is built apart from pass.wbd-rd.nl and thegoldenbasket.nl — a separate shell that imports the modules, the way Node-RED imports palette packages. The host apps keep running; the master app is where the COMOS goal lands: every discipline on one canvas, one interaction grammar, one asset backbone.

The grammar is set by what already works, measured against each other:

Selecting, dragging, relating — flowio is the bar the process editor's select/drag/snap/insert UX is the reference every screen must match; it ships in @wbd-rd/flowio today
Wiring — elecIO is the bar the installation tab's wire-to-terminal interaction is the reference for connections; it ships in @wbd-rd/elecio today
Component creation — the gap to close creating components in the electrical view is not yet as good as flowio's palette flow; the master app closes this by using ONE palette/preset flow (flowio's) over every domain pack
Asset lifecycle — reuse passport as-is identity by tag, custody, verplaats(toestel, plaats), QR flows and the measurement tree are built and reviewed — the master app consumes them over /v1, it does not rebuild them
master application (shell) one canvas · one palette · one selection model · one theme — per estate, behind its own SSO schema editorflowio kern + packs cabinet & wiringelecIO motoren asset passportpassport /v1 client live & control/live per tag · cmd path modules are imported, not forked — every screen speaks the same drag/select/relate grammar (flowio) and the same wiring grammar (elecIO) flowio servicedocuments · versions · svg passport/v1 register · custody asset-catalog/v1 types · specs telemetryFROST · Z-info · MQTT one writer per store · versioned contracts · identity = tag The same shell runs at home and at work; only the data, the SSO realm and the service endpoints differ.
Figure 3 — The master application composes the existing modules over their public contracts. Nothing is rebuilt: flowio brings the editor grammar, elecIO the electrical engines, passport the asset lifecycle, and telemetry joins on the tag.

The three rules that keep it modular

One shared core, one truth. The framework-free logic ships as a semver package on the Gitea registry. No git-SHA pins, no vendored copies — consumers pin a version, and a breaking change carries a migration line anyone can run.
One writer per store, talk over /v1. No shared files or tables across a boundary. Whoever wants data asks the owner over a path-versioned REST contract with an OpenAPI descriptor — the way FROST /v1.1 already works.
Identity is the tag, not the device. A pump that gets replaced keeps its tag; the measurement chain must not fall over. The drawing carries the tag and the relation; the register fills in the rest. One source per fact.

Where it stands

PhaseWhatStatus
0–2registry packages (general-functions 1.1.0, 13 consumers) · /v1 on passport & asset-catalog · back-doors closed · node-red cutoverlive
E@wbd-rd/elecio v0.1.0 — shapes, nets/phase, checks, wire router, rails; extracted verbatim with behaviour-neutral proof (4 measurement gates byte-identical); CI greenlive
E6thegoldenbasket consumes elecIO back (vendor + re-export shims)PR open
F1flowio service: document API, append-only versions, If-Match, render.svg — running at home; registry image + stack merged for worklive
Mmaster application — separate shell, one visual language (§3)next build
F2–F4viewer (same build as the editor — never a second renderer) · node-red-contrib-flowionext
K·Tone relations derivation · passport instance at home · /live per tag · control last (test-mode gate)next

Nothing changes in functionality while this moves; code quality only goes up. Every step is a move-commit first (behaviour identical), a change-commit second (measured).

Provenance

Source of truth: the revamp plan in ~/plans/revamp/ on the work machine (secondBrain was retired 2026-08-10; archive kept) and its work-side copy in RnD/infra/docs/revamp/ (README + migration doctrine + flowio architecture). Runtime facts verified 2026-08-11: elecIO v0.1.0 tag + CI, the live flowio /healthz (home instance), the registry package list, and the merged infra stack. Diagram is hand-drawn inline SVG in the house theme. Contact: R&D lab.