Aircraft Technical Publications Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the effectivity requirement get scoped as document tagging so often?

Because on the first day of discovery it looks like one. Someone shows the developer a shared drive of manual chapters, an OEM portal login and a spreadsheet, and the obvious summary is that the operator needs a better place to keep documents with a search box on top. That summary produces a quote everyone likes and a system that cannot answer the only question the regulator asks.

Both the European and the American maintenance frameworks require that current, applicable technical data is available to the person performing the work. Applicable is the word that breaks the document library model. Manufacturers publish applicability by serial number range and modification status. Your fleet has diverged from that baseline through service bulletins applied at different times, supplemental type certificates inherited from previous operators, cabin variations across subfleets and your own engineering orders. Resolving whether a procedure applies to the aircraft on the stand is a computation, not a filter.

The fix is a scoping decision made before pricing. Insist that applicability expressions are parsed into structured conditions rather than carried as prose, and that the system holds a configuration record per tail against which those conditions are evaluated at the moment a task is opened. If a proposal does not name applicability parsing and per tail resolution as line items, it is pricing an intranet. Ask the supplier to walk through a wet leased aircraft with an unfamiliar modification status before you sign anything, because that single scenario separates the two designs.

What goes wrong when you migrate a legacy manual set into a new system?

Two things, and only one of them is software. The first is format. You will hold S1000D data modules from one manufacturer, ATA iSpec 2200 content from another, and unstructured files for older types and for a large number of component manuals. Each manufacturer applies the standards with its own conventions for data module codes, change marks, illustration handling and revision markers. Every distinct source is its own ingest project, and teams that quoted for one discover the second in week six.

The second problem is not software at all. Effectivity resolution can only be as accurate as your knowledge of what is actually installed on each tail, and in most operators that knowledge is spread across the maintenance system, a modification status register, engineering order files and the memory of a continuing airworthiness engineer. Loading incomplete configuration records into a system that resolves confidently produces something worse than the spreadsheet, because it presents a wrong answer without a warning note attached.

The fix is to run configuration record recovery as a named workstream with its own owner and its own budget, in parallel with the build rather than inside it. Then design the system so uncertainty is a first class state. Where the configuration record for a tail is incomplete, the mechanic should see that the resolution is unconfirmed and why, rather than a clean procedure that happens to be wrong. Fail loudly on unknown, silently on known.

Why do the OEM feed and maintenance system integrations break after launch?

Because both ends move without telling you. Manufacturers change delivery mechanisms, adjust their application of the standard between issues, and occasionally restructure a chapter in a way that invalidates assumptions your parser made about their previous output. On the other side, your maintenance and engineering system holds task cards whose references were written by people who assumed a human would interpret them.

The break is rarely loud. A parser that silently drops a new element type produces a library that looks complete and is missing content. A task card reference that no longer resolves falls back to a search box, and the mechanic finds something plausible. Neither event raises an alarm, so the failure is discovered by an auditor rather than by monitoring, which is the worst possible order.

The fix is validation at ingest with a refusal to publish on unexplained change. Compare each incoming revision against the previous one and report structural differences to the publications manager before anything reaches a device, so an unexpected element or a restructured chapter becomes a fifteen minute review rather than a finding. On the maintenance system side, resolve task card references to a specific data module and revision at the point of linking, and treat an unresolvable reference as a work package exception, not as a prompt to search. Budget continuing effort for both. A publications pipeline is not a project you finish, it is a feed you operate.

What happens when offline distribution and acknowledgement are not covered properly?

This is the gap teams defer to phase two and then discover is the whole point. A hangar is a signal dead zone. A remote line station has intermittent connectivity. A flight crew needs manuals on an electronic flight bag that may be offline for a full duty period. If the system assumes a connection, it fails at exactly the moment the mechanic needs it, and the workaround is a printed copy of unknown vintage.

