Work carried
through to use.

Working through the delivery constraints

The client was evaluating an AI-powered scientific-literature platform under licensed-content constraints. I structured the pilot around incremental delivery and feedback: demonstrations, workshops, Q&A and train-the-trainer sessions, with 60 power users before the wider launch. Part of the pilot was moving about 700,000 documents from the previous vendor in 40 days, in phases, so the platform could go live with the first batches while the remaining deltas were processed.

When the AI answers fell short of what the client expected mid-pilot, I didn’t manage expectations down. I ran evaluation sessions with the client on answer quality, accuracy, hallucination limits and speed, and worked with the engineers on guardrails, retrieval settings and the system prompt so that answers stayed grounded in licensed sources, with citations. We shortened the QA and demonstration cycle so the client could assess working software, and ran load and performance tests with the product team before scale-up.

The July 2026 launch date was maintained. The implementation approach, tracking framework and presentation materials became reusable assets for colleagues. My responsibility was implementation and cross-functional delivery, not model development.

A second rollout

In 2026 I also led discovery and the first stage for a second pharmaceutical client moving off a legacy literature system: about 150,000 documents cleaned, normalized and imported into three libraries, with AI search and summarization live for 30 power users in June 2026. I was assigned a few days before the first on-site discovery sessions, so much of that first week was about giving the client confidence in the approach and agreeing what we’d need from them.

Why I built it this way

SuppClaimCheck checks a claim about a dietary supplement against open-access biomedical literature and returns a verdict, a 0 to 100 score and word-for-word quotes with citations. The one rule I set before anything else was that the model never decides and never acts. Code searches PubMed, keeps the articles whose licence allows text mining, computes the verdict and score from a versioned rubric and verifies every quote word for word; quotes that fail are dropped and logged. The model only fills schema-validated fields.

I wanted to see what the discipline I used on client AI rollouts looks like when I own the whole thing. So every prompt, model, retrieval or config change had to be measured against a labelled eval set, 35 cases with 9 held out for release candidates, which replays in CI on every pull request and fails on a regression. That’s how I learned that more articles, ranking by study type and hybrid retrieval moved accuracy, while five prompt-wording variants didn’t.

The code is agent-written. Claude Code agents worked under a written never-list enforced by hooks that fail closed, and I reviewed and merged about 60 pull requests and ran every deploy and drill myself, including a restore drill and a database-down drill that found a worker hanging silently. The repository is public at github.com/cg-rt/suppclaimcheck.

It’s an independent project with no external users yet, and it doesn’t make me a software engineer. What it shows is that I can specify, direct, evaluate, secure, release and run an LLM application end to end, and that I can get useful work out of AI coding agents without losing control of what ships.

Making the data and workflows usable

I worked with the client to obtain and normalize its legacy documents and metadata, design custom fields and library structure, and configure client-specific workflows. Duplicate checks, exception reviews and QA covered the data, libraries and workflows, with Product, business and Support teams involved where needed. Where Excel wasn’t enough, I wrote C# scripts to split fields, normalize dates so day and month couldn’t be swapped on import, skip superseded versions and clean fields by rule.

This was a separate engagement from the enterprise AI pilot.

Changing a live account without breaking billing

The account had more than ten years of accumulated configuration: unused organizational units and billing setups far more granular than anyone needed. The risk sat in the billing. Orders landing on the wrong invoice, or users losing access, right before the automatic monthly invoicing run, would have been very visible to the client.

So I built the plan around that date. I pulled all invoices and their orders on 27 July as the reference, restructured the account, pulled them again and cross-checked totals and orders invoice by invoice before the 30 July run, with a plan to restore the previous structure if anything didn’t match. Support knew what was changing and when, cut their client documentation from 80 pages to 15 and switched to the new processes at the right moment. I kept checking invoices and support cases for several months afterwards and reported the method and the results to the client and to our executives.

Starting with the review, not the reassurance

The client had been through several contacts on our side, had a list of unresolved technical and configuration issues, and had stopped giving honest feedback because earlier efforts hadn’t changed anything they could see. Promising that it would be different this time would have made it worse.

So I started with a technical account review: a methodical look at the configuration, the open issues and the history, written down and brought back to the client with a prioritised plan and a plain account of what had gone wrong. Every commitment became a tracked item with a visible status. When I needed engineering or product, I escalated internally and kept that complexity away from the client, because what they needed to see was things getting resolved. Over a few months the updates went from formal to a normal working relationship, and the client came back to the table for new implementation work.

I’ve used the same approach on five strategic accounts that were strained when I took them on. The account-review template that came out of this work was later used by colleagues for their own reviews.

Making regional requirements work together

A twelve-month technical account review established how the existing setup worked and what needed to change. The consolidation involved different regional requirements, interpreters and multiple time zones.

I worked through conflicting requirements with the relevant groups, established who needed to contribute to each decision and who needed to approve it, and kept actions visible across the implementation. That connected the technical review to configuration decisions the stakeholders could sign off.

Preparing the people as well as the platform

The client needed a content-management solution that fitted its internal workflows. I translated those requirements into a practical configuration and delivery sequence, using testing and client feedback to check the fit.

Training covered both users and administrators: one group needed to work with the platform, the other to support and maintain it. I connected that training with the documentation and knowledge transfer the operations team needed to take over.