Explainer
Applicability in S1000D: ACT, CCT, and PCT, With an Example
The Problem
One Library, Many Aircraft
The page-based world handled configuration differences with footnotes and judgment: “aircraft 1–50 pre-mod,” an effectivity column, a maintainer expected to know which variant they were touching. At fleet scale that breaks — mods land on some tail numbers and not others, customer options multiply, and the difference between two configurations can be the difference between a correct torque and a damaged component. S1000D's answer is applicability: content declares, in machine-evaluable expressions, which product instances and conditions it is true for — at module level, and down to the individual step or warning.
The machinery lives in three special data modules. The ACT defines the product attributes you may test (model, serial number). The CCT defines conditions (a modification embodied, a service bulletin incorporated). The PCT lists real product instances with their values — which tail has which mod. The content speaks the vocabulary; the tables ground it in the actual fleet.
The Example
Mod-42, Two Tails, One Module
Concretely: a pump-removal procedure where one step changed with Mod-42. The common steps carry no annotation. The two variant steps each carry an expression — “Mod-42 embodied” on the new step, “not embodied” on the old. The PCT records that tail 103 has the mod and tail 104 doesn't. Now the viewer filtered to tail 103 renders one clean procedure, tail 104 the other, and the print rendition shows both with applicability statements. One module maintained, zero duplication, and the wrong-variant page can't be opened by accident — the same single-source principle that powers effective-dated publishing, applied to configuration instead of time.
The craft is in restraint. The vocabulary belongs in the business-rules conversation at program start: few attributes, named well, fed by configuration records you actually trust — because the PCT automates whatever the mod-tracking data says, right or wrong. Applicability done well is invisible; done badly it's a fleet-wide logic puzzle. It is, in our experience, the single best predictor of whether an S1000D program understood the spec or merely validated against it.
FAQ
Questions We Hear
What is applicability in S1000D?
The mechanism for one library serving many configurations. A fleet is never uniform — serial ranges differ, modifications land on some tail numbers and not others, options vary by customer. Applicability lets content declare, in machine-evaluable form, exactly which product instances and conditions it applies to, down to individual steps and warnings. A viewer filtered to a specific aircraft then shows the maintainer only what is true for that aircraft.
What are the ACT, CCT, and PCT?
Three cross-reference data modules that hold the shared vocabulary. The ACT — Applicability Cross-reference Table — declares the product attributes applicability can test, such as model and serial number. The CCT — Conditions Cross-reference Table — declares conditions, typically whether a modification or service bulletin has been embodied. The PCT — Product Cross-reference Table — lists actual product instances (real tail numbers) with their attribute and condition values. Content expresses applicability against the ACT/CCT vocabulary; the PCT is what lets a system evaluate it for a specific aircraft.
What does a worked example look like?
Take a pump procedure where one step differs after a mod. The ACT defines attributes 'model' and 'serialNo'; the CCT defines condition 'Mod-42 embodied'; the PCT records that tail 103 has Mod-42 and tail 104 does not. In the procedure, the common steps carry no annotation, while the two variant steps each carry an applicability expression — 'Mod-42 embodied' on one, 'Mod-42 not embodied' on the other. A maintainer viewing tail 103 sees one clean procedure; tail 104 sees the other; the paper-style output can show both with applicability statements. One module, no duplication, no wrong-variant risk.
Where do applicability implementations go wrong?
Three places. Skipping the tables and hand-writing 'applies to aircraft 1-50' as text — human-readable, machine-useless, and unmaintainable. Letting the vocabulary sprawl — every attribute anyone ever wanted, until expressions become unreviewable. And forgetting the data feed: the PCT is only as good as the configuration records behind it, so if mod status isn't tracked reliably per tail number, applicability faithfully automates wrong answers. The cure for all three is treating applicability as a data design problem, settled early with the business rules.
Get In Touch
Applicability You Can Trust?
If your library's applicability is text notes, sprawl, or fed by configuration data nobody believes, the filtered view is theater. We design applicability models that hold.