1. Purpose and Scope

This article provides guidance for authoring applicability in S1000D when factory configuration conditions (e.g., Drawing / Modsum) coexist with in-service configuration conditions (e.g., Service Bulletins).

The intent is to:

• Make lifecycle assumptions explicit
• Define the required business rule decisions up front
• Show clear, computable applicability fragments
• Demonstrate how content is correctly associated with applicability (best-practice terminology)

All examples use generic condition names and are intended to be portable across S1000D-compliant systems.

---

2. Business Rule Decisions (Must Be Agreed First)

Before authoring any applicability, the following business rule decisions must be explicitly agreed at project level. These are not optional.

2.1 Lifecycle Separation

• Factory conditions describe how the product is built or delivered.
  • Examples: Drawing status, Modsum, production modification
• In-service conditions describe changes embodied after delivery.
  • Examples: Service Bulletins (SB)

Even if a factory modification and an SB refer to the same physical change, they represent different lifecycle states and must be modeled as separate conditions.

A drawing does not “become” an SB, and an SB does not retroactively redefine a drawing.

---

2.2 Condition Domains Used in This Article

For the purpose of this article, the following condition domains are assumed:

Factory condition (Drawing / Modsum)

• FACTORY_MOD = NO
• FACTORY_MOD = YES

In-service condition (Service Bulletin)

• SB = NA (not applicable)
• SB = PRE (applicable, not embodied)
• SB = POST (embodied)

---

2.3 Content Authoring Intent

For the remainder of this article, we assume the following explicit authoring intent:

• PARA-A applies to products before embodiment of the modification
  • Factory: NO
  • In-service: PRE
• PARA-B applies to products after embodiment of the modification
  • Factory: NO
  • In-service: POST

This split is intentional and reflects a common retrofit documentation pattern:

• Same factory baseline
• Different instructions depending on SB embodiment state

2.4 Model Assumptions and Normalization Rules

For the purpose of this article, applicability is authored against a specific, constrained configuration model for a single modification.

The following assumptions apply:

• The modification can be embodied either at the factory or in service, but not both.
• Service Bulletin (SB) status is only meaningful when the factory modification is not present.
• When the modification is embodied at the factory, the SB is not applicable.

Under these rules, the following configurations are treated as semantically equivalent, as they represent the same resulting configuration state (modification embodied):

• FACTORY_MOD = NO and SB = POST
• FACTORY_MOD = YES and SB = NA

Applicability authored for the embodied state must therefore explicitly include both conditions. This equivalence is not inferred by S1000D and must be modeled deliberately in the applicability logic.

These assumptions apply only to the model described in this article and must not be generalized without explicit project agreement.

---

3. Key Authoring Principles

3.1 Applicability Is Logical, Not Interpretive

S1000D does not infer transitions.

Changing an SB from PRE to POST:

• Does not automatically change factory conditions
• Does not implicitly flip applicability

Applicability resolution is based only on:

• The authored logic in <applic>
• The values present in the Product Configuration Table (PCT)

If applicability must change when SB status changes, that behavior must be explicitly authored.

---

3.2 Author PRE and POST Separately

Best practice is to:

• Author applicability against PRE (before embodiment)
• Author applicability against POST (after embodiment)

POST should be treated as a resulting configuration state, not a shortcut for reversing logic.

---

4. Applicability Authoring Patterns

4.1 Pattern A — PARA-A (Not Yet Embodied)

Authoring intent:

PARA-A is applicable only while the modification is not yet embodied for factory-baseline products.

For this article’s model, PARA-A and PARA-B are intended to be mutually exclusive for any given product configuration. This ensures that when the SB status transitions from PRE → POST, PARA-A becomes not applicable and therefore hidden from filtered output.

Computable applicability fragment (mutually exclusive with PARA-B)

<applic id="app-paraA">
  <evaluate andOr="and">
    <assert applicPropertyIdent="FACTORY_MOD"
            applicPropertyType="condition"
            applicPropertyValues="NO"/>
    <assert applicPropertyIdent="SB"
            applicPropertyType="condition"
            applicPropertyValues="PRE"/>
  </evaluate>
</applic>

---

4.2 Pattern B — PARA-B (Embodied)

Authoring intent:

PARA-B is applicable when the modification is embodied, either:

• at the factory, or
• in service via SB embodiment

This pattern explicitly implements the article’s normalization rule that the following are equivalent “embodied” states:

• FACTORY_MOD = YES and SB = NA
• FACTORY_MOD = NO and SB = POST

Computable applicability fragment

<applic id="app-paraB">
  <evaluate andOr="or">
    <evaluate andOr="and">
      <assert applicPropertyIdent="FACTORY_MOD"
              applicPropertyType="condition"
              applicPropertyValues="YES"/>
      <assert applicPropertyIdent="SB"
              applicPropertyType="condition"
              applicPropertyValues="NA"/>
    </evaluate>
    <evaluate andOr="and">
      <assert applicPropertyIdent="FACTORY_MOD"
              applicPropertyType="condition"
              applicPropertyValues="NO"/>
      <assert applicPropertyIdent="SB"
              applicPropertyType="condition"
              applicPropertyValues="POST"/>
    </evaluate>
  </evaluate>
</applic>

---

4.3 Explicit Mixed Case — Factory NO AND SB POST

Some projects allow (or temporarily observe) the combination:

• Factory baseline unchanged (NO)
• SB embodied in service (POST)

If this combination is meaningful, it should be explicitly modeled, not implied.

