Revision, addendum or clarification answer?
Changes to a tender arrive in three main forms. Treat all three as changes to the requirements until you have checked them.
| What arrives | What it usually is | What to do |
|---|---|---|
| New revision of a document | A full reissue, for example Rev B of the project specification or datasheet | Compare it with the revision you bid against, clause by clause |
| Addendum | A separate document that adds, deletes or changes parts of the tender | Apply each item to the clauses it names, and check the tender's order of precedence for addenda |
| Clarification answers | The buyer's replies to bidder questions, often sent to all bidders | Check whether each answer changes a requirement; if it does, treat it like an addendum |
See governing-document precedence for how tenders rank addenda and later revisions.
Step 1: Log what arrived
- Record the document number, new revision, date and the revision it replaces.
- Check the tender instructions: do you need to acknowledge the addendum in your offer?
- Check whether the bid deadline or the clarification deadline has moved.
- Update the list of governing documents on your compliance matrix or deviation list cover sheet.
- Keep the old revision. You will need it to compare and to show what your earlier answers were based on.
Step 2: Compare the revisions
Revision clouds, triangles and change logs help, but they are not always complete. Compare the full text of the old and new revision. Word and PDF compare tools do this for text. For datasheets and tables, compare line by line, because a changed value in a table cell is easy to miss.
Sort what you find into four groups: added requirements, changed requirements, deleted requirements and no change. Note the clause number and page in the new revision for each one. Never assume an unchanged clause number means unchanged text: clauses get renumbered, and text changes under the same number.
Step 3: Recheck the affected requirements
Recheck every added and changed requirement against your current datasheets, as you did for the first revision. Then look for knock-on effects. One change can affect several rows.
Example (invented)
Rev B of a ball valve datasheet raises the design temperature. That one change can affect the pressure–temperature rating of the body, the seat material and the soft goods, the test conditions and the cost. A diff shows one changed line; the recheck has to cover all the rows that depend on it.
Also check for a changed standard edition. If the new revision calls up a newer edition of API 6D or ISO 15848-1, rows that were "complies" may need a fresh look.
Step 4: Update the compliance matrix and deviation list
- Add rows for new requirements and mark deleted ones as deleted, rather than removing them.
- Withdraw deviations and clarifications that the change has closed, and say why.
- Add new deviations the change has created, with justification and cost of withdrawal.
- Keep row numbers stable, so the buyer can match the new list to the old one.
- Note the spec revision each row was checked against.
- Pass any change in cost or delivery to the commercial team.
Reissue the technical deviation list with a new revision rather than answering only by email. Our free deviation list template and compliance matrix template have revision fields ready.
Step 5: Keep version control on your offer
- Give each issued offer, compliance matrix and deviation list its own revision number and date.
- Keep a simple register: which offer revision answers which spec revision and addendum.
- Save each issued version as read-only. Make changes only in a new revision.
- Use one file-naming pattern for the whole bid, including the document number and revision.
- Hand the final, agreed revision to the project team with the order.
Can we reuse past answers?
Yes, as a starting point. Keep a library of approved answers and standard deviations, each with its source and date. Recheck each one against the current datasheet and spec revision before you send it. An answer that was right for one edition of a standard can be wrong for the next.
How do we stay consistent across bids?
Use one template, one list of statuses and one set of standard wording across all bids. Store approved deviations and clarifications in one place, with their dates. Spot-check a sample of rows from each project against the source. The same clause and product should get the same answer, unless a datasheet or edition has changed.
Common traps
- Rechecking only the clouded clauses and missing an unmarked change.
- Updating the compliance matrix but not the deviation list, so the two disagree.
- Missing a clarification answer that changes a requirement, because it came by email.
- Sending an offer that still names the old revision on its cover sheet.
- Losing track of which deviations the buyer already accepted or rejected.
What OdysseyGPT does with a revised package today
Current limit
OdysseyGPT cannot yet re-run an outdated review on a new revision, and it does not carry your engineers' earlier assessments forward from one revision to the next. It also does not show a revision-to-revision diff.
The workaround is manual but simple. Run a fresh Document Review on the revised package with your datasheets. Export the new compliance matrix and deviations & clarifications list. Then compare the two exports side by side, for example by clause reference in Excel, to find the rows whose requirement or status changed. Carry your engineers' earlier decisions across by hand, and recheck each one against the new revision.
Every row in the new review still cites the clause and page in the revision you uploaded, so you can see which revision each finding comes from. Your engineers decide every open item. See OdysseyGPT for manufacturing and the pages for valve and actuator makers.