Revenue & Margin
Recovery.

Generic chat widgets often can't see the store's catalog, orders or policy pages — and answer confidently anyway. The website channel stays uncovered; the data stays out of the owner's hands.

Self-hosted PrestaShop 8 module with LLM function calling: live catalogue search with ranked retrieval, answers grounded in CMS/policy pages, privacy-gated order lookup (reference + email, no enumeration). Multilingual.

Deployed on a public storefront. A retrieval miss — exact products not being found — was reproduced against the real catalogue and fixed with a ranked-retrieval and grounding release: top-1 retrieval 27% → 92% on a frozen 140-question local hold-out (n=74), and 5 of 5 traced question → source → answer chains accepted on the live server. An embeddings-based search stage was tested and rejected: it added false sources to questions the store cannot answer. Business effect is not claimed.

Moving a catalog between stores is usually manual or a one-off script: a second run creates duplicates, a mid-way failure leaves the store half-migrated, and there is nothing to verify the result against but eyesight.

A deterministic migration engine: whole-batch fail-closed preflight, stable identity and a local state layer for mappings, parent-first category-tree replication, full field-level verification after every write, no delete operations, and fully idempotent reruns. On top of it, an MCP control plane: plan before mutation, approval binding, four-class mutation accounting. On the same pipeline sits an AI transformation layer for moving a catalog between markets: content and imagery generated under explicit policy, every component carrying provenance and a fingerprint, checked against source facts and image QA, then deterministically materialized into an immutable package.

A real migration of 160 products and 22 business categories from PrestaShop 8.2 to 9.1: 22/22 categories verified, 154/154 category-field checks, 160/160 products reconciled on reference, price, descriptions, relations, stock and images — zero mismatches. The source stayed read-only. An immediate rerun produced zero writes. The transformation layer was proved on the same catalog and taken to a live storefront: 705 of 705 components accepted, a read-only backup taken before any change, then 22/22 categories and 160/160 products verified field by field with zero mismatches, products staged inactive pending owner activation, and an immediate rerun producing zero writes. The codebase carries 1,400+ automated tests. The MCP control plane was accepted live against a real PrestaShop 9.1.5 target: 32 of 32 checks in 26 seconds, including a genuine ambiguous-write recovery.

Customers go quiet gradually: nothing breaks, so nobody notices. There was no segmentation by historical value and no systematic re-engagement.

Deterministic extraction over order and email history (~36.6k emails, ~6.4k order rows): dispatch risk, payment issues, reactivation candidates. Then 46 dormant-customer case files generated automatically — order, margin and correspondence history and a suggested next step. I decided whom to contact; every message went out only after human approval.

488 reactivation candidates → 46 case files → four dormant customers ordered again. Together they represent approximately $21k in combined historical lifetime value. This is my own recorded outcome, and the figure is those customers' historical value — not revenue attributed to the outreach: there was no control group.

~45,000 emails across 10 inboxes in four languages over eight years of the operation. Inbox volume was visible, the operational signal was not: payment problems, delivery delays and compensation requests were buried in one queue.

Deterministic extraction over the archive (36.6k emails reconciled with ~6.4k order rows) into operational views — payment issues, dispatch risk, open issues — feeding a capacity-aware prioritized queue. Multilingual response drafts are prepared by the system and held for human approval — refunds, reships and outbound sending never go out unattended. Before automating further, an LLM classifier was measured once on 280 human-labelled real threads with preregistered thresholds.

One recorded run produced a 356-row prioritized queue and 278 response drafts in four languages, with refunds, reships and outbound sending held behind human approval. The benchmark showed why the rest stays human: message-class accuracy 0.90 but macro-F1 0.36, priority accuracy 0.28 — under the preregistered rule only 4 of 280 items qualified for auto-handling, so 98.6% went to a person.

Margin by country looked fine in aggregate and wrong in the detail: one order shipped as several parcels, revenue sat on one line, replacement shipments looked like losses. Compensation shipments were mixed into the commercial baseline.

A deterministic reconciliation module in Python: two-level control-total reconciliation (shipment subtotals and yearly totals), commercial and compensation margin separated, multi-shipment orders and split-revenue rows resolved, and an audit gate that reports discrepancies instead of smoothing them. No LLM in the numeric path.

~$838k of own order history reconciled (2019–2026, September-2026 export, 6,542 ledger rows). Four documented classes of discrepancies surfaced rather than smoothed (verdict PASS_WITH_FLAGS). Compensation shipments separated from the commercial baseline. No effect on margin or pricing is measured or claimed.

LLM analytics on my own data produced plausible, well-formatted numbers that did not reconcile with the source. An unverifiable metric is more dangerous than no metric: the owner makes decisions based on it.

Control-total reconciliation introduced before any AI-derived metric can reach a decision: control totals, hierarchy-of-truth checks against primary data, and gates that pull unverifiable metrics out.

My own recorded incident, with no artifact: the wrong numbers were caught before anyone relied on them. The same rule now lives in the margin-reconciliation module above: the source system wins, and a figure that does not reconcile is reported, not used. Every case figure on this page traces to a claims ledger with evidence pointers; where the evidence is my own recorded outcome rather than an artifact, the card says so.