Field Guide
Choosing a Digital Technical Publication System for Aircraft Maintenance
The Problem
What These Systems Exist to Solve
An aircraft maintenance operation runs on manufacturer content — maintenance manuals, parts catalogs, wiring data, service bulletins — arriving from multiple OEMs, in multiple formats, on their schedules rather than yours. The operation is obliged not just to have this content but to keep it current, put the right slice of it in front of each technician, and prove afterwards which revision reached which person on which date.
A digital technical publication system is whatever sits between those obligations and the people doing the work. The market ranges from OEM-supplied viewers, through general document management dressed for aviation, to standards-aware platforms that understand ATA iSpec 2200 and S1000D structure rather than treating a manual as a large PDF. The label on the box matters less than how the product behaves on the seven dimensions below.
Evaluation
What Separates the Good Ones
- Revision currency and service bulletin integration
- The core promise of any system is that the person doing the work is reading the current revision. Ask precisely how OEM revisions and service bulletins enter the system: automatically from the manufacturer's distribution, or by someone uploading files? How long is the gap between an OEM issuing a revision and it being live in front of a mechanic? Can the system show you what changed, or does it hand over a new document and leave the comparison to the reader? A system that cannot answer these is a document folder with a search box.
- Applicability and effectivity filtering
- A team maintaining multiple aircraft types — or multiple configurations of one type — lives or dies by filtering. The system should show only the content that applies to the tail in front of the technician, and it should be trustworthy enough that nobody feels the need to double-check against the unfiltered manual. Filtering that is almost right is worse than none, because it trains people to ignore it.
- Mixed-standard support
- Most real fleets are mid-transition: legacy libraries in ATA iSpec 2200, newer aircraft delivering S1000D. A credible system ingests both and presents them through one interface, one search, and one revision-control model — the specification a procedure was authored in is not something a mechanic should have to care about.
- Usability at the point of work
- Technical reference happens under time pressure, on the hangar floor, often on a tablet. Interfaces that bury content under portal chrome, search that returns document titles instead of procedures, and viewers that fight the reader all slow down critical reference work — and slow reference work gets replaced by saved PDFs, which quietly destroys revision control. Watch a mechanic use the system for ten minutes before believing any demo.
- The compliance trail
- Continuing airworthiness obligations include being able to establish which revision a person was working from on a given date. The system should record acknowledgments and access against revisions as a matter of course, and produce that history without a support ticket. If the audit story is a manual export, it will fail exactly when you need it.
- Offline and distribution
- Connectivity at the point of work is not guaranteed — line stations, remote operations, and secure environments all break the assumption of a live connection. Ask how content gets to devices that are sometimes offline, and how the system reconciles currency when they return.
- Exit cost
- The data outlives every viewer. Whatever you adopt, your content should come back out in the standard it was authored in, with its structure and revision history intact. A platform that ingests standard data but cannot return it has made your library its hostage — evaluate leaving before signing up to stay.
Due Diligence
Questions to Ask Any Vendor
- Walk me through an OEM revision arriving: what happens between the manufacturer issuing it and a mechanic seeing it, and how much of that is manual?
- Show me the same procedure filtered for two different tails. Who maintains the applicability data that filtering depends on?
- Show me iSpec 2200 and S1000D content side by side in the reader. Does search cross both?
- Produce the record of who acknowledged the last revision of a given manual, without leaving the product.
- What does a mechanic see on a tablet with no connectivity, and how does it catch up?
- If we leave in three years, what do we get back, in what format, and at what cost?
Full disclosure of our own position: Shakewell builds Content Portal, a delivery platform for standards-based technical content, and provides the engineering services around it. The criteria above are the ones we build against — and the ones we would use to evaluate anyone, including us.
FAQ
Questions We Hear
How do documentation systems keep content current with OEM service bulletins and revisions?
The good ones connect to the manufacturer's distribution channel and ingest revisions and service bulletins as they are issued, present what changed rather than just the new document, and record who has seen it. The weak ones rely on someone downloading files from an OEM portal and uploading them — which works until the one week it doesn't. The question to ask is how long the gap is between OEM issue and live availability, and how much human effort sits inside that gap.
What should a small maintenance team managing multiple aircraft types look for?
Three things ahead of everything else: one place to look across all types and manufacturers, so nobody maintains a mental map of OEM portals; applicability filtering that can be trusted, because a small team has no slack for double-checking; and a compliance trail that assembles itself, because a small team has no one whose job is audit preparation. Feature depth matters less than whether the everyday loop — find the procedure, trust it is current, get back to work — is fast.
How do you centralize OEM documentation from multiple manufacturers?
Ingest each manufacturer's data in the standard it is delivered in — iSpec 2200, S1000D, or plain PDF for the long tail — into one repository with one revision-control model, and deliver it through one reader. The hard part is not storage but the ingestion paths: each OEM's distribution mechanism is different, and the centralised library is only as current as its weakest feed.
Do we need a full authoring system, or just a delivery platform?
If you only consume manufacturer content, you need delivery: currency, filtering, distribution, and the audit trail. You need authoring and content management when you produce or modify content — supplements, engineering orders, operator-specific procedures — at which point standards-compliant authoring and a managed source become the foundation the delivery layer sits on. Many operations need far less authoring capability than they are sold.
Get In Touch
Evaluating Options?
Tell us what your fleet looks like and what your current documentation loop costs you. We will tell you honestly what you need — including when it is less than you have been quoted.