Research
Work on method, labelled honestly
Alsadaany Research is where the platform's capability comes from. Everything on this page carries its stage, what has actually been established, and what is still open, because a research page that reads like a product page is the fastest way to lose a technical reader.
How to read this page
None of the work on this page is peer reviewed, and none of it should be read as a validated result. Entries labelled Research are under investigation and have produced no deployed capability. Where something has been built and can be run, it is labelled Prototype and linked.
Area
Simulation
Urual simulation engine
Status: Prototype
A headless, plugin-first, job-based simulation engine in Go. The execution infrastructure the platform is intended to run on.
Urual is an engine rather than an application. It owns users, projects, plugins, jobs, files, results and reports, and it knows nothing about pallets, gates, beds or gantry cranes. Everything domain-specific lives in a plugin, which is what allows one execution layer to serve models from unrelated industries.
It ships no user interface and depends on no website. It is cloned, run, extended through its SDK and driven over its HTTP API, and it includes the job state machine, the worker runtime, the storage and artifact subsystem, and its own schema.
The separation it enforces is the same one the mission twin demonstrates: the engine owns simulation state, and every viewer is a viewer.
- Established
- Foundations are complete and the engine runs jobs end to end through its API.
- Open
- The MVP is in progress. It is not ready for production use, no deployment runs on it today, and it is presented here as infrastructure under development rather than as a product.
Coupled subsystem simulation
Status: Prototype
Subsystems that share state, so a fault in one propagates into the others through the physics rather than through a script.
Most operational failures are cross-subsystem. The interesting behaviour is what the rest of the system does once one part of it degrades, and that behaviour cannot be produced by models that are run separately and combined afterwards.
The mission twin is the clearest demonstration: orbit, power, thermal, attitude and communications share state, eight faults can be injected into a running mission, and the vehicle's own autonomy sheds load and enters safe mode because the state crossed a threshold rather than because a timeline said so.
- Established
- Coupled propagation and emergent protective behaviour are demonstrated in a running system with a 198-test engine behind it.
- Open
- Generalising the coupling pattern into the platform, so an industrial model gains it without being written as a bespoke engine.
NeuroSim: simulation method on a system with published ground truth
Status: Available
Reconstructed connectomes turned into running spiking networks, driven, recorded, ablated and compared against reported behaviour.
Industrial models are hard to check because the ground truth is a plant that is only ever observed in one configuration. Biological circuits mapped by published connectome work are unusual in giving a simulation an external standard to be wrong against.
NeuroSim exists partly for that reason. It is a working platform in its own right, and it is also the place where simulation and validation method is exercised against something whose answer is not ours to decide.
- Established
- The platform runs in the browser and is publicly available.
- Open
- It is an experimental research platform. It makes no clinical or diagnostic claim of any kind.
Area
Optimization
Simulation-based optimization
Status: Research
Searching the space of operational actions using the simulation itself as the objective function.
Comparing scenarios a person proposed is a different problem from searching the space they were drawn from. The second is what an operation actually wants, and it is expensive: each evaluation is a set of replicated simulation runs rather than a function call.
The work is on making that search tractable. It depends on the execution engine above, because the approach only becomes practical once large run sets can be distributed and their results held and compared systematically.
- Established
- The problem is scoped and the dependency on distributed execution is understood.
- Open
- Everything else. No optimization capability is deployed, no result is claimed, and nothing in this area is sold as though it were finished.
Area
Decision systems
Operational reasoning over the model
Status: Research
Letting an operations engineer interrogate a twin in the operation's own terms, with answers resolved against the model rather than against text.
The intent is narrow and deliberate. An operations engineer should be able to ask where the constraint is, what a change would cost, or which of two interventions performs better, and get an answer that came from the operational model and from simulation runs.
That is a different system from a language interface over a dashboard. The reasoning has to be grounded in the structure of the model and in results the system actually computed, and any answer has to carry the assumptions and the runs that produced it. An answer that cannot be traced back to a run is not usable in an industrial decision.
Nothing in this area executes anything. Safety functions stay on deterministic systems, which is an engineering and regulatory constraint rather than a preference.
- Established
- The scope, the grounding requirement and the execution boundary are settled.
- Open
- Implementation. This is under investigation and is labelled Research everywhere it appears on this site.
Area
Digital twins
Calibration and out-of-sample validation
Status: Available
The practice of fitting a model on one period of operational history and testing it against another it has not seen.
The failure mode this addresses is ordinary and widespread: a model is tuned until it reproduces the history it was tuned on, and its agreement with that history is then reported as accuracy. It is not accuracy. It is a description of the fitting.
The method used on delivered work separates the two periods, reports the deviation on the period the model never saw, and states which conclusions survive that deviation and which do not. Where an input is unknown, the assumption is written down and the conclusion is tested for how much it depends on it.
- Established
- This is standing practice on delivered engineering work, not an open question.
- Open
- How much validation a given decision requires is still decided case by case rather than by a rule we would publish.
Area
Physical AI and robotics
Physical AI: perception, planning, control
Status: Research
The problems a robot has to solve are the problems a twin models. Work here runs in both directions.
A robot that plans a path through a space, allocates itself a task and reacts to a change is solving, on hardware and in real time, the problem a simulation solves in a model. The transfer runs both ways: control policies can be validated in simulation before hardware is committed, and hardware returns observations that correct the model.
The commercial reason robotics sits inside this company rather than beside it is the second direction. A twin's hardest ongoing problem is staying current, and an autonomous system that moves through the modelled space is a way of keeping it so.
- Established
- Robot cells and fleets with control logic in the loop are within the simulation capability already demonstrated.
- Open
- Closed-loop correction of an operational model from robot telemetry. No deployment does this today.
Next step
Research problems come from operations
Everything on this page started as a question a real operation could not answer. If you have one, it is worth a conversation whether or not it turns into an engagement.
Prefer email? sales@alsadaany.com