Sorting supplier offers by price is easy. Establishing what those prices refer to is the part that needs a policy.
An offer may use a different unit, specification, delivery condition or validity period. A clean comparison table can conceal those differences if normalization turns them into apparently equivalent rows without recording a judgment.
My public procurement case separates original supplier evidence, normalized working data, a frozen comparison snapshot and a justified human decision. This technical note focuses on the boundary between normalization and equivalence. It does not report a new deployment or a measured purchasing benefit.
Normalization does not grant eligibility
Normalization makes information easier to compare. It can standardize a unit name, preserve the quoted quantity and expose a delivery term in a consistent field.
Equivalence asks a different question: does this offer satisfy the approved need under the comparison policy?
A unit conversion can be mathematically valid while the product remains unsuitable. An apparently matching description may omit a required specification. A delivery date can be acceptable for one requisition and disqualifying for another.
The data model should let a reviewer inspect those distinctions. A normalized price should retain its relationship to the original offer, and an unresolved equivalence check should remain unresolved. It should not become eligible because a parser successfully populated the numeric fields.
An invented comparison
Imagine a fictional requisition for mounting kits. One offer describes a pack of compatible kits with delivery within the required window. Another describes individual brackets with a lower headline price, but leaves the fasteners and delivery condition unclear.
Converting both offers into a price per component would not establish that either component meets the requested kit specification. The missing fasteners could change the required purchase, and uncertain delivery could change whether the offer is usable.
Under a proposed category policy, the second offer would need clarification before entering an eligible-price comparison. The point is not that it must lose. It is that its eligibility cannot be inferred from the lower number. This is an invented example, not a published supplier quote.
Make the policy reviewable
I would describe an equivalence policy in terms of required attributes, permitted transformations and unresolved conditions.
Required attributes establish what must be known. Permitted transformations describe how quantities or units can be reconciled. Review conditions identify judgments that cannot safely be automated, such as whether a substitute material satisfies the operational need.
Policy versioning matters because a justified decision belongs to the rules and evidence available at the time. If a category policy changes later, the system should preserve the original decision context rather than silently reinterpreting it.
The procurement case uses frozen comparison snapshots for that reason. New evidence can support a new comparison. It should not rewrite what an earlier buyer saw or the reason they recorded.
A checklist before sorting eligible prices
- Is the approved need explicit enough to define a comparable item?
- Are unit, quantity and specification checks recorded separately?
- Are commercial and delivery conditions available for inspection?
- Is every transformed value linked to its original evidence?
- Can an offer remain pending without receiving a fabricated equivalent value?
- Is the policy version bound to the frozen comparison?
- Does an authorized person record the final choice and justification?
This checklist is a design aid. A completed checklist does not independently prove that a particular product is suitable or that the buying decision saved money.
The next useful measurements would include clarification frequency, unresolved equivalence cases and the time required to reconstruct a prior decision. Those remain measurement work, rather than benefits inferred from the presence of a comparison interface.
The public procurement case documents the evidence and authority pattern behind this note.
Which attributes would your system need to establish before it is allowed to call two offers comparable?
Top comments (0)