What problem was the operator trying to solve?
The questions were ones every supply chain team asks. Are our stock levels right? Are we paying what we agreed? Which spend numbers are real? Do we already hold this part somewhere else? The answers existed, but getting them took expert time and a lot of spreadsheet work.
Four things made it hard:
- Stock levels lived in an expert's spreadsheet. The site inventory expert had their own working figures, and any system had to agree with them before anyone would trust it.
- The data was big. Millions of purchasing, receipt, payment and stock rows, far too many to check by hand.
- Some numbers were quietly wrong. There were data problems the client didn't know it had, including in how spend was counted.
- The same part could sit under different records at different sites. Without a reliable match, stock gets bought again instead of shared.
On top of that, quotes needed judging against what was agreed and what was last paid, and tenders needed scoring the same way every time.
What was built?
Six pieces, built inside the client's own environment with read-only access to source data.
| Piece | What it does | Case study |
|---|---|---|
| Data audit | Checked the source data before anything was built on it | AI data audit |
| Stock level engine | Recalculates min/max for every stock line with plain, checkable maths | Min/max inventory engine |
| Contract price book | Built from the client's own contract history, so quotes are judged against what was agreed and what was last paid | Contract price book |
| Cross-site parts matching | Matches parts across sites using evidence tiers, so stock can be shared instead of re-bought | Cross-site parts matching |
| Tender scorer | Scores bids against set criteria, calibrated against a real evaluation panel | Tender scorer |
| Commercial assistant | Answers commercial questions inside Microsoft Teams | Teams commercial agent |
The design rule across all of it: deterministic maths for the numbers, AI only to explain. Every number links back to the line it came from. A person approves. The AI never decides.
How was it proven before anyone relied on it?
By checking it against the people who already knew the answers, and by testing every answer automatically. Trust was earned line by line, not assumed.
The data was audited first
Before building, the source data was audited. That surfaced data problems the client didn't know it had. Spend was checked too, and a whole class of wrong spend numbers was caught: quotes and unapproved orders were being counted as spend. One rule fixed it.
The stock engine was checked against the expert
The stock level engine was compared line by line with the site inventory expert's own spreadsheet. Where they disagreed, the cause was found and fixed. One rule change, netting returns off usage, took agreement on disputed items from 73% to 98.4%. A part issued and returned unused isn't real usage, and counting it pushes levels up.
The tender scorer was checked against a real panel
The scorer was calibrated against a real evaluation panel's scores. It matched the panel exactly on one bid and came within a point on another.
Parts matching was built to refuse a guess
Cross-site matching sorts every possible match into evidence tiers. Where the evidence is weak, it says so instead of being confidently wrong.
Every answer is tested
Every answer the assistant gives passes 511 automated checks. Every mistake a user catches becomes a permanent test. The AI verification method explains how this works.
What were the results?
The short version: the numbers agree with the experts, the assistant gets used, and wrong numbers get caught.
| Area | Result |
|---|---|
| Stock level engine | Matched the site inventory expert's own spreadsheet 99.8% of the time |
| Disputed items | Agreement went from 73% to 98.4% after one rule change (netting returns off usage) |
| Commercial assistant | Answers from millions of purchasing, receipt, payment and stock rows in about a minute |
| Adoption | Commercial leadership use the assistant without being asked to |
| Answer quality | Every answer passes 511 automated checks, and every caught mistake becomes a permanent test |
| Tender scorer | Matched the evaluation panel exactly on one bid, within a point on another |
| Spend reporting | A whole class of wrong spend numbers caught and fixed with one rule |
| Parts matching | Evidence tiers so stock can be shared across sites instead of re-bought |
The adoption result matters most. A tool that leadership opens on their own is a tool they trust.
Did the AI make any decisions?
No. It calculated, matched, scored and explained. People decided.
- Stock level changes are recommendations. The stores team approves them.
- Tender scores are a first pass. The panel decides.
- Parts matches with partial evidence go to a person to confirm.
- Price book flags show the source lines. A buyer reviews them.
That split is deliberate. In supply chain work a confident wrong answer costs more than a slow right one, so the system is built to show its working and hand the call to a person.
What does this mean for your operation?
The same approach works at a smaller scale, on either side of the supply chain.
If you're a miner or mining contractor
The build covers a stock level (min/max) engine, a PO vs contract checker, a contract price book and an assistant inside Microsoft Teams. It's built inside your own Azure, Databricks or Snowflake. See AI for mining supply chain.
If you're a mining services supplier
The price book and PO checking ideas apply from the other side. Quote Desk reads RFQ emails, drafts the quote from your own price book, and checks every PO that comes back against your quote before anything ships. See Quote Desk for mining suppliers.
How it starts
Either way, it starts with a free 15 minute call with Tristan, or a quick enquiry. No obligation, no pitch. Work is charged at a consulting day rate. The price depends on your sites, systems and data, so we talk first, then Tristan sets out what he'd build, how many days it takes and what it costs.
- 15 minute call. Free, no obligation, no pitch. Tristan asks what you run and what is costing you, and tells you straight whether there is something worth fixing and roughly what it would cost.
- A look at a sample export. Only if it's useful, and read-only.
- A clear scope and price. What gets built, how many days it takes and what it costs, in writing before any work starts.
- Build inside your systems. Your own Azure, Databricks or Snowflake for miners. Your Microsoft 365 or Google account plus an Australian-hosted database you own for suppliers.
- Run, check and support. Re-runs, fixes and new sites or users as you grow. A person approves every change.
For a different kind of supplier project, see how a Perth mining parts supplier turned 13 PDFs into 35,268 searchable pages and 94,062 keyword variants in the Equipment Group case study.
