採購比較：凍結決策記錄，而非工作文件

A supplier comparison is a moving object. A revised offer arrives, a quantity changes, and someone corrects the delivery condition. The working document should accommodate those changes. The decision record needs to preserve what was actually compared.

That distinction shaped an internal procurement implementation documented in my public portfolio. This article discusses its anonymized design pattern. It introduces no new deployment or measured purchasing benefit.

The central question is simple: when someone revisits a purchase decision, can the system show the evidence and assumptions that existed when the choice was made?

Give the objects different lifecycles

The original supplier document, normalized offer, working comparison, and decision snapshot serve different purposes.

The document records what the supplier provided. Normalization records an interpretation: which number is the unit price, which unit applies, and what conditions accompany it. A working comparison lets the team resolve uncertainties. The snapshot preserves the comparison context submitted for a decision.

Collapsing these into one editable row creates a subtle failure. A correction made today can make yesterday's decision appear to have used information that was not available then.

In the documented implementation, originals are preserved with integrity metadata. Reprocessing creates another version. A human decision attaches to a frozen comparison and a justification, while the audit trail retains subsequent events.

A cheaper offer can be a different offer

Consider this entirely invented example:

Neither headline value establishes the better purchase. Before comparing price, the buyer needs an equivalence rule covering the relevant specification, unit, quantity, and commercial conditions.

The snapshot should capture the result of that review, including unresolved conditions. Recording only the chosen supplier and total would lose the reasoning that made the selection defensible.

A source hash helps identify the document used. It does not prove that an extracted number is correct or that two items are equivalent. Those remain distinct checks.

Freeze at the authority boundary

Freezing every draft edit would burden the workflow without clarifying the decision. The useful boundary is the transition from a mutable comparison to a context on which an authorized person may act.

At that transition, the system should validate the eligible offers and relevant policies, create the snapshot, and connect the human choice to it. Competing changes need explicit handling so that the choice cannot accidentally refer to one version while the displayed table shows another.

A later correction should remain possible. It should produce an amendment, replacement decision, or new snapshot with a reason. It should not silently rewrite the earlier context.

This also changes interface design. The buyer needs to recognize whether they are viewing the current workspace or the historical decision context. An attractive table is insufficient if that distinction is hidden.

Review the transition before adding extraction

AI extraction could eventually help structure incoming evidence. In this case, external AI processing and other integrations remain separately gated. The comparison model must remain understandable before a parser adds another source of interpretation.

My practical review checklist is:

• Can a reviewer recover the original evidence associated with the decision?
• Are units and equivalence assumptions explicit?
• Does reprocessing create a version rather than overwrite evidence?
• Can a concurrent edit change an already confirmed comparison?
• Is the approver's choice connected to a snapshot and reason?
• Can a correction preserve the previous decision history?

Useful future measurements include the effort to reconstruct a decision, unresolved-equivalence frequency, and time from approved need to justified choice. I have no validated public baseline for those outcomes.

The procurement case describes the wider implementation and its limits. What needs to remain inspectable after the working document changes?