Systems Dispatch #10 – Integration, Qualification, and Acceptance

Introduction: The First Moment the System Becomes Real

In earlier dispatches we shaped the system conceptually.

We reasoned about its boundaries, defined its functions, allocated responsibilities, and stabilised its interfaces. These steps are the intellectual backbone of systems engineering, but they are still abstractions. They describe intention, not reality.

Integration, qualification, and acceptance are where those abstractions become physical, observable, and accountable.

This is the phase where the system leaves documentation and enters the world.

It is where mismatches surface, where design decisions face constraints, and where evidence begins to accumulate. It is also where engineering becomes collaborative developers, testers, stakeholders, and operators all converge to understand not just what the system does, but how it behaves under conditions that are closer to lived operational use.

In this dispatch, I want to walk through how I approach this phase in real projects: the mindset, the sequence, the discipline, and the lessons that come from seeing a system stand up for the first time.

 

1. Integration   Bringing Subsystems Together with Intent and Discipline

Integration is often misunderstood as “just connecting the parts”. In practice, it is far more structured.

Integration is the controlled process of progressively assembling the system so that each interaction between subsystems is introduced deliberately, observed carefully, and understood fully.

This is where the system’s behaviour starts emerging from its architecture.

1.1 What Integration Actually Is

Integration is not about proving full functionality.

It is about proving that subsystems can coexist.

Every interface, every shared data exchange, every physical connection, every state transition across subsystem boundaries is exercised for the first time. The objective is not completeness it is stability. We want to understand whether the assumptions embedded in earlier dispatches hold up when the system is embodied.

A well-run integration phase reveals questions like:

• Does timing align with what the ICD describes?

• Do subsystems recover gracefully from resets or brown-out conditions?

• Do mechanical tolerances and component interactions behave as anticipated? 

• Does the system still make architectural sense once the pieces are real?

Most surprises during integration are not “bugs” they are misunderstandings that accrued silently during design.

1.2 Why Integration Is Incremental

The biggest mistake teams make is attempting “big bang” integration assembling everything at once. Without staged integration, failures become impossible to attribute. When multiple subsystems interact for the first time simultaneously, you create more noise than signal.

Integration should progress in layers:

• Subsystem integration   verifying each subsystem behaves as designed.

• Interface integration   verifying the correctness and completeness of ICDs.

• Behavioural integration   observing the system’s early emergent behaviours.

• End-to-end integration   assembling everything with controlled complexity.

This scaffolding mirrors the structure we defined in Dispatch #7 and #8.

Integration is the physical realisation of that structure.

1.3 Observability: The Hidden Determinant of Integration Quality

A system that cannot be observed cannot be integrated.

Logs, serial traces, telemetry, instrumentation, fault injection points   these are not conveniences. They are engineering necessities.

With the OTP Locker System, integration only succeeds when:

• The controller logs its internal state machine transitions

• LTE retry logic can be traced and correlated with signal conditions

• Solenoid actuation timing can be measured, not guessed

• UI touch events and error states are captured reliably 

• Backend requests and responses are logged with timestamps

• These signals form the narrative that tells us why the system behaves the way it does.

A system without observability may look functional, but it is not trustworthy.

2. Qualification   Turning Requirements into Evidence

If integration is where the system begins to behave, qualification is where it begins to be proven.

Qualification is the formal, structured process of demonstrating that the system meets each requirement defined earlier in the lifecycle.

Where integration asks, “How does it behave?”

Qualification asks, “Does it meet what we said it must do?”

2.1 The Purpose of Qualification

Qualification is about evidence, not opinion.

It is where the V&V Matrix from Dispatch #9 becomes operational. Each requirement now has a defined verification method, test procedure, acceptance criteria, and responsibility. Qualification executes those commitments.

The aim is to produce evidence that satisfies four conditions:

• Traceable   linked to a requirement and method

• Repeatable   producing the same result under the same conditions

• Objective   measured using defined criteria

• Defensible   reviewable by anyone without needing interpretation

• Qualification is the backbone of technical credibility.

  
  

2.2 The Qualification Stack (Component → Subsystem → System)

Qualification follows a hierarchy.

This hierarchy preserves the causality of evidence and prevents misattribution of failures.

Component Qualification:

Validating electrical, mechanical, or software modules independently.

