The Hidden Gap in Model-Based Product Definition – and How to Fill It

White Paper

April 6, 2026

Andrew

Bank

Strategy & Business Development

For years, model-based engineering has promised faster cycles, fewer errors, and a true digital thread from design to delivery. Most organizations have taken the first step: replacing 2D drawings with 3D CAD models and adding Product and Manufacturing Information (PMI).

That step matters. But it’s not the end.

If your definition of “model-based” stops at geometry and tolerances, you’re still running a document-driven process – just with nicer visuals.

In practice, most of the information that governs how a product is made, tested, purchased, and sustained still lives outside the CAD model:

Materials. Heat treatments. Coatings. Manufacturing processes. Test methods. Quality requirements. Acceptance criteria. Regulatory constraints. Industry standards. Supplier and lead-time realities. And more.

These requirements are often referenced in notes like “per ASTM B117” or “per AMS 2750,” buried in PDFs, technical data packages, customer requirement documents, purchase specs, and standards. Humans can read them. Machines can’t. And that breaks the digital thread.

The result is a partial and fractured product definition: highly precise geometry surrounded by static pointers to documents that require manual interpretation. Downstream teams – manufacturing, procurement, quality, compliance – are forced to re-read, re-key, and re-interpret the same information repeatedly, increasing risk and slowing delivery.

That’s not model-based engineering. It’s document management with better graphics.

The Defense Standardization Program Office’s 2026 Digital Standards Strategy (DSS) makes this gap harder to ignore. It defines digital standards as standards published in machine-readable and machine-interpretable formats for use in digital tools and processes, including models. In plain terms, defense programs are moving away from standards as static reference documents and toward standards as usable digital inputs.

Why CAD Alone Creates Real Risk

Relying on the CAD model as the single “source of truth” creates blind spots that show up late and cost real money:

Outdated specifications slip into new designs because nothing flags that a referenced standard has been revised, replaced, or canceled.
Regulated materials and critical minerals get specified without visibility into restrictions, obsolescence threats, or geopolitical sourcing risk (PFAS, cadmium, scarcity, and more).
Long-lead-time processes hide in plain sight until procurement discovers that a casting or forging adds months to the schedule (often around 200 days when administrative + production lead time is combined).
Supplier dependencies get locked in by a single line in a spec, long before anyone evaluates supplier health, ownership, capacity, or disruption exposure.

None of these are geometric problems. They are definition problems. They are information gap problems.

And they persist because many of the requirements that matter most are not model-based at all – they’re static text trapped in documents.

Why “Digitizing PDFs” Doesn’t Fix It

Many organizations try to close this gap with requirements on extraction tools or general-purpose AI. These approaches can identify that a requirement exists, but they often fail to understand what it actually means.

Recognizing “shall,” “should,” and “may” is easy. Knowing whether the statement refers to a tolerance, surface finish, chemical specification, test method, or process constraint is not. And extracting the correct values, ranges, dependencies, and context is even harder.

There’s also a deeper issue: semantic consistency. Without a robust engineering ontology and canonical semantic model, the same concept can be described differently across documents and drawings, preventing parts from being grouped, compared, or analyzed reliably.

As complexity increases, general-purpose AI adds another risk: hallucinated interpretations and inferred attributes. In engineering, that’s not “occasionally annoying.” It can derail manufacturing, disrupt compliance, or compromise performance and safety.

What a Complete Product Definition Really Looks Like

A complete Model-Based Product Definition goes beyond geometry. It defines exactly all requirements for the part or assembly in a structured, machine-readable way – including the operational, compliance, and procurement context that determines real-world outcomes.

Practically, this means MBPD is not just an annotated 3D model. It’s a combination of:

A geometric model (features, tolerances, GD&T)
A requirements graph that captures every requirement – including those originating in external standards and process specifications

The key shift is that “requirements” stop being vague pointers buried in PDFs and become explicit, linkable objects that downstream systems can reason over. Materials, coatings, heat treatments, inspection criteria, test methods, and supplier or lead-time constraints can be represented alongside geometry in a consistent way. In this world, industry standards are no longer just citations (e.g., “test according to ASTM B117”). They become reusable, versioned, machine-consumable requirement sets that can be linked, validated, and propagated across programs.

The DSS says this shift starts with machine-readable formats such as XML, but it does not stop there. It also calls for machine-interpretable formats, including models, so standards can be used directly in digital tools, and it names Systems Modeling Language (SysML) as one example. That is a practical reminder that “per ASTM B117” is not model-based product definition. It is still a pointer to a document that someone has to go read.

Where SWISS Fits In (At a High Level)

This is the problem SWISS is built for.

At a high level, SWISS transforms static engineering documents and standards into structured, interoperable product intelligence, organized in a requirements graph (the SWISS Knowledge Graph) that connects geometry to the requirements, standards, and constraints that drive real-world outcomes.

SWISS can also support the move into model-based forms. Exiger has already demonstrated prototype work for NASA in which requirements captured in SWISS were mapped into SysML in Cameo, with traceability back to the source. The point is not to force everything into one modeling tool. It is to turn legacy technical content into structured requirement data that can feed the tools and models that need it.

SWISS does this through an ensemble of capabilities working together: engineering-aligned ontologies that enforce semantic consistency; semantic understanding to interpret requirements in context; authoritative standards metadata (and/or full text) to treat standards as data rather than footnotes; and AI that can extract and normalize requirements into structured objects that can be validated, versioned, and reused. The result is not simply “digitized documents,” but a coherent model-based product definition that enables inferences and downstream automation that aren’t possible when critical requirements remain trapped in static text.

What this enables for the digital thread and supply chain is straightforward: fewer late surprises. When standards, processes, and constraints are captured as structured requirements (not just citations), systems can flag when a standard is outdated, surface regulated substances hiding inside a plating callout, and highlight long lead-time processes before schedules are committed. It also reduces the “handoff reset” between engineering and supply chain teams – so procurement isn’t forced to re-interpret the same requirements from scratch. Model-based definition stops being an engineering hygiene effort and becomes a practical bridge to buying, building, and sustaining the product with fewer avoidable delays.

That shift from documents as the source of truth to a structured, machine-interpretable product definition is where things get interesting.

Want the Full Picture?

Download the full paper if you want to understand:

What a complete model-based product definition actually requires
Why general-purpose AI alone can’t solve this problem
How industry standards can be brought into the model itself
How this enables automation across manufacturing, procurement, supply chain, compliance, and sustainment
And how a requirements graph can serve as the model-based “source of truth”

Because the promise of model-based engineering isn’t just better models. It’s better and faster decisions that come from better decision-making data – and that only happens when the whole product definition is finally visible, connected, and usable.

Contact Us

Exiger’s SWISS platform uses domain-specific, semantic AI trained with proprietary ontologies and data on parts, materials, and manufacturing processes to turn analog drawings, standards, and technical documents into structured, machine-readable product definition. Organized in the SWISS Knowledge Graph and available by API, that data can flow by reference into PLM/PDM, QMS, MES, and supply-chain workflows – helping teams catch outdated specs, regulated materials, critical mineral vulnerabilities, long lead-time processes, and supplier constraints before they become delays, rework, procurement emergencies, or compliance liabilities.