Agree the document package before the build. At handover, the customer needs to identify the delivered configuration, understand the agreed interface and see the evidence against the acceptance criteria. The required detail depends on the contracted work package and the rights agreed for drawings and other supplier information.
Use this checklist to specify what is required, who provides it and how it will be accepted. An item in the checklist is a discussion point, not a promise that every document is included in every supply scope.
For each required item, also record the file format, delivery milestone and person who will confirm that the agreed information is present. Link the entry to any agreed access or use restrictions.
| Deliverable | What the record should identify | Required? / owner / revision / evidence |
|---|---|---|
| Scope and exclusions | Supplied hardware, customer-supplied items and software responsibilities | __________ |
| As-built configuration | Build/serial identity and the installed component configuration | __________ |
| Mechanical information | Agreed assembly, mounting and service information; released revisions | __________ |
| Electrical information | Agreed wiring, connector, supply and I/O information; released revisions | __________ |
| Firmware and configuration | Installed versions and the configuration needed for the agreed functions | __________ |
| Hardware interface | Supported functions, request/result meaning, states, faults and version identity | __________ |
| Calibration record | What was calibrated, setup, reference, configuration, result and date, where in scope | __________ |
| Manufacturing checks | Agreed inspection records and their build/revision references | __________ |
| FAT protocol and results | Acceptance criteria, tested setup, actual results and evidence references | __________ |
| Fault and recovery results | Interrupted/failed cases tested, resulting states and recovery responsibility | __________ |
| Open-item register | Unresolved item, impact, owner, agreed action and closure/release decision | __________ |
| Operation and service | Agreed instructions, maintenance information and support responsibility | __________ |
| Change record | Changes from the reviewed configuration and the decision on repeat verification | __________ |
| Final release record | Delivered configuration, document index and authorized release decision | __________ |
Keep the evidence tied to one configuration
Identify the build and relevant revisions in the document index. Where a test applies to only one configuration or labware setup, say so. Keep incomplete tests and open actions visible; a document title such as “FAT report” does not by itself show that the agreed criteria were met.
Review the hardware FAT scope and the quality and traceability information when agreeing the package.
Define what happens after a change
Record the proposed change, affected documents and the person responsible for deciding whether verification must be repeated. Preserve the configuration that the earlier evidence applies to. The customer team owns scheduling, laboratory workflow logic and the agreed instrument software integration. Record what information it needs to assess the change on its side of the interface.
Use the hardware interface note for that responsibility review. Bring the required package to the OEM manufacturing discussion before release of the work scope.
Link each open item to its acceptance evidence
A delivery folder can contain every test file and still leave one question unanswered: which result closes which open issue? Give each issue a stable ID and link it to the affected requirement or drawing, the observed configuration, the corrective action and the verification result. Keep the technical result separate from the shipment or use decision.
The issue record explains what differed and why it matters. The evidence index identifies the file, page, log interval or image and the setup it represents. The release record states who made the disposition, which restrictions remain and what happens next. A photograph can document a mounting change; it does not, on its own, demonstrate a successful transfer or a corrected interface response.
| Field | Entry to complete |
|---|---|
| Issue identity | Issue ID: ___; requirement/drawing reference: ___; detection date: ___ |
| Observed condition | Expected: ___; observed: ___; affected hardware or function: ___ |
| Configuration | Build ID: ___; tool, fixture and firmware revisions: ___; labware state: ___ |
| Effect and ownership | Affected acceptance or use decision: ___; responsible party: ___; due date: ___ |
| Corrective action | Action and change reference: ___; implemented revision: ___ |
| Verification | Test/inspection ID: ___; criterion: ___; method and conditions: ___; actual result: ___ |
| Evidence index | File/report ID and revision: ___; page, log interval or image reference: ___; storage location: ___ |
| Disposition | Open / corrected, awaiting verification / verified closed / accepted deviation: ___ |
| Release decision | Decision owner: ___; allowed use or restrictions: ___; remaining action and date: ___ |
Use statuses that preserve the actual result
“Corrected, awaiting verification” means the change exists but the acceptance evidence is incomplete. “Verified closed” requires the agreed evidence and a recorded closure decision. An accepted deviation records an authorized exception; it does not turn a failed test into a pass. State the affected requirement and any restriction so the receiving team can use the record correctly.
A customer-owned item can remain visible without becoming a LabCarry deliverable. For example, an unresolved scheduler decision can be marked customer-owned while the index points to the hardware state evidence already available. The complete workflow is not accepted merely because the hardware reported the expected state message.
Example: a connector label is corrected
Illustrative entry HI-014 records a connector label that differs from the released wiring record. The corrective action links to the revised identification and its revision. Closure requires the agreed check against the released identification and affected connection record, with a dated result. If that review also finds a wiring difference, the wiring change needs its own impact assessment and verification; a new label alone does not close it.
Check the handover copy as the recipient will
Open the referenced files from the actual handover copy. Confirm that each file exists, identifies its configuration and shows the relevant result. Keep superseded and current results distinguishable. For shared logs, include an event or time-range reference so the recipient does not have to infer which entry matters. Leave missing evidence explicitly open rather than filling the index with a folder name.
NASA’s requirements verification matrix guidance illustrates the general principle of giving each requirement a unique identifier and recording its source and verification approach. The statuses and fields above are a proposed hardware handover format, not an external certification scheme.
Link the issue index to the hardware FAT record and the released configuration records. Agree the evidence package during the OEM manufacturing review, so both teams know what is required to close an item before delivery.