Cited, or exact.
Skyvize compiles an airline’s maintenance manuals, minimum equipment list, service bulletins and fleet history into one versioned, auditable knowledge system that helps licensed engineers resolve aircraft defects. Every line of an answer resolves to an exact document at an exact revision — or it is not stated.
And when it cannot make the call, it does not simply go quiet. It isolates the fact that is stopping it and names that — the installed count for this item is not on record, the modification status for that bulletin was never captured — so the engineer knows exactly what to go and confirm rather than starting the search again. A licensed engineer reviews the evidence and signs. The system never decides.
The answer is in the manual. That is the problem.
A hundred thousand pages, written for a fleet rather than for your tail. At three in the morning, with a departure to make, the distance between the right procedure and a nearly-right one is a configuration difference nobody has time to check.
And every year there are fewer people who can close that distance from memory. The manuals are not getting shorter.
03:10. A defect comes in.
Illustrative. The document references are representative of the sources Skyvize cites; the aircraft, its configuration and its history are synthetic.
Entered by the duty engineer
R BLEED TRIP OFF illuminated during climb, FL180. Reset OK. Recurred on descent. Tail VT-4521.
Finding this by hand means the maintenance manual, the minimum equipment list, the open bulletins for this configuration, and whatever the fleet has already learned. Usually about an hour, at three in the morning.
Defect summary
Right bleed system trip. Intermittent, recurring within a single flight.
Tail VT-4521, A320, post-bulletin 36-1042 configuration
Dispatch status
Dispatch permitted under MEL 36-11-01a, Category C, subject to the (M) procedure: bleed monitoring computer test per the maintenance manual.
Category C carries a ten-day rectification interval. The clock started at the deferral and the deadline is stamped on the record.
FAA-approved MMEL item 36-11-01, Rev 22
AMM 36-11-05, Rev 14
Probable cause, ranked
- 1
Sense line temperature sensor, intermittent fault
Matches two of three similar cases on this fleet in the past 90 days, both in the same post-bulletin configuration as this tail. Both were resolved by replacing the sensor, not the valve.
Fleet history WO-88213 (MSN 4519), WO-89042 (MSN 4527)
Fault Isolation Manual 36-11 Task 801, Rev 14 - 2
Precooler control valve sticking
One of three similar cases. Requires an operational check before it can be ruled in or out.
Fault Isolation Manual 36-11 Task 802, Rev 14
Compliance
No open airworthiness directives and no deferred defects against ATA 36 for this tail.
Confidence and gaps
Moderate. Two fleet precedents is not a large enough sample to call this confidently. Run the computer test before committing to a fix.
Every line above is drawn from the manufacturer's manual at its current revision, the approved minimum equipment list, and the operator's own fleet history. None of it comes from model memory. A licensed engineer reviews it, and signs.
And when it cannot make the call.
A system that has read a hundred thousand pages can always produce something. The property worth paying for is the opposite one — and going quiet is only half of it. An answer that stops has to say what would have let it continue.
Asked by the same engineer
Any history of APU auto-shutdowns on this tail?
Answer
Nothing on record for this tail.
What was searched
Fleet defect history for this tail across ATA 49, the auxiliary power unit, for the last twenty-four months. Maintenance manual and fault isolation procedures for the same chapter.
Citations
None. Nothing was found that could be cited.
What would settle it
Auxiliary power unit events for this tail were never captured in the records compiled into this build. This is an absence in the source data, not a failed search — so widening the query will not produce it, and the operator’s own maintenance system is where it would have to come from.
Nothing was caught here, because there was nothing to catch: no source was invented, so no checker had to reject one. That is the whole distance between the manual states and a model believed it read — and at three in the morning it is the difference that matters.
More often the gap is narrower than this one and lands mid-determination: a dispatch call that stops on a single missing number — the installed count for that item is not on record — and says exactly that, naming the figure and the record it belongs in. The engineer confirms one fact instead of restarting the search.
Why not just give the manuals to a chatbot?
Because a document is not a decision. The minimum equipment list is a rulebook of intervals, conditions and installed-versus-required counts, and the manual is written for a fleet: it has to be narrowed to one tail’s configuration before a word of it is safe to act on. Reading the pages is the easy half.
So Skyvize does not search a pile of text and hope. It compiles the library — the way a compiler reads source, not the way a reader skims — into a versioned system that can be queried, cited, audited, and rebuilt whenever a revision lands.
graph = compile(code_sha, source_batch) -
Parsed by structure
Every task, limit and interval keeps its place in the document tree, stamped with the revision it came from.
-
Filtered before ranked
What does not apply to the tail is removed before anything is scored. Never a candidate — not a wrong answer scored and discarded.
-
Rules, not weights
Dispatch legality comes from a deterministic rules engine against the minimum equipment list. No model anywhere in that path.
-
Cited and exact
A claim resolves to an exact document at an exact revision, or it is not made. And where a determination is blocked, the blocking fact is named — not "insufficient data", but which number is missing from which record.
-
Conflicts surfaced
Open deferrals are checked against each other for compounding effects, and where fleet experience would invert the manufacturer’s own ordering, the disagreement is shown rather than quietly resolved in one direction.
-
Answers with a date
Any past answer can be rebuilt as of the manual revision and the fleet state in force on the day it was given.
-
Compiled once
The expensive work — parsing, filtering, cross-linking — happens at compile time, once per revision. Not again on every question.
The questions an airline asks first.
Who decides whether an aircraft can legally fly with a defect?
Rules do — and then a person does. Dispatch legality is a deterministic question against the minimum equipment list and that tail’s configuration, answered by a rules engine with no model anywhere in the path. The verdict is advice until a licensed engineer signs.
How does it know an answer applies to this aircraft?
A true fact about the wrong variant is a dangerous answer. Content that does not apply to that tail is filtered out before anything is ranked, so it is never a candidate in the first place — not a wrong answer that was scored and then discarded.
What does it do when it does not know?
It isolates what is missing and names it. Not “insufficient data” — the specific fact that would settle the question, and where it should have been recorded: the installed count for that item is not on record, the modification status for that bulletin was never captured. You are told what to go and confirm, and what was searched to establish that it is genuinely absent rather than merely unfound. An answer that names its gap is actionable. A confident one resting on nothing is the failure this system exists to prevent.
What happens where the manual runs out?
Reasoning starts, and stays bounded. The system weighs the evidence already compiled — the procedures, the bulletins, and the fleet history in the build — and every conclusion it draws still has to name the source it rests on.
Can an answer from last month be audited today?
Yes. Every answer is given against a versioned build, so it can be reconstructed exactly as it stood on the day it was given — the manual revision and the fleet state both as they were, not as they are now.
Does Skyvize ever decide anything itself?
No. It never asserts airworthiness, never writes to an airline system, and holds no authority to release an aircraft. Its job is to put every relevant document in front of a licensed engineer in seconds instead of an hour. The engineer decides, and signs.
The licensed human always signs off. The system never guesses.
Skyvize puts in front of a qualified engineer, in seconds, what would otherwise take an hour of searching and a colleague who has already gone home. What it does not do is decide.
Bring us a defect you have already closed.
We will run it against your own documentation and your own fleet history, and you can check the answer against what your engineers actually did.
Request a walkthrough