Aircraft Technical Publications Software: Proving the Mechanic Had the Current Revision

Why the revision problem is worse than it looks from the outside

A mechanic is on a stand at 02:00 with a tablet, working a task on an aircraft that arrived on a wet lease three weeks ago. The maintenance manual on the tablet is the operator's library. The aircraft was modified under a supplemental type certificate by its previous operator, and the affected chapter in the operator's library does not reflect that modification, because the effectivity in the OEM data is by manufacturer serial number and the operator's library was built around its own fleet baseline. The mechanic follows the procedure that is on the screen. Nothing goes wrong that night. The finding appears eleven months later during a records audit, and the question asked is not whether the work was correct, it is whether the organisation can demonstrate the mechanic had the applicable data.

Both the European and the American maintenance frameworks require that current, applicable technical data is available to the person performing the work. That sentence contains three separate engineering problems: current means revision control against a continuous OEM feed, applicable means effectivity resolved to the specific aircraft in front of the mechanic, and available means it reached an offline device in a hangar with no signal and can be proved to have done so.

The typical stack is a shared drive of PDFs, an OEM portal per manufacturer with its own login, a viewer application for the structured data, an email distribution list for revision notices, and a spreadsheet where the publications manager tracks which revision is current for which manual. That spreadsheet is the actual control system, and it is maintained by one person who has been doing it for years. This is not a document management problem. It is a data problem that produces documents.

Problem 1: the source data is structured, and structured differently by manufacturer

Modern maintenance data arrives as S1000D data modules with a common source database, or as ATA iSpec 2200 content, or as PDF for older types and for a surprising number of component manuals. Each manufacturer applies the standards with its own conventions. Data module codes, applicability expressions, illustration handling and revision markers all vary in ways that matter when you try to automate.

Vistair DocuNet, Web Manuals and Comply365 all address parts of this space and each is genuinely good at what it targets. Web Manuals is strong for flight operations manual authoring and compliance linking with an accessible editing experience. Comply365 is strong on distribution and read and sign at scale. DocuNet spans document control for operators with a long aviation track record. What none of them removes is the operator specific work of taking manufacturer structured data, applying your own fleet effectivity, layering your deviations, and producing something that resolves correctly for a specific tail. That work is why your publications manager exists.

What a custom build does: ingest each source into a normalised internal model that keeps the original intact and records where every fragment came from. Applicability expressions are parsed rather than treated as text, so the system can answer whether a data module applies to this aircraft rather than leaving that judgement to a human reading a note. This is unglamorous parsing work and it is the foundation for everything else, because effectivity resolution is impossible when applicability is prose.

Problem 2: effectivity is per tail, and your fleet is not the OEM baseline

The manufacturer publishes by serial number range and modification status. Your fleet carries service bulletins applied at different times, supplemental type certificates from previous operators, cabin configurations that differ across subfleets, and equipment changes made by your own engineering department under engineering orders. Wet leased aircraft arrive with someone else's history and leave again.

Most operators resolve this by publishing a superset and adding warning notes, then relying on the mechanic to read the note and check the tail. That works right up until the night it does not, and it is also unfalsifiable in an audit, because there is no record of which resolution the mechanic actually applied.

What a custom build does: hold a configuration record per tail with its modification status, then resolve applicability at the moment the mechanic opens the task, for that aircraft, and record what was resolved and shown. The mechanic sees one procedure rather than a procedure with four conditional branches, and the organisation holds evidence of exactly what was presented. Where the configuration record is uncertain, the system says so loudly rather than guessing, because a wrong resolution presented confidently is worse than a warning note.

Problem 3: distribution has to work offline and prove itself

A hangar is a signal dead zone. A remote line station has intermittent connectivity. A flight crew needs the operations manuals on an electronic flight bag that may be offline for a full duty period. Distribution therefore means synchronising a large content set to devices, keeping it current, and knowing with certainty which revision each device holds at each moment.

The read and acknowledge requirement layers on top. When a temporary revision or an urgent notice is issued, the organisation must show that the affected population received it, and often that named individuals acknowledged it before performing relevant work. Email distribution lists cannot prove this and neither can a shared drive.

What a custom build does: differential synchronisation so a revision does not force a full redownload over a hotel wifi connection, a device manifest so the system knows exactly what each device holds, and enforcement rules where they are justified, such as blocking a task in the maintenance system until the applicable notice is acknowledged. Acknowledgement records are immutable and reportable by person, role and station, which is what an auditor asks for and what most operators currently assemble by searching an inbox.

