Engineering
How a twin is actually built
Seven phases, in order, each with a gate that has to hold before the next one starts. The gates are the part worth reading: they are where a project is stopped, rescoped, or told that the data to support it does not exist.
Method
Seven phases and seven gates
A phase is not finished because the work in it is done. It is finished because the thing that has to be true before the next phase can start is true.
Discover
Map the operation, its rules and its constraints. Establish what operational data exists and in what state. Define the decision the model has to inform and the accuracy that decision requires.
- Output
- A written assessment with a target architecture, an integration boundary, a value case with its assumptions stated, and a recommendation.
- Gate to the next phase
- The decision is defined, and the data to support it has been shown to exist. If it does not, that is the finding, and it is worth more than a model built on top of the gap.
Model
Write the operation down as objects, relationships, states, events, constraints and actions, in the terms the people who run it actually use. Built with them rather than for them.
- Output
- An operational model of the scoped process, reviewable by the domain experts who described it.
- Gate to the next phase
- The people who run the operation recognise it in the model, including the parts that are wrong.
Validate
Calibrate on one period of operational history, then run against another period the model was never fitted to and compare the output with recorded performance.
- Output
- A validation report stating the deviation on out-of-sample data, and which conclusions survive it.
- Gate to the next phase
- The deviation is understood and is small enough for the decision the model was scoped against. Not small in the abstract. Small enough for this decision.
Simulate
Run the model forward under demand, variability and disruption. Seeded, replicated, versioned. Results are distributions across replications rather than single runs.
- Output
- Baseline behaviour, constraint identification, and the measures the operation is judged by, all measured from model state.
- Gate to the next phase
- A baseline exists that the operation agrees describes it, so a scenario has something to be compared against.
Optimize
Define candidate interventions and evaluate them against the same model from an identical starting state. Buffer sizes, staffing, sequencing, routing, maintenance windows, capital additions.
- Output
- A comparison of interventions on measured outcomes, with the assumptions behind each figure attached to it.
- Gate to the next phase
- The recommended intervention is one the operation can actually execute. An optimum that violates a constraint nobody wrote down is a modelling failure.
Deploy
Install inside your boundary, connect the read paths the model depends on, set up access, and train the engineers who will run it.
- Output
- A running deployment, documentation, and a team that can operate it without us.
- Gate to the next phase
- Your engineers have run a scenario end to end themselves, without help.
Operate
Use it. Compare what the model predicted against what the operation did, and correct the model against the difference. This is where a twin either becomes part of how decisions get made or quietly stops being opened.
- Output
- A model that tracks the operation as it changes, and a record of where it was right and where it was not.
- Gate to the next phase
- None. This is the steady state, and it is what the annual platform agreement exists to support.
Engineering positions
What we will not trade away
Each of these exists to prevent a specific failure, and the failure is stated. A philosophy without a failure attached to it is a preference.
The engine owns the state. Everything else is a viewer.
A model that computes its state inside its visualisation cannot be tested, integrated or driven by anything except its own interface. Every system this company builds separates the two, and the mission twin enforces it across a process boundary.
Every number comes from a state variable.
No animation curves, no per-frame randomness, no hard-coded timelines, no placeholder graphs. If a figure is on screen, the simulation integrated it. This is the single cheapest way to keep a demonstration honest, and the single easiest thing to quietly abandon.
The model is data. The build is not the model.
Plants, terminals and estates are defined as data assets rather than written into code, so a second facility is a second dataset. A twin that requires a rebuild per site is a consultancy deliverable wearing a product's clothes.
Fidelity is scoped by the decision.
Modelling beyond what the decision requires costs money, extends delivery, and adds parameters nobody can calibrate. Under-modelling produces an answer that is confidently wrong. The scoping conversation in Discovery is where that is settled.
Uncertainty is reported.
A single run of a stochastic model is one sample. Results are distributions across replications with the deviation stated, and where an input is unknown the assumption is written down and the conclusion tested against it.
Technical stack
What the systems are built with
Only what is genuinely in use across the company’s own systems. Every entry here can be checked against a published project on this site.
Simulation and real-time systems
- Unity 6 with the universal render pipeline, for real-time interactive models
- C# with Burst-compiled jobs and struct-of-arrays storage for agent populations
- GPU instancing and distance levels of detail, so operational scale stays real-time
- Deterministic clocks and seeded random number streams throughout
Engines and services
- Go for the headless simulation engine, its job state machine and worker runtime
- Python with FastAPI for physics engines exposed over REST and WebSocket
- PostgreSQL for model and job state, Redis for coordination, object storage for artifacts
- Docker and Docker Compose for reproducible engine environments
Interfaces and delivery
- TypeScript and React for operator interfaces and reporting
- Desktop, server and browser delivery from the same model, with an explicit performance budget per target
- Model definitions as data, so a new facility is a dataset rather than a build
- Parameter registries driving both the model and its controls, so an interface cannot drift from what it controls
Practice
- Simulation separated from rendering, so a model can be tested with no viewer present
- Automated test suites over engine behaviour rather than over the interface
- Versioned inputs and seeded runs, so any published figure can be regenerated exactly
- Unattended, seeded capture for demonstration material, regenerated rather than re-shot
Delivery
Six commitments that decide how work is handed over
Statements about method rather than about scale. There is no headcount, no project tally and no percentage anywhere on this site.
Scoped by the decision, not the platform
Work begins with the decision the model has to inform and the accuracy that decision requires. The method follows from the problem. A model built to a higher fidelity than the decision needs costs money and buys nothing.
Validated against data it has not seen
A model is calibrated on one period of operational history and validated against another it was not fitted to, with the deviation documented rather than summarised. A model that has only ever been checked against its own training period has not been checked.
Delivered as maintained software
Simulation code is reviewed, tested and version-controlled to the same standard as production software, so a model stays usable years after the study that prompted it.
Reproducible by construction
Runs are seeded, inputs are versioned and every result carries the assumptions that produced it. Any figure we report can be regenerated exactly, months later.
Uncertainty is reported, not smoothed
Results are distributions across replications. Where an input is unknown we state the assumption and test how much the conclusion depends on it, which is usually more useful than a more precise input would have been.
Operable by your engineers
Scenario configuration, inputs and reporting are built for your team to run without us. A model only your supplier can operate stops being used the moment the engagement ends.
FAQ
Working with our engineers
What technical and operations teams ask before a first engagement.
What does simulation give us that analysis does not?
The interaction. Queueing, contention, blocking, starvation and failure produce behaviour that a static calculation of capacity cannot represent, because the calculation assumes away the interference that decides real throughput. The characteristic finding is that the constraint is not where the utilisation figures suggest, and that it moves as soon as it is relieved.
What data do you need, and what if we do not have it?
A description of the process and its rules, the layout or network structure, resource capacities and shift patterns, and historical records of demand, cycle times and downtime. Discovery exists partly to establish how much of that actually exists in a usable state. Where data is missing we state the assumption explicitly and test how much the conclusion depends on it, which is frequently more informative than a more precise input would have been.
How accurate is a delivered model?
Accuracy is reported against a period the model was not calibrated on, as a deviation, rather than asserted as a percentage. A model that reproduces the history it was fitted to has demonstrated fitting, not accuracy. Whether the deviation is acceptable is decided against the decision the model was scoped for, which is why that decision is defined before anything is built.
How long does a first deployment take?
Discovery is typically two to four weeks. A pilot on one bounded process is typically six to twelve weeks. An operational deployment across a working operation is typically three to six months, sequenced so parts of the model are usable before the whole is finished. Site access and data availability move these more than model complexity does.
Can our engineers extend the model themselves?
Yes, and the deployment is built on the assumption that they will. Scenario configuration, inputs and reporting are designed for your team to run without us, and the models are defined as data rather than written into code. Handover includes training, and the gate for finishing a deployment is your engineers running a scenario end to end without help.
Do you work on-site?
Discovery involves site access wherever the operation allows it, because the gap between the documented process and the operated one is usually where the model's accuracy is decided. The company is based in Egypt and delivers internationally; the working arrangement is agreed per engagement rather than assumed.
Next step
Start with an assessment
Discovery is fixed price, agreed before it starts, and ends in a document you can act on with or without us.
Prefer email? sales@alsadaany.com