Subsystem Qualification:

Validating behaviour within one bounded subsystem (UI, actuation, communications).

Interface Qualification:

Validating that interaction across ICDs matches timing, protocol, and behavioural definitions.

System Qualification:

Validating complete functional behaviour under controlled conditions.

This layered approach prevents entire-system tests from being polluted by low-level defects. In the locker system, testing “OTP retrieval works” is meaningless if the solenoid or LTE retry logic has not passed qualification individually.

2.3 What Qualification Evidence Looks Like in Practice

Qualification produces tangible artefacts:

oscilloscope traces, logs, environmental chamber reports, packet captures, touchscreen event logs, battery discharge curves.

For the locker system:

• Actuation timing is proven through electrical waveform capture

• OTP validation latency is shown through timestamped backend logs

• Security behaviour (TLS) is confirmed through handshake traces

• Retry logic under weak LTE is validated through controlled degradation tests

Qualification converts design intent into measurable fact.

3. Acceptance   Confirming the System Is Ready for Its Real Environment

Acceptance is not a technical milestone.

It is a confidence milestone.

This is the point where stakeholders confirm not only that the system works, but that it works for them   in their environment, under their workflows, with their constraints.

Acceptance is not one activity; it happens in layers.

3.1 Factory Acceptance Testing (FAT)

FAT is executed in a controlled environment where the variability of the real world is removed.

Its purpose is to prove capability, completeness, and conformance.

During FAT, we confirm:

• All core functions perform as expected

• All acceptance criteria from the contract can be measured

• All interfaces behave predictably under controlled conditions

• All non-functional behaviours (security, logs, fallback) work correctly

• In the locker system, FAT is where we demonstrate:

• End-to-end OTP workflows

• Behaviour during LTE outage

• Proper mechanical actuation

• Backup mode behaviour

• Stability over sustained operation

FAT is about predictability   making sure the system is technically sound.

3.2 Site Acceptance Testing (SAT)

SAT introduces the environment as a variable.

The purpose of SAT is to understand how the system behaves under:

• Real power conditions

• Real signal quality

• Real lighting and temperature

• Real user interaction patterns

• Real operational rhythms

SAT uncovers issues that cannot be simulated meaningfully in the lab:

latency spikes, environmental sensors behaving differently, minor usability friction, or constraints related to installation access.

For the locker system, SAT might reveal that:

• LTE drops for a few seconds at certain hours

• Touchscreen visibility is reduced in direct sunlight

• Users stand in unexpected positions, affecting sensors

• Cleaning staff open access hatches more frequently than expected

SAT is where the system’s theoretical robustness is tested against lived reality.

3.3 Operational Acceptance

Operational acceptance is the final confirmation that the system fits the organisation’s processes, not just its technical requirements.

This includes:

• Monitoring workflows

• Admin access routines

• Maintenance cycles

• Daily operational load

• Fallback procedures

Operational acceptance closes the gap between system intent and operational truth.

It is where the system finally earns the confidence of those who will use it daily.

4. How Dispatch #10 Connects Back to the Lifecycle

This dispatch stands on the foundation built earlier:

#5: Boundary and interface control dictate what can be integrated.

#6: Requirement clarity determines what can be qualified.

#7: Architecture defines qualification layers and subsystem responsibilities.

#8: ICD precision determines integration predictability.

#9: The V&V matrix becomes the script for qualification and acceptance.

Integration, qualification, and acceptance are not isolated steps  

they are the fulfilment of everything that came before.

Closing Reflection

This stage of the lifecycle is where engineering becomes accountable.

Design decisions are tested, assumptions are confronted, and the system finally reveals the truth of its behaviour.

Integration teaches humility   nothing behaves exactly as imagined.

Qualification teaches discipline   evidence is the only currency that counts.

Acceptance teaches empathy   the system must serve its real users, not its designers.

When these steps are approached with care, the outcome is not just a delivered system but a trusted one. And trust, in engineering, is earned through transparency, verification, and demonstrable readiness.

Next: Systems Dispatch #11 – Configuration Management, Change Control, and Release Readiness

Now that the system is proven, the next challenge is sustaining its integrity over time.

The next dispatch will look at how configuration baselines are created, how change is controlled, and how systems remain reliable as they evolve.