A defence or aerospace operator rarely lacks the data to answer its own question. It lacks a model of its own world that the systems agree to, and a path from question to action that survives being asked about a year later. This is how we build one.
What one readiness question costs
Which airframes can fly tonight, and if that is not enough, what is the cheapest thing to change before dawn. Answering that means reconciling maintenance write-ups and deferrals, the supply position on every part they name, and aircrew currency in a personnel system that has never spoken to the maintenance one.
Six systems, four owners, one deadline. Someone exports a spreadsheet, someone re-keys it, and the slide arrives after the window it was meant to inform. Nobody can say a month later which records produced the number, so disagreement gets settled by seniority.
Why an agent guesses here
Point a capable model at those tables and it answers fluently, and you cannot tell when it is wrong. The meaning of a fleet is not in the schema. No column says that a deferred defect past its expiry grounds the aircraft, that a part robbed off one airframe is still owed back to it, or that the path from serialised item to installed position to airframe to sortie is the join the maintenance controller rebuilds by hand every morning. So it infers the join, and a plausible wrong join in fluent prose is worse than no answer at all.
What we declare, in order
Start from a decision, never a source system: name it, its owner, and what undoing it looks like. That is what tells you which forty of four thousand columns matter.
Then the objects it names: airframe, work order, defect, serialised item, sortie, crew qualification. Ten or twelve, not two hundred. Every property binds to a real table and column in a system of record, so the model is falsifiable rather than aspirational. Links come next: the joins nobody should re-derive, and precisely what a model must not invent. Then purposes, because the reason someone is looking governs access here, not their job title. Each purpose is a database role with column-level grants, so a read outside it takes a refusal from the database, not a polite one. Actions last: a safe write needs to know who is asking and on what authority.
What the agent can do then
Given that model, the agent stops guessing. It reads the maintenance record, the supply position and crew currency where they sit, under the purpose it is acting under, in the vocabulary of the flight line rather than table names. That is the difference between AI that drafts text and AI that carries a decision: one question across six systems, resolved along declared links, with the action that follows already formed. As an illustration and only that: cross-levelling a serialised item out of the depot pipeline reaches the supply chief as a parameterised action with a diff, not a suggestion.
Nothing moves before approval
The write never executes inline. It persists as a pending approval, shows a dry-run diff of what will change, and holds until a person commits or discards it. Where the operator is not licensed to write to the system of record, and much of a modern platform’s sustainment record sits under contractor control, the output is a proposal a human carries across.
The trail is append-only, hashed by the database rather than the caller, and anchored by default. Replay is the control that matters in an inquiry: reopening a saved decision re-derives it under today’s permissions with no model call, which separates “the answer changed” from “the answer was always wrong”.
State the limits early, since an accreditation team finds them anyway: this is the wrong tool inside a control loop, it is not certification evidence, and it repairs nothing about a record that was already wrong. Name the decision, model the smallest world that answers it, bind every field to a real column. Each step forces a conversation with someone who owns something, and those are the conversations a warehouse project exists to avoid.