Before an AI assistant helps release a material order, ask more than “Where did that answer come from?” Ask which revision it used, what that revision was approved for, and who can authorize the next action. A link to a real project file is evidence of origin. It does not establish permission to buy or build.

Procore’s version-control guide, updated August 30, distinguishes file storage from a controlled process that identifies current approved documents and retires superseded revisions. It also points out that tracking a revision does not assess everything affected by the change. That remains work for the project team. The guide addresses Australian projects; this Field Note applies its operational document-control distinction, not its jurisdiction-specific claims.

Datum’s recommendation is to make document authority visible beside every consequential AI recommendation. For a remodeler, designer, showroom, or supplier, that means the review should expose the specific evidence supporting a selection or purchase before anyone acts on it.

A citation can be accurate while the recommendation is unusable

Consider a hypothetical bathroom project. Selection schedule revision B contains the approved brushed-nickel faucet. A newer revision C proposes matte black but is still awaiting owner approval. A vendor quote also lists matte black. An assistant asked “Which faucet should purchasing order?” could find two matching documents and confidently recommend the proposed finish. Both citations could be real. The release decision would still be unresolved.

The useful response identifies the approved finish, flags the pending alternative, and holds the order for the designated reviewer. It should not treat two matching documents as two votes for approval. Nor should it resolve a conflict by choosing whichever file was uploaded most recently. This is an illustrative failure case, not a report of a client incident.

Put five checks beside the recommendation

  • Project and item: identify the job, room, product, and exact decision being reviewed. Similar descriptions on another project are not interchangeable.
  • Evidence location: link the source and identify the page, schedule row, or detail supporting the claim. The reviewer should be able to inspect the underlying record.
  • Revision and status: show the revision identifier and its recorded approval or issue status. Mark missing status as unknown.
  • Scope of approval: say what the approval covers. A selected finish does not, by itself, establish an approved quantity, acceptable price, or release date.
  • Action owner: name the person authorized to release the order and show any unresolved conditions. The assistant prepares the recommendation; your release process controls the commitment.

These five checks are Datum’s proposed review format. Your team should adapt them to its actual document register and approval process. Start with one purchase category where the source records are already maintained reliably.

Keep source context attached when AI searches

Anthropic’s Contextual Retrieval article explains how splitting documents into searchable pieces can strip away the information needed to interpret a passage. Its approach adds explanatory context to those pieces before retrieval. That is useful background for builders evaluating document-search tools, even though the article is not a construction approval system.

Our application is straightforward: a retrieved selection row should travel with its project, document identifier, revision, and recorded status. Keep model-generated explanations separate from those controlled fields. An assistant can summarize an approval record; it must not manufacture approval because the surrounding prose sounds final.

Ask a prospective vendor to demonstrate this with your own authorized sample packet. Watch which version the assistant retrieves, whether the reviewer can open the evidence, and what happens when approval information is absent. A fluent explanation is only one part of that demonstration.

Try a small conflict test before a live order

  • Approved versus newer draft: provide both revisions. The assistant must distinguish them and flag the pending change.
  • Missing approval: remove the approval record. It should return an unresolved status rather than infer consent.
  • Wrong project: include a nearly identical product on a second job. It should keep the projects separate.
  • Conflicting current records: make the approved schedule and another current source disagree. It should expose the conflict for review.
  • Approval changes after drafting: update the source before release. The workflow should recheck authority and invalidate an outdated recommendation.

Keep the expected result and actual output for each case. Count unsupported release recommendations separately from ordinary wording corrections. If any example recommends a commitment without the required evidence, keep that workflow in draft-and-review mode while you fix the gap. This is a proposed pilot check, not proof that a system is safe in every project condition.

Make the next review easier to perform

Choose one recent, completed order. Rebuild its decision trail: item, approved source, revision, open conditions, and release owner. Then ask whether your current AI setup could produce that same review packet without filling missing fields with guesses. That exercise reveals a concrete next improvement: better source records, a clearer approval boundary, or a more inspectable answer.

Sources Read

Next step, if this note maps to a problem on your desk: Book Private Training.

Related Field Notes