An automation engineering supplier should provide an agreed technical specification, system drawings, a component register, applicable safety and compliance evidence, software deliverables, acceptance test records, and operating and maintenance instructions. The package should describe the equipment as installed, including changes made during commissioning. Its exact scope depends on whether the contract covers individual components, a controls retrofit, or a complete integrated machine.

Documentation belongs in the supply agreement before engineering begins. Each deliverable needs a defined format, submission stage, revision status, and acceptance condition. Otherwise, “documentation included” can mean anything from a folder of component manuals to a complete, recoverable engineering record.

Compare the documentation package with the supplier’s actual scope

A component supplier and a turnkey integrator have different responsibilities. A servo drive datasheet describes one device; it does not establish whether the selected motor, gearbox, load, and control settings will meet the required motion profile. Similarly, declarations supplied with individual components do not establish the conformity of a completed automation cell.

For a partial retrofit, the package should identify both changed equipment and retained interfaces. A drawing marked “existing” without confirmation of its accuracy leaves uncertainty about the circuits connected to the new controls.

The specification must define measurable performance

The technical specification provides the reference against which design and acceptance tests are judged. It should state the process sequence, operating modes, product range, throughput requirements, accuracy criteria, utility conditions, and physical interfaces. Any exclusions or assumptions that affect performance belong in the same controlled record.

Performance figures need their test conditions. A robot cycle time has limited meaning without the payload, tooling, travel path, process dwell, and loading method. A positioning requirement should distinguish repeatability from absolute accuracy. Throughput should identify whether it includes inspection, rejected parts, replenishment, and normal recovery from interruptions.

For motion systems, record the load assumptions, duty cycle, acceleration requirements, and holding conditions used for sizing. Pneumatic equipment needs specified supply pressure and air-quality conditions. Where hydraulic performance depends on fluid temperature or viscosity, those conditions should appear in the specification and relevant test procedure.

A functional description then explains how the system achieves those requirements: sequence transitions, permissives, interlocks, alarms, recovery behavior, and manual modes. This makes a disagreement about machine behavior traceable to an agreed requirement rather than an undocumented programming choice.

Drawings should support installation and fault tracing

The drawing package should show how the system is assembled and connected. Electrical documents normally include power distribution, control circuits, terminal assignments, cable references, panel layouts, grounding arrangements, and an I/O list. Mechanical records should cover equipment layout, mounting interfaces, service access, and relevant assembly details. Pneumatic and hydraulic schematics should identify valves, actuators, isolation points, and specified settings.

As-built status matters more than drawing volume. Commissioning often changes sensor positions, terminal allocations, cable routes, or component selections. The final drawings must incorporate those changes. A design-stage schematic paired with the installed software can send fault diagnosis toward an input that no longer exists.

Device identifiers should remain consistent across drawings, component lists, software tags, and alarm messages. If a pressure switch has different names in each record, maintenance requires avoidable interpretation. Cross-references between electrical pages and physical locations are particularly useful when cabinets or stations are spread across a production line.

The component register should identify exact part numbers, installed quantities, configuration-dependent options, and relevant firmware versions. “Equivalent sensor” is insufficient when replacement affects switching behavior, connector wiring, or a safety function. Wear parts and recommended spares should be identified separately from the general bill of materials.

Safety and compliance evidence must match the delivered system

Request documentation that identifies the applicable requirements, the equipment covered, and the party responsible for the assessment. The required legal documents vary with destination, equipment type, supply arrangement, and modification scope. A certificate carrying a familiar mark is useful only when its scope and product identity match the delivered item.

For an integrated machine, the safety documentation should explain identified hazards, protective measures, and remaining restrictions. Relevant supporting records include the risk assessment, safety function descriptions, circuit information, and validation results. The contractual deliverables should distinguish documents accompanying the equipment from technical records retained by the responsible party.

Validation records need to show what was tested and under which conditions. An emergency stop test alone does not establish that every protective function works correctly. Guard interlocks, reset behavior, prevention of unexpected restart, and operating-mode restrictions require evidence relevant to the actual design.

