“We’ll Figure It Out During Integration” Is Not a Systems Engineering Strategy

It is late afternoon on the first day of integration.

The hardware team has delivered its unit. The software team has a build ready. The test equipment is powered. Everyone has been reporting green status for weeks.

Then the first connection is made.

The mechanical interface fits, but the cable cannot achieve its minimum bend radius. The receiving software expects a timestamp in UTC milliseconds, while the sending system provides GPS seconds. One subsystem interprets a status bit as “valid,” while the other interprets the same bit as “faulted.” Both teams designed for 28 volts nominal, but only one considered the transient that occurs during startup.

Nothing is obviously broken when tested alone.

Together, almost nothing works.

Someone looks around the room and says:

“Well, this is what integration is for.”

It is not.

Integration is where independently developed system elements are deliberately combined and their interactions are verified. It will always uncover some emergent behaviour. That is part of engineering complex systems.

But integration should not be the first time two teams discover what they built for each other.

When that happens, the problem did not begin in the integration lab. It began months earlier—in an assumption nobody recorded, an interface nobody owned, a requirement nobody verified, or a decision that existed only in a meeting.

Integration simply made the problem impossible to ignore.

The Most Dangerous Sentence on a Program

“We’ll figure it out during integration” sounds practical.

It can even sound agile. Why spend weeks debating every detail when the teams can connect the equipment, observe what happens, and adjust?

There are situations where learning through integration is exactly right. You may be exploring a new technology, characterizing emergent behaviour, or intentionally using rapid prototypes to reduce uncertainty.

But that is different from deferring basic engineering decisions.

If teams have not agreed on what crosses a boundary, in what format, under what conditions, with what tolerances, and how compliance will be demonstrated, integration is no longer being used to reduce uncertainty.

It is being used to discover the design.

That is an expensive way to design anything.

By the time integration begins, hardware may already be manufactured, supplier contracts may be closed, software architectures may be difficult to change, test facilities may be booked, and delivery dates may already have been promised.

A problem that would have taken an hour to resolve in an interface review can now require a new circuit card, harness modification, software redesign, contract change, regression campaign, or schedule replan.

The issue is not that the engineers were incapable.

The issue is that the program allowed two competent teams to build two incompatible interpretations of the same system.

Interfaces Are More Than Connectors and APIs

When engineers hear “interface,” they often think of a connector, an API, a message definition, or a mounting pattern.

Those are interfaces, but they are only part of the picture.

A complete interface definition may need to address:

• Physical geometry, clearances, mass properties and mounting
• Electrical power, grounding, protection and transients
• Signals, pin assignments and electrical characteristics
• Data types, units, precision, ranges and coordinate frames
• Protocols, message sequencing, timeouts and retries
• Timing, latency, synchronization and update rates
• Startup, shutdown, reset and initialization behaviour
• Operating modes and state transitions
• Fault reporting, degraded behaviour and recovery
• Environmental loads and thermal paths
• Cybersecurity and access-control boundaries
• Human actions, responsibilities and operational handoffs
• Verification methods, test equipment and acceptance criteria

A document that says “Subsystem A shall provide target position to Subsystem B” has not defined an interface.

Position in which coordinate frame? At what rate? With what accuracy? Referenced to what time? What happens when the data is stale? Is there a validity flag? How is loss of communication detected? Does the receiver hold the last value, extrapolate it, or declare a fault?

Every unanswered question becomes an assumption.

And assumptions have an uncomfortable habit of crossing organizational boundaries without announcing themselves.

Two Teams Can Both Be Right—and the System Can Still Be Wrong

Most interface failures do not begin with negligence.

They begin with locally reasonable decisions.

The power team assumes the load will tolerate the voltage transient because similar equipment usually does.

The equipment team assumes the platform power bus will remain inside the nominal range.

The software producer assumes an absent field should be interpreted as zero.

The consumer assumes the same field will always be present.

The mechanical team designs to the connector envelope shown in the drawing.