<applic id="app-factoryNO-sbPOST">
  <evaluate andOr="and">
    <assert applicPropertyIdent="FACTORY_MOD"
            applicPropertyType="condition"
            applicPropertyValues="NO"/>
    <assert applicPropertyIdent="SB"
            applicPropertyType="condition"
            applicPropertyValues="POST"/>
  </evaluate>
</applic>

Whether this case maps to PARA-B or is handled separately is a business rule decision, not an authoring accident.

---

5. How Content Is Associated with Applicability

In S1000D, applicability is associated with content by referencing an applicability annotation from the content element using the attribute applicRefId.

An applicability annotation (defined using <applic>) represents a logical condition. Content elements reference that annotation to indicate when they apply.

Applicability references apply to the element on which they are declared and to all of its descendant elements.

Recommended phrasing in documentation

The following phrasing is recommended when describing applicability behavior:

• “This paragraph references applicability app-paraA.”
• “Applicability app-paraA is applied to this paragraph via applicRefId.”
• “This content is applicable under the conditions defined in app-paraB.”

Using consistent terminology helps avoid ambiguity when discussing applicability logic, reviews, and implementation.

---

6. Structure and Use of Applicability in a Data Module (BREX-Style)

6.1 Data Module–Level Applicability

Rule 6.1.1
The overall applicability of a data module shall be defined in the ident and status section using <applic> within <dmStatus>.

<identAndStatusSection>
  <dmStatus>
    <applic>...</applic>
  </dmStatus>
</identAndStatusSection>

Rule 6.1.2
Data module–level applicability shall define the maximum applicability scope for all content contained in the data module.

Rule 6.1.3
Content-level applicability shall not broaden or contradict the applicability defined at data module level.

---

6.2 Content-Level Applicability — S1000D Issue 4.0.1

Rule 6.2.1
For data modules authored to S1000D Issue 4.0.1 (and earlier), applicability annotations intended for reuse within the data module shall be defined using <referencedApplicGroup> outside the <content> element, typically within the status section.

Rule 6.2.2
Content elements shall reference these applicability annotations using the attribute applicRefId.

<identAndStatusSection>
  <dmStatus>
    <referencedApplicGroup>
      <applic id="app-paraA">...</applic>
      <applic id="app-paraB">...</applic>
    </referencedApplicGroup>
  </dmStatus>
</identAndStatusSection>

<content>
  <description>
    <para applicRefId="app-paraA">...</para>
    <para applicRefId="app-paraB">...</para>
  </description>
</content>

---

6.3 Content-Level Applicability — S1000D Issue 4.1

Rule 6.3.1
For data modules authored to S1000D Issue 4.1, applicability annotations intended for reuse within the data module shall be defined under <content> using <referencedApplicGroup>.

Rule 6.3.2
Content elements shall reference these applicability annotations using the attribute applicRefId.

<content>
  <referencedApplicGroup>
    <applic id="app-paraA">...</applic>
    <applic id="app-paraB">...</applic>
  </referencedApplicGroup>

  <description>
    <para applicRefId="app-paraA">...</para>
    <para applicRefId="app-paraB">...</para>
  </description>
</content>

---

6.4 Applicability Propagation

Rule 6.4.1
When an applicability reference is applied to a content element, that applicability shall apply to the element and all of its descendant elements, unless explicitly overridden by a narrower applicability reference.

---

6.5 Portability and Compliance

Rule 6.5.1
Authors shall place applicability annotations according to the S1000D issue defined for the project.

Rule 6.5.2
Systems and processes shall not assume that applicability annotations will be relocated, inferred, or reinterpreted across different structural locations.

Rule 6.5.3
The logical meaning of applicability shall be considered identical across S1000D issues; only the structural placement differs.

---

7. Mandatory Consistency Rule

Rule 7.1
The data module–level applicability shall define the outer boundary of applicability for the data module.

Rule 7.2
Applicability referenced at content level using applicRefId shall only further restrict the applicability defined at data module level.

Rule 7.3
Content-level applicability shall not broaden, expand, or contradict the applicability defined for the data module.

Rule 7.4
If a data module is not applicable for a given configuration, no content within that data module shall be applicable for that configuration.

---

8. What to Avoid

• Mixing factory and in-service semantics into a single condition
• Assuming PRE automatically becomes POST
• Relying on runtime logic or viewer behavior
• Authoring ambiguous OR logic without documented intent

Any deviation from these rules must be treated as a project-specific customization, with acknowledged risks including development cost, validation effort, long-term maintenance impact, and the possibility of different applicability results being produced by different S1000D-compliant systems when processing the same data.

---

9. Final Recommendation

Successful applicability authoring requires:

• Explicit lifecycle modeling
• Agreed business rules before XML is written
• Separate handling of PRE and POST states
• Clear association of content with applicability annotations

If the intent is clear in the business rules, the XML becomes straightforward and the results become predictable, portable, and maintainable.

Turning theory into a working model

In real programs, applicability models rarely stay this clean. Legacy condition sets, inconsistent SB semantics, overlapping fragments, and loosely defined condition values quickly introduce ambiguity, even when the underlying business intent is sound.

Synaxiom works with OEMs, MROs, and technical publication teams to correct these issues by re-establishing clear lifecycle rules, normalizing condition definitions, and restructuring applicability fragments into a coherent, computable model aligned with S1000D best practice.

Programs that struggle with unpredictable filtering results, complex exception handling, or growing authoring effort are typically seeing symptoms of an applicability model that needs professional intervention. Synaxiom provides targeted applicability assessments and remediation services to bring these models back under control and keep them that way as configurations evolve.

To discuss applicability assessment or remediation support for your program, contact Synaxiom.
.