The Most Expensive Engineering Decisions Are Often Made in a Meeting

Six months later, someone opens slide 47.
There is a block diagram showing the system architecture. One interface is Ethernet. Another is discrete I/O. A processing function that could have lived in hardware has been allocated to software.

Someone asks a reasonable question:

“Why did we design it this way?”

Nobody knows.

The engineer who presented the trade study remembers discussing three options, but not exactly why one was rejected. The software lead vaguely remembers a latency constraint. The electrical engineer thinks there was a supplier limitation. Someone else remembers that the customer wanted room for future expansion.

The meeting minutes say:

Team agreed to proceed with Option B.

That is it.

Option B is now embedded in schematics, software architecture, interface definitions, procurement decisions, and test plans.

But the reasoning that created Option B has disappeared.

So the team does what engineering teams do when the evidence is gone.

They reconstruct it.

They reopen old presentations. Search email. Message former team members. Dig through issue trackers. Compare old revisions of specifications. Repeat calculations that were probably already performed. Schedule another meeting.

And eventually somebody says:

“I think this was because of the timing requirement.”

Think.

That word can get very expensive.

The Architecture Rarely Changes When Someone Edits the Architecture Document

We tend to imagine engineering decisions happening inside controlled artifacts.

A requirement is changed.

A SysML model is updated.

An interface control document is revised.

A drawing is released.

An engineering change request is approved.

Sometimes that happens.

But many of the decisions that actually shape a system happen several steps earlier — in conversation.

A systems engineer says:

“Let’s let software handle that.”

A supplier says:

“We should be able to meet 50 milliseconds.”

A mechanical engineer says:

“If you keep the connector here, we can make the packaging work.”

Someone at PDR says:

“We’re comfortable carrying that risk.”

The customer says:

“We don’t really need that operating mode anymore.”

A chief engineer looks at three alternatives and says:

“Option two gives us the best path forward.”

None of those sentences necessarily look like requirements.

But they can alter requirements.

They can constrain an interface.

They can determine the architecture.

They can accept risk.

They can remove functionality.

They can quietly invalidate a verification approach.

In other words, the engineering baseline may have changed before anybody has touched the engineering baseline.

That is the dangerous part.

NASA’s Systems Engineering Handbook treats decision rationale very differently from administrative meeting trivia. Its guidance on decision analysis calls for capturing the decision context, criteria, alternatives, evaluation methods, assumptions, uncertainties, results, recommendations, the final decision, and its rationale.[1]

That distinction matters.

The fact that a decision occurred is not the same thing as understanding the decision.

Six Months Later, You Don’t Need the Answer. You Need the Reasoning.

Imagine the original architectural decision was this:

Use Ethernet between Subsystem A and Subsystem B.

That is useful information.

Now imagine instead that the engineering record says:

Use Ethernet between Subsystem A and Subsystem B because the interface must support the planned diagnostic data stream, future bandwidth growth is expected, both candidate controllers already provide Ethernet hardware, and analysis showed that the additional network latency remains below the allocated 20 ms interface budget. Deterministic bus Option C was rejected because it provided no meaningful performance advantage for this traffic profile while adding hardware and integration complexity.

Now you have engineering knowledge.

Six months later, someone can ask:

• Has the diagnostic data requirement changed?
• Is future bandwidth growth still expected?
• Did the controller selection change?
• Is the 20 ms allocation still valid?
• Has the traffic profile changed?

If one of those answers changes, the team has a reason to revisit the architecture.

Without the rationale, Ethernet simply looks like the architecture.

And that is how yesterday’s engineering decision becomes tomorrow’s mysterious design constraint.

NASA makes the same point at the requirements level. Its guidance recommends retaining requirement rationale, documenting assumptions, linking to parent requirements or trade studies where appropriate, and capturing design constraints imposed by evolving decisions.[1]

A requirement without rationale tells you what somebody decided.

A decision record tells you why it was reasonable at the time.

Those are not the same thing.

The Rejected Option Is Often More Valuable Than the Selected One

Engineering documentation has a strange habit.

We carefully document what we built.

We are much worse at documenting what we deliberately chose not to build.

Yet six months later, that may be exactly what the team needs to know.

Suppose a new engineer joins the program and notices that the current sensor architecture is expensive.

They find a cheaper alternative.

Excellent.

They build a presentation showing a 30% component-cost reduction.

Everyone gets excited.

Then, halfway through the new trade study, someone remembers:

“Wait. Didn’t we evaluate that sensor last year?”

Maybe.

Why was it rejected?

Nobody remembers.

Now there are two possibilities.

The original rejection is no longer valid, in which case reconsidering the sensor is good engineering.

