Platform overview
One shared architecture. Each capability has one canonical owner, so definitions never drift between products.
The architecture in one picture
From physical assets to the experience.
Intelligence from DoubleSlit / YNTR is connected only where it is implemented and validated for that product.
Canonical owners
Detailed definitions live on the owner page. Everywhere else links here.
Helix
The single home for identity, all digital twins, lifecycle, permissions and relationships.
Learn more →ViSE
Measurement definitions, analytics, progress and reporting.
Learn more →MTRX
The unified experience that integrates Helix and ViSE.
Learn more →Helix owning the canonical twin model does not mean every sensor reading is stored in Helix. Data ownership, transport, storage, APIs, permissions and retention are defined in each technical design.
The digital-twin stack
Eight layers from the physical world to action, each with one owner. Layers describe the design; what runs in a project is confirmed in its technical design.
| Layer | What it contains | Owner |
|---|---|---|
| Physical | Living Nodes, IoT devices, sensors, machines, buildings, infrastructure | Living Nodes |
| Connection | Connectivity, APIs, edge computing, telemetry, geospatial data | Per project, see interoperability |
| Identity | Human, Asset and Place identity, credentials, permissions | Helix |
| Twin | Human, Asset, Place and Experience Twins, with lifecycle state | Helix |
| Graph | Relationships, context, events, history, dependencies | Helix |
| Measurement | Metrics, analytics calculations, progress and reporting | ViSE |
| Intelligence | AI, prediction, simulation, optimisation (research; per-project) | YNTR and DoubleSlit |
| Experience and action | Dashboards, mobile, web, trails, learning, alerts, recommendations | MTRX and the application |
Do not read the stack as a claim that every layer is implemented in every deployment. The Smart Solar Bench V1.0 Base is pilot deployed; intelligence layers are research until installed and validated.
Why one architecture
Benefits of a single owner per capability.
- One definition of identity across every application
- Metrics defined once, traceable to source and method
- Applications can differ in interface without differing in meaning
- Easier governance: consent, retention and access control in one place
Built to connect, not to replace
Design principles that apply to every product that uses the platform.
Open and modular
Open APIs and a modular architecture, documented by actual availability.
Portable
Data portability and permissioned data sharing.
Separated
Identity kept separate from measurement, with role-based access.
Standards-aware
Designed with reference to emerging digital-twin and interoperability standards, with no certification claimed.
Discuss your use case
We will map it to the right parts of the platform.