Who this guide is for
This guide is for the supplier side: the valve, pump, actuator or instrument maker that has to answer a tender or RFQ. It is not about how a buyer scores bids. For that, see the technical bid evaluation guide.
The output of a good analysis is two documents: a compliance matrix with one row per requirement, and a technical deviation list with the rows you cannot meet as written.
Step 1: List the package and its revisions
Before reading any clause, list every document you received, with its number, revision and date. A typical package has a material requisition (MR), a project specification, datasheets, owner standards, an inspection and test plan (ITP), a vendor data requirements list, drawings and any addenda.
Check the list against the MR's list of referenced documents. If a referenced document is missing, ask for it now. You cannot comply with a document you have not seen.
Step 2: Find the order of precedence
Tender documents often disagree. The order of precedence tells you which one wins. It is usually stated in the requisition, the instructions to bidders or the general conditions. See governing-document precedence.
| Document | What it usually does | What to watch |
|---|---|---|
| Addenda and clarification answers | Change earlier documents | Where the tender ranks them; some rank them first, some do not say |
| Datasheet | States the duty, sizes, ratings and materials for each tag | Conflicts with the general specification on materials or tests |
| Project specification | Sets rules for this project | Clauses that override the owner standard |
| Owner standard (for example ADNOC, Aramco or Shell) | Adds to or tightens industry standards | Extra tests, stricter materials, more certificates |
| Industry standard (for example API 6D or API 610) | Sets the base design and test rules | Which edition the tender calls up |
Owner standards and project specs usually add to industry standards, not replace them. A clause in an owner standard that asks for more than API 6D does not cancel API 6D; it adds a requirement. Where the order is missing or still leaves a conflict, raise a technical query. Do not guess. For Gulf owner rules, see ADNOC, Aramco and Shell valve specs.
Step 3: Confirm the scope of supply
Read the scope of supply next. It decides which clauses apply to you. Note what is in scope (the valve, the actuator, the motor, spares, special tools, documents) and what is by others. A clause about the motor does not apply if the motor is by others, but you should still say so in the matrix.
Step 4: Extract the requirements
Split the document into single, testable statements. Look for "shall", "must" and values with units. Also check tables, notes, footnotes and side clauses, where costly requirements often hide. Give each row its clause number and page. A clause with three requirements becomes three rows.
Keep headings and cross-references apart from real requirements. A line that says "Valves shall comply with Section 7" is a pointer; the requirements are in Section 7. Our free spec requirement extractor does a first pass in your browser. An engineer should still check the result.
What to extract: a checklist
| Category | Examples | Why it matters |
|---|---|---|
| Design and rating | Design pressure and temperature, pressure class, size, ends | The offer must cover the design case |
| Standards and editions | API 6D, API 610, ISO 15848-1, ASME B16.34 | A different edition can change tests or limits |
| Materials | Body, trim, seats, bolting, sour service and hardness limits | Material changes are the most common deviations |
| Tests and inspection | Hydrotest, seat test, fugitive emission test, witness points | Extra and witnessed tests add cost and time |
| Certificates | EN 10204 3.1 or 3.2, PMI, NDE reports | A 3.2 certificate needs a third party |
| Documents | VDRL items, data books, due dates | Late or missing documents can hold payment |
| Painting, marking and packing | Coating system, tagging, export packing | Easy to miss and often priced late |
| Commercial items in the technical spec | Delivery time, warranty, spares | Pass these to the commercial team |
For certificates, see EN 10204 3.1 vs 3.2. For valve tests and fugitive emissions, see API valve standards and ISO 15848-1.
Step 5: Mark which requirements apply to you
Not every line in a tender applies to your scope. Mark each row as a requirement, a reference, a heading or not applicable, and keep a reason for every row you set aside. Check the scope of supply and the order of precedence first, because they decide which documents and clauses govern your equipment.
Step 6: Check each requirement against your datasheet
For each row, find what your product actually offers. Use your current datasheet, catalogue, test procedures and qualification records. Compare values with their units, and convert where needed. Check the edition of every standard: a valve qualified to one edition is not automatically compliant with the next.
Our datasheet vs specification checklist lists the lines to compare one by one.
Step 7: Record a status and the evidence
Give every row one status, such as complies, clarification, deviation or not offered, and add the reference that proves it: the datasheet line, test report or certificate. Rows that are not "complies" become your deviation list. Rows that need an answer from the buyer become clarifications.
Free templates with the columns ready: the compliance matrix template and the technical deviation list template, both as XLSX and CSV.
Step 8: Decide who checks what
Tag each requirement by discipline: mechanical, materials, testing, documents, commercial or quality. Send each group to its owner with a due date and the clause reference, and keep one shared matrix so answers stay consistent. Small teams often have one engineer check the whole spec; in that case, ask a second person to check every deviation and every row about materials, tests and certificates.
How to make sure nothing is missed
Make every source row count. Each line in the spec should end up as a requirement with a status, or be set aside with a reason, such as heading or not applicable. Keep a running count that matches the source document, so a reviewer can see that no page was skipped.
Common traps
- Working from an old revision of the requisition or datasheet.
- Missing requirements in tables, notes and footnotes.
- Treating a cross-reference as covered without reading the clause it points to.
- Assuming the industry standard governs when an owner standard tightens it.
- Quoting a different edition of a standard without saying so.
- Leaving a clause unanswered. Anything not listed as a deviation is usually taken as full compliance.
- Sending clarifications after the deadline, or answering them only by email and not in the offer.
Where OdysseyGPT helps, and where it does not
Document Review checks each customer requirement in the package against your own datasheets. Each requirement gets a status (complies, deviates, clarification, not addressed, document requested, not applicable or out of scope) with a quote from the source page, sheet or cell, and each quote is checked against that source. You get an editable compliance matrix and a deviations & clarifications list. The export also has a Coverage sheet that shows, for each document, the source rows read and what happened to each.
Two related tools are in beta: Customer Specification Review turns a specification into a cited requirements register, and Deviation Register tracks each deviation through to the customer's answer.
OdysseyGPT reads PDF, Word (.docx), Excel (.xlsx, .xls) and CSV files. It does not interpret engineering drawings such as general arrangements or P&IDs, so check those yourself. Your engineers decide every open item and own what goes to the customer. See OdysseyGPT for manufacturing, or the pages for valve and pump makers.