Why graphics matter in long-lifecycle technical documentation

In long-running aerospace programs, technical documentation is sustained for decades. During that time, products evolve, suppliers change, and delivery platforms come and go. Graphics sit directly in the path of that change. They are not disposable artwork. They are information assets that need to remain usable, traceable, and maintainable over a long lifecycle.

That is why early decisions about graphics have outsized impact. A format choice is not only a viewer preference. It affects authoring toolchains, interchange commitments, quality assurance, configuration control, and the cost of sustaining large legacy libraries. Those costs do not show up immediately. They emerge over years, often during platform transitions, outsourcing, or modernization initiatives.

The practical goal is not to pick a “best” format in isolation. The goal is to design a graphics lifecycle that remains supportable when today’s tools, operating systems, and deployment constraints are no longer in place.

Graphics are part of the information system, not just illustrations

In S1000D, graphics are referenced and managed as CSDB assets. They are tied to content, identified for reuse, and often integrated with navigation and cross-referencing behaviors in delivery. In many projects, a graphic also carries meaning through structure such as callouts, identifiers, and linkable regions. That meaning supports tasks, fault isolation, parts identification, and training, not merely appearance.

When an organization treats graphics as “just pictures,” two predictable problems follow:

1. Loss of traceability: It becomes harder to prove what changed, why it changed, and which data modules are affected.
2. Loss of functional intent: The delivered page may still show an image, but the interactive behavior, identifiers, or relationships that users rely on can degrade over time.

A sustainable approach assumes from the start that graphics participate in information governance alongside text.

The role of CGM in S1000D programs

CGM (Computer Graphics Metafile) has a long history in technical publishing and has been widely used in S1000D environments. Many programs adopted CGM because it is standardized, device-independent, and well-suited to controlled technical illustration workflows. Those characteristics map well to the priorities that shaped early S1000D programs, particularly controlled interchange between organizations and predictable reproduction across platforms.

It is also important to be precise about what “CGM in S1000D” often means in practice. Many toolchains rely on established CGM profiles used in technical publications, and many organizations have invested heavily in CGM libraries that represent significant intellectual capital. That investment matters. Even when an organization modernizes delivery, it rarely wants to discard a source library that is proven, governed, and integrated into QA and configuration processes.

CGM is therefore best understood as a mature, established choice for authoritative source graphics in many S1000D programs. It is not “old” in the sense of being irrelevant. It is proven and deeply embedded in long-life documentation ecosystems.

Why SVG is common in modern runtime delivery

Scalable Vector Graphics (SVG) is widely used in many delivery environments today because it fits how those environments are typically deployed. SVG is a web-native vector format supported by modern browsers and is generally straightforward to render in web and mobile-oriented viewers. That matters for organizations that deploy IETPs through standard browsers, locked-down enterprise endpoints, or controlled networks where installing plugins or specialized rendering components is undesirable.

For runtime delivery, SVG often offers practical benefits:

• Strong alignment with web delivery and modern UI frameworks
• Reduced dependence on specialized client-side rendering components
• Easier integration with responsive layouts and zooming behavior
• Familiar handling by IT and cybersecurity stakeholders in web deployments

None of these points imply that SVG is universally “better.” They explain why, at runtime, many organizations prefer a format that aligns with the delivery stack they already operate and secure.

Authoring and interchange formats versus runtime formats

A common source of confusion is the assumption that a program must use one graphics format from authoring through delivery. Mature documentation ecosystems often separate these concerns.

A useful way to frame the lifecycle is:

• Authoritative source representation: The format and files the organization governs for long-term maintenance, reuse, and interchange commitments..
• Delivery representation: A format optimized for the viewing environment, performance, and platform compatibility.

Many organizations keep CGM as the interchange-governed source format while delivering SVG as a runtime representation. This is an architectural pattern, not a loophole. The key compliance point is not “one format everywhere.” The key point is that interchange obligations and the meaning of the information are preserved according to program requirements, contractual commitments, and business rules.

For program managers and technical publication leads, the question becomes: what must be preserved as authoritative, and what can be derived for delivery without creating future risk?

Preserving meaning during CGM to SVG conversion

It is tempting to treat CGM to SVG conversion as a simple export step. For technical publishing, that is often the wrong mental model.

A technical graphic can contain meaning beyond appearance. That meaning may include stable identifiers, callout relationships, link targets, and interactive regions that tie the graphic to other information objects in the CSDB and to viewer behaviors. If those semantics are lost, the graphic may still look correct, but it may not behave correctly in delivery or may no longer support traceability and reuse.

