Engineering Data as a Decision Asset

From Gut Feel to Evidence

Engineering decisions have always relied on some combination of experience, analysis, and intuition. The question is the mix — and whether the mix is deliberate or accidental.

In many organizations, decisions that should be data-informed are made by intuition because the data is locked in documents, spreadsheets, and slide decks that nobody has time to synthesize. The data exists, but it is not accessible at the moment the decision is made. The result: engineering decisions that are defended by "engineering judgment" when what actually happened was "I didn't have the data in front of me, so I went with my gut."

Digital engineering changes the accessibility equation. When engineering information is structured, queryable, and connected through the digital thread, data becomes available at the point of decision — not days later after someone digs through archives.

Three Levels of Decision Maturity

Organizations do not jump from intuition to data-driven overnight. There is a progression, and each level has distinct characteristics.

Intuition-Based Decisions

Decisions rest primarily on experience, precedent, and the judgment of senior engineers. Data may exist somewhere in the organization, but it is not systematically consulted. This is not always wrong — experienced engineers carry valuable pattern recognition. But it is fragile: it fails when the senior person retires, when the situation is genuinely novel, or when organizational memory fades.

Recognizable signs: Decisions justified by "we've always done it this way," no documented rationale, outcomes not tracked against predictions.

Data-Informed Decisions

Data is consulted during the decision process, but it serves as input to human judgment rather than driving the decision directly. Engineers review simulation results, reference test reports, and consider historical performance — but the synthesis and weighting happen in someone's head. The data influences the decision; it does not determine it.

Recognizable signs: Analysis reports are produced and reviewed before decisions, but the link between specific data points and the final choice is informal. Rationale documents exist but are written after the fact.

Data-Driven Decisions

Structured data flows directly into the decision framework. Criteria are defined quantitatively, alternatives are evaluated against those criteria with model-derived or measured data, and the decision rationale is traceable from choice back to evidence. Human judgment still plays a role — in framing the decision, selecting criteria, and interpreting results — but it operates within a structured process rather than replacing one.

Recognizable signs: Decision criteria and weights are defined before analysis begins. Each alternative is scored against each criterion with traceable data sources. The rationale document is generated from the analysis, not written retrospectively.

Types of Engineering Data

In a digital engineering ecosystem, four categories of data feed decisions. Each serves a different purpose, and understanding the distinction prevents treating all data as equivalent.

Model Data

Properties and relationships defined in the system model: component masses, power budgets, interface definitions, requirement allocations. This data represents the design intent — what the engineering team has decided the system should be. In an MBSE context, model data is structured by the modeling language (SysML, CAPELLA, or others) and is queryable, traceable, and version-controlled. It is the authoritative source for "what did we design?"

Simulation Data

Results from executing behavioral models: stress analysis, thermal simulations, performance benchmarks, Monte Carlo runs. This data tests the design predictions — what the models say will happen if we build what we designed. Simulation data carries uncertainty (model assumptions, mesh sensitivity, input variability) that must be understood before it is trusted.

Test Data

Results from physical or integration testing: measured performance, failure modes, pass/fail verdicts against requirements. This data validates the design reality — what actually happened when we built and exercised the system. Test data is the gold standard for confidence, but it arrives late in the lifecycle and is expensive to generate.

Operational Data

Telemetry, logs, sensor readings, maintenance records, and anomaly reports from deployed systems. This data reveals the design in context — how the system performs under real conditions over time. Operational data is the most valuable for improving future designs, but it is also the hardest to connect back to the engineering model because it lives in operations systems, not engineering systems.

MBSE as the Data Backbone

The system model in MBSE is not just a design artifact — it is the structural backbone that gives engineering data its context. Without the model, a simulation result is a number. With the model, that number is connected to the component it describes, the requirement it verifies, the interface it depends on, and the alternative it evaluates.

This is the MBSE reinforcement from DGTLENG 104 (Requirements): requirements captured in the model are not just text — they are elements with typed relationships to the architecture, to verification methods, and to the data that supports each decision. When requirements are structured this way, every decision that touches a requirement can trace its evidence chain from stakeholder need through system requirement through analysis data to the final choice.

The digital thread extends this connectivity across the lifecycle: model data connects to simulation data connects to test data connects to operational data. The thread makes it possible to ask questions that span these categories — "How does the actual thermal performance of component X compare to what the simulation predicted, and does it still satisfy the requirement?" — and get answers without manual archaeology.

The Trap: More Data Is Not Better Data

The most common failure mode in data-driven engineering is not too little data — it is too much undifferentiated data. When every parameter, every simulation run, and every sensor reading flows into a decision, the signal drowns in noise.

Data without context is noise. A temperature reading means nothing without knowing which component, under what conditions, measured by what instrument, with what accuracy.

Data without relevance is distraction. Not every available data point is relevant to the decision at hand. Defining what data matters — before collecting it — is an essential step that most organizations skip.

Data without quality assessment is dangerous. A simulation result from an unvalidated model is not evidence — it is a hypothesis. Treating it as fact leads to false confidence. Every data source should carry a confidence indicator: is this measured or predicted? Validated or assumed? Current or stale?

The discipline of data-driven decision-making is not "use all the data." It is "use the right data, understand its limitations, and be explicit about what you know and what you are assuming."

Assessment