Ask for missing definition
Use when the owner can resolve an ambiguity before bid close or award.
Use the O-PAS Supplier Bid Evaluation and Technical Comparison Guide →
Home › O-PAS Bid Clarifications and Technical Exceptions
EPC Bids · Clarifications · Assumptions · Exceptions · Commercial Boundaries
O-PAS bid clarifications and technical exceptions Turn ambiguous requirements into explicit bid positions
A practical guide for EPC proposal, estimating, controls and owner teams converting an O-PAS requirement into a reviewable clarification, assumption and technical-exception register before price and responsibility are fixed.
The short answer
An O-PAS bid should not silently convert ambiguous owner language into unlimited EPC integration responsibility.
Each unclear requirement should be translated into a specific question or stated bid basis covering the applicable O-PAS requirement, architecture role, product evidence, IEC 61131 application scope, interface boundary, integration responsibility, verification method, correction obligation, schedule dependency and lifecycle deliverable. Clarifications resolve uncertainty; assumptions state the basis used to price unresolved items; technical exceptions identify requirements the bidder does not accept as written.
01 · Clarification register
Separate questions, assumptions and exceptions
These are different commercial instruments. Mixing them makes it difficult to know what the bidder asked, what it priced and what it declined.
State the priced basis
Use when the bid must proceed before the owner resolves the uncertainty.
Identify non-acceptance
Use when the bidder cannot or will not comply with a requirement as written.
Define cost treatment
State allowance, unit rate, provisional sum, owner dependency or exclusion where scope cannot be fixed.
Name required input
Identify owner, supplier or third-party information and the date required.
Track disposition
Record response, bid revision, contract incorporation and residual open item.
Use the O-PAS Project Change Order and Scope Growth Management Guide →
Bid stop condition: the proposal contains a general statement such as “O-PAS compliant” but the team cannot point to the architecture, product evidence, interfaces, integration scope and acceptance basis included in the price.
02 · Ambiguous requirement language
Clarify the words that move scope
Broad terms can hide materially different technical and commercial obligations.
| Owner language | Clarification needed | Why it changes the bid |
|---|---|---|
| “O-PAS compliant” | Which edition, requirements, profiles, products and evidence are required? | Defines product selection and evidence scope. |
| “Interoperable” | Which products, interfaces, functions and failure conditions must operate together? | Defines integration and test work. |
| “Portable applications” | Which IEC 61131 applications, source assets, runtimes, libraries and portability demonstrations are required? | Defines application engineering and verification. |
| “Open architecture” | Which boundaries, owner rights, engineering assets and lifecycle substitutions are required? | Defines architecture and handover obligations. |
| “Vendor neutral” | Does this constrain supplier selection, proprietary dependencies, integration tools or lifecycle support? | Changes procurement and integration strategy. |
| “Complete system” | Who owns architecture, cross-supplier integration, correction and final acceptance? | Determines single-point accountability and risk. |
Use the O-PAS Profiles and Project Requirements Guide to separate standard requirements from project-specific obligations.
03 · Architecture clarifications
Resolve the decisions that define what the EPC is delivering
| Area | Clarification questions |
|---|---|
| Component roles | Which functions and architecture roles are in EPC scope, owner scope or supplier scope? |
| Retained systems | Which legacy functions remain, what interfaces are required and who supplies information needed to integrate them? |
| Supplier freedom | Are products nominated, approved-list constrained or bidder-selected subject to evidence? |
| System management | Who provides inventory, configuration, deployment, monitoring, backup, recovery and lifecycle functions? |
| Resilience | Which functions require redundancy, degraded operation, failover or recovery evidence? |
| Lifecycle replacement | What component substitution and technology-refresh capability must the architecture preserve? |
Use the O-PAS Architecture and Component Roles Guide to establish the architecture basis behind these questions.
04 · Product evidence
Clarify exactly what evidence the owner expects
Do not let product conformance language expand silently into a guarantee of system interoperability or project acceptance.
Exact offered product
Product, version, edition/profile basis, certificate or register evidence and stated limitations.
Outside certified scope
Identify project functions, configuration, interfaces and dependencies that still require engineering or verification.
Evidence after change
Clarify required position after updates, substitutions, recertification or product withdrawal.
Use the CSI O-PAS Conformance Certification Tracker to verify dated product evidence against authoritative records.
05 · IEC 61131 application scope
Clarify what “migration” and “portability” mean in this bid
| Question | Bid consequence |
|---|---|
| Which IEC 61131 applications are new, reused, converted, re-engineered, replaced or retired? | Establishes application quantities and engineering method. |
| Who provides authoritative source, libraries, documentation and legacy functional evidence? | Defines owner dependencies and discovery risk. |
| Which runtime environments and application allocations are assumed? | Defines deployment, toolchain and test scope. |
| What constitutes acceptable functional equivalence? | Defines expected results, regression and owner acceptance. |
| Is portability a source-handover requirement, a redeployment demonstration or a migration requirement? | Prevents a broad word from becoming unlimited application scope. |
Use the O-PAS Application Portability Guide to define source, runtime, dependency and verification positions.
06 · Interface ownership
Clarify both sides of every boundary
A bidder cannot price an interface responsibly if the provider, consumer, information definition, configuration responsibility, test method or correction owner is unknown.
Who defines it?
Name authority for information, commands, states, quality, diagnostics and failure behavior.
Who provides each side?
Identify products, retained systems and supplier deliverables.
Who implements it?
Assign mapping, security, application and configuration work.
Who proves it?
Define environment, scenarios, expected results and witnesses.
Who fixes failure?
Assign diagnosis, supplier coordination, remediation and retest.
Who closes it?
Name authority for evidence, deviations and final boundary acceptance.
“Interface by others” needs another named party
State exactly what that party must provide, when it is required and what happens commercially if it is late or incomplete.
Use the Interface Definition and Boundary Management Guide →07 · Integration responsibility
Clarify who owns the assembled system
Multi-vendor delivery needs an accountable integration function even when product responsibilities remain distributed.
| Activity | Clarification |
|---|---|
| Architecture authority | Who approves integrated design decisions and supplier boundary changes? |
| Integration environment | Who supplies, operates, funds and schedules the representative environment? |
| Supplier coordination | Who directs cross-supplier diagnosis and correction? |
| Baseline control | Who owns integrated releases, versions, configurations and evidence? |
| Failed interoperability | Who resolves it, who pays for correction and which retest closes the issue? |
Use the O-PAS Responsibility Matrix to convert answers into explicit contractual allocation.
08 · Verification and acceptance
Clarify the evidence required to get paid and close the project
| Evidence layer | Clarification required |
|---|---|
| Product conformance | Which exact evidence must be submitted for each product and version? |
| System interoperability | Which boundaries, functions, failures, configurations and supplier combinations must be tested together? |
| Project acceptance | Which FAT, SAT, performance, cybersecurity, recovery, resilience and lifecycle demonstrations define contractual completion? |
| Correction | How many correction cycles are included, who pays and what triggers change? |
| Exceptions | Who may accept deviations and what evidence is required for closure? |
Use the O-PAS FAT and Interoperability Testing Guide to define the integrated evidence basis.
09 · Lifecycle and handover
Clarify what must exist after the project team leaves
Engineering assets
IEC 61131 source, libraries, configurations, build and deployment assets.
System-management assets
Inventory, monitoring, backup, restore, update and recovery procedures.
Supplier model
Contacts, response, escalation, correction, spares and support periods.
Lifecycle change
Component substitution, obsolescence notice and qualification obligations.
Accepted baseline
Requirements, tests, defects, deviations, versions and approvals.
Owner control
Access, licenses, credentials, documentation and use rights required for operation.
10 · Commercial treatment
Connect each unresolved technical issue to its price and schedule treatment
| Status | Bid treatment |
|---|---|
| Resolved clarification | Incorporate the response into the estimate, schedule and technical proposal. |
| Unresolved but bounded | State assumption and price basis; use allowance or unit rate where appropriate. |
| Unresolved and material | Use provisional treatment, owner dependency or explicit qualification rather than hidden contingency. |
| Requirement not accepted | State a technical exception and proposed alternative clearly. |
| Owner information required | Name the deliverable, required date and cost/schedule consequence of late information. |
Use the O-PAS Project Estimating Guide to carry these positions into quantities, allowances, schedule and contingency.
11 · Register structure
Make every bid position traceable
| Field | Purpose |
|---|---|
| ID and source | Unique identifier plus specification section, drawing, data sheet or owner response. |
| Requirement | Quote or concise paraphrase of the requirement being addressed. |
| Issue type | Clarification, assumption, technical exception, commercial qualification or dependency. |
| Bid position | Exact question, assumed basis, exception or proposed alternative. |
| Cost/schedule effect | Estimate account, allowance, risk, milestone or dependency affected. |
| Owner response | Dated response and authority. |
| Disposition | Proposal revision, contract incorporation, open item or superseded position. |
12 · Bid gate
Review the O-PAS positions before submission
Requirements reviewed
Every material O-PAS requirement has an owner, interpretation and evidence basis.
Architecture basis stated
Component roles, retained systems, supplier assumptions and lifecycle boundaries are visible.
Applications classified
IEC 61131 new-build, migration, portability and retirement scope is quantified.
Interfaces assigned
Definition, supply, configuration, test, correction and acceptance ownership is stated.
Acceptance separated
Product conformance, system interoperability and project acceptance are not conflated.
Commercial treatment aligned
Each unresolved item has a visible assumption, allowance, dependency, exception or exclusion.
Contract path defined
Clarifications and negotiated positions have a mechanism for incorporation into the final contract basis.
Final bid question: could a project manager six months after award reconstruct exactly what the EPC priced, what the owner clarified, what remained assumed and what was explicitly excepted? If not, the register is not complete.
13 · Connected guidance
Connect bid positions to the complete EPC decision chain
RFQ
Procurement Specification
Identify the requirements the owner should define before bids arrive.
EstimateProject Estimating
Carry clarified positions into quantities, schedule and commercial exposure.
ResponsibilityResponsibility Matrix
Assign architecture, integration, verification and lifecycle accountability.
InterfacesBoundary Management
Define what crosses supplier and system boundaries.
AcceptanceFAT and Interoperability
Define evidence, correction and retest obligations.
EPCO-PAS for EPCs
Connect bid strategy to the complete execution model.
Frequently asked questions
O-PAS bid clarification and exception questions
What is the difference between a clarification, assumption and technical exception?
A clarification asks the owner to define an ambiguous requirement. An assumption states the basis the bidder used when an issue remains unresolved. A technical exception identifies a requirement the bidder does not accept as written and should normally state the proposed alternative.
Should an EPC accept a requirement for “O-PAS compliance” without clarification?
Not as a complete technical scope. Clarify the applicable O-PAS basis, exact product evidence, architecture roles, project integration requirements and acceptance evidence expected.
How should interoperability be clarified in an O-PAS bid?
Identify the products and interfaces that must operate together, required information and behavior, configuration, failure and restoration conditions, test environment, expected results, correction responsibility and acceptance authority.
How should application portability be treated in a bid?
Define the IEC 61131 applications in scope, source and library assets, runtime basis, deployment expectations and the specific demonstration or migration outcome the owner expects.
Does product conformance eliminate the need for technical exceptions?
No. Product conformance evidence addresses the evaluated product scope. The project may still contain requirements, interfaces, configurations, dependencies and acceptance conditions outside that scope.
How does CSI support EPC bid clarification?
CSI helps EPC teams interpret O-PAS requirements, define architecture and supplier boundaries, structure clarifications and assumptions, identify technical exceptions, assign integration responsibility and connect bid positions to estimating and acceptance scope.
Before ambiguous O-PAS language becomes fixed-price scope
Make every material bid assumption explicit
CSI can help EPC proposal and controls teams review owner requirements, build clarification and exception registers, define integration boundaries and align technical positions with the estimate.
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 bid and project-planning aid and does not imply endorsement by The Open Group. The applicable owner specification, bid documents, clarifications, negotiated contract, current O-PAS Standard and current certification records govern the project.