The installation team needs additional space for the backshell, tool access and cable routing.

Each decision may make sense inside its own discipline. The failure appears only when the decisions meet.

This is why interface management cannot be reduced to emailing an Interface Control Document between teams. The real work is creating agreement across the boundary.

NASA’s Systems Engineering Handbook treats interface management as a continuous technical-management process. It begins during system formulation, when internal and external interfaces are identified from the Concept of Operations and emerging architecture. It continues through design, configuration control, integration, verification and validation [1].

That sequence matters.

NASA does not describe integration as the point where interface definitions are invented. It describes interface requirements and controlled interface documentation as inputs to integration and verification [1].

In other words, integration should test an agreement that already exists.

The Mars Climate Orbiter Was Not Just a Units Error

The loss of the Mars Climate Orbiter is often reduced to a memorable sentence: one team used imperial units and another used metric units.

That is true, but incomplete.

NASA’s investigation found that a ground software output provided impulse data in pound-seconds when the applicable Software Interface Specification required newton-seconds. The navigation software processed that data as though it were metric, causing the effect of spacecraft manoeuvres to be underestimated by a factor of 4.45 [2].

It is tempting to treat this as a simple coding mistake.

The investigation tells a much broader story.

The board also identified inadequate communication between project elements, a systems engineering process that did not adequately address the transition from development to operations, and verification and validation that did not adequately cover the ground software. The interface specification existed, but it was not properly used in development and testing. End-to-end testing did not expose the discrepancy [2].

That distinction is important.

The mission was not lost because humanity had failed to define a newton.

It was lost because the technical and organizational mechanisms that should have enforced an existing interface agreement did not catch the departure from it.

That pattern is painfully familiar on less dramatic programs:

• The interface requirement exists, but the implementation team never sees it.
• The ICD is approved, but one side designs against an older revision.
• Both units pass qualification, but nobody verifies the end-to-end data chain.
• An anomaly is discussed by email but never enters the formal problem-tracking process.
• A temporary workaround quietly becomes the operational design.
• The engineer who understands the assumption changes roles before it is documented.

The final failure appears during integration or operation. Its origin is much earlier.

Why Late Integration Surprises Keep Happening

1. Interface ownership is unclear

When an interface sits between two teams, it can become the responsibility of neither.

One team owns the output. Another owns the input. Nobody owns the compatibility of the complete exchange.

A healthy interface has named owners on both sides and a defined authority for approving the shared technical baseline. NASA’s current systems engineering requirements explicitly call for formal interface management when work is divided among programs, contractors, or geographically separated teams [3].

An interface without ownership is not controlled. It is negotiated repeatedly.

2. Assumptions are mistaken for agreements

“We thought the data would arrive at 20 Hz.”

“We assumed the chassis would provide the ground path.”

“We expected initialization to take less than ten seconds.”

“We believed the supplier was handling that fault condition.”

These sentences usually appear after something fails.

An assumption is not automatically bad. Engineering would be impossible without assumptions. The problem is an assumption that is hidden, untested, or held by only one side of an interface.

Useful assumptions are written down, assigned an owner, given a validation date, connected to the affected design elements, and either confirmed or retired.

Anything else is deferred risk.

3. Documents are reviewed instead of behaviour

A team can approve a polished ICD without proving that the two sides behave consistently.

The connector table may be correct while the startup sequence is not. The message layout may match while the timing does not. The nominal case may work while reset recovery leaves the system in conflicting states.

Good interface reviews use scenarios, sequence diagrams, state models, prototypes and failure cases—not just tables.

Ask both teams to walk through the same event:

Power is applied. One subsystem boots slowly. Communications are intermittent. A message is corrupted. The operator commands a reset. What happens next?

Misalignment becomes visible very quickly when an interface is examined as behaviour rather than paperwork.

4. Verification planning starts too late

If nobody can explain how an interface will be verified, the interface is not mature.

