About
We believe software should be able to tell an organisation the truth about itself.
Not summarise it. Not describe it persuasively. Tell it what is actually true right now, what a change will reach, what it will cost, and who is permitted to decide what happens next.
That matters most at the moment somebody has to act. Committing money, changing a production plan, accepting a risk, telling a customer something they would rather not hear. Until then, a confident answer and a correct one look identical.
So the software we are interested in is narrower than most of what enterprise AI is reaching for. Not a system that can discuss an organisation fluently. A system that holds an accurate model of one, and can show its working when it is asked.
Origin
Artificial intelligence had become extraordinarily good at talking about companies. It could search their documents, summarise their quarters, explain their policies and draft their reports. Increasingly it could use tools and take actions.
And organisations holding more information than at any point in their history still could not reliably answer a question as ordinary as: this shipment is late, what does it break?
Systems that hold records, not relationships
Every major platform inside an organisation records objects accurately. Orders, inventory, shipments, contracts, customers. Each record can be perfectly correct while the company still cannot answer what depends on what, because the meaning lives in the connections and nothing owns them.
Language models mistaken for systems of record
Give a model access to everything and it becomes tempting to let it hold the truth as well as interpret it. That is an architectural mistake. A model is an extraordinary interpreter of operational reality. The reality itself needs firmer foundations.
Explanations standing in for evidence
Machines have become fluent at justifying their conclusions. Fluency is not proof. When software recommends spending money, changing a supplier or missing a commitment, the question is not whether it can tell a good story, but whether the decision resolves to the facts that made it necessary.
None of that is an intelligence problem. The models are capable. The gap is that nothing in the stack holds an authoritative model of the business itself, so every system reasons over fragments and hopes the fragments agree.
We saw a need for the model to come first, and for the reasoning to sit on top of it. That is why Automa Dynamics exists.
What we build
A company is not a hierarchy. Operationally it is a graph. A customer depends on an order, an order on production, production on materials and capacity and time, materials on suppliers and inventory and transport. The company keeps working because those dependencies keep holding, and serious problems begin when one of them stops.
Project HELIOS is our attempt to hold that graph properly: an operational ontology platform and enterprise digital twin that carries the canonical model of an operation, traces the consequences of change through it, and governs the decisions taken in response. The question every part of it has to answer is whether it increases the ability to observe, understand, decide or act.
A shipment carrying critical component batches is disrupted. The system identifies every dependent production commitment, customer order, contractual deadline and pound of financial exposure. It proposes feasible responses. It names who is permitted to approve them. It records the decision with the evidence that produced it, in a form that can still be reconstructed a year later.
How we work
It would be difficult to argue that operational decisions need evidence, traceability and explicit authority while building the software that makes that argument any other way.
Governed, not improvised
HELIOS is built against a written engineering specification that predates the code. It defines the ontology, the architecture, the security model and the acceptance criteria before implementation begins.
Evidence at every gate
No phase closes because the code exists. It closes when its acceptance criteria are met, its tests pass, its documentation is current and the decision is recorded in a board review that remains readable afterwards.
Determinism by default
Generation, fixtures, impact analysis and demonstrations run from fixed seeds. A result that cannot be reproduced is not a result.
The programme explains itself
Requirements, code, tests, architecture decisions and evidence are linked through stable identifiers, so any conclusion about the system can be traced the same way the system traces conclusions about an operation.
Where we’re going
HELIOS is in active development and is not finished. We are publishing the reasoning behind it while it is being built rather than waiting to present a completed product with a story attached afterwards.
That order is deliberate. A position that has been written down in public can be examined, disagreed with and held to account. Anyone can eventually demonstrate software. Far fewer will show you the argument it rests on before it exists, when the argument is still capable of being wrong.
If the thinking does not stand up, the product built on it will not either. So the thinking goes out first.