Learn how to define engineering acceptance criteria using technical requirements, deliverables, documented evidence, testing, commissioning, and technical validation.
Check it out!
Acceptance criteria in engineering define how a technical delivery will be validated by the contracting party. They indicate which requirements must be met, which evidence must be presented, which tests will be considered, which pending items prevent acceptance, and which conditions allow a stage, work order, or contract to be closed.
Without clear acceptance criteria, delivery can become a subjective discussion. The supplier understands that it has fulfilled the scope, the contracting party identifies pending items, and validation begins to depend on interpretation, negotiation, or pressure to close out.
For this reason, acceptance criteria should not be defined only at the end of the project. They should be established from the engineering Terms of Reference onward, in the contract, detailed design, commissioning plan, work orders, and measurement instruments.
This topic is directly connected to technical acceptance in engineering projects, deliverable-based measurement in engineering consulting, and measurement reports in engineering consulting.
What are acceptance criteria?
Acceptance criteria are predefined conditions used to validate whether a delivery complies with the scope, technical requirements, required documentation, and intended conditions of use.
In engineering, these criteria may be applied to designs, reports, technical opinions, installations, systems, equipment, integrations, testing, commissioning, As-Built documentation, training, measurement reports, and consulting deliverables.
They help answer:
- what must be delivered;
- how the delivery will be verified;
- which evidence is required;
- which technical requirements are mandatory;
- which pending items block acceptance;
- which pending items may be accepted with reservations;
- who validates the delivery;
- how acceptance will be recorded.
The expression “acceptance criteria” is also used in different contexts. In engineering practice, these criteria should be treated as the basis for technical acceptance of the delivery.
Why acceptance criteria should be defined before contracting
Criteria defined only at contract closeout tend to create conflict.
When the contract does not establish how the delivery will be accepted, the supplier may work with a minimum interpretation of the scope while the contracting party expects a more complete delivery. This difference appears at the worst possible time: when the service has already been performed, payment is under discussion, and operations need to begin.
For this reason, acceptance criteria should appear in documents such as:
- Terms of Reference;
- detailed design;
- design narrative;
- technical specification;
- contract;
- work order;
- risk matrix;
- commissioning plan;
- test plan;
- measurement report.
In Technical Procurement, these criteria help compare suppliers and avoid proposals that appear equivalent but do not consider the same depth of delivery, testing, and documentation.
Relationship among scope, requirements, and acceptance
Technical acceptance depends on a logical chain: scope, requirements, deliverables, evidence, and validation.
| Element | Function |
| Scope | Defines what must be delivered |
| Technical requirements | Define minimum conditions for performance, compatibility, and documentation |
| Deliverables | Materialize the technical work product |
| Evidence | Demonstrates execution, testing, analysis, or document delivery |
| Acceptance criteria | Define how the delivery will be validated |
| Technical acceptance | Formalizes validation by the contracting party |
If the scope is generic, acceptance criteria become weak. Therefore, their definition should begin in the Terms of Reference and be connected to Requirements Management. If requirements are not objective, validation becomes interpretive; if evidence is not required, acceptance loses traceability. In larger projects, this chain must be incorporated into Quality Management in Engineering Projects itself.
A technically robust acceptance criterion must answer four questions before execution: what will be verified, against which requirement, by which method, and which evidence will close the verification. Expressions such as “proper installation,” “normal operation,” or “complete documentation” are insufficient when they do not indicate tolerance, reference, inspection method, or expected record. The wording should allow two technically competent teams to reach the same conclusion from the same evidence.
For this reason, an acceptance matrix can be used to connect requirement, deliverable, verification stage, responsible party, method, instrument, tolerance, and evidence. This matrix does not replace specifications or procedures; it functions as a traceability index. A performance requirement may be verified during FAT, again during SAT, and finally in an integrated functional test, while a document requirement may depend on approval of the As-Built and the Construction Data Book. The matrix makes clear when each obligation becomes verifiable and prevents acceptance from being postponed to a generic closeout review.
ABNT NBR ISO 9001:2015 reinforces this logic by requiring design outputs to include or reference monitoring and measurement requirements and acceptance criteria. In practice, the criterion should not arise only during commissioning: it should be developed together with the requirement and mature as the design details interfaces, materials, tolerances, procedures, and expected performance. This allows Design Review, procurement, inspection, and execution to work against the same compliance reference.
Another point is to separate acceptance criterion from verification method. The criterion establishes the condition that must be met; the method defines how to demonstrate it. For example, “minimum insulation resistance in accordance with the specification” is a criterion; the measurement procedure, instrument, test voltage, duration, environmental conditions, and record constitute the method. This separation makes it easier to update procedures without improperly changing the contractual requirement and improves traceability among design, inspection, and acceptance.
Examples of acceptance criteria in engineering
Acceptance criteria vary according to the type of contract, but some examples are recurring.
For a detailed design, acceptance criteria may include:
- delivery of the required drawings, design narratives, diagrams, and quantities;
- minimum coordination among disciplines;
- identification of assumptions, limitations, and interferences;
- compliance with the requirements defined in the Terms of Reference;
- formal technical review before delivery;
- response to comments from the contracting party.
For a technical implementation, acceptance criteria may include:
- installation completed according to scope;
- functional tests performed;
- As-Built documentation delivered;
- organized photographic records;
- training completed;
- blocking pending items addressed;
- commissioning completed or approved with reservations.
In engineering consulting, acceptance criteria may include:
- report, technical opinion, or matrix delivered in the required format;
- analysis of the reference documents indicated in the work order;
- record of assumptions and limitations;
- identification of risks and pending items;
- substantiated technical recommendation;
- delivery of applicable evidence or attachments.
These examples must be adapted to the actual scope. An acceptance criterion should not be so generic that it fails to guide validation.
Documented evidence for validation
Acceptance criteria must be associated with documented evidence.
Evidence consists of records demonstrating that the delivery was produced, tested, reviewed, or validated. It may include:
- test reports;
- checklists;
- photographic records;
- certificates;
- meeting minutes;
- commissioning reports;
- risk matrices;
- measurement reports;
- technical opinions;
- As-Built documentation;
- training records;
- pending-items lists;
- integration protocols;
- final document versions.
Without evidence, technical acceptance is vulnerable. With evidence, the decision becomes more traceable and defensible.
The quality of evidence matters as much as its existence. A test report without identification of the tested equipment, date, responsible party, procedure, instrument used, and result compared against the criterion does not adequately close traceability. Likewise, a photograph without reference to the location, item, or condition verified may prove very little. The evidence should make it possible to reconstruct the acceptance decision later, including by a team that did not participate in execution.
When verification depends on measurement, the reliability of the result also depends on the resources used. ABNT NBR ISO 9001:2015 establishes that monitoring and measurement resources must be suitable for their intended purpose and, when measurement traceability is required, must be calibrated or verified against appropriate references. For acceptance, this means checking calibration validity, instrument identification, range, resolution, and suitability for the test. If an instrument is later considered unsuitable, it is necessary to assess whether previous results may have been affected and whether the test needs to be repeated.
In projects with many requirements, evidence should be organized according to a traceability logic. The Inspection and Test Plan (PIT/ITP) may indicate the control point, method, criterion, and required record; the NCR documents deviations and treatment; the Data Book consolidates supply or construction records; and the As-Built demonstrates the configuration actually delivered. These documents should not be viewed as independent attachments, but as parts of the chain supporting acceptance.
It is also necessary to distinguish evidence of execution from evidence of conformity. A signed work order may prove that an activity occurred; it does not necessarily prove that the result meets the requirement. To do so, the record must be associated with the applicable criterion. This distinction is especially important in contractual measurements: physical progress and technical acceptance may proceed together, but they are not synonymous.
Acceptance criteria and deliverable-based measurement
Deliverable-based measurement verifies whether the planned delivery was produced. Acceptance criteria verify whether that delivery meets what was defined.
The relationship is complementary.
The deliverable may exist but fail to meet the acceptance criterion. A report may have been delivered but fail to address the reference documents. A system may be installed but not tested. A design may have been issued but contain significant incompatibilities.
For this reason, the measurement report should record not only the existence of the delivery, but also its validation status, the evidence considered, and associated pending items.
This distinction is important because production, submission, approval, and acceptance may represent different states. A document may have been submitted on time and still be under review; it may have been reviewed and returned for correction; or it may have been technically approved but depend on complementary evidence to release a given milestone. If the contract treats all these states as equivalent, measurement loses its ability to represent actual progress.
A robust practice is to define in advance which conditions release each payment installment or milestone. For a design, payment may depend on formal issuance of the specified revision and approval according to defined criteria. For an inspection, it may depend on the report, field records, and treatment of critical pending items. For a supply, it may require an approved FAT, minimum documentation, and release for shipment. For commissioning services, it may depend on execution of the planned tests, valid evidence, and closeout of items that block acceptance.
This does not mean turning every measurement cycle into a complete audit. The level of verification should be proportional to the criticality of the deliverable and the risk of paying for a condition that is difficult to recover later. Intellectual deliverables, custom-manufactured equipment, and irreversible milestones normally require more explicit criteria than routine and easily verifiable activities.
It is also advisable to separate a pending item that prevents acceptance from one that may be closed later. When this classification does not exist, any comment may block measurement — or, at the other extreme, incomplete deliveries may be considered accepted merely because they were formally submitted. The criteria matrix should define these classes and their consequences for measurement, provisional acceptance, final acceptance, and payment release.
In on-demand contracts, this logic helps transform a Work Order into a verifiable unit of technical production. The authorized scope, deliverables, criteria, and evidence form the basis of the acceptance calculation. This allows the contracting party and contractor to discuss objectively what was produced, what still depends on correction, and which portion is effectively eligible for measurement.
Acceptance criteria in OS-LPU and OS-CIC
In engineering consulting contracts, acceptance criteria should be defined according to the nature of the demand.
In an OS-LPU, the demand is specific and linked to an item in the LPU. The acceptance criterion may be associated with delivery of a technical opinion, matrix, checklist, technical meeting minutes, or preliminary analysis.
In an OS-CIC, the demand involves an integrated engineering cycle. Acceptance may depend on stages, milestones, validation meetings, an interim report, final report, risk matrix, action plan, or consolidated documentation.
The article OS-LPU and OS-CIC in Engineering Consulting explains this distinction.
Acceptance criteria and commissioning
In critical systems, commissioning is one of the main sources of evidence for acceptance.
It verifies whether installation, integration, configuration, automation, alarms, operational workflows, documentation, and operating conditions comply with the project and contracting-party requirements.
Without commissioning, acceptance may occur based only on physical completion of the installation. This is insufficient for systems that depend on performance, integration, availability, and safe operation.
The articles on commissioning of critical systems and FAT, SAT, and integrated testing complement this point.
Commissioning works best when acceptance criteria have already been decomposed into verifiable prerequisites. Before starting a functional test, for example, it may be necessary to confirm completion of installation, safe energization, availability of utilities, approval of procedures, instrument calibration, loaded configuration, minimum documentation, and closure of blocking pending items. Without this readiness verification, the test may fail for reasons that do not represent the actual performance of the system and create rework that is difficult to interpret.
It is also useful to distribute criteria throughout the supply chain. The FAT may verify manufacturing, logic, performance, and documentation while still at the supplier; the SAT confirms conditions after transportation, installation, and site integration; functional commissioning verifies operation under defined scenarios; and integrated testing evaluates interfaces and responses among systems. The criterion should indicate at which of these stages the obligation will be demonstrated and whether an earlier verification must be repeated after relevant changes.
Results outside the limit should not be informally “absorbed” into acceptance. When a requirement is not met, the workflow must provide for recording the nonconformance, technical evaluation, correction or approved disposition, and, where applicable, retesting. The decision to accept a condition different from the specified one must have defined authority and traceable justification; otherwise, the project risks turning unevaluated exceptions into the final configuration.
Likewise, acceptance with reservations requires criteria. A Punch List may allow minor items to remain open without preventing a particular milestone, but pending items affecting safety, performance, availability, legal compliance, or testability must be treated differently. The classification must be established before the acceptance decision and associated with a responsible party, deadline, correction evidence, and closeout authority.
For this reason, final approval should not be an isolated signature at the end of construction. It is the result of a chain of verifications: defined requirements, objective criteria, valid evidence, treated deviations, classified pending items, and consolidated documentation. When this chain is planned from contracting onward, commissioning ceases to be an attempt to discover at the end whether the project works and becomes the stage in which previously defined requirements are demonstrated in a controlled manner.
Pending items and acceptance with reservations
Not every pending item prevents acceptance, but every pending item must be recorded and classified.
Pending items may be:
- blocking;
- significant;
- minor;
- document-related;
- conditional;
- dependent on third parties.
Acceptance with reservations may be applied when the pending item does not compromise the purpose of the delivery, provided that a deadline, responsible party, and verification method are defined.
When a pending item compromises operation, safety, performance, critical documentation, or minimum compliance, it should prevent acceptance until it is addressed.
Common mistakes in defining acceptance criteria
Some mistakes occur frequently:
- criteria that are too generic;
- criteria defined only at the end of the project;
- absence of mandatory evidence;
- lack of relationship with the Terms of Reference;
- absence of measurable requirements;
- acceptance based only on visual perception;
- final documentation not required;
- commissioning not planned;
- pending items without classification;
- undefined validation responsibilities.
These problems increase the risk of conflict, rework, unstable operation, and difficulty enforcing warranties.
How A3A supports the definition of acceptance criteria
A3A supports private companies, industries, public agencies, and institutions in defining acceptance criteria for designs, implementations, critical systems, and engineering consulting services.
This work may be performed together with:
- Engineering Terms of Reference;
- Detailed Design;
- Technical Procurement;
- Ongoing Engineering Consulting Services;
- Technical Due Diligence;
- Owner’s Engineering.
The objective is to avoid subjective acceptance, reduce disputes, and create a documented basis for technical validation, operations, maintenance, auditing, and contract closeout.
Recommended complementary content
To explore technical validation of deliverables in greater depth, see also:
- Technical Acceptance in Engineering Projects;
- Deliverable-Based Measurement in Engineering Consulting;
- Measurement Report in Engineering Consulting;
- OS-LPU and OS-CIC in Engineering Consulting;
- Risk Matrix in Engineering Projects;
- FAT, SAT, and Integrated Testing in Critical Systems.
Conclusion
Acceptance criteria in engineering are essential for validating deliveries objectively, with evidence and traceability.
They should be defined before contracting and linked to the scope, technical requirements, deliverables, testing, commissioning, and required documentation.
When well structured, acceptance criteria reduce subjectivity, protect the contracting party, guide suppliers, and improve technical contract closeout.
In engineering, accepting a delivery is not merely agreeing that something has been completed. It means verifying that what was delivered complies with what was requested, measured, tested, and documented.
Talk to our Engineering Department
If your organization needs to define acceptance criteria, structure technical validation, review deliverables, monitor commissioning, or close contracts with greater assurance, contact A3A’s Engineering Department.
A3A supports private companies, industries, public agencies, and institutions in contracting, measuring, and technically validating engineering services with methodology, evidence, and document traceability.
Technical references
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9001:2015 — Quality management systems — Requirements. Geneva: ISO, 2015. Available at: https://www.iso.org/standard/62085.html.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 10005:2018 — Quality management — Guidelines for quality plans. Geneva: ISO, 2018. Available at: https://www.iso.org/standard/70398.html.
[3] PROJECT MANAGEMENT INSTITUTE. PMBOK® Guide and Standards. Newtown Square: PMI. Available at: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok.
[4] AACE INTERNATIONAL. Recommended Practices. Morgantown: AACE International. Available at: https://web.aacei.org/resources/publications/recommended-practices.
Frequently asked questions
They are predefined conditions used to validate whether a delivery complies with the scope, technical requirements, required documentation, and intended conditions of use.
Acceptance criteria define how the delivery will be validated. Technical acceptance is the formalization of validation based on those criteria, evidence, and records.
They should be defined before contracting, preferably in the Terms of Reference, detailed design, contract, work order, test plan, or commissioning plan.
Test reports, checklists, photographic records, certificates, meeting minutes, commissioning reports, measurement reports, As-Built documentation, technical opinions, and pending-items lists.
Yes, provided that the pending items do not compromise the purpose of the delivery and that a deadline, responsible party, and verification method are defined.
Complementary technical materials
Related solutions
- Requirements, Evidence, and Acceptance Criteria Management
- Pending Items, RFIs, and Nonconformities Management
- Process, Workflow, and Technical Approval Management
- Project, Program, and Portfolio Governance
Related services
- Technical Acceptance of Engineering Works and Services
- Technical Support for Inspection
- Engineering Technical Audit
- Owner’s Engineering
- Equipment Commissioning
Main content on this topic
- Requirements Management in Engineering
- Inspection and Test Plan (PIT/ITP)
- QA/QC in Engineering Works
- Punch List in Engineering
- Construction Data Book
- FAT and SAT
- Nonconformance Report (RNC/NCR)