Verification planning forces precision. It exposes missing tolerances, inaccessible measurement points, unavailable test equipment, ambiguous pass/fail criteria and environmental conditions that cannot be recreated.

NASA’s integration-readiness criteria expect applicable mechanical and electrical interface requirements to have been verified against controlled interface documentation before system integration begins, with plans in place for the remaining verification [4].

That is a very different standard from “both teams say they are ready.”

5. Teams optimize for subsystem completion

Programs often measure progress by asking whether each box is complete.

Mechanical design released: green.

Software feature implemented: green.

Supplier unit delivered: green.

Test procedure drafted: green.

But a system is not merely a collection of completed boxes. It is the behaviour created by the connections among them.

Subsystem dashboards can remain green while system risk accumulates in the whitespace between them.

6. Interface changes are treated as local changes

A revised message field, connector, power limit or mounting location rarely affects one artifact.

It may affect requirements, architecture, drawings, software, test equipment, procedures, safety analyses, supplier data and operational documentation.

NASA warns that interface changes made late in design or implementation are more likely to have significant cost, schedule and technical consequences [1].

The later the change, the more important traceability becomes. Without it, teams update the artifact they remember and leave the rest of the system behind.

Integration Is a Verification Activity, Not a Negotiation Meeting

A strong integration event begins with questions that already have answers:

• Which configuration of each item is being integrated?
• Which interface baseline applies?
• Have both sides demonstrated compliance independently where practical?
• What sequence will be used?
• What instrumentation and test equipment are required?
• Which requirements are being verified?
• What constitutes a pass, failure or blocked test?
• How will anomalies be recorded, owned and closed?
• What is the rollback or recovery plan?
• Which residual risks have been formally accepted?

The integration team should still expect discoveries. Complex systems produce interactions that models and component tests do not perfectly predict.

But there is a meaningful difference between discovering an emergent interaction and discovering that two teams used different definitions of the same field.

The first may be a legitimate integration finding.

The second is an unpaid design review occurring at the most expensive possible time.

The U.S. Government Accountability Office found that leading companies develop design specifications sufficiently to support system integration and prototype testing, then use iterative modelling and simulation to reduce major uncertainty before final validation [5].

The objective is not to eliminate learning during integration.

It is to move inexpensive learning earlier.

What Good Interface Management Looks Like

Good interface management does not require a hundred-page document for every connection.

It requires enough shared, controlled information to prevent incompatible interpretations.

A practical approach looks like this:

Create an interface register early

List internal and external interfaces as soon as the system context and architecture begin to emerge.

Include technical interfaces, supplier boundaries, operational handoffs, external systems and enabling systems such as test equipment, support equipment and facilities.

Assign responsibility on both sides

Name the producer, consumer, technical owners and approval authority.

Do not assign an interface to “the software team” or “the supplier.” Assign it to people or defined roles who are accountable for reaching and maintaining agreement.

Expose assumptions

Ask each side to state what it believes about the other.

This is one of the simplest and most productive interface exercises a team can perform. Compare the lists. Every mismatch is an early finding rather than a late surprise.

Define behaviour, not just structure

Document nominal behaviour, sequencing, modes, timing, degraded states, invalid inputs, startup, shutdown, resets and recovery.

Static tables are necessary. They are rarely sufficient.

Trace interfaces to requirements and verification

Every critical interface parameter should connect to its source requirement, affected design elements, planned verification method and resulting evidence.

That chain allows the team to answer not only “What is the interface?” but also “Why is it defined this way?” and “How do we know both sides comply?”

Test risky seams early

Use engineering models, emulators, hardware-in-the-loop rigs, software stubs, interface simulators, breadboards and early data exchanges.

You do not need the final system to test whether two teams agree on units, timing, sequencing, data validity or fault behaviour.

Control changes as system changes

When an interface changes, perform impact analysis across both sides of the boundary and across every connected artifact.

Approval without impact visibility is administrative theatre.

Hold an evidence-based integration readiness review

“Ready” should mean more than parts being physically available.