Or the original rejection is still completely valid, and the team is spending three weeks rediscovering something it already knew.

The only way to distinguish the two is to preserve the original decision context.

NASA’s decision-analysis guidance specifically recommends documenting alternatives that were considered, even when they are eliminated during analysis. Its example decision-report structure includes criteria, options, scoring rationale, risks and benefits, recommendations, final decisions, and dissent.[1]

That is not bureaucracy.

That is protection against organizational amnesia.

The Software Engineering Institute at Carnegie Mellon makes a similar argument in its architecture-documentation work: documenting architecture is not merely about drawing the final structure. Architectural rationale and the decisions that created the architecture are part of what makes the architecture understandable and usable.[3]

A box-and-line diagram tells you what exists.

It rarely tells you why every other reasonable-looking option does not.

Assumptions Are Decisions Wearing Camouflage

Some of the most consequential engineering statements made in meetings begin with harmless phrases:

“We’re assuming…”

“The supplier should…”

“Normally the operator would…”

“That interface won’t ever…”

“We don’t expect…”

The conversation moves on.

Nothing is formally changed.

Except now the architecture depends on something that nobody has committed to proving.

Suppose your thermal design assumes the equipment will never operate continuously at maximum processing load.

That assumption influences heat-sink sizing.

The heat-sink size influences enclosure geometry.

The enclosure geometry influences mass.

Mass influences mounting loads.

Mounting loads influence structural qualification.

Six months later, the customer asks for continuous maximum-load operation.

The requirement change might appear to affect one operating mode.

In reality, it can reach through half the system.

If the original assumption was explicitly linked to the architecture, the impact is discoverable.

If it lived only in someone’s memory of a meeting, the team finds out during testing.

NASA’s requirement guidance is unusually direct on this point: assumptions should be documented, and stated assumptions should be confirmed before the affected document is baselined.[1]

An assumption that can change your design deserves an engineering identity.

Interfaces Are Where Verbal Agreements Become Hardware

The phrase I would worry about most in an engineering meeting is not:

“I disagree.”

It is:

“Yeah, we can handle that on our side.”

Because that sentence often ends the discussion.

Mechanical will accommodate it.

Software will compensate for it.

Electrical will filter it.

The supplier will convert it.

The test team will account for it.

Operations will work around it.

Everyone walks away satisfied.

Except each group may have walked away with a slightly different interpretation of what was just agreed.

Then integration begins.

NASA’s Systems Engineering Handbook notes that late changes to interface requirements are more likely to have significant cost, schedule, technical-design, or operational consequences. Its interface-management guidance also calls for maintaining rationale and assumptions associated with interface decisions.[1]

This is one reason interface problems can be so deceptive.

The connector fits.

The packets arrive.

The voltage is correct.

Each subsystem can pass its standalone testing.

And the overall system still does not behave correctly because the agreement between the teams existed socially but never became an engineered interface definition.

A verbal agreement is not an ICD.

“We Accepted the Risk” Is Not a Risk Record

Design reviews create another category of disappearing engineering knowledge: accepted risk.

The discussion often sounds perfectly reasonable.

There is a technical issue.

The team understands it.

Mitigation would cost schedule.

The likelihood appears low.

The chief engineer or program manager decides to proceed.

That can be the correct decision.

Engineering is full of deliberate compromises.

The problem begins when the only surviving record says:

Accepted.

Accepted based on what?

What probability was assumed?

What consequence was considered tolerable?

What evidence justified the decision?

What condition would trigger reconsideration?

Was the risk accepted permanently, or only until another test was completed?

If one of the underlying assumptions changes, who knows that the original decision should be reopened?

Architecture evaluation standards reflect this broader view of architectural decision-making. ISO/IEC/IEEE 42030 describes architecture evaluation as a means of assessing stakeholder concerns, identifying risks and opportunities, generating knowledge about the architecture, and supporting decisions involving architectural alternatives.[4]

The decision is not simply the final selection.

The decision is the selection plus the evidence and context that made it defensible.

Design-Review Actions Can Disappear Just as Easily

There is another scene almost every engineer has seen.

A reviewer raises a legitimate concern.

Someone agrees.

An action is recorded:

SYS-142: Confirm worst-case startup timing before release.

The review moves on.

Two weeks later the spreadsheet says Closed.

Why?

Perhaps an analysis was performed.

Perhaps the requirement changed.

Perhaps somebody had a conversation with the supplier.

Perhaps the reviewer agreed the concern was no longer applicable.

Perhaps someone simply clicked Closed after receiving an email saying, “Looks good.”

Six months later there is no difference between those five histories.

