Contact
A person compares two printed component specifications beside a machined metal part and a laptop displaying supplier records side by side.
Hypermodern / Journal

Which Information Should Your AI Trust?

Applied AI / 24 September 2026 / 7 mins

An AI purchasing assistant finds an old specification, a recent supplier email, and a conflicting quote. Which information should it rely on, and what needs checking before the business acts?

One Operational Ecosystem, Part 2

The purchasing assistant has found a replacement supplier. Its recommendation includes a price, a delivery date, and a link to a specification. Everything looks ready for approval.

Then an engineer opens the specification. It is last year's version.

The current version requires a different coating. The supplier's email says it can provide that coating, but the attached quote describes the original component. Meanwhile, the supplier register shows approval for a different product category.

Each record contains useful information. Together, they leave several questions unanswered. Can this supplier provide the right component, under the quoted terms, with the approval this purchase requires?

In the first article in this series, I used a hypothetical purchasing assistant to explore what happens when AI enters a business workflow. This time, I want to stay with the information behind its recommendation.

Before the team can rely on that recommendation, it needs a clear way to establish which records apply.

Decide which source governs each question

A supplier brochure may describe what the company can manufacture. A quote records what it has offered for a particular purchase. An engineering specification sets the requirements for the component. An internal register records the scope of the supplier's approval.

The assistant needs each source for a different reason.

For this workflow, I would ask the business owners to identify the governing source for each decision. Engineering owns the approved specification. Procurement owns the supplier approval record. The quote supplies the commercial terms, subject to its validity period and any subsequent agreed changes.

Those responsibilities need to be settled by the organization. Leaving the assistant to infer them from filenames, writing style, or where a document appears in search creates an avoidable source of error.

Even within an approved source, the details matter. A supplier can be approved for one category and awaiting assessment for another. A specification can apply to one product revision or one customer. A document can be genuine and still fall outside the scope of the purchase being considered.

The useful question is: what does this record establish for this particular task?

Check the dates that actually matter

Suppose someone uploads an old specification this morning. Its upload date is recent, but the requirements inside it have already been replaced.

Another document might have been approved yesterday but only take effect next month. A quote might remain valid until Friday while offering a delivery date the supplier has since withdrawn.

I would want the assistant to distinguish the date a record was added from the dates that determine when it can be used. Depending on the record, that could mean its approval date, effective date, expiry date, or the time its status was last confirmed.

The same applies to copies held by the AI system. If the assistant searches a periodically refreshed copy of the supplier register, the team needs to know how far behind that copy can be. For a preliminary comparison, yesterday's status might be acceptable. Before an order is submitted, the workflow may require a fresh check against the register itself.

A failed refresh should have a defined consequence. If current approval cannot be confirmed, the assistant can still prepare work that does not depend on it. The order should remain on hold until the required check succeeds.

Keep the evidence attached to the claim

A recommendation with three links at the bottom still leaves the reviewer with work to do. Which link supports the price? Which establishes the coating requirement? Which confirms that the supplier is approved?

For our purchasing assistant, I would make those connections explicit. The quoted price should identify the quote and its version. The technical comparison should identify the approved specification. Supplier eligibility should point to the relevant approval record and when it was checked.

The reviewer should also be able to distinguish what the source says from what the assistant has inferred. A supplier saying it can produce a coating is different from a quote committing to supply that coating at a stated price.

In Chapter 3 of The Hyperstore Manifesto, I argue that AI workflows need to retain the connections between content, metadata, versions, permissions, and history. The practical concern here is simple: when a record becomes a search result or a summary, the information needed to judge its use should remain available.

For later review, I would retain the record identifiers, versions, relevant supporting material, and checks used at the time, within the organization's access and retention rules. A link to a document that keeps changing may be insufficient to explain an earlier decision.

That history helps the team investigate a recommendation. It does not, by itself, establish that the underlying source was correct.

Give conflicting information somewhere to go

The supplier's email and quote now disagree. The assistant should flag the difference and identify what is needed to resolve it.

In this case, procurement might request a revised quote that names the current specification and confirms the coating, price, and delivery terms. Engineering might need to assess whether the proposed component meets the requirement. The assistant can assemble the relevant records and prepare the questions.

Until those questions are answered, its recommendation should show the unresolved condition. It should avoid presenting a single settled answer that hides the disagreement.

There will also be cases where information is simply missing. The supplier register may contain no approval for the required category. That absence should lead to the appropriate review process. The organization needs to decide whether it means the supplier is ineligible, requires assessment, or can proceed under a specific exception.

Someone must own that resolution. A warning that sits indefinitely in an interface will do little to help the purchasing team meet its deadline.

Apply access rules to the supporting material

A buyer might be allowed to see a supplier's approval status without being allowed to read the confidential assessment behind it. The assistant should provide the permitted status and enough context for the buyer's task, while respecting the restriction on the assessment.

I would test this with the actual roles that will use the system. What can a buyer see? What can an engineer see? What happens when a user's access changes after a comparison has already been prepared?

Search results, generated summaries, saved comparisons, and source links all need to be included in that review. Otherwise, a restriction applied in the original system may be lost as information moves through the workflow.

This connects the data question directly to cybersecurity and operations. The team needs to know who is asking, what they are permitted to receive, and whether the copy being used still reflects the source's access rules.

Start with a few difficult cases

In Chapter 2 of the Applied AI Handbook I describe a data reality check as part of assessing whether an AI project is feasible. It includes understanding the sources, their meaning, known gaps, ownership, and retention obligations.

For an existing project, I would begin with a small set of realistic cases. Give the assistant an expired quote, two conflicting specifications, a supplier approved for the wrong category, and a record the current user cannot access. Agree in advance how each case should be handled.

Then examine the recommendation and the next step it enables. Did it identify the applicable record? Did it show the uncertainty? Did it route the issue to someone who could resolve it? Could the order proceed while a required check remained incomplete?

Measure how much checking the reviewer still has to do, as well as whether the answer is correct. If people have to reopen every source and rebuild the comparison themselves, the workflow needs more work.

For our purchasing manager, a useful outcome could be a comparison that clearly says: this supplier appears suitable, but the quote needs updating and category approval is pending. That gives the team specific work to complete before committing money.

Choose one recommendation your business would be willing to act on. Ask the team to trace every important claim back to the record that supports it. Wherever that path becomes unclear, you have found something to resolve before giving the assistant more responsibility.

Further reading

Written by Dom Jocubeit
Founder, Hypermodern

Published independently by Hypermodern.
Brisbane · Albuquerque