When a complex asset is delivered, the contract often focuses on the asset itself. The engineering information needed to operate, maintain, and support that asset throughout its life is treated as a secondary deliverable.
That creates a serious handover problem.
Operators may receive product data late, in inconsistent formats, without clear ownership, or with insufficient detail to validate its completeness and usability. Suppliers may believe they have met the requirement. The operator may discover too late that the data does not support maintenance planning, configuration control, support solution development or future modification.
The issue is rarely a lack of data. It is a lack of precise, measurable and enforceable requirements for that data.
Contracting for engineering information means defining what information must be delivered, when it is needed, which standards and semantics apply, how quality will be measured, and what usage rights govern access across the asset lifecycle.
The data problem in complex asset handover
At Eurostep, we have developed ShareAspace to consolidate engineering data from diverse systems and maintain a digital thread of product information. The goal is to support complex assets such as ships, submarines, power-generation equipment, vehicles, and industrial systems from design through operation and sustainment.
That product information is rarely created in one place.
It is authored across multiple engineering tools, supplier systems, maintenance environments and enterprise applications. Different organisations own different parts of the product definition. Each has its own processes, formats, access controls and assumptions about what “complete” means.
The technical challenge is significant. Data must be integrated, mapped, validated and kept under control as the asset changes. The commercial challenge is just as important. The contract must make clear what information is required, who owns it, who may use it, how it will be delivered, and how its quality will be checked.
If those points are not defined early, the handover becomes a negotiation after the fact. That is when delays, disputes and expensive rework appear.
Why vague information clauses fail
Many contracts include broad statements such as:
“All product data must be delivered in accordance with ISO 10303-239, S3000L, or other relevant standards.“
This may sound reasonable, but it is often too vague to be enforceable in practice.
A standard can provide structure, terminology and exchange rules. It does not automatically define the exact business context, the required level of detail, the reference data to use, the validation rules, or the point in the lifecycle at which the information must be available.
For a complex asset programme, that lack of specificity can lead to serious consequences:
- The operator receives information that is technically compliant but operationally incomplete.
- Suppliers interpret the same requirement differently.
- Data arrives without enough context to validate or reuse it.
- Intellectual property and usage rights remain unclear.
- Maintenance, support and modification teams cannot rely on the delivered baseline.
- Configuration changes become harder to trace across organisations.
The contract needs to describe the information outcome, not just name a standard.
Questions to answer before contracting for data
Before placing engineering information requirements into a contract, the programme needs clear answers to several practical questions.
- Scope and specificity
– Does the contract clearly define the scope of data requested? - Intellectual property
– Does the contract express who owns the Intellectual Property of the data and the conditions of use? - Semantic clarity
– Are the semantics within the standard clear and unambiguous, ensuring that all parties share the same understanding? - Reference data
– Does the standard explicitly mandate the necessary reference data, such as quantities, units, and part properties? - Validation and format
– Is there a specified data exchange format against which the data can be validated?
A SMART framework for contracting information
A practical way to improve information requirements is to treat them like engineered requirements. They need to be specific enough to guide delivery, measurable enough to support acceptance, and clear enough to survive handover between organisations.
Inspired by SMART goals in requirements management, we coined a SMART framework for contracting engineering information. It helps turn broad data expectations into requirements that are clear enough to deliver, measure and validate.
S: Semantics
The contract should define the meaning of the requested information.
This includes the terminology, relationships, classifications, attributes and reference data used to describe the asset. Without semantic clarity, one organisation may deliver data that appears complete while another cannot use it without manual interpretation.
For example, a requirement for “part information” may not be enough. The contract may need to define whether that includes part identifiers, version information, supplier references, material properties, effectivity, approved alternatives, installation context, maintenance relevance and links to supporting documentation.
Shared meaning is the basis for reliable exchange.
M: Measurable
Information requirements should include measurable quality criteria.
If the contract states that data must be “complete” or “accurate”, it must also define how completeness and accuracy will be assessed. That may include mandatory attributes, validation rules, format checks, relationship checks, approval states and defined error thresholds.
Measurable requirements allow both parties to identify whether the data is acceptable. They also reduce the risk of subjective disputes late in the programme.
Examples may include:
- Mandatory fields for specific object types
- Required relationships between parts, documents and configurations
- Validation against agreed reference data
- Acceptance checks for units, classifications and identifiers
- Rules for revision, status and effectivity
- Defined reporting of missing or inconsistent data
The more critical the asset and support environment, the less room there is for informal interpretation.
A: Accurate
The information requirement should specify the level of precision needed for the intended use.
Accuracy is not only about whether a value is correct. It is also about whether the information is suitable for the task it supports. Data used for maintenance planning, operational support, modification work or safety-related analysis may need different levels of detail and assurance.
A contract should therefore define the required level of accuracy for the business process. It should also make clear which source is authoritative when information exists in multiple systems.
For complex assets, this matters because the same item of product information may be reused across design, manufacturing, support, operations and disposal. If the baseline is uncertain, downstream decisions become weaker.
R: Reasoned
Information requirements should have a clear rationale.
Every data requirement has a cost. Suppliers need to know why specific information is being requested, how it will be used, and what risk it helps control. Without that rationale, data delivery can become a box-ticking exercise.
A reasoned requirement connects the information to a practical outcome, such as:
- Maintaining the asset safely
- Supporting configuration control
- Enabling future modification
- Improving spares planning
- Validating supplier deliverables
- Improving support solution development
- Reducing manual reconciliation during handover
This helps all parties focus on information that has operational value.
T: Timely
The contract should define when data is required and how its maturity changes over time.
Even accurate information loses value if it arrives too late. Some information may be needed early to support planning and analysis. Other information may only be valid after design approval, manufacture, test or installation.
A timely requirement should include both delivery milestones and update obligations. Complex assets change continuously, so the contract must also define how changes will be communicated, approved and reflected in the controlled information baseline.
This is especially important where multiple suppliers contribute to the same product structure or support environment.
From contractual requirement to validated engineering data
The purpose of contracting for engineering information is not to create heavier documentation. It is to make sure the delivered data can be trusted and used.
A strong information requirement should make it possible to answer questions such as:
- What information has been delivered?
- Which asset, system or configuration does it describe?
- Which version or baseline is authoritative?
- Who supplied it?
- What changed since the last delivery?
- Has it passed the agreed validation checks?
- Who is allowed to access and use it?
- Is it ready for operational, maintenance or support use?
These questions are difficult to answer if information is exchanged through unmanaged files, emails and spreadsheets. They require governance, traceability and controlled access across the extended enterprise.
How ShareAspace supports governed information delivery
ShareAspace helps teams turn contractual information requirements into controlled, repeatable data deliveries across primes, suppliers, partners and operators.
It supports the definition, acquisition, validation and reuse of structured engineering and product support information, keeping data connected to the right configuration, lifecycle stage and access rules.
For defence and complex asset programmes, this creates a clearer path from contractual requirement to trusted support data.
Explore our ShareAspace IPS capabilities or see how Eurostep supports contracting for information, data assurance and governed collaboration.
Driving up data quality through better information requirements
Complex asset programmes cannot rely on vague handover language. They need contractual requirements that define the data to be delivered, the meaning of that data, the quality checks it must pass, and the rights that govern its use.
You need more than a reference to a standard. You need precise, measurable, and operationally grounded information requirements.
By applying a SMART approach to contracting for engineering information, asset owners, operators and suppliers can reduce ambiguity, improve data quality and create a stronger foundation for through-life support.
The result is not simply better data at handover. It is a more reliable information baseline for the decisions that follow: maintenance, modification, support, compliance and long-term asset availability.