Technology
Capabilities, with the stage of each one
Organised by what the engineering actually does rather than by the tools it happens to use. Every entry carries its stage, and the entries that do not exist are listed as absent rather than left out.
How to read this page
Everything on this page exists in a repository this company controls, and carries the stage it has actually reached. Where something is genuinely absent, it is listed as absent rather than left out, because a gap a reader discovers later costs more than a gap they were told about.
- Status: Production
- Deployed and running against a live operation, with the operator depending on its output.
- Status: Available
- Can be bought and delivered today under a written scope.
- Status: Pilot
- Delivered as a scoped first deployment, against a defined process and a defined dataset.
- Status: Demonstration
- Built, published and runnable so the engineering can be examined. Models an illustrative system, not a customer's.
- Status: Prototype
- Built and runnable. Demonstrates the mechanism; not yet packaged as a product.
- Status: Research
- Under active investigation. The approach is chosen; the result is not settled.
- Status: Planned
- A committed direction with a design behind it, and no implementation yet.
Capability group
Simulation
The methods the models are actually built from. Which one applies is decided by the mechanism that governs the system, not by preference.
Discrete-event simulation
Status: AvailableQueueing, contention, blocking, starvation and failure as consequences of the model rather than parameters of it. The default method for production lines, warehouses and terminal processes.
Agent-based simulation
Status: AvailablePopulations of individuals with their own attributes, decisions and routing. Used where the behaviour of the population is what decides the outcome, as with passengers, operators and vehicle fleets.
Coupled physical models
Status: DemonstrationSubsystems sharing state so a fault propagates through the physics rather than along a script. Demonstrated across orbit, power, thermal, attitude and communications.
Seeded, replicated execution
Status: AvailableRuns are seeded and inputs versioned, so a run reproduces exactly. Results are reported as distributions across replications, because one run of a stochastic model is a sample rather than an answer.
Monte Carlo analysis
Status: AvailableRepeated replication under sampled inputs to characterise the spread of an outcome rather than its central case. Delivered as part of an engagement; it is a way of running the models above, not a separate engine.
Spiking neural network simulation
Status: ResearchReconstructed connectomes executed as running spiking networks, with circuits that can be driven, recorded and ablated. Research infrastructure rather than an industrial method.
Capability group
Digital twins
What turns a simulation into a twin: a structured model of a specific operation, and something that keeps it in step with the real one.
Operational model and ontology
Status: AvailableObjects, relationships, states, events, constraints and actions, in the terms the operation uses. Built with the people who run it, because a model no domain expert has checked is a model of an assumption.
Calibration and out-of-sample validation
Status: AvailableFitted on one period of operational history and tested against another it never saw, with the deviation reported rather than summarised.
Model definitions as data
Status: DemonstrationPlants and terminals are generated at runtime from layout and equipment data, so a second facility is a second dataset rather than a second build.
Scenario management and comparison
Status: DemonstrationAlternatives run from an identical starting state and compared on measured outcomes. Demonstrated by instantiating complete additional plants; not yet a platform feature.
Historical data ingestion
Status: AvailableFiles, exports and database extracts of demand, cycle times, downtime and movement, used to calibrate and then to validate.
Real-time state synchronisation
Status: PlannedLive read paths that keep a deployed twin current. Delivered as integration engineering per site; no shipped connector exists, and this entry will say otherwise only when one does.
Capability group
Visualization
An interface onto the model. It is how a result is read, and it is never where a number comes from.
Real-time 3D environments
Status: DemonstrationUnity 6 with the universal render pipeline, generating the environment at runtime from layout data rather than from an authored scene.
Crowd rendering at operational scale
Status: DemonstrationBurst-compiled jobs over struct-of-arrays storage with spatial-grid neighbour avoidance, GPU instancing and three distance levels of detail. The crowd costs a handful of draw calls rather than ten thousand scene objects.
Browser delivery
Status: DemonstrationWebGL builds with an explicit performance budget per target, trimmed deliberately rather than degrading unpredictably.
Operator interfaces and reporting
Status: AvailableTypeScript and React surfaces over model state, with control panels generated from a parameter registry so an interface cannot drift from what it controls.
Capability group
Infrastructure
What executes a model, stores what it produced, and lets another system drive it.
Headless engine with an HTTP API
Status: PrototypeUrual: a job state machine, a worker runtime, a plugin system, storage and artifacts, and a Postgres schema behind all of it. Driven entirely over HTTP.
Engine and viewer separation
Status: DemonstrationThe engine owns simulation state and every client is a viewer. Enforced across a process boundary in the mission twin, where the client computes no physics and says so when the engine stops.
Typed API client
Status: PrototypeA Go SDK that is a translation of the platform's HTTP API and nothing more: no simulation logic, no plugin knowledge, no state beyond a session.
Local execution
Status: PrototypeThe engine running entirely on one machine, with no checkout, no licensing and no outbound network call. This is the deployment model for operational data that may not leave a site.
Containerised environments
Status: AvailableDocker and Docker Compose for reproducible engine environments, in use across the platform and the Python simulation engines.
Automated test suites over engine behaviour
Status: AvailableTests written against what the model computes rather than against the interface. The mission twin's engine carries 198 of them.
Capability group
AI and optimization
This group is short, and it is short because almost none of it is implemented. Optimization and decision support are the direction the platform is heading; publishing them as capability would be the single most damaging thing on this page.
Constraint identification
Status: DemonstrationThe binding constraint derived analytically from stage capacity and corroborated independently by queue depth. This is analysis over model state, not a learned model, and calling it AI would be a category error.
Rule-based autonomy
Status: DemonstrationProtective behaviour that emerges from state crossing a threshold rather than from a timeline: load shedding, downlink inhibit and safe-mode entry in the mission twin. Deterministic by design.
Parameter sweeps and design of experiments
Status: PlannedSystematic exploration across a defined parameter space, distributed over the execution engine. Depends on the platform reaching the point where large run sets can be scheduled and compared.
Simulation-based optimization
Status: ResearchSearch over the space of operational actions using the simulation as the objective function. Under investigation. Nothing is deployed and no result is claimed.
Operational reasoning over the model
Status: ResearchAn engineer asking a question in the operation's own terms and getting an answer resolved against the model and the runs, with the assumptions attached. Under investigation, and it executes nothing.
Computer vision and machine learning
Status: PlannedAlsadaany operates no trained model in any delivered system today. Terra's product direction depends on vision and sensor fusion, and that work is ahead of the company rather than behind it. It is listed here so its absence is explicit rather than inferred from silence.
Next step
Bring us a system
The useful conversation is about the mechanism that governs your operation and which method actually fits it. That is a question our engineers can answer in one call.
Prefer email? sales@alsadaany.com