Where protective-device placement depends on stopping performance, the records should connect the measured or validated stopping behavior to the installed arrangement. A generic calculation from an earlier design revision does not substantiate a changed layout.

A collaborative robot also needs application-specific evidence. The robot’s supplied documentation does not resolve hazards introduced by its gripper, workpiece, fixtures, or surrounding equipment. The completed application determines which protective measures and validation records are necessary.

Software delivery should make recovery possible

A software handover should distinguish editable engineering projects from runtime files and device backups. A runtime image can restore certain equipment, while later modification or troubleshooting may require the original project, libraries, configuration files, and compatible engineering tools. The contract should state which files and rights are included.

The package should cover the devices actually installed: PLC and safety controller projects, HMI applications, robot programs, drive parameters, vision configurations, and relevant network-device settings. Database structures, interface configurations, or deployment files also belong in scope when software integration forms part of the supply.

Useful recovery information includes:

• Version and dependency records: engineering software versions, firmware compatibility, required libraries, and installation prerequisites.
• The location and date of the final backups, with a clear connection to the commissioned equipment revision.
• License ownership, transfer conditions, and any restrictions affecting modification or reinstatement after hardware replacement.
• A restoration procedure covering device replacement, configuration loading, and confirmation that the restored system matches the accepted state.

Passwords and access credentials require a controlled handover method. They should not be scattered through ordinary manuals or left solely in an individual’s account. Where source access is restricted by agreement, the documentation should explain the practical consequences for recovery, future changes, and support.

A backup becomes stronger evidence when restoration has been demonstrated. The record should identify the files restored, the hardware or test environment used, and any steps that still depend on external access or assistance.

Acceptance records should expose the test conditions

Factory acceptance testing and site acceptance testing answer different questions. Factory tests establish performance under the available pre-delivery conditions. Site tests address installation, real utilities, surrounding equipment, and production interfaces. A successful factory test does not resolve items that were simulated or unavailable at that stage.

Every acceptance criterion should point to a result. “Passed” without measurements or observations provides little basis for investigating a later disagreement. A throughput test should retain the elapsed time, output count, rejection treatment, and interruptions relevant to the agreed calculation.

Tests should also cover defined abnormal conditions, such as loss of communication, interrupted power, missing parts, or a failed sensor. The resulting records should show the alarm, machine state, and recovery sequence. Production equipment spends part of its working life recovering from interruptions; that behavior needs acceptance criteria too.

Maintenance instructions need system-specific detail

Component manuals remain useful, but the delivered system needs instructions for its assembled configuration. Operating information should explain permitted modes, startup and shutdown, changeover, alarm response, and recovery limitations. Maintenance information should identify isolation points, stored-energy hazards, inspection tasks, lubrication requirements, and replacement procedures.

Intervals and settings should have a stated basis where operating conditions affect them. A maintenance schedule derived from continuous operation is different from one intended for intermittent duty. Settings such as belt tension, hydraulic pressure, or sensor alignment need enough detail to reproduce the accepted condition.

For replaced devices, instructions should address configuration as well as physical installation. Fitting an identical drive without restoring its parameters can leave the machine unable to run or alter its behavior. Calibration and post-replacement verification should therefore be documented where relevant.

Release documents at the stage when they are needed

Before ordering, agree the deliverable register, scope boundaries, performance criteria, software rights, and submission schedule. During design, review layouts, interface definitions, functional descriptions, and safety-related assumptions while changes remain practical. Before factory testing, obtain the test procedure and the design revision it will verify.

At shipment, installation and handling information must be available for the delivered configuration. After commissioning, the package should incorporate site changes, final software backups, completed test reports, and resolved deviations. Any remaining item needs an explicit status rather than disappearing into a general handover signature.

Final document acceptance should examine usability as well as presence. PDFs support reading and archiving; native files support editing and future engineering where those rights are included. Files should open, references should resolve, and the revision index should identify the authoritative set. The decisive question is whether the package allows the installed system to be traced, serviced, and restored using records that match its accepted configuration.