The acknowledgement side carries the compliance weight. When a temporary revision or an urgent notice is issued, the organisation must be able to show that the affected population received it, and often that named individuals acknowledged it before performing relevant work. An email distribution list cannot prove this. Neither can a shared drive. The evidence an auditor wants is a record per person, per revision, per station, and assembling it by searching an inbox is not evidence.

The fix has three parts. A device manifest, so the system knows exactly what each device holds rather than what it was last sent. Differential synchronisation, so a revision does not force a full redownload over a hotel wifi connection at an outstation. And a currency indicator that fails closed, telling the user the content may be stale rather than presenting old data confidently. Test all three against a large revision on a weak connection before accepting the work, because that is the real deployment condition and it is not the one that gets demonstrated.

Should you build custom or configure what you already own?

If you operate a single type with a stable fleet and no significant operator specific configuration, configure a packaged product and stop. Web Manuals is strong for flight operations manual authoring and compliance linking with an accessible editing experience. Comply365 handles distribution and read and sign at large scale. Vistair DocuNet spans document control for operators with a long track record in the sector. A twelve aircraft single type operator whose effectivity work amounts to a few days a month for one person will not recover a build.

The split we recommend most often is to buy for flight operations and build for engineering. Flight operations manuals are authored content with a compliance library behind them, and the products above handle that well. Engineering data is structured source material that has to be resolved against your fleet before it is safe to present, and that resolution is operator specific by definition. Running a purchased tool for the operations manual set alongside a built layer for engineering data is frequently the cheapest correct answer, and it is the one a supplier selling a full platform will not propose.

Build the engineering layer when you carry a mixed fleet with real configuration variation, when you are a maintenance organisation working customer aircraft whose configurations you do not control, or when your effectivity work is a spreadsheet held by one person whose retirement would be a compliance event.

How do hidden costs get into the quote?

Through five specific doors, all of them opened by a discovery process that looked at the manual library and not at the surrounding operation. Format count is the first. A quote written after seeing one manufacturer's data assumes one ingest pipeline, and every additional source format is effectively another one.

Illustrations are the second and they are consistently underestimated. Interactive graphics, hotspots and wiring diagrams are far harder than text, and a proposal that prices content ingest without separating illustration handling is pricing half the job. Configuration record recovery is the third, and as covered above it is engineering work rather than software work, so it belongs in a different budget line and often a different team.

Device and station management is the fourth. Provisioning, tracking and recovering devices across line stations is an operational capability, not a screen. Customer separation in a maintenance organisation is the fifth, and it is the one that quietly touches every part of the system, because each customer's data, configuration and specific instructions must be isolated and that constraint cannot be added at the end.

Get all five priced explicitly at proposal stage, as separate lines with separate assumptions. A supplier who will not break them out has not thought about them, and you will meet each one anyway.

What separates a build that works from one that fails here?

Ask the supplier to explain applicability without prompting. A team that has done this will talk about applicability expressions, configuration records per tail, resolution at the point of use and what the system does when the configuration record is uncertain. A team that describes tagging documents by aircraft type has built an intranet before and will learn this domain at your expense.

Ask how the offline device knows it is current, and listen for a manifest, differential synchronisation and an indicator that fails closed. Ask what source data they have actually parsed, naming the standard and the manufacturer, and ask specifically how they handled change marks and illustrations, because that is where the effort hides.

Ask what happens when an ingest sees an element it does not recognise. The right answer is that the revision is held and a human is told. Any answer involving skipping or best effort handling is describing the silent failure mode that produces audit findings two years later.

Finally, settle ownership before kickoff. You should hold the repository, the infrastructure accounts, the ingest pipelines and the normalised content store, with the unrestricted right to move to another firm. This system forms part of your continuing airworthiness evidence and has to outlive any supplier relationship. At Digital Heroes the client owns the code from the first commit, and a developer who wants to keep your manual pipeline on their own accounts is holding a piece of your approval.