Problem 4: your own content is where the risk concentrates

Deviations, engineering orders, temporary revisions, local procedures and customer specific instructions in an MRO are all operator authored content that carries the same regulatory weight as the OEM data and none of the OEM's tooling. It is usually written in a word processor, converted to PDF and distributed separately, which means the mechanic sees the manual in one place and the deviation somewhere else.

What a custom build does: author operator content in the same model as the source data so it appears inline at the point of use, attached to the specific data module and the specific effectivity it modifies, with its own approval workflow and expiry. A temporary revision that expires disappears from the presentation automatically rather than lingering in a folder for three years. For an MRO this is doubly important, because customer specific instructions must appear only for that customer's aircraft, and getting that wrong is a contractual problem as well as a technical one.

Problem 5: the publications system does not talk to the maintenance system

The maintenance and engineering system holds the task, the work package, the sign off and the aircraft record. The publications system holds the procedure. They are usually joined by a mechanic typing a reference into a search box, which is where currency fails silently, because nothing checks whether the procedure opened is the revision applicable to the work package raised last week.

What a custom build does: link task cards to the exact data module and revision, so opening a task opens the applicable content and the sign off records the revision that was in force. When a revision lands that affects an open work package, the system flags the package rather than waiting for someone to notice. This linkage is the single feature that turns publications from a library into a control, and it is also the one most often deferred, which is why so many operators run a compliant library and a non compliant process.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape for technical publications platforms. A first release covering ingest of your primary manual set, effectivity resolution to tail level, and controlled offline distribution with read and acknowledge tracking runs $80,000 to $190,000 and ships in 14 to 20 weeks. Adding operator authoring with approval workflow, flight operations manual management, task card linkage into the maintenance system and full revision audit reporting takes the total to $220,000 to $550,000 across 6 to 14 months.

What drives the number up here specifically: the number of distinct source formats, because each manufacturer's application of the standard is its own ingest project. The quality of your configuration records, since effectivity resolution is only as good as your knowledge of what is actually installed on each tail, and recovering that is engineering work rather than software work. Illustration handling, particularly interactive graphics and wiring diagrams, which are far harder than text. Offline device management across stations. And in an MRO, customer separation, because every customer's data and instructions must be isolated and that constraint touches everything.

Build versus buy, and the split that usually works

Buy if you run a single type with a stable fleet and no significant operator specific configuration. A packaged product will handle your revisions and distribution well, and the operator specific work you would be automating is currently one person for a few days a month, which does not justify a build.

Buy for flight operations, build for engineering, is the split we recommend most often. Flight operations manuals are authored content with a compliance library behind them, and products in that space handle it well. Engineering data is structured source material needing effectivity resolution against your fleet, and that is where the packaged products leave the operator specific work on the table. Running a purchased tool for the operations manual set and a built layer for the engineering data is frequently the cheapest correct answer.

Build properly when you carry a mixed fleet with real configuration variation, when you are an MRO handling customer aircraft whose configurations you do not control, when your effectivity work is currently a spreadsheet maintained by one person whose retirement would be a compliance event, or when your maintenance system and your publications have no link and your audit exposure is the gap between them. That last case is the most common trigger and the most expensive to leave alone.

How to choose a developer for technical publications software

Ask them to explain applicability. A team that has done this will talk about applicability expressions, configuration records per tail, resolution at point of use and what to do when the configuration record is uncertain. A team that talks about tagging documents by aircraft type has built an intranet and will not survive contact with a wet lease.

Ask how the offline device knows it is current. The right answer involves a manifest, differential synchronisation and a visible currency indicator that fails closed, meaning the device tells the user it may be stale rather than presenting old content confidently. Ask what happens on a hotel wifi connection with a large revision, because that is the real deployment scenario.

Ask what source data they have actually parsed, naming the standard and the manufacturer. S1000D from two manufacturers is two projects. iSpec 2200 legacy content is a third. PDF component manuals are a fourth with no structure at all. Ask to see how they handled illustrations and change marks, because that is where the effort hides.

Ask who owns the code, the ingest pipelines and the normalised content store, and settle it before kickoff. You should own the repository, the infrastructure accounts and the right to move to another firm, because this system is part of your continuing airworthiness evidence and must outlive any supplier relationship. At Digital Heroes the client owns the code from the first commit, and any developer who wants to hold your manual pipeline is holding your certificate.