Understand why an installed and operating system may still not be technically delivered, and how documentation, tests, As-Built records, configurations, and acceptance complete the delivery.
Check it out!
A system may be installed, energized, and apparently operational without its technical delivery being complete. In engineering, physical completion shows that components have been installed; technical delivery requires evidence—through documents, tests, records, and traceability—that the delivered scope complies with the contract; and acceptance is the owner’s formal decision after that verification.
This distinction is especially important in technology systems, where a significant part of the delivered condition is not visible. Configurations, integrations, licenses, native files, backups, tests, inventories, As-Built drawings, manuals, and performance evidence may be as relevant as the installed equipment.
Therefore, “it is working” is not the same as “it has been technically delivered”. The owner’s question must be broader: can the organization demonstrate what was installed, in which configuration, against which requirements, with which tests and documents, and with which remaining punch-list items?
Installation, operation, technical delivery, and acceptance are different milestones
Confusion begins when different milestones are treated as a single event. A contractor may finish installation and consider physical production complete while the owner still needs to verify compliance, documentation, and readiness to take over the system.
| Condition | What it demonstrates | What may still be missing |
| Installed | Equipment and infrastructure have been installed | tests, documentation, integration, corrections |
| Operating | Observable functional response exists | demonstrated performance, full coverage, traceability |
| Tested | Specific checks have been performed | final documentation, open items, baseline |
| Documented | Records and files have been produced | quality validation and correspondence with field conditions |
| Technically delivered | Requirements, evidence, and deliverables have been reconciled | formal owner decision |
| Received/accepted | The competent authority recognized delivery against applicable criteria | remaining obligations, warranties, and support |
| Handover completed | Operations received the asset, information, knowledge, and responsibilities | residual follow-up when required |
Technical Acceptance in Engineering Projects addresses the formal validation of deliverables. Technical Handover in Engineering addresses the transition to operations. Technical delivery sits between these milestones as the structured demonstration of what was actually produced and delivered.
What defines a technical delivery
There is no universal package for every project or system. Delivery depends on the contract, discipline, criticality, and defined requirements. The principle, however, is consistent: the contractor must provide sufficient evidence to demonstrate the condition it claims to have delivered.
Depending on the scope, a technical delivery may include:
- compliance of the physical scope;
- equipment and materials consistent with requirements;
- inspection records;
- tests and examinations;
- commissioning reports;
- certificates;
- As-Built drawings and diagrams;
- asset inventory;
- final parameters and configurations;
- native files and backups;
- licenses and credentials transferred through a secure process;
- operation and maintenance manuals;
- training;
- supplier documentation;
- warranties;
- Data Book or quality dossier;
- punch list and closeout evidence;
- terms or records required for receipt and acceptance.
The specific obligation must be read within the contract as a whole. The mistake is to assume that apparent operation replaces formally required or technically necessary deliverables.
CCTV benchmark: the cameras work, but the system is still not technically delivered
Apparent operation proves only part of the delivered condition. A technical decision must reconcile installation, tests, documents, configurations, open items, and acceptance criteria.
Consider an IP CCTV project in which the installation contractor has completed implementation. The cameras are mounted, the VMS displays images, and users can view the system. The immediate perception is positive: the system exists and works.
However, during the receipt review, the owner identifies that the final documentation does not fully represent the installed condition. There are discrepancies between drawings and field conditions, test records do not provide traceability for every device, the inventory is not reconciled, some final configurations are undocumented, and the delivered package does not allow the system baseline to be reconstructed reliably.
This does not necessarily mean the physical installation was poorly executed. Cameras, switches, servers, and the VMS may be operating satisfactorily while, at the same time, contractual and technical delivery remains incomplete because required evidence is missing or inadequate.
This type of situation matters because quality has different dimensions:
| Dimension | Control question |
| Execution quality | Was the equipment installed correctly? |
| Functional quality | Does the system perform the intended functions? |
| Performance quality | Were measurable criteria demonstrated? |
| Documentation quality | Do the records correctly represent the installed condition? |
| Evidence quality | Can compliance be demonstrated objectively? |
| Contractual completeness | Were all required deliverables and obligations satisfied? |
Quality Management in Engineering Projects and QA/QC in Engineering Works help structure these dimensions during execution, preventing the discussion from being postponed until project closeout.
In digital systems, a significant part of the delivery is not visible during a field inspection
In digital systems, the baseline also exists in backups, parameters, licenses, and configuration files. Without these elements, the owner may receive a system that operates today but whose future maintenance and recovery remain dependent on the installer.
Integrate documentation, configurations, and As-Built records into final delivery →
A camera may be mounted on a wall, but that does not reveal its configured resolution, codec, bitrate, recording retention, user profiles, analytics rules, time synchronization, integrations, firmware, or network parameters. The same applies to automation, BMS, SCADA, access control, and many software-based systems.
Therefore, delivery may need to include elements such as:
- configuration backups;
- firmware and software versions;
- final parameters;
- logical topology;
- addressing;
- user and profile matrix when applicable;
- licenses;
- programming files;
- configured integrations;
- restore procedures;
- interface documentation;
- asset inventory and serial numbers.
These elements must be handled under appropriate security governance. Credentials, private keys, and secrets should not be indiscriminately inserted into broadly circulated documents; the owner should establish a secure process for transfer and custody.
Incorrect As-Built documentation prevents a reliable baseline
The As-Built must represent the condition actually installed. If a drawing shows a camera in a different location, identifies equipment that was replaced, or fails to incorporate changes made during implementation, the document does not adequately fulfill its role as a baseline.
This becomes even more relevant years later. Maintenance teams will use this record set to locate components, plan modifications, investigate failures, replace equipment, and understand interfaces.
An incorrect document may not prevent the system from operating today, but it increases risk and cost throughout the asset lifecycle.
A delivered document must also be an acceptable document
The number of files is not a measure of documentation quality. Technical Documentation in Engineering must be assessed for content, revision status, consistency, traceability, and intended purpose.
It is necessary to distinguish between:
- required document;
- produced document;
- submitted document;
- reviewed document;
- rejected document;
- corrected document;
- document approved or accepted for its required purpose.
The Master Document Register — MDR makes it possible to reconcile the expected document universe with what was actually received and the status of each item.
At project closeout, saying “the documents were sent” does not answer the main question: do they meet the requirements and represent the final condition?
An isolated test does not replace acceptance criteria
An informal demonstration may prove that a particular function responded at that moment. Acceptance criteria require a prior definition of what will be verified and what result will be considered satisfactory.
In CCTV, for example, different projects may require verification of:
- coverage;
- field of view;
- scene identification;
- recording;
- retention;
- video retrieval;
- redundancy;
- failover;
- integration with access control;
- events and alarms;
- analytics;
- PTZ operation;
- time synchronization;
- connectivity;
- permissions and profiles;
- server and storage performance.
The article Acceptance Criteria in Engineering shows how to transform requirements into objective verification criteria.
When criteria were not defined in advance, closeout can become a subjective negotiation between “it worked during the demonstration” and “I do not consider it delivered.”
Commissioning creates structured evidence of readiness
Engineering Commissioning verifies whether systems and subsystems were installed, configured, and tested against applicable requirements. Its value is to turn observations and tests into traceable evidence.
In integrated systems, this is especially relevant because problems may exist at interfaces rather than within isolated components. A camera works; the VMS works; access control works. Even so, a promised integration may fail to execute the required workflow.
Commissioning also helps ensure that the tested configuration is the same configuration represented in the documents, native files, and backups delivered to the owner.
A punch list separates physical completion from closeout of open items
A project approaching delivery may still have residual open items. The issue is not necessarily that a pending item exists, but that there is no governance over it.
An Engineering Punch List should identify, as applicable:
- item;
- system or location;
- criticality;
- affected requirement;
- responsible party;
- deadline;
- temporary condition;
- evidence expected for closeout;
- verification responsibility;
- status.
Blocking items should not be diluted into a generic list merely to declare the project complete. Minor items may be managed when there is a technical basis and a defined control mechanism.
Substantial completion and technical delivery should not be confused
International contracts and delivery models may use the concept of substantial completion, associated with a stage at which the project has reached a condition sufficient for certain contractual effects even though residual work remains. Its definition and effects depend on the applicable contract.
This concept should not be automatically imported into every Brazilian contract or used as a synonym for technical acceptance. A physically substantial condition may coexist with documentation gaps, tests, corrections, and receipt requirements.
The management principle is to clearly separate each milestone and its effects: physical completion, functional readiness, documentation delivery, receipt, acceptance, warranty, and operational handover.
In public procurement, the contractor declares delivery; the contracting authority verifies it
In Brazilian public procurement, Law No. 14,133/2021 requires contract performance to be monitored and inspected and provides that, for works and services, provisional receipt occurs through a detailed record after technical requirements have been verified.
Therefore, the contractor’s declaration of completion is relevant information, but it does not replace the Public Administration’s verification procedure. The scope may also be rejected, wholly or partially, when it does not comply with the contract.
How to prevent documentation from becoming a problem only at the end
Closeout documentation should not be produced all at once after the field team demobilizes. Document control should accompany execution.
A sound strategy includes:
- define the deliverable list in the design, Terms of Reference, and contract;
- structure the MDR and responsibilities;
- require submittals at defined milestones;
- control revisions and comments;
- continuously incorporate field changes;
- link inspections and tests to the corresponding documents;
- review As-Built documentation progressively;
- control documentation gaps as part of progress;
- reconcile the final package before receipt;
- transfer to operations only accepted and usable information.
Document Control in Engineering and the Engineering Data Book are components of this process.
How Owner’s Engineering changes the delivery perspective
The contractor is responsible for executing the scope within its contractual obligations. Owner’s Engineering looks at the same project from the owner’s perspective: requirements, interfaces, quality, evidence, risks, changes, documentation, operations, and acceptance.
Owner’s Engineering can support the lifecycle from scope definition through delivery, reducing information asymmetry between the party executing the work and the party that must take over the asset.
At closeout, this role may include documentation review, punch-list analysis, support during testing, interface verification, coordination of specialists, and technical opinions to support the owner’s decisions.
The purpose is not to distrust the contractor by default. It is to create an independent verification chain proportionate to the risk and complexity of the scope.
If the system is already operating, technical delivery can still be corrected
When a system entered service before documentation and evidence were finalized, the work becomes a baseline recovery effort.
A possible approach includes:
- review of the original scope and obligations;
- inventory of the installed condition;
- asset reconciliation;
- review of existing documents;
- supplementary As-Built survey;
- configuration verification;
- analysis of available test records;
- additional technically justified testing;
- punch-list matrix;
- documentation correction;
- Data Book consolidation;
- technical recommendation for receipt and acceptance.
The article Construction quality failures: what to hire to diagnose, correct, and restore technical control shows how to select audit, QA/QC, inspection, commissioning, technical receipt, or Owner’s Engineering according to the problem identified.
Delivery problems often begin in the design and Terms of Reference
If the owner expects to receive certain evidence at the end, that obligation must be considered at the beginning. Design documents, specifications, and Terms of Reference should make clear, according to the nature of the scope, what will be delivered and how it will be verified.
This may include:
- document formats and revisions;
- native files;
- As-Built requirements;
- tests;
- instruments;
- approval criteria;
- commissioning responsibilities;
- Data Book content;
- training;
- warranties;
- configurations and backups;
- submittal deadlines;
- review and resubmittal process;
- effects of open items on measurement and receipt.
The Engineering Terms of Reference connects these definitions to public procurement.
A simple matrix to decide whether the system is truly ready for delivery
The owner can structure the decision by readiness dimensions:
| Dimension | Possible evidence |
| Physical | inspection, quantities, installation, identification |
| Functional | tests and controlled demonstrations |
| Performance | measurements and quantitative criteria |
| Documentation | MDR, As-Built, manuals, reports, Data Book |
| Digital | backups, versions, parameters, licenses, configurations |
| Quality | inspections, NCRs, punch list, and corrections |
| Operational | training, procedures, support, and spare parts |
| Contractual | deliverables, records, warranties, and receipt requirements |
Not every system needs the same documentation package. The package should be proportionate to the complexity, criticality, and contracted requirements.
Final considerations
An installed system may represent completed physical execution. An operating system may demonstrate part of its functional condition. Neither milestone, by itself, proves that technical delivery is complete.
A mature delivery connects the physical scope, requirements, tests, documents, configurations, open items, and evidence. Acceptance follows verification, according to the applicable authority and procedure. Handover transfers the accepted condition to operations.
When these boundaries are defined during contracting and controlled throughout execution, closeout no longer depends on subjective discussions. When they are not, Consulting Engineering, QA/QC, Document Control, commissioning, inspection, and Owner’s Engineering can help the owner reconstruct the necessary evidence and restore technical control of the delivery.
Owner’s Engineering creates an independent layer between the contractor’s declaration and the owner’s decision, organizing requirements, evidence, interfaces, quality, and acceptance recommendations.
Technical references
[1] BRAZIL. Law No. 14,133, of April 1, 2021. Public Procurement and Administrative Contracts Law. Available at: https://www.planalto.gov.br/ccivil_03/_ato2019-2022/2021/lei/l14133.htm
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-2:2018 — Organization and digitization of information about buildings and civil engineering works, including building information modelling — Information management using building information modelling — Part 2: Delivery phase of the assets. Available at: https://www.iso.org/standard/68080.html
[3] CHARTERED INSTITUTION OF BUILDING SERVICES ENGINEERS. Guide M7: Handover procedures. 2023. Available at: https://www.cibse.org/knowledge-research/knowledge-portal/guide-m7-handover-2023/
[4] U.S. DEPARTMENT OF ENERGY. Federal Energy Management Program. Commissioning Process for Federal Facilities. Available at: https://www.energy.gov/cmei/femp/commissioning-process-federal-facilities
Frequently asked questions
Not necessarily. Operation demonstrates a functional condition, but technical delivery may also depend on documentation, tests, As-Built records, configurations, inventories, closeout of open items, training, and other required deliverables.
Physical installation puts equipment and infrastructure in place. Technical delivery demonstrates, through traceable evidence, that the installed scope meets requirements, is documented, has been tested, and satisfies the defined conditions for receipt.
When required by the scope or necessary to represent the final condition, yes. The As-Built must correspond to the condition actually installed and serve as a baseline for operations, maintenance, and future interventions.
Yes, depending on the affected requirement and the contract. The criticality of the gap should consider its impact on compliance, operations, maintenance, safety, warranty, traceability, and contractual obligations.
Because images in the VMS prove only part of functionality. Evidence may still be missing for coverage, testing, inventory, configurations, integrations, As-Built records, backups, licenses, training, and required final documentation.
Yes. It may be necessary to reconstruct the contractual baseline, inventory the installed condition, review documents, perform an As-Built survey, validate configurations, complete testing, close open items, and consolidate the final technical package.
Related technical resources
Related solutions
Related services
- Technical Receipt of Engineering Works and Services
- Engineering Commissioning
- Engineering As-Built
- Owner’s Engineering