NASA’s current systems-engineering review criteria repeatedly call for Requests for Action, Review Item Discrepancies, and action items from preceding reviews to be addressed or have defined closure plans. PDR and CDR guidance also expects supporting trade analyses and increasingly mature or baselined technical products.[2]

An action item is not complete because its status changed to green.

It is complete when its disposition becomes part of the engineering record.

Meeting Minutes Are Necessary. They Are Also Not Enough.

Meeting minutes solve a chronological problem:

What happened during the meeting?

Engineering records need to solve a relational problem:

What does this decision affect?

Those are very different things.

Suppose the minutes contain:

Decision D-17 — Option B selected.

Useful.

But six months later, you also need to know that D-17:

• affects REQ-204;
• constrains ICD-017;
• was based on Trade Study TS-006;
• accepts Risk R-031;
• changes architecture element SYS-BLK-12;
• creates Action A-119; and
• requires verification approach V-044 to be updated.

The meeting was where the decision happened.

The engineering system is where that decision must live.

This is why traceability matters beyond compliance matrices.

NASA describes bidirectional traceability as a way to connect requirements through design, implementation, and verification while also supporting change-impact assessment when requirements or other work products change.[5]

Traceability turns a six-month-old decision from archaeology into navigation.

The Most Dangerous Decisions Are Often the Ones Everyone Agreed With

Controversial decisions tend to generate documentation.

People challenge them.

Data are gathered.

Alternatives are compared.

Reviewers demand justification.

Someone writes the rationale because they know somebody else will ask for it.

The decision everybody immediately agrees with is different.

“Obviously we use the existing processor.”

“Of course software owns that.”

“Yes, use the same connector.”

“Nobody needs that mode.”

“Twenty milliseconds should be fine.”

No argument.

No trade study.

No decision record.

No explicit assumption.

No one feels the need to defend it.

And that may be precisely why the reasoning disappears.

The architecture still depends on the decision.

Its consequences do not care whether the meeting took four hours or four minutes.

What Should Actually Survive the Meeting?

You do not need a 40-page report every time engineers choose between two connectors.

The amount of rigor should match the consequence of the decision.

But for a meaningful technical decision, a surprisingly small record can preserve most of the value.

That might take five minutes to record.

Reconstructing it six months later can take days.

For major architectural choices, it should become something more rigorous: a formal trade study or decision analysis with alternatives, weighted criteria, evidence, uncertainty, sensitivity, and approval history.

This is consistent with the systems-engineering discipline described in both NASA guidance and ISO/IEC/IEEE architecture standards. ISO/IEC/IEEE 42010 establishes architecture descriptions as formal expressions of architecture and its relevant concepts and relationships, while ISO/IEC/IEEE 42030 specifically addresses organizing and recording architecture evaluations.[4], [6]

The objective is not documentation for documentation’s sake.

The objective is preserving engineering intent.

This Is Where Engineering Tools Need to Do More Than Store Documents

A shared drive can store the meeting minutes.

A ticketing system can store the action.

A requirements tool can store the requirement.

A modeling tool can store the architecture.

A spreadsheet can store the trade study.

A risk system can store the risk.

The problem appears six months later when somebody needs to understand the relationship between all of them.

This is one of the problems Ngenaire is intended to address.

Ngenaire treats engineering information as connected artifacts rather than isolated documents. Requirements can carry history and be linked upstream and downstream. Impact analysis can expose affected elements when something changes. Traceability can connect requirements with CONOPS information, SOW elements, tests, risks, and system models.[7], [8]

For architectural choices, Ngenaire’s trade-study workflow can preserve candidates, weighted criteria, scores, selected options, and the rationale behind the decision. Sensitivity analysis can help teams understand whether the preferred architecture remains preferable if assumptions or weighting change.[9]

Baselines add another piece.

A requirements set can be captured at a review such as SRR, PDR, or CDR and compared with later baselines. Changes after baseline can then be handled through a controlled engineering-change process rather than quietly rewriting what everybody previously agreed to.[10]

None of this replaces the engineering meeting.

And AI should not be deciding architecture simply because engineers failed to document theirs.

The useful role of a system like Ngenaire is much more practical:

Make it difficult for engineering context to disappear.

A decision should be able to point to the requirement that drove it.

The requirement should point to the stakeholder need.

The trade study should preserve rejected alternatives.

The assumption should be visible.

The affected architecture should be identifiable.

The risk should carry its disposition.

The verification approach should show how the resulting design will eventually be proven.

Then, when the system changes six months later, engineers are not searching for somebody who remembers the meeting.

They can interrogate the engineering record.

The Real Test Is Whether Someone Who Wasn’t There Can Understand It

There is a simple way to evaluate your engineering decision-management process.