A conservative expectation in many programs is that conversion preserves the information required for the program’s intended use, not only the visual result. S1000D defines how meaning is expressed in each graphics format, but not how one format is transformed into another.

What “required” means depends on the program. Some programs use graphics primarily for static illustration. Others rely on hotspots, interactive callouts, and cross-references. The more functional the graphic is in delivery, the more important it becomes that conversion preserves identifiers and relationships consistently and predictably.

This is also why conversion is a governance topic, not a last-minute production task. It needs acceptance criteria and quality checks that reflect how the organization uses graphics.

As with most long-lifecycle programs, there are edge cases, and these usually surface during reuse or platform transitions rather than initial delivery.

Common misconceptions to correct gently

“SVG replaces CGM”
In many S1000D programs, SVG does not replace CGM. Instead, SVG is used as a delivery representation while CGM remains an authoritative source representation. Whether a program chooses that pattern depends on contractual commitments, existing libraries, and toolchain maturity.

“Graphics formats are just a viewer concern”
Format choices affect authoring tools, QA practices, interchange packaging, long-term maintainability, and the ability to reuse graphics across programs. Viewer compatibility is only one part of the decision.

“Conversion is a simple export”
Conversion is often a controlled transformation of an information asset. If the program relies on semantics such as identifiers or interactive regions, conversion must preserve those aspects consistently. Visual similarity alone is not a sufficient definition of success in many technical publishing contexts.

Where organizations typically need support

Organizations usually seek support when they need to modernize without breaking sustainment.

Common needs include:

• Defining a graphics strategy that distinguishes authoritative sources from delivery representations, aligned to program lifecycle and contractual interchange expectations
• Managing legacy CGM libraries in a way that protects existing investment while enabling modern delivery stacks
• Ensuring compliance while modernizing, including governance of derived delivery assets and clear acceptance criteria for conversion results
• Training teams so that program leadership, publication leads, and architects share a common understanding of graphics lifecycle decisions and the risks of informal conversions

These are cross-functional issues. They typically involve engineering governance, publication operations, QA, IT security, and vendor management.

Closing perspective

CGM and SVG are best understood as serving different roles in many S1000D environments. CGM is often associated with controlled authoring and long-term stewardship of technical graphics libraries. SVG is often associated with pragmatic runtime delivery in modern web-oriented environments. Treating this as a lifecycle design choice, rather than a format debate, leads to clearer governance and fewer surprises later.

If your organization is planning a modernization program, consolidating toolchains, or inheriting a large legacy graphics library, these topics are often explored in more depth through structured training or professional services. The value is not in selecting a format slogan. The value is in making a graphics lifecycle decision that remains supportable ten or twenty years from now.

A perspective shaped by real programs

The challenges described in this article are not theoretical. They come from programs that have accumulated large CGM libraries over many years, often across multiple suppliers and generations of tooling. They come from teams under pressure to modernize delivery without breaking interchange commitments, invalidating legacy data, or losing the embedded knowledge encoded in technical graphics.

Common concerns tend to sound familiar:

• “We cannot afford to lose the meaning embedded in our CGMs.”
• “We need modern browser-based delivery, but we cannot rewrite decades of content.”
• “Our graphics are more than pictures. They carry identifiers, structure, and behavior.”
• “We want to move forward without creating a parallel documentation universe we cannot sustain.”

These are reasonable concerns. They reflect an understanding that graphics sit at the intersection of authoring, governance, and delivery.

NIVOMAX was shaped in response to these realities. The goal is not to treat CGM as a legacy obstacle, and not to treat SVG as a shortcut. The goal is to respect the role each plays in a long-lived technical information system. CGM graphics are consumed as managed information assets. When SVG is generated for runtime use, the intent is to preserve meaning, metadata as governed by S1000D graphics and ICN constructs, and interactive behavior alongside visual fidelity, so delivery can modernize without hollowing out the underlying information.

For organizations navigating this transition, the hardest part is often not the conversion itself, but confidence. Confidence that modernization will not silently erode traceability, reuse, or correctness. Confidence that what is delivered to users faithfully represents what was authored and governed over time.

If you are facing these questions and looking for a path that acknowledges both where you have been and where you need to go, this is the space where Synaxiom and NIVOMAX typically engage. Not by prescribing a single answer, but by working through constraints, risks, and expectations together, based on how real S1000D programs operate.