From a spreadsheet everyone shared to a system that remembers

The temptation with a project like this is to rewrite from a fresh specification and move on. We didn't. The spreadsheet contained the client's real replenishment policy, and getting it subtly wrong would have been worse than useless — a planner who spots one incorrect number stops trusting the whole system.

So we started by decoding the workbook itself, not a description of it. That meant reading the macro code line by line, unpacking a calculation sheet hundreds of columns wide, and mapping every rule in the decision logic back to the exact fields it drew on. Several of the trickier derivations — how available stock was really composed, how the distribution centre's position was calculated, how demand was normalised for online orders — had never been written down anywhere. We reconstructed them from the formulas and confirmed each one against the client's own worked examples.

Those worked examples became our proof. The client had a sample output workbook — a set of fully worked lines covering every branch of the logic. We turned it into an automated acceptance test: our engine had to reproduce every one of those results exactly, or the build failed. Not checked by eye, once — enforced on every change, forever. When we could show the new system matching the old spreadsheet line for line, the conversation stopped being 'do we trust this?' and became 'what else can it do?'

Being honest about the edges mattered just as much. Where a calculation was reconstructed rather than certain, we surfaced it in the product with a plain confidence label and a short list of questions for the client's own experts to confirm — rather than burying an assumption inside the code and hoping. That turned the first client review into a working session instead of an interrogation.

A guard against repeat orders closes a subtle gap. Because the ERP's outstanding-order export can lag, an order raised on Monday might not appear in Tuesday's file — so the same line resurfaces and gets ordered again. The platform remembers what was already issued and warns before a duplicate goes out, even across days.

And an AI assistant lets planners simply ask — 'what must I order this week?', 'what's been stuck the longest?', 'is the exception rate improving?' — and get answers in plain language, with charts and tables, instead of clicking through screens.

We were deliberate about this, and we say so plainly to every client: the recommendation engine is deterministic. The rules decide, exactly as the business defined them, auditable and repeatable — the same inputs always produce the same answer. That is not a limitation; for an inventory process that has to stand up to scrutiny, it is the point.

The AI's job is to explain and assist, never to decide. Every figure the assistant reports is computed by the system from live data; the model only puts it into words. If it cannot compute an answer, it says so rather than inventing one. There are no hallucinated numbers, because the numbers never come from the model.

That division — rules for decisions, AI for language and analysis — is what makes an AI feature safe to put in front of a team whose trust you cannot afford to lose.

The client needed the system to run entirely within their own environment, on their own hardware, with no dependency on the outside world at runtime. The platform was built to those constraints from the start: the data never leaves the building, and the whole system is light enough to run on modest on-premises infrastructure rather than a server farm.

This engagement is a template for how Catalyst AI delivers: we begin by faithfully understanding what already works, prove the new system against the old one before we extend it, and use AI to accelerate the build — while being disciplined about keeping AI out of the decisions that must remain auditable. The result is software a team actually trusts, delivered in a fraction of the usual time.