Take an important architectural decision from six months ago.

Give it to an engineer who did not attend the meeting.

Then ask:

• Why was this decision made?
• What alternatives were rejected?
• What assumptions were involved?
• What evidence supported it?
• Which requirements drove it?
• What risks were accepted?
• What other parts of the system depend on it?
• What would cause us to reconsider it?

If answering those questions requires finding someone who attended the meeting, you do not have an engineering record.

You have institutional memory.

And institutional memory has a habit of resigning, retiring, transferring projects, going on vacation, or simply forgetting.

GAO’s work examining major defense programs has repeatedly emphasized the importance of obtaining engineering knowledge early enough to support consequential program decisions. Its analysis found better outcomes when detailed systems engineering was performed early enough for risks to be addressed through trade-offs and investment before they became deeply embedded in development.[11]

There is a larger lesson there.

Engineering decisions become expensive not only because the wrong decision was made.

They become expensive because the organization loses the ability to explain, challenge, or safely change a decision that was once perfectly reasonable.

Before Everyone Leaves the Room

At the end of your next design review, architecture meeting, or technical working group, pay attention to the last ten minutes.

That is often where the actual engineering happens.

The slides are finished.

The formal agenda is over.

People are resolving the uncomfortable details.

“We’ll let software handle it.”

“Okay, then we’ll assume 20 milliseconds.”

“Let’s accept that risk.”

“Mechanical can accommodate the change.”

“Option B it is.”

Those sentences deserve more attention than another beautifully formatted meeting summary.

Before everyone leaves, ask one more question:

What did we just decide that the engineering record does not know yet?

Then capture it.

Because six months from now, nobody will care how clear the conversation felt in the room.

They will care whether they can still understand why the system looks the way it does.

And sometimes the most expensive engineering decision on a project is not the decision that turned out to be wrong.

It is the perfectly reasonable decision that everyone agreed on—

and nobody recorded.

References

[1] National Aeronautics and Space Administration, NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev. 2, Washington, DC, USA, 2016. [Online]. Available: https://www.nasa.gov/wp-content/uploads/2018/09/nasa_systems_engineering_handbook_0.pdf

[2] National Aeronautics and Space Administration, “Appendix G: Life-Cycle and Technical Review Entrance and Success Criteria,” NPR 7123.1D, NASA Systems Engineering Processes and Requirements, 2023. [Online]. Available: https://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7123_001D_&page_name=AppendixG

[3] F. Bachmann, L. Bass, P. Clements, D. Garlan, J. Ivers, R. Little, R. Nord, and J. Stafford, Documenting Software Architectures: Organization of Documentation Package, CMU/SEI-2001-TN-010, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, USA, Aug. 2001. [Online]. Available: https://www.sei.cmu.edu/library/documenting-software-architectures-organization-of-documentation-package/

[4] ISO/IEC/IEEE 42030:2019, Software, Systems and Enterprise—Architecture Evaluation Framework, International Organization for Standardization, Geneva, Switzerland, 2019. [Online]. Available: https://www.iso.org/standard/73436.html

[5] National Aeronautics and Space Administration, “SWE-047—Traceability Data,” NASA Software Engineering Handbook. Accessed Aug. 31, 2026. [Online]. Available: https://swehb.nasa.gov/spaces/7150/pages/16449982/SWE-047+-+Traceability+Data

[6] ISO/IEC/IEEE 42010:2022, Software, Systems and Enterprise—Architecture Description, 2nd ed., International Organization for Standardization, Geneva, Switzerland, Nov. 2022. [Online]. Available: https://www.iso.org/standard/74393.html

[7] Ngenaire, “Requirements: EARS Patterns, Quality, and Management,” Ngenaire Documentation. Accessed Aug. 31, 2026. [Online]. Available: https://ngenaire.com/docs/define/requirements

[8] Ngenaire, “Traceability,” Ngenaire Documentation. Accessed Aug. 31, 2026. [Online]. Available: https://ngenaire.com/docs/concepts/traceability

[9] Ngenaire, “Trade Studies: Weighted Decision Analysis,” Ngenaire Documentation. Accessed Aug. 31, 2026. [Online]. Available: https://ngenaire.com/docs/define/trade-studies

[10] Ngenaire, “Requirement Baselines,” Ngenaire Documentation. Accessed Aug. 31, 2026. [Online]. Available: https://ngenaire.com/docs/define/requirement-baselines

[11] U.S. Government Accountability Office, Weapon System Requirements: Detailed Systems Engineering Prior to Product Development Positions Programs for Success, GAO-17-77, Washington, DC, USA, Nov. 2016. [Online]. Available: https://www.gao.gov/products/gao-17-77