System handover records are the operational memory of an automated warehouse. They document what was built, how it was tested, how the system performed at the moment of transition from project to operations, and which deviations were accepted by both parties. They also define the boundary between design intent and installed reality. This article explains the operating principles behind handover records, how they interact with live material-handling systems, how to recognize when they are incomplete or stale, and where decision authority begins and ends. The guidance is purely educational: site-specific procedures, lockout requirements, OEM documentation, and competent engineering judgment always take priority over any general recommendation in this article.
Purpose and Scope of System Handover Records #
A handover record is not one document. It is a controlled set of references and evidence that together answer four questions about an automated warehouse system:
- What was installed? This includes mechanical layout, electrical drawings, network topology, software versions, and hardware revisions.
- How was it tested? This includes factory and site test scripts, acceptance criteria, measured results, and signed approvals.
- What was the achieved performance? This includes throughput evidence, exception rates, downtime figures, and the conditions under which those numbers were produced.
- What was left open? This includes known limitations, non-conformances, agreed corrective actions, and temporary settings that must later be replaced.
The scope ends where operational responsibility begins. Handover records transfer knowledge, not authority. Ongoing safety obligations, maintenance ownership, and change-control accountability move to the site team at an agreed point, but that point must be visibly documented. Without a clear scope boundary, every future fault can become a debate about whether the integrator, OEM, or site team owns the problem.
Operating Context: From Commissioning to Continuous Operation #
Warehouse automation systems pass through a predictable lifecycle: design, build, factory testing, site installation, site testing, ramp-up, steady-state operation, modification, and eventual decommissioning. Handover records matter most between site testing and the end of ramp-up, because that is when the system is most unstable and when human knowledge is most concentrated.
During ramp-up, real traffic places demands that no test plan can fully anticipate. Conveyor subsystems interact with sorters, shuttles, and vertical lifts through controls that depend on timing and queue depth. Throughput evidence collected in one week may not represent another week because the pattern of inbound cartons, SKU mix, and staffing changes. Operating principles for handover records therefore require the records to state not only what happened, but also the context in which it happened.
A common operating failure is to treat handover records as a fixed archive. In an operational warehouse, the system changes: sensors drift, software is patched, parts are substituted, layouts are adjusted. A record that is not updated at the same rate as the physical system becomes a liability rather than a reference.
Component Interactions and Record Ownership #
An automated warehouse is a layered system. At the physical layer, components such as motorized roller conveyors, straights, curves, merges, diverts, lifts, and palletizers interact mechanically. At the control layer, PLCs, scanners, and frequency inverters exchange signals with a warehouse control system (WCS) or warehouse execution system (WES). At the information layer, the WCS/WES communicates with the host ERP or order management system.
Handover records must capture each layer and the interactions between them. A software version number is meaningless without the corresponding parameter-set version. A mechanical drawing is misleading if redline changes were never registered. A throughput baseline is useless if the associated SKU mix and shift structure are not recorded.
Record ownership should be explicit. Typically, the site engineering or controls team owns the “as-maintained” set of records after handover, while the integrator retains source design documents. Maintenance teams own calibration and parts records; operations owns shift performance logs; IT owns network and server configuration. The operating principle is simple: one system, several record owners, one shared controlled copy.
Observable Symptoms of Missing or Stale Records #
Operators and engineers usually discover record problems through symptoms rather than through audits. Recognizable patterns include:
- Throughput during normal shifts falls below the value quoted in the acceptance letter, even though no equipment change has been made.
- A rebuilt zone behaves differently after replacement with the same part number because the original part was a substituted revision that the records never captured.
- Frequent jams occur in a location that commissioning notes describe as “adjusted on site during acceptance testing.” The adjustment details are missing, so the current setup cannot be compared with the commissioned setup.
- Warranty disputes stall because the original acceptance criteria are ambiguous or not located in a controlled document.
- New engineers cannot safely bring the system back to a known state after a power-down because startup parameters exist only in the memory of senior staff.
- Modifications were carried out years ago, but the as-built drawings still show the original layout, so planning a new upgrade is based on fiction.
These symptoms have a common root cause: the boundary between project evidence and operational baseline was not maintained after handover.
Evidence Collection: What to Record and When #
Evidence collection is often treated as an acceptance-testing chore. In operating practice, it should continue across the whole lifecycle. The following categories form a minimum practical set:
- Baseline performance evidence: throughput per hour, by time slice and by direction, including peak, average, and minimum values; exception counts such as jam events, recirculations, and missed scans.
- Configuration evidence: software and firmware version IDs, checksums where available, PLC and WCS parameter exports, network switch configurations, and HMI screen versions.
- Environmental evidence: temperature in the building, ambient humidity if relevant, and any seasonal factors that demonstrably affect performance.
- Change evidence: every documented modification, including the reason, the risk assessment, the person or team who implemented it, and the verification result after implementation.
- Open-item evidence: the formal list of known limitations, agreed concessions, and deadlines for corrective actions.
Because these records are used years later, files should be stored in formats that remain readable after software changes and should be time-stamped by a person with defined authority. Photographs of sensors, label placements, and damaged components are valuable, but they must be dated and tied to a specific zone or asset identifier.
Diagnostic Table: Reading Handover Record Gaps #
The following table is a practical starting point for diagnosing whether a performance or reliability issue actually originates from record deficiencies. It is not a substitute for a formal root-cause analysis.
| Observed Symptom | Likely Record Gap | Evidence to Collect | Decision Boundary |
|---|---|---|---|
| Throughput drops below the acceptance value with no recorded equipment change. | Baseline was recorded as peak performance only, not sustained performance, or environmental conditions during acceptance are absent. | Shift-level throughput logs, exception counters, PLC trends, inbound carton profiles. | Site operations and controls confirm the current operating envelope. The integrator or OEM is engaged only if contractual acceptance criteria are questioned. |
| A replacement motor or sensor behaves differently from the original despite the same part number. | Hardware revision changes after handover were not captured in the bill of materials. | Serial numbers, manufacturer date codes, physical dimension checks, parameter files. | Maintenance and stores decide whether compensation circuitry or parameters must be adjusted. If safety-rated features are affected, OEM documentation and site risk assessment take priority. |
| Jams recur in a zone documented as “adjusted during commissioning” but without adjustment details. | Commissioning redlines were informal or never migrated into controlled records. | Photo/video of the jam pattern, sensor timing captures, gap measurements between conveyors. | Site controls team can re-establish a baseline from measured behavior; any formal concession from the original acceptance must be re-confirmed with the integrator. |
| Warranty or service dispute about whether a condition was an acceptance requirement. | Acceptance criteria wording is ambiguous or exists only as presentation slides. | Original test scripts, signed daily logs, acceptance correspondence, email records. | Contract administration, not engineering, decides contractual disputes. Engineering provides factual evidence only. |
| After a complete power-down, starting the line requires undocumented operator actions. | Start-up and recovery procedures were trained verbally but never written into handover documents. | Observed start sequence, HMI menu logic, PLC memory flags, interview with experienced operators. | Site engineering must document a controlled start-up procedure. Lockout and tagout rules apply fully; no undocumented bypass is permissible. |
Common Interpretation Errors #
The most frequent errors in reading handover records come from treating evidence as if it were a promise. Several patterns deserve specific attention.
First, factory acceptance test (FAT) results are often confused with site performance. A machine running in a clean factory hall, with no real cartons, no building interfaces, and no network contention, will behave differently from the same machine at a customer site. FAT evidence proves the machinery works under controlled conditions; it does not prove the installed solution will match the same numbers.
Second, peak throughput is frequently mistaken for sustained throughput. Peak is the highest value observed for a short interval. Sustained throughput is the value maintained over a full shift, including the effects of jams, recirculation, changeover, and staff breaks. Handover records should state both values and the calculation method; a record that lists only one number hides the most important performance boundary.
Third, exception events are often counted as “acceptable” and then forgotten. A sorter that misses one percent of its cartons is operating within many acceptance criteria, but if the record does not state the miss rate, another team will assume the miss rate was zero and will search for a root cause that does not exist.
Finally, a software version number alone is an unreliable record. The same version of a WCS can behave differently depending on parameter tables, database contents, network latency, and HMI configuration. Records must identify the complete configuration set, not merely the executable name.
Maintenance Implications and Lifecycle Planning #
Good handover records directly improve maintenance quality. Preventive maintenance plans become more accurate when the records contain baseline measurements such as motor current, vibration levels, sensor alignment tolerances, and drive temperatures. A change in one of those values after a repair indicates a real problem; in the absence of a baseline, the change is invisible.
Spare-parts management also depends on handover accuracy. When a site stocks parts for a system that has been extensively modified, the listed part numbers may be obsolete. Records that track hardware revisions and substitution history prevent the costly cycle of ordering the wrong part and then expediting the correct one.
For lifecycle planning, handover records
Related Pearl Gateway Guides #
Site-Specific Review Worksheet #
This educational worksheet supports a structured review of system handover records: operating principles and system boundaries. Begin by identifying the equipment boundary, control ownership, operating modes, material characteristics, upstream dependencies and downstream consequences. Record what the system is expected to do, what was actually observed and which evidence is time-aligned. Avoid changing several variables at once, because simultaneous changes make cause and effect difficult to establish.
Evidence to collect #
- Operating mode, active mission or route, and the exact sequence state.
- Alarm history, device state changes and controller timestamps.
- Physical observations such as alignment, contamination, wear, obstruction and load condition.
- Recent maintenance, software changes, parameter changes and recurring work orders.
- Upstream and downstream readiness, including blocked, starved and unavailable conditions.
Decision boundaries #
Use approved site procedures and competent engineering judgment before intervention. General information in the Commissioning, Performance & Lifecycle library cannot determine whether a specific machine is safe to enter, restart or modify. Preserve original settings, document authorized adjustments and establish a rollback point before controlled testing. When evidence conflicts, stop and resolve the timestamp, naming or measurement discrepancy before drawing a conclusion.
Closeout record #
A useful closeout record states the symptom, confirmed cause, evidence, corrective action, validation method, residual risk and follow-up owner. It should also identify whether the event exposed a design weakness, maintenance gap, training issue, spare-parts issue or monitoring blind spot. This turns a single recovery into reusable reliability knowledge without treating one observation as universal.
