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.

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.

Minimum identity record for each side of the comparison
FieldState AState BWhy it matters
Buyer objectIssued title and identifierIssued title and identifierPrevents cross-object comparison
Source evidenceURL, message or noticeURL, message or noticeProves provenance and order
RepresentationMedia type, size and checksumMedia type, size and checksumBinds later findings to bytes
ScopeLots, stage and audienceLots, stage and audiencePrevents false applicability
AccessRetrieved, unavailable or partialRetrieved, unavailable or partialBounds completeness

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.

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.

One comparison does not fit every response surface
SurfaceCompareCommon blind spot
DOCXStructure, text, tables, controls and notesAccepted revisions or header changes
XLSXSheets, formulas, values, validations and hidden stateSame displayed value from a new formula
PDFRendered pages, text, objects and fieldsOCR noise or changed form behavior
ArchiveMembers, paths, sizes, hashes and relationshipsRenamed or split objects
PortalLabels, options, limits and observed stateUncaptured access-gated fields

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.

Verification states prevent false certainty
StateMeaningAllowed use
verified_changeBoth source representations prove the deltaRoute for effect review
verified_moveSame content has a proved new locationUpdate citations
representation_noise_confirmedNative source does not contain the apparent editExclude with evidence
semantic_review_requiredSource wording differs; effect is unresolvedSend to named reviewer
unreadable_regionPart of either source cannot be inspectedBlock the affected scope
lineage_unresolvedThe pair or order is not provedReturn to source verification

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.

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.

Example deltas and owners
DeltaVerificationRouteImmediate action
Submission dateExact old and new notice fieldsAN-073 and AN-075Revalidate event
Offline durationClause value 4 to 12 hoursAN-069Review affected answer
Maintenance formulaNative formula comparisonPricing ownerFreeze workbook output
New explanation cellCell and validation addedAN-074 and AN-072Map response object
Moved audit clauseText equal, anchors differCitation ownerUpdate references
Unreadable pageDecode and image review failedSource ownerBlock linked scope

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.

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.

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.

How to run the work

  1. 01

    Freeze the comparison pair

    Name the procurement, stage, lots, audience, earlier package, later package, authorized sources, retrieval times and comparison purpose.

  2. 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.

  3. 03

    Compare the package inventory

    Account for every added, removed, replaced, renamed, split, merged and byte-identical object before looking inside files.

  4. 04

    Compare native structures

    Inspect headings, clauses, tables, fields, sheets, cells, formulas, validations, comments, attachments and portal controls using format-appropriate methods.

  5. 05

    Verify atomic content deltas

    Pair the old and new source locations, preserve exact values and distinguish content edits from extraction or rendering noise.

  6. 06

    Classify and route response effect

    Assign the affected scope, response surface, review owner and specialist control without inventing legal significance or buyer intent.

  7. 07

    Release the reviewed delta set

    Publish confirmed changes, bounded unknowns, exclusions and downstream handoffs, then expire the result when either package identity changes.

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?

Where teams lose control

01

A local file with a newer timestamp is treated as the buyer's successor version without lineage evidence.

02

A changed checksum is reported as a changed requirement even though only metadata or compression differs.

03

Identical extracted prose hides a changed spreadsheet formula, field validation, embedded object or page instruction.

04

OCR spelling changes and PDF line wrapping generate hundreds of false content deltas.

05

A deleted clause is paired with the nearest new paragraph and misreported as a rewrite.

06

A moved or renumbered requirement is counted as both a deletion and an addition.

07

The diff labels a change legally material without applying the procurement's governing rule and decision authority.

08

A confirmed source delta is allowed to alter a live answer, price or submission package without review.

09

An unread sheet, hidden row or access-gated portal field disappears from the comparison boundary.

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

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.

Primary references

Tony Kim

Tony Kim

Founder and CEO

Tony writes about applied AI, dependable product engineering and the systems that turn complex response work into controlled delivery.

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.