It should mean the applicable baselines are known, interface compliance has been assessed, procedures are approved, equipment is available, anomalies are understood, and remaining risks have owners.

Where Ngenaire Helps

The difficult part of interface management is rarely writing one more document.

The difficult part is keeping requirements, architecture, assumptions, decisions, changes, risks and verification evidence connected while the design evolves.

That is where Ngenaire is useful.

Ngenaire brings requirements, system diagrams, verification artifacts, risks and project information into a connected engineering workspace. Its AI-assisted workflows can help teams:

• Review interface requirements for ambiguity, missing units, weak tolerances and unverifiable language
• Connect requirements to system architecture, data flows and verification activities
• Identify broken trace links and unverified critical requirements
• Preserve project assumptions, constraints and design decisions in Project Memory
• Support change-impact analysis when an interface or requirement is modified
• Generate and maintain test plans, procedures and requirements-verification traceability
• Audit artifacts for inconsistencies and drift across the project lifecycle

This does not replace interface owners, technical reviews, engineering judgement or physical testing.

It makes the seams visible.

Instead of reconstructing the logic of an interface from spreadsheets, old documents, inboxes and the memory of whoever attended a meeting six months ago, teams can work from connected project context. When something changes, the affected requirements, design information and verification obligations are easier to identify.

That is the real value of AI in this part of systems engineering: not producing more words, but helping engineers find contradictions, missing connections and unresolved assumptions while they are still inexpensive to correct.

The Question to Ask Before Integration

Before declaring a system ready, ask every team:

What are you assuming about the systems you connect to?

Do not accept “it is in the ICD” as the complete answer.

Ask them to explain the interface in their own words. Ask what happens during startup, nominal operation, failure, reset and recovery. Ask how they know their implementation complies. Ask which version they tested. Ask what remains uncertain.

Then ask the team on the other side the same questions.

If the answers differ, integration has already started—just early enough to be useful.

“We’ll figure it out during integration” is not a strategy.

A strategy defines the boundaries, exposes the assumptions, assigns ownership, plans the evidence and retires the highest-risk unknowns before the schedule becomes dependent on getting everything right the first time.

Integration should be where the system comes together.

It should not be where the team finally discovers what the system was supposed to be.

References

[1] National Aeronautics and Space Administration, NASA Systems Engineering Handbook, Rev. 2, NASA/SP-2016-6105, Washington, DC, USA, 2016. [Online]. Available: https://science.nasa.gov/wp-content/uploads/2023/04/nasa_systems_engineering_handbook_0.pdf. Accessed: Aug. 16, 2026.

[2] Mars Climate Orbiter Mishap Investigation Board, Mars Climate Orbiter Mishap Investigation Board Phase I Report, National Aeronautics and Space Administration, Nov. 10, 1999. [Online]. Available: https://llis.nasa.gov/llis_lib/pdf/1009464main1_0641-mr.pdf. Accessed: Aug. 16, 2026.

[3] National Aeronautics and Space Administration, “Systems Engineering Procedural Requirements,” NPR 7123.1D, Jul. 5, 2023. [Online]. Available: https://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7123_001D_&page_name=Chapter3. Accessed: Aug. 16, 2026.

[4] National Aeronautics and Space Administration, “Entrance and Success Criteria for Life-Cycle Reviews,” Appendix G, NPR 7123.1D, Jul. 5, 2023. [Online]. Available: https://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7123_001D_&page_name=AppendixG. Accessed: Aug. 16, 2026.

[5] U.S. Government Accountability Office, Leading Practices: Iterative Cycles Enable Rapid Delivery of Complex, Innovative Products, GAO-23-106222, Washington, DC, USA, Jul. 2023. [Online]. Available: https://www.gao.gov/assets/830/828252.pdf. Accessed: Aug. 16, 2026.

[6] Ngenaire, “Ngenaire—We Solve Hard Engineering Problems,” 2026. [Online]. Available: https://ngenaire.com/. Accessed: Aug. 16, 2026.