A tender_version_delta_register is a reviewed comparison between two identified procurement package states. It preserves each issued artifact, its source and representation evidence, then records file, structure and content changes with old and new anchors, change type, verification state, affected scope, likely response surface, named reviewer, downstream route and expiry. It reports what changed in the declared boundary. It does not decide whether a change is legally substantial or silently rewrite the response.
A buyer posts a revised pack containing twenty files and a note that says only “documents updated.” The team runs a PDF comparison, sees hundreds of line shifts and assumes most are formatting. A new insurance value sits in a table, a pricing formula changed inside a workbook, one question moved to a portal field and the deadline appears only in the notice. A raw diff gives too much noise and still misses the changes that can damage a bid. The team needs a traceable answer to a narrower question: which propositions and response surfaces differ between the two versions that were actually issued?
Prove identity and lineage before comparing content. Preserve the original bytes, source location, retrieval evidence and declared package boundary for both states. Compare the package inventory first, then native structure, then atomic content. A changed hash proves byte inequality, not a changed requirement. Matching extracted text does not prove that formulas, fields or layout stayed equal. Classify operational response effect separately from legal materiality, and let each specialist process decide the meaning of its own routed change.
Boundary
Compare two controlled states, not two convenient filenames
A version comparison begins with two identified procurement states. Record the procedure, stage, lot scope, intended supplier audience, official source, publication or issue evidence, retrieval time and every object inside the declared boundary. Label the earlier state A and the later state B only after the buyer's publication chain, amendment notice, message or package history supports that order. A filename ending in FINAL-v3 is not lineage evidence.
AN-024 should already have established whether the amendment chain is complete through a checked time. AN-078 consumes two accepted states from that chain. It does not decide that a portal download is the latest pack, fill a missing amendment number or infer that two similar files belong to the same procurement. If lineage is unresolved, return lineage_unresolved and preserve both candidates for the source process.
Define the unit of comparison. It may be the full tender pack, the technical volume for Lot 2, a pricing workbook, a Q&A export or an authorized portal form. A file-level comparison cannot support “nothing else changed in the RFP.” State included objects, excluded objects, unavailable surfaces and the time of observation. The result is only complete for that boundary.
Keep issued artifacts apart from working copies. A converted PDF, extracted text file, OCR layer or parsed spreadsheet is a derived representation used for comparison. Store the tool and version that created it, but never let it replace the original. W3C PROV-DM provides a useful model for entities, activities and revisions; using that vocabulary as a design reference does not make the register PROV-conformant.
| Field | State A | State B | Why it matters |
|---|---|---|---|
| Buyer object | Issued title and identifier | Issued title and identifier | Prevents cross-object comparison |
| Source evidence | URL, message or notice | URL, message or notice | Proves provenance and order |
| Representation | Media type, size and checksum | Media type, size and checksum | Binds later findings to bytes |
| Scope | Lots, stage and audience | Lots, stage and audience | Prevents false applicability |
| Access | Retrieved, unavailable or partial | Retrieved, unavailable or partial | Bounds completeness |
Inventory
Reconcile the package before opening individual documents
List every object in A and B. Match an object by buyer identifier, explicit replacement relation and content evidence before using a similar filename. Classify package actions as unchanged_exact, changed_bytes, added, removed, renamed, replaced, split, merged, inaccessible or match_unresolved. A document can be renamed without changing bytes. Another can keep its name while its content changes. Those are different events.
A checksum is strong evidence about the representation that was hashed. NIST FIPS 180-4 defines the SHA family used for this purpose. Matching SHA-256 values on the actual bytes give strong evidence of byte equality. Different values prove only that the byte sequences differ. They do not tell the reviewer whether wording, metadata, compression, signatures or embedded previews changed.
HTTP metadata is useful but bounded. RFC 9110 explains that ETags distinguish representations and that Last-Modified is generally a weaker validator. Preserve the URL, content type, content encoding, ETag and Last-Modified value observed at retrieval. Do not use one shared ETag to claim equality across different resources, and do not equate a changed timestamp with a changed tender clause.
A removed file needs review even when its text appears inside a new combined volume. Record the old object, the new target and the evidence for the merge. The same applies when one spreadsheet becomes separate lot workbooks. Package topology can change the expected submission objects even when many cells remain identical, so route that finding to the submission architecture control.
- Preserve the buyer-visible filename exactly, including case and extension.
- Store a collision-resistant checksum for the retrieved bytes, not for a later conversion.
- Record explicit supersedes, replaces or revises evidence when the buyer provides it.
- Keep unmatched objects open rather than forcing a similarity match.
- Route package-shape changes before interpreting any internal text delta.
Method
Use a comparison method that can see the native structure
Start with structural coordinates that exist in the source. For a word-processing file, preserve headings, paragraphs, tables, list identities, content controls, footnotes, headers and embedded objects. For a spreadsheet, compare sheet identity, cells, displayed values, formulas, named ranges, validations, comments, hidden state, protection and print areas. For a fillable PDF, inspect visible text and form fields. For a portal form, capture the permitted field labels, options, constraints and observed version state.
Office Open XML packages contain separate parts and relationships, as specified by ECMA-376. That structure explains why a binary diff of two DOCX or XLSX archives produces little editorial meaning. It also explains why comparing only visible paragraphs or calculated cell values is insufficient. A changed formula can produce the same displayed value today and a different value when quantities change.
PDF comparison needs two views. Compare the rendered pages because position, labels, boxes and instructions can matter. Compare recoverable text and objects because visual inspection can miss a one-character value. If either PDF is scanned, bind the OCR output to its exact source bytes, language, engine and page, then verify every material candidate against the image. OCR confidence is not procurement confidence.
Use stable source anchors on both sides. A visible locator might be “Schedule 3, table 4, row Insurance limit.” A machine locator might be a document part plus paragraph identity, sheet and cell, PDF page plus text quote, or portal field identifier tied to an observation. W3C Web Annotation selectors are a useful design reference for text quotes, positions and resource states. Store enough surrounding text to recover the target after renumbering.
| Surface | Compare | Common blind spot |
|---|---|---|
| DOCX | Structure, text, tables, controls and notes | Accepted revisions or header changes |
| XLSX | Sheets, formulas, values, validations and hidden state | Same displayed value from a new formula |
| Rendered pages, text, objects and fields | OCR noise or changed form behavior | |
| Archive | Members, paths, sizes, hashes and relationships | Renamed or split objects |
| Portal | Labels, options, limits and observed state | Uncaptured access-gated fields |
Verification
A candidate delta becomes a change only after source verification
Diff engines nominate candidates. A reviewer or deterministic native check confirms them. Store old_value, new_value, old_locator, new_locator, comparison_method and verification_evidence. Use added, removed, value_changed, condition_changed, scope_changed, moved, renumbered, reformatted, representation_only and unresolved. Do not pair two passages merely because their words are similar.
Movement and rewriting require separate tests. If a requirement keeps its meaning but moves from section 5.2 to Schedule A, record moved with both anchors. If its threshold also changes, create a linked value_changed record. If the old sentence disappears and a different provision appears elsewhere, preserve deletion and addition until a reviewer proves a replacement relation. This prevents a semantic matching model from hiding a withdrawal.
Derived text may normalize ligatures, Unicode forms, whitespace, page headers and line breaks to improve candidate matching. Keep every normalization rule with the comparison run and preserve raw strings beside normalized strings. Unicode Standard Annex #15 explains normalization forms, but normalization does not authorize changing buyer text or treating visually similar characters as identical.
Return representation_noise_confirmed when source verification shows that only extraction or rendering changed. Return semantic_review_required when the words changed but meaning cannot be classified deterministically. Use unreadable_region for a page, object or cell range that cannot be inspected. A zero-candidate run with an unreadable appendix is not no_change_confirmed.
| State | Meaning | Allowed use |
|---|---|---|
| verified_change | Both source representations prove the delta | Route for effect review |
| verified_move | Same content has a proved new location | Update citations |
| representation_noise_confirmed | Native source does not contain the apparent edit | Exclude with evidence |
| semantic_review_required | Source wording differs; effect is unresolved | Send to named reviewer |
| unreadable_region | Part of either source cannot be inspected | Block the affected scope |
| lineage_unresolved | The pair or order is not proved | Return to source verification |
Routing
Classify response effect without pretending to decide legal materiality
The word material has several meanings. A buyer may use it informally. Procurement law may attach a jurisdiction-specific test to a significant or substantial modification. A bid team may call any change that affects work “material.” AN-078 uses response_effect to describe operational consequences and preserves the buyer's wording separately. It never issues a legal_materiality conclusion.
Regime sources show why that restraint matters. UK Procurement Act 2023 section 31 defines when a covered procurement may be modified and includes a specific substantial-modification test. Section 54 and current Cabinet Office guidance address time limits after changes. EU Directive 2014/24/EU Article 47, German VgV section 20 and French Code article R2151-4 address deadline extensions for significant or important changes in their own settings. The bidder-side register can flag those review questions, but only the qualified authority decides their legal effect.
Other regimes use their own amendment mechanics. FAR 15.206 requires a solicitation amendment when the US Government changes requirements or terms and lists the minimum amendment information, while FAR 52.215-1 addresses acknowledgment and proposal modifications when that provision is incorporated. The World Bank's September 2025 Procurement Regulations require an addendum when a complaint review leads the borrower to modify request documents and a deadline extension when necessary. Preserve the applicable source and never transfer one regime's consequence to another.
Route a verified delta by its object. Obligation language goes to AN-069 or AN-070. Answer limits go to AN-071. File and envelope changes go to AN-072. Date assertions go to AN-073 and AN-075. Template dependencies go to AN-074. Evaluation rules go to AN-076. Gates go to AN-077. Conflicts go to AN-061 or AN-062. AN-066 owns the controlled propagation into live answers, prices, approvals and production artifacts.
Assign one of no_response_effect_confirmed, citation_update_only, response_review_required, price_review_required, evidence_review_required, schedule_review_required, submission_structure_review_required, qualification_review_required or effect_unresolved. The label starts work; it does not finish the specialist decision. Record the affected lot, question, cell, file or approval and the named owner who accepts the route.
- Preserve the buyer's own change description without treating it as exhaustive.
- Separate detected wording change from reviewed response effect.
- Separate operational priority from legal significance.
- Name the exact downstream object and control owner.
- Reopen affected work through AN-066 instead of editing it inside the diff process.
Worked example
A five-file revision produces four different kinds of work
Consider a fictional procurement for a national rail operator's station asset platform. Package A contains instructions, technical requirements, a pricing workbook, a security questionnaire and contract terms. Package B keeps all five filenames. The portal note says “minor clarifications.” Hashes differ for four files. The security questionnaire is byte-identical.
Native comparison shows that the instructions contain only a regenerated table of contents and a new submission date. The technical volume raises offline operation from four to twelve hours and moves the audit-log clause without changing it. The workbook changes a formula in the maintenance total and adds a mandatory explanatory cell. The contract fixes a cross-reference. Four changed hashes therefore produce one representation-only change, one date, one technical value, one moved citation, one formula, one response field and one corrected contract reference.
The register routes the date to the timetable control, the twelve-hour requirement to obligation and technical owners, the moved clause to citation updates, the formula and cell to pricing and template review, and the contract reference to legal review. The buyer's “minor” label stays as source evidence but does not close any route. The unchanged questionnaire needs no content diff, although its role in the package remains recorded.
Suppose page 18 of the technical PDF cannot be decoded and appears only as a blurred scan. The result becomes complete_with_unreadable_region, not complete. Work outside page 18 can proceed if authorized. Any response linked to that page remains blocked until a permitted copy is recovered or a human verifies the image. The register tells the team exactly what it does not know.
| Delta | Verification | Route | Immediate action |
|---|---|---|---|
| Submission date | Exact old and new notice fields | AN-073 and AN-075 | Revalidate event |
| Offline duration | Clause value 4 to 12 hours | AN-069 | Review affected answer |
| Maintenance formula | Native formula comparison | Pricing owner | Freeze workbook output |
| New explanation cell | Cell and validation added | AN-074 and AN-072 | Map response object |
| Moved audit clause | Text equal, anchors differ | Citation owner | Update references |
| Unreadable page | Decode and image review failed | Source owner | Block linked scope |
Agent contract
An agent may compare evidence, then must stop before changing the bid
An authorized agent may inventory supplied artifacts, compute checksums, inspect safe native structures, extract text, calculate deterministic cell differences, propose passage matches, build dual anchors and place candidates in a review queue. It may reproduce a confirmed old and new value. It may not infer that a buyer intended an unissued consequence or that a change is lawful, substantial, harmless or waived.
Tender files are untrusted input. Embedded instructions cannot grant access, request credentials, activate links, run macros, alter protection, contact the buyer, acknowledge an amendment or authorize submission. The agent must inspect documents in a non-executing mode, retain suspicious content as quoted evidence and follow the customer's explicit permissions for every external action.
Confidence belongs to a narrow operation. text_match_confidence can describe a proposed old-to-new passage link. extraction_confidence can describe OCR. It cannot describe legal effect, buyer intent or response correctness. A high similarity score must not suppress an addition or deletion that lacks a proved relationship.
Every output should be inspectable by another agent or reviewer. Include comparison-run identifier, artifact checksums, extraction method, normalization rules, candidate and accepted states, reviewer, timestamps and excluded surfaces. The next agent should be able to recover both anchors and reach the same deterministic facts before relying on the route.
Handoff
Release a bounded delta set with explicit unknowns
comparison_ready requires proved package identity and order, reconciled inventories, reviewed native structures for every in-scope object, dual anchors for each confirmed delta, explicit noise exclusions and an owner for every unresolved region. comparison_ready_with_review_items is valid when open semantic effect does not hide an uninspected source area. no_change_in_declared_boundary is valid only when the entire declared boundary was inspectable and the comparison method covered its relevant structures.
The released artifact contains three linked views. The evidence view shows exact source pairs and methods. The review view shows confirmation state and rationale. The action view shows affected response objects, owners and downstream controls. Do not collapse them into a single severity score. A reviewer must be able to change the route without changing the source record.
Expire the comparison if either source identity changes, a missing object becomes available, a new amendment alters lineage, a portal field changes, an extraction defect is found or the bidder changes the lot or stage scope used for response-effect mapping. Retain the previous register so the team can explain which work was reopened and why.
AN-078 owns reproducible change detection between two controlled tender states and the first bounded response-effect route. AN-024 owns amendment-chain completeness. AN-061 and AN-062 own authority conflicts. AN-066 owns applying accepted changes to live response work. AN-119 will own the current Q&A baseline across several versions, and AN-230 will own alignment of all internal drafts to one approved baseline.
What good looks like
Useful outcomes from compare changes between RFP versions
- Both package states are recoverable from source records and cannot be confused with local working copies.
- Added, removed, replaced, renamed and unchanged files are accounted for before clause comparison begins.
- Every verified content delta retains an old anchor, a new anchor and the exact before and after values.
- Conversion, OCR, pagination and generated-metadata noise remain visible without entering the response plan as buyer changes.
- Dates, obligations, gates, evaluation rules, response constraints and submission objects are routed to their named controls.
- Each affected answer, price cell, evidence item or approval has an owner without AN-078 editing it automatically.
- Unmatched or unreadable regions block only the scope whose comparison cannot be proved.
- An agent can repeat the comparison and cite its evidence without deciding legal effect or taking an external action.
Operating model
How to run the work
- 01
Freeze the comparison pair
Name the procurement, stage, lots, audience, earlier package, later package, authorized sources, retrieval times and comparison purpose.
- 02
Prove artifacts and lineage
Store issued filenames, identifiers, media types, sizes, checksums, source URLs and the evidence that the buyer linked or replaced each version.
- 03
Compare the package inventory
Account for every added, removed, replaced, renamed, split, merged and byte-identical object before looking inside files.
- 04
Compare native structures
Inspect headings, clauses, tables, fields, sheets, cells, formulas, validations, comments, attachments and portal controls using format-appropriate methods.
- 05
Verify atomic content deltas
Pair the old and new source locations, preserve exact values and distinguish content edits from extraction or rendering noise.
- 06
Classify and route response effect
Assign the affected scope, response surface, review owner and specialist control without inventing legal significance or buyer intent.
- 07
Release the reviewed delta set
Publish confirmed changes, bounded unknowns, exclusions and downstream handoffs, then expire the result when either package identity changes.
Evaluation
Questions that change the decision
- Are these two artifacts buyer-issued states of the same procurement object, and what proves their order?
- Does the comparison cover the full pack, one file, one lot or one response surface?
- Which files were added, removed, replaced, renamed, split, merged or left byte-identical?
- Is a detected difference present in the native source or only in an OCR, conversion or rendered view?
- What exact old and new values changed, and can both be recovered from durable locators?
- Does the change affect a requirement, date, gate, score, template, price basis, evidence item or submission object?
- Which existing dossier owns the interpretation and downstream response update?
- What unreviewed region prevents a complete comparison claim, and which work can still proceed?
- What new package, amendment or source event will make this comparison stale?
Failure modes
Where teams lose control
A local file with a newer timestamp is treated as the buyer's successor version without lineage evidence.
A changed checksum is reported as a changed requirement even though only metadata or compression differs.
Identical extracted prose hides a changed spreadsheet formula, field validation, embedded object or page instruction.
OCR spelling changes and PDF line wrapping generate hundreds of false content deltas.
A deleted clause is paired with the nearest new paragraph and misreported as a rewrite.
A moved or renumbered requirement is counted as both a deletion and an addition.
The diff labels a change legally material without applying the procurement's governing rule and decision authority.
A confirmed source delta is allowed to alter a live answer, price or submission package without review.
An unread sheet, hidden row or access-gated portal field disappears from the comparison boundary.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- package objects accounted for in both controlled inventories
- artifacts with source identity, media type, size, checksum and retrieval evidence
- candidate differences confirmed against both native representations
- verified deltas with exact old and new anchors and values
- representation-noise candidates excluded with a recorded reason
- unmatched or unreadable regions carrying an owner and bounded scope
- confirmed deltas routed to the correct response, compliance, pricing or timetable owner
- downstream artifacts reviewed or reopened through AN-066 rather than changed by the diff
- repeat comparisons that reproduce the same reviewed delta set
Questions
Common questions
Does a changed checksum prove that a requirement changed?
No. It proves that the hashed bytes differ. Verify native content to distinguish wording, formulas, metadata, compression and signatures.
Can the buyer's change summary replace a full comparison?
No. Preserve it as source evidence, then reconcile the actual package and content. The summary may be scoped or incomplete.
Is a Word tracked-changes view enough?
No. It may help, but compare the issued files, tables, headers, controls, notes and package structure. Revisions may have been accepted before issue.
What if the extracted text is identical?
Inspect native formulas, fields, layout, validations, embedded objects and package membership before claiming no relevant change.
May the register call a modification legally substantial?
No. It records the verified change and routes the jurisdiction-specific question to qualified review with the governing source.
How should moved text be recorded?
Preserve both anchors and prove content identity. Record any simultaneous wording change as a separate linked delta.
Can response work continue with an unreadable appendix?
Only for an explicitly authorized independent scope. Block every answer, price, gate and submission object that may depend on the unread region.
What may an AI agent do with the result?
It may cite verified deltas, identify affected objects and propose controlled handoffs. It may not edit, approve, acknowledge or submit the bid without separate authority.
Sources
Primary references
- Guidance: Modifying a Competitive Procurement, updated 17 August 2026 UK Cabinet Office
- Procurement Act 2023, section 31 The National Archives
- Procurement Act 2023, section 54 The National Archives
- Directive 2014/24/EU, Article 47, consolidated 1 January 2026 EUR-Lex
- German Public Procurement Ordinance, section 20 German Federal Ministry of Justice and Federal Office of Justice
- French Public Procurement Code, Article R2151-4 Légifrance
- FAR 15.206, Amending the solicitation Acquisition.gov
- FAR 52.215-1, Instructions to Offerors Acquisition.gov
- Procurement Regulations for IPF Borrowers, seventh edition, September 2025 World Bank
- RFC 9110, HTTP Semantics, representation validators RFC Editor
- Web Annotation Data Model, selectors and states World Wide Web Consortium
- PROV-DM, entities, derivations and revisions World Wide Web Consortium
- FIPS PUB 180-4, Secure Hash Standard National Institute of Standards and Technology
- ECMA-376, Office Open XML file formats Ecma International
- Unicode Standard Annex 15, Unicode Normalization Forms Unicode Consortium
Ziva
Proposal software for source-grounded RFP, RFI, DDQ and questionnaire response work.
Bid, proposal, presales, security and compliance teams. Start with the workflow, constraints and evidence you already have.