What operational AI actually is
Software that answers specific operational questions from the system's own data, shows the evidence behind each answer, and — where it has been explicitly authorized — carries out a bounded action and verifies the result.
It is scoped to a defined role, constrained by the same permissions that govern the people it works alongside, and auditable at every step.
The distinction worth drawing is not between "AI" and "not AI". It is between a system that produces plausible text about your operation and a system that answers a question from your actual records, tells you where the answer came from, and stops at the boundary of what it is permitted to do.
An aviation business cannot use the first kind. The cost of a confidently wrong answer about a condition code, a core due date or an airworthiness document is not an awkward sentence — it is a shipment that should not have left, or one that did not leave when it should have. Operational AI has to be built so that being wrong is visible, bounded and recoverable.
That requirement shapes everything below. Each of the five stages exists to constrain the one after it.
The five-stage model
Stage 1 — Define the outcome
A capability starts as a clear, specific outcome, written in one sentence before anything is built. Not "help with sales orders" — something closer to identify the sales orders that need attention today and explain why each one is on the list.
The sentence is doing more work than it looks. It fixes what is in scope and what is not, it names the data and evidence the answer must rest on, and it states what a good answer looks like well enough that you can tell whether you got one. A capability without that sentence has no definition of being wrong, which means it can never be tested and should never be trusted.
The outcome is agreed before design starts, and it is narrow on purpose. Most of the value in operational AI comes from a handful of specific questions answered reliably, not from one broad assistant answering everything approximately.
Stage 2 — Give it an operational identity
A capability is given a defined role, in the same sense a person in the business has one: a mission, a scope of data and actions it is allowed to touch, an explicit list of things it must not do, and a path for escalating anything outside that scope.
That identity is mapped onto the permission model AERONEXUM already enforces. It operates within an existing tenant, under existing user permissions and domain authority. It has no direct database access and no private channel to the data — it reaches information through the same services, and the same authorization checks, as any other caller.
This is the stage that makes the rest safe to build. If a capability cannot exceed the authority of the person asking, then the worst case for a bad answer is a bad answer, not an unauthorized change.
Role, allowed data, prohibitions and escalation are documented up front, and session and audit requirements are set at the same time. Nothing is granted implicitly.
Stage 3 — Build the orchestrator
The orchestrator is the coordinator. It interprets what was actually asked, selects which domain capabilities are relevant, sequences them, and assembles a single structured response — carrying the evidence, the policy decisions and the authorization state along with the answer.
A question about whether an order can ship is rarely a question about one domain. It touches the sales commitment, the serialized stock behind it, the quality status of that material, the documents that must accompany it, and the shipping arrangement itself. The orchestrator is what turns that into one coherent answer rather than five partial ones the person has to reconcile.
It is also where tenant isolation and audit logging are enforced centrally, rather than being reimplemented — and eventually got wrong — in each individual capability.
Requests are routed to the appropriate AERONEXUM domains — sales, inventory, quality, receiving, shipping, relationships and the rest — and the structured result is returned with its supporting evidence attached.
Stage 4 — Create domain capabilities
Underneath the orchestrator sit specialized capabilities, one domain at a time. Each is narrow by design: it knows its own domain, uses the existing services and data for that domain, and answers a defined set of questions rather than improvising across the whole system.
Narrowness is the point. A capability bounded to serialized inventory can be reasoned about, tested against known cases, and held to deterministic behaviour in a way a general-purpose assistant cannot. When it answers, it returns the evidence behind the answer — the records it read, not a summary you have to take on faith.
Where an action has been enabled for that domain, the capability prepares it rather than performing it. Preparation and execution are deliberately separate steps, which is what makes the final stage possible.
Capabilities are built one domain at a time, each with an explicit list of the tools and data it may use, so that adding a new domain never quietly widens the reach of an existing one.
Stage 5 — Trust in stages
Autonomy is not a setting. It is a sequence, and each step has to be earned against evidence from the step before it:
- Observe — read-only. The capability reports what it finds and nothing else.
- Recommend — it proposes an action and shows the evidence for the recommendation.
- Authorize — a person explicitly approves the specific action.
- Execute — the action is carried out through a controlled, bounded operation.
- Verify — the result is confirmed by an independent read, not by the component that performed it.
- Expand — only then, and only to further low-risk actions, on the basis of proven reliability and policy.
Most capabilities should spend a long time at observe and recommend, and some should never move past them. That is not a limitation to apologise for. An operation that can see its own state clearly, with the evidence attached, has already captured most of the value — and it has done so without handing anything irreversible to a system still earning its reputation.
New capabilities start in observation. Controlled actions are enabled individually, each requiring explicit authorization, and each verified by a separate read afterwards. Expansion follows demonstrated reliability rather than a roadmap date.
What this deliberately does not do
It does not make airworthiness determinations, sign releases, or substitute for the judgement of the people authorized to exercise it. Those are certificate-holder responsibilities and they stay with the certificate holder.
It does not reach around the permission model, and it does not see data the person asking could not see themselves. It does not act without an explicit authorization for that specific class of action. And where it is uncertain, the correct behaviour is to say so and escalate — not to produce a confident answer because a confident answer is more satisfying to read.
This page describes a model and the order in which it is built, not an implementation. Which capabilities exist for a given organization, and which stage each one has reached, is a question about that deployment — and the honest answer to it is specific rather than general.
Why the staged model is the point
The temptation with operational AI is to start at the end: give it broad access, let it act, and tighten things up if something goes wrong. In an aviation business that order is backwards, because the first thing that goes wrong is rarely cheap and is often discovered late.
Building outcome-first, identity-second and autonomy-last produces something less impressive to demonstrate and considerably more useful to operate. The capability does a narrow thing reliably, shows its working, and expands only where it has demonstrated it should. People keep the exceptions, which is where their judgement is actually worth something, and stop spending their mornings on the predictable.
That is the whole ambition: quietly handling the predictable, so people can focus on the exceptional.