Technical Content Delivery Portal

We are asked to compare authoring platforms, content management systems, and delivery portals more often than we are asked to sell one. These are the questions that separate the systems that survive contact with a real program from the ones that demo well — whichever vendor you end up with.

• Native standard support

  Is the standard native, or bolted on?

  A system that stores your content as the standard's own data model behaves very differently from one that stores something else and exports to it. Ask which issues and revisions are supported natively — S1000D 4.x versus 5.x versus 6, MIL-STD-40051, iSpec 2200 — and what happens on the day the specification revises.

• Source management

  Where does the source actually live?

  S1000D expects a Common Source Database; DITA expects a component content management system. Either way you need check-in and check-out, versioning, branching for concurrent revisions, and a single authoritative copy of every module. A folder of XML files on a share drive is not a CSDB, however well organized.

• Applicability and effectivity

  How does it handle multiple aircraft from one source?

  This is where small teams running mixed fleets get hurt. One procedure that differs across three tail numbers should be one module with applicability expressions, not three near-identical copies that drift apart. Ask to see applicability resolved at publish time against a real configuration, not described on a slide.

• Business rules enforcement

  When does non-compliant content get caught?

  Validation against the governing DTDs, schemas, and business rules should happen while the author is writing, not in a delivery review three weeks before the drop. Ask whether BREX and equivalent rule sets are enforced at authoring time and what the author sees when a rule fails.

• OEM and supplier data ingestion

  What happens to data you did not author?

  Operators rarely control the format their OEMs deliver in. A centralised documentation operation lives or dies on how well it absorbs mixed supplier data — different standards, different issues, different levels of compliance — without hand-rebuilding each drop. Ask what the ingestion path looks like for a supplier who sends you legacy PDF.

• Illustration pipeline

  How are graphics managed and reused?

  Technical illustrations carry their own control numbers, revisions, and hotspot data linked to parts. Ask how illustrations are stored, how ICNs are allocated, whether hotspots survive a revision, and what happens when one graphic is reused across many modules.

• Output channels

  Can one source produce every deliverable you owe?

  Most programs owe more than one format: page-based PDF for the contract deliverable, an IETM for the maintainer, a portal or EFB view for daily use, and something that works with no connectivity in a hangar. All of it should come from the same source without a parallel production process per channel.

• Security and export control

  Does the deployment model match your obligations?

  Distribution statements, export-controlled content, and customer security requirements constrain where content can be hosted and who can see it. Ask about deployment options — cloud, on-premise, air-gapped — and whether access control is granular enough to scope permissions by customer, team, and individual document.

• Migration in, and migration out

  How do you get your content back?

  The migration into a platform is quoted and planned. The migration out usually is not, and it is the question that tells you how much leverage you are giving up. Ask what a full export looks like, in what format, and whether it round-trips into another compliant system.

Working through this list is exactly what our analysis and strategy engagements do — platform selection and build-versus-buy evaluation against the standards your program actually owes. Most of them end with a recommendation for a platform we do not sell.