A conversational assistant that turns a visitor's plain-language measurement problem into a cited, technically validated recommendation — with a deterministic rule engine, not the language model, holding all recommendation authority.
At a large technical exhibition, the bottleneck is not footfall. It is that a visitor with a genuine measurement problem has to wait for one of a small number of applications specialists to be free, describe their problem, and hope the specialist happens to know the right instrument for that exact application. Most visitors never get that conversation. The ones who do get it late.
The obvious fix — put a chatbot on a screen — fails for a specific reason. In analytical instrumentation, a confidently wrong recommendation is worse than no recommendation. A language model that invents a product name, or attaches a specification to the wrong instrument, does not merely give a bad answer. It damages technical credibility with exactly the audience whose trust the business depends on.
So the design question was never "can an LLM answer this?" It was: how do you get the fluency of a language model without ever letting it decide anything that matters?
The architecture separates two jobs that chatbots usually blur together.
The language model interprets the visitor's words and explains a result. It never selects a product. A deterministic, version-controlled rule engine does that.
In practice, the flow is:
The result is a system where the failure mode is "I need to bring in a specialist" rather than "here is a confident answer that happens to be wrong."
Retrieval is only as trustworthy as what it retrieves from. The ingestion pipeline crawls a curated source list and is content-hash idempotent, so re-running it is safe and produces no duplicates. Every ingested passage moves through a draft → review → approved workflow. Nothing that has not been explicitly approved can ever be cited back to a visitor.
This is the part that gets skipped in most enterprise AI pilots, and it is the part that determines whether the thing can be signed off internally.
The system ships with a 44-case evaluation suite covering AI behaviour and rule correctness, run alongside the normal software gates — type checking, linting, unit and integration tests, end-to-end browser journeys, accessibility, security and performance checks.
That matters more than it sounds. It means a change to a prompt, a rule or the retrieval layer is regression-tested the same way a code change is. Model behaviour stops being a thing you spot-check before a demo and becomes a thing you can prove.
I designed the architecture and the safety model, wrote the specifications, and drove the implementation and test suite, working with AI coding agents under Git version control.
I am not going to claim this makes me a software engineer. What it does show is something I think is more relevant to a transformation role: the distance between "we should try AI for this" and working, governed, test-gated software is now short enough that one person who understands the business problem can cross it. Knowing where that line sits — and where it does not — is increasingly the job.
Rebuilding a country corporate site from a brochure into a platform that carries product discovery, technical documentation, 3D catalogue, events and enquiry capture — and became a primary source of organic traffic and digital enquiries.
Replacing fragmented shared-mailbox enquiry handling with a centralised, automated lead workflow across Power Automate, SharePoint and Salesforce — and a lifecycle framework that finally connected a digital enquiry to its sales outcome.
An IT infrastructure operations platform that started as an internal ticketing requirement and grew into a SaaS proposition — SLA management, escalation workflows, asset inventory, monitoring and operational reporting.