Architecture
What is real, what is built for you, and what is not there yet
An architecture diagram with no implementation status attached is a drawing of an intention. Every stage below is split three ways, and the third column is the one worth reading first.
Before you read the diagram
This is the architecture Alsadaany deployments are built to. It is not a description of a running production estate: no customer deployment exists today, the platform is in development, and the stages below carry the stage each has actually reached. Read the Not yet column as seriously as the other two.
The chain
Seven stages, in order
Data enters on the left and a change to the physical operation comes out on the right. The last stage returns to the first, which is what makes it a twin rather than a study.
What the operation already records
Operational data
Status: Available
The systems that hold your process, production and movement data. The twin reads from them and does not become a system of record for any of it, which keeps the integration boundary small and keeps ownership where it already is.
In the platform
Nothing at this stage.
Built per engagement
- Survey of what data exists, in what state, and what it can support
- Agreement on the integration boundary before anything is built
- Historical extracts for calibration and for validation
Not yet
- Shipped connectors for OPC UA, MQTT, SCADA, MES or ERP
Getting data in, and refusing it when it is wrong
Ingestion and validation
Status: Prototype
Input is uploaded, hashed and validated before anything runs against it. Validation happens twice: once against the platform's own contract, then against the rules of the domain plugin that will consume it.
In the platform
- Upload, hashing and content-addressed storage of inputs
- Two-stage validation: engine contract, then plugin rules
Built per engagement
- Mapping from your export formats into the model's inputs
- Cleaning rules, and the decision about what to do with gaps
Not yet
- Streaming ingestion from a live plant feed
The structured description of the operation
Digital twin model
Status: Available
Objects, relationships, states, events, constraints and actions, expressed in the terms the operation actually uses. Everything above this layer computes over it, and no layer above it can be better than this one.
In the platform
- Domain models as plugins against a published contract
- Model definitions held as data rather than written into a build
Built per engagement
- The model of your specific operation, built with the people who run it
- Calibration against your operational history
- Out-of-sample validation, with the deviation reported
Not yet
- A documented interchange format so a model outlives its first deployment
Running the model forward
Simulation and execution
Status: Prototype
A job is submitted over the API and moves through a state machine; a worker executes the plugin against validated inputs. Runs are seeded and replicated, so a result is a distribution rather than a single sample.
In the platform
- Job state machine, worker runtime and artifact store
- Local execution with no outbound network call
- Cloud execution against object storage and Postgres
Built per engagement
- Replication counts and run design sized to the decision
- The execution target, agreed rather than assumed
Not yet
- Distributed scheduling of large run sets
- Parameter sweeps and design of experiments
Comparing alternatives on measured evidence
Scenario analysis
Status: Demonstration
A scenario is a defined change to the model. Comparing two means running both from an identical starting state and measuring the difference rather than estimating it.
In the platform
- Result bundles: artifacts and reports, retrievable over the API
Built per engagement
- Scenario definitions drawn from the decisions you actually face
- The measures the operation is judged by, computed from model state
- Reporting and export into your own analysis
Not yet
- Scenario comparison as a platform feature rather than as engineering
- Search across the space of interventions
Turning a result into a change someone can make
Decision support
Status: Research
Options presented against the measures the operation is judged by, with the assumptions and the runs behind each figure attached to it. Today this is a report and a working model your engineers operate; the reasoning layer over it is research.
In the platform
Nothing at this stage.
Built per engagement
- A comparison your team can re-run when the operation changes
- The assumptions written down and tested for how much they matter
Not yet
- Operational question answering grounded in the model and the runs
- Automated intervention comparison and trade-off analysis
Where the loop closes
Action in the physical system
Status: Research
The chosen change goes into the operation, or into the control logic of the systems that run it. Operational data comes back, the prediction is compared against what the plant did, and the difference corrects the model.
In the platform
Nothing at this stage.
Built per engagement
- Comparison of predicted against observed after a change lands
- Model correction against the deviation
Not yet
- Closed-loop correction from robot telemetry
- Any automated execution against a live operation
The rule everything follows from
The engine owns the state. Everything else is a viewer.
A model that computes its state inside its own visualisation cannot be tested, integrated, or driven by anything except its own interface. Every system here separates the two, and the mission twin enforces it across a process boundary: the client computes no physics, and when the engine stops the client stops updating and says so rather than coasting on an animation.
Next step
Where would your systems attach?
The integration boundary is the first thing Discovery settles, and it is usually smaller than an organisation expects.
Prefer email? sales@alsadaany.com