How to tell digitization from real change

I said this in a recent conversation with Kirsten McCane and a few of our AeroDef application engineers, “Digital engineering is anything that replaces the paper trail with a digital trail.” Someone asked a fair question. “So, if we scan documents into PDF, are we doing it right?”

The answer is no. Scanning is useful. But it is not digital engineering. That’s why we launched this blog, to clarify statements like these and make them useful in your daily work.

Three terms that sound similar but are not the same

• Digitization: converts analog to digital files (scanned PDFs, OCR’d specs, shared drives). It improves access and search, but it leaves the underlying process unchanged.
• Digitalization: modernizes the process around those files (e.g., electronic signatures, basic workflow automation). Work moves faster. But it is still driven by documents.
• Digital engineering: You move from document first to model first. Truth lives in models and connected digital artifacts that span mission analysis, architecture, detailed design, verification, and sustainment. In AeroDef, the goal is an authoritative set of models and evidence that the whole program uses.

Why the distinction matters: Programs win (or stall) at the “seams” or interfaces of product develolpment. For example, where requirements meet design, designs meet test, and test evidence meets certification and acquisition artifacts. Only a model-centric approach can keep those “seams” tight under change.

What “good” looks like, and why PDFs fall short

In a document first flow, each review (SRR, PDR, CDR) freezes a snapshot of truth in a report. Changes ripple slowly, inconsistently, and expensively. In a model first flow, truth lives in executable and analyzable artifacts. System architecture models. Parameterized simulations. Generated code. Verification results. Data that is under configuration control. Reviews consume models and generated evidence, not static documents. This isn’t just a tooling choice; it’s a product lifecycle commitment that acquisition, systems engineering, design, V&V, acquisition and sustainment agree to share.

Five quick tests to see if you are actually doing digital engineering

1. Authoritative models, not files
   Do requirements, architectures, interfaces, and behaviors have a single authoritative representation in models (e.g., system architecture, simulation, verification assets)?  Or are they buried in PDFs and slide decks?
2. Traceability that runs both ways
   Can you navigate bidirectionally from a mission objective to a system requirement, to an interface, to the test that verifies it? Do those links update when things change? Not “we can look it up,” but “the links live in and across the models.”
3. Executable evidence
   When you say a requirement is met, do you show a simulation or an automated test that anyone can rerun? Or do you point to a paragraph in a report?
4. A connected digital thread
   Are models, parameters, generated code, and test results versioned and baselined together? Do reviews pull from that single thread?
5. Lifecycle participation
   Do acquisition and technical reviews actually consume model artifacts? Or do you still rebuild the truth as documents while the models sit on the side?

If you pass most of these tests, you’re practicing digital engineering. If not, you may be doing useful digitization or process digitalization. Both have value. But don’t expect the step change in speed, quality, or risk you’re hearing about until models become the source of truth.

A small, concrete pattern

Consider a safety-critical subsystem with a performance requirement and an interface contract. In a model first approach:

• The requirement is managed in a system model and linked to the relevant architecture element and design model.
• The interface contract is defined in the architecture model and checked in simulation, including edge cases from mission context.
• Verification is executable (simulation with test harness) and runs in CI on every change. Results trace back to the requirement and are part of the report package generated for review.
• When a requirement changes late in the program, the impact analysis is instant. Affected components, tests, and documentation regenerate from the models.

None of this happens by scanning documents. It happens when models replace documents as the source of truth and when verification is automated and connected.

Why we’re writing about this here

From the start, we promised practical content and no hype. We also promised to keep this relevant across industries while honoring AeroDef realities. Calling out the “PDF fallacy” is part of earning that trust.

What do you want next?

We are planning a follow up. Option one shows how to make architecture models authoritative without trying to model everything on day one. Option two shows how to turn document-based verification into executable evidence. Tell us which one would help your team more right now.