Accepted system definition
As-built architecture, component roles, retained systems, supplier boundaries and approved deviations.
Home › O-PAS Project Documentation, As-Built and Lifecycle Handover
As-Built · Handover · Source Assets · Acceptance Evidence · Lifecycle Custody
O-PAS project documentation, as-built and lifecycle handover Turn project records into an operating baseline the owner can actually use
A practical guide for owner, EPC and system-integration teams defining the complete O-PAS handover package from accepted architecture and IEC 61131 source through test evidence, recovery assets, support records and lifecycle ownership.
The short answer
O-PAS handover should deliver the recoverable, supportable operating system—not just a folder of drawings and PDFs.
The owner should receive the accepted architecture, exact product and version inventory, interface register, IEC 61131 source and libraries, deployment assets, configuration baselines, requirements traceability, FAT/SAT evidence, identity and certificate records, backup/recovery packages, licenses and engineering tools, supplier support records, spares, open exceptions, training records and clear custody of the lifecycle baseline.
01 · Handover basis
Define the package before the project team demobilizes
Handover requirements should be contractual and traceable from procurement through commissioning so the owner receives usable lifecycle assets rather than whatever documents happen to exist at closeout.
Installed baseline
Exact products, versions, firmware/software, configuration identities and applicable product evidence.
Owner control assets
IEC 61131 source, libraries, documentation, build/deployment packages and runtime allocation.
Boundary records
Provider/consumer definitions, mappings, states, quality, diagnostics, security and failure behavior.
Acceptance record
Requirements traceability, FAT, SAT, commissioning, defects, deviations and approvals.
Operating custody
Support, spares, backup/recovery, credentials, licenses, procedures, training and change ownership.
Handover stop condition: the system is operating, but the owner cannot rebuild an application, identify the accepted versions, recover a failed component or determine who supports a cross-supplier issue without calling the project team.
02 · Architecture and inventory
Preserve what was actually installed and accepted
| Record | Minimum handover content |
|---|---|
| As-built architecture | Component roles, locations, retained systems, infrastructure services, supplier boundaries and approved deviations. |
| Product/version inventory | Manufacturer, product, version, firmware/software, configuration identity, location and lifecycle status. |
| Interface register | Provider, consumer, information, commands, states, quality, diagnostics, security and failure/restoration behavior. |
| Dependency map | Applications, libraries, runtimes, services, tools, certificates and retained-system dependencies. |
| Product evidence | Exact certificate/register references, scope, limitations and project gap disposition where applicable. |
Use the O-PAS Architecture and Component Roles Guide and Interface Definition and Boundary Management Guide to structure these records.
03 · IEC 61131 application assets
Hand over enough to rebuild, deploy and verify the accepted applications
Controlled application source
Accepted IEC 61131 source, libraries, versions and documentation.
Reproducible build basis
Required tools, versions, dependencies, instructions and build configuration.
Deployment package
Runtime allocation, loading sequence, configuration and deployment procedure.
Verification assets
Functional, regression, failure and recovery test records associated with the accepted release.
Owner access
Licenses, credentials and rights required to maintain, modify and redeploy the applications.
Change lineage
Release notes, approved deviations and superseded versions needed for lifecycle decisions.
Use the O-PAS Application Portability Guide to define source, library, runtime and deployment ownership.
04 · Configuration baseline
Hand over the exact state the owner accepted
| Configuration area | Required handover |
|---|---|
| Products | Configuration exports, parameters, firmware/software settings and restore procedures. |
| Interfaces | Mappings, endpoints, information definitions, security configuration and diagnostic settings. |
| System services | Identity, certificates, time, monitoring, inventory, logging, backup and deployment configuration. |
| Cybersecurity | Accounts, roles, trust relationships, hardening records, access rules and accepted exceptions. |
| Baseline manifest | Authoritative list connecting exact versions, configuration identities, applications and approved deviations. |
Use the O-PAS Configuration Management, Change Control and Regression Testing Guide for baseline control.
05 · Verification and acceptance evidence
Preserve why the system was accepted
Traceability matrix
Requirement, allocation, verification method, evidence, deviations and acceptance status.
FAT evidence
Procedures, expected results, executed records, witnesses, defects, corrections and regression.
SAT and commissioning
Installed-system evidence, site-specific results, cutover, startup and stabilization records.
Approved deviations
Residual conditions, rationale, restrictions, risk acceptance and responsible owner.
Conformance records
Exact product evidence and limitations linked to the installed baseline.
Acceptance decisions
Named authority and formal release/acceptance records for each applicable gate.
Use the O-PAS Requirements Traceability and Verification Matrix Guide to connect requirements to accepted evidence.
06 · Operations and recovery assets
Deliver what the operating team needs on day two
| Operating asset | Handover requirement |
|---|---|
| Monitoring and diagnostics | Dashboards, alerts, logs, procedures, thresholds and diagnostic access. |
| Backup and recovery | Protected backups, restoration order, tools, dependencies, procedures and demonstrated results. |
| Change procedures | Impact assessment, approval, deployment, rollback, regression and baseline update process. |
| Support model | Service-entry route, supplier contacts, escalation, response obligations and integrated support owner. |
| Spares | Criticality, identity, storage, configuration readiness, replenishment and replacement path. |
| Training | Role-based training, competency evidence and knowledge-transfer records. |
Use the O-PAS Multi-Vendor Operations and Support Model Guide and Backup, Restore and Disaster Recovery Guide for operating readiness.
07 · Commercial and supplier records
Close obligations without losing lifecycle access
Usage and renewal rights
Runtime, engineering, development and support licenses with transfer and renewal requirements.
Supplier commitments
Support periods, warranties, response obligations, known limitations and lifecycle notifications.
Engineering access
Required utilities, portals, accounts, diagnostic tools and owner access rights.
Open obligations
Remaining correction, warranty, support and closeout actions with responsible parties.
Asset custody
Delivered spares, storage location, preservation, configuration and ownership.
Future transition
Records and rights the owner will need if a supplier or support provider changes later.
08 · Open items and exceptions
Do not hide unresolved conditions inside handover
| Open item | Required record |
|---|---|
| Defect | Severity, workaround, correction owner, target date, regression and acceptance status. |
| Deviation | Requirement, rationale, restriction, residual risk, approving authority and review date. |
| Temporary configuration | Reason, duration, owner, restoration path and effect on the accepted baseline. |
| Deferred lifecycle action | Patch, replacement, training, documentation or support action transferred into operations. |
09 · Handover acceptance
Accept the package by demonstrating owner capability
Inventory the package
Confirm every required artifact is delivered, identifiable and revision-controlled.
Check reproducibility
Build or restore representative applications and configurations using delivered assets.
Check traceability
Navigate from requirement to implementation, evidence, defect and approval.
Check recovery
Demonstrate that critical functions can be restored using owner-held backups, tools and procedures.
Check support readiness
Raise a representative support path and verify supplier contacts, escalation and access.
Transfer custody
Name the owner role responsible for the accepted baseline, credentials, source, records and lifecycle updates.
Acceptance rule: handover is not complete because files were uploaded. It is complete when the owner can operate, recover, support and change the accepted system using the transferred assets.
10 · Lifecycle custody
Make the handover package the starting point for every future change
After acceptance, the owner should maintain the package as the authoritative lifecycle baseline. Patches, IEC 61131 application releases, component replacements, support changes, recovery tests and retirement decisions should update the same records rather than create disconnected document sets.
Project closeout should create the operating source of truth
The value of the handover package is measured by whether the next engineer can make a controlled decision without reconstructing the original project.
Use the O-PAS System Management and Lifecycle Operations Guide →11 · Connected guidance
Connect handover to the complete lifecycle control set
Site
Commissioning and Cutover
Define readiness and acceptance before handover.
EvidenceTraceability Matrix
Preserve why the system was accepted.
ApplicationsApplication Portability
Transfer IEC 61131 source and deployment assets.
LifecycleSystem Management
Maintain the accepted baseline after startup.
SupportOperations and Support
Activate the day-two integrated support model.
RecoveryBackup and Recovery
Transfer tested recovery assets and procedures.
Frequently asked questions
O-PAS documentation and handover questions
What should be included in an O-PAS project handover package?
At minimum: as-built architecture, exact product/version inventory, interface and dependency records, IEC 61131 source and libraries, deployment/configuration assets, requirements traceability, FAT/SAT evidence, identities and certificates, backup/recovery assets, licenses/tools, support records, spares, open exceptions and training records.
Is a PDF documentation set enough for O-PAS handover?
No. The owner also needs machine-usable source, configuration, backups, deployment assets, licenses, credentials, tools and controlled records sufficient to recover and modify the operating system.
Who should own the accepted lifecycle baseline after handover?
The owner should name a custodian with authority and responsibility for the integrated inventory, source/configuration assets, evidence, credentials, support records and controlled updates after project closeout.
How should open defects be handled at handover?
Keep them explicit with severity, workaround, responsible party, target correction, regression requirement, operational restriction and acceptance status. Handover should not erase unresolved project obligations.
How should IEC 61131 application source be handed over?
Provide the accepted source, libraries, toolchain/version basis, build and deployment instructions, runtime allocation, required licenses and corresponding test evidence so the owner can reproduce and maintain the release.
How does CSI support O-PAS lifecycle handover?
CSI helps owners and EPCs define handover requirements, structure as-built and source packages, reconcile accepted baselines, verify recovery/support readiness and transfer custody into lifecycle operations.
Before the project team leaves with the system knowledge
Turn project closeout into an owner-controlled operating baseline
CSI can help owners and EPC teams define, verify and accept the architecture, source, configuration, evidence, recovery and support assets needed for sustainable multi-vendor operation.
O-PAS™ and Open Process Automation™ are trademarks of The Open Group. CSI is an independent commercial licensee of the O-PAS Standard. This guide is a project and lifecycle planning aid and does not imply endorsement by The Open Group. The applicable contract, owner documentation standards, current O-PAS Standard and current certification records govern the project handover package.