What a production hand-over pack has to contain

A hand-over pack has one job: let a competent engineer who was not on the project build the product, prove it works, keep it compliant, support it in the field, and change it — without phoning the original team. Anything less is a dependency, not a delivery.

This is the contents list we work to. It spans hardware, firmware, test, and compliance, because a product that splits those across separate incomplete hand-overs has no owner for the seams.

1. Released, versioned design data

Not “the latest files” — a release, tagged, with a revision and a date.

Hardware

• Schematics (PDF) and source project, at the released revision.
• PCB layout source, Gerbers, drill, netlist, fab drawing with stack-up and impedance spec, assembly drawings.
• BOM with manufacturer part numbers, approved alternates, and DNP items marked. Lifecycle status noted for anything NRND or single-source.
• Mechanical: enclosure models, gaskets, thermal interface parts, fasteners, labels and their artwork.
• The ECO/ECR history — every change since the first build, why it was made, and which build it entered. This is how the factory knows a v3 board is not a v2 board with a sticker.

Firmware and software

• Source, in a repo the client controls, tagged for the release.
• A reproducible build: pinned toolchain (container or documented exact versions), pinned dependencies, one command. The test is that a fresh machine reproduces the released binary — or the released image manifest — bit for bit. (For a Yocto-based product, this is its own checklist; see the Embedded Linux hub’s BSP hand-over reference.)
• The released binaries themselves, with checksums and signatures, and the public keys to verify them.
• Build and flashing instructions from empty machine to programmed unit.

2. Requirements and traceability

• The requirements the product was built to, at their released version.
• A traceability matrix: requirement → design element → verification test → result. Even a lightweight one. This is what a customer audit, a safety assessor, or a future change-impact analysis needs, and it cannot be reconstructed later without re-deriving intent.
• Interface control documents for every external interface (connector pinouts, protocols, message definitions, electrical limits).

3. Verification and validation records

• Test plans and procedures, with pass/fail criteria that are numbers, not adjectives.
• Results for the released revision: what was run, on how many units, with what outcome, signed and dated. Raw data retained, not just a summary.
• Coverage statement: what was tested, what was explicitly not, and why. A hand-over that implies everything was verified when it was not is worse than one that is honest about the gaps.
• Regression suite and how to run it, so the client can re-verify after a change.

4. Compliance / certification file

Whatever regimes apply (EMC, safety, radio, environmental, sector-specific):

• Test reports from the accredited lab, in full, not just the certificate.
• The Declaration of Conformity and the technical file / construction file behind it.
• The exact configuration tested: hardware revision, firmware version, cables, orientation, peripherals, any test-mode firmware used. A certificate that does not pin the configuration does not transfer to production cleanly.
• Applied standards and their editions. Standard editions change; the file must say which one the product was assessed against.
• Conditions and limitations of the approval, and the class/limits the product passed against (with margin, ideally).
• What invalidates the certification — which changes force re-test. This is the single most useful sentence for the team that inherits it.
• Radio module certs (modular approval IDs) and the conditions attached to using them under that approval.

5. Software bill of materials and update story

• SBOM (SPDX or CycloneDX) for the shipped image: every component, version, licence, and source. Increasingly a legal requirement, and the basis for answering “are we affected by CVE-XXXX” quickly.
• Licence compliance: the licence manifest, written offers where copyleft requires them, and the corresponding source archive.
• Secure/verified boot: key hierarchy, what signs what, where keys are stored or fused, key-rotation procedure, and the recovery path for a unit that fails a signature check.
• Field update mechanism: how an update is packaged, signed, delivered, applied, and rolled back; A/B or recovery-slot behaviour; what happens on power loss mid-update; version-compatibility rules.
• Provisioning: per-unit secrets, certificates, serial numbers — how they are generated, injected at the factory, and stored/backed up.

6. Manufacturing pack

• Factory test procedure with a defined sequence, measurement points, and limits for every measured parameter. This is what makes a contract manufacturer able to accept or reject a unit without judgement calls.
• Test fixtures: design, firmware, calibration procedure and interval, and a spare or the data to build one.
• Programming: what gets programmed, in what order, with what tool, and how the line verifies it took.
• Calibration: what is calibrated, against what reference, to what tolerance, and where the calibration constants are stored.
• Serialisation and labelling: numbering scheme, label content and placement, what is recorded per unit and where that record lives.
• Packaging and ESD/transport requirements.
• First-article inspection report and the golden-unit definition.
• Yield and known failure modes from the builds so far, with the diagnosis for each — so the line does not re-learn them.

7. Field support material

• Service manual: diagnosis flow, safe-to-replace parts, what needs a depot, recovery procedures (including “how to un-brick”).
• Diagnostics: what the product logs, how to extract it, and how to read it.
• RMA criteria and the data to capture on a return.
• Spares strategy: which parts, expected failure rates if known, last-time-buy exposure on any component.

8. The known-issues and deferred-work list

Every project has one. A hand-over without it means the client discovers the list one incident at a time.

• Open bugs with severity, reproduction, and any workaround.
• Deferred features and the reason they were cut.
• Design compromises made under schedule pressure and what a proper fix looks like.
• Component or supplier risks not yet resolved.
• Anything that “works but we do not fully understand why”.

9. Contacts, licences, and accounts

• Which third-party licences, subscriptions, or accounts the product depends on (cloud tenant, certificate authority, code-signing service, paid libraries), who holds them, and renewal dates.
• Escrow arrangements if any.
• A named transition contact and a defined support window, so the hand-over is a ramp, not a cliff.

How to know the pack is complete

Run the test that matters: give the pack to an engineer who was not on the project and have them, using only what is in the box, (a) build the firmware and get a matching binary, (b) build and pass one unit through the factory test, and (c) answer “what change would invalidate the CE marking”. If any of the three needs a phone call, the pack has a hole, and the hole is cheaper to fill now.

The trade-off

Assembling this properly is weeks of work, concentrated at the end of a project when budget and patience are thinnest, and most of it produces no visible feature. It is genuinely tempting to ship the design files and a README and call the rest “support”.

The cost of that shortcut is entirely borne later and by someone else: the first CM build that fails because the test limits were in someone’s head, the CVE response that takes three weeks because there is no SBOM, the field failure with no service procedure, the change that quietly invalidates a certification because nobody wrote down what the certification depended on. The pack is insurance, and like insurance its value is invisible right up until the moment it is the only thing that helps.