Case studies

Eight constraints,
eight engineered answers.

Each pattern below describes the constraint as we found it, the technical intervention, and the indicators we tracked against the discovery baseline. Client organizations are anonymized and figures are rounded; the architectures are exactly as deployed.

01 · Manufacturing — custom machined components · 180 employees

Shop-floor sequencing under changeover constraints

Context & constraint

The ERP sequenced production orders by due date alone. Each material or tooling changeover imposed a 45-to-90-minute setup that the scheduler did not model, so mathematically similar jobs were being scattered across the week. Two planners rewrote the sequence by hand in a spreadsheet twice daily, and the cost of a bad sequence only became visible in the next shift report.

Engineering intervention

Order extraction through the ERP REST API into a staging schema. A changeover cost matrix was learned from 26 months of historical production events — actual setup durations by material, tooling family and machine, rather than the standard times in the routing master. A constraint solver then minimizes total setup time subject to due dates, machine capability, operator certification and material availability.

A natural-language layer lets the planner state the day's real constraints in plain English — an absent operator, a late steel delivery, an expedited customer — and receive a revised sequence with the trade-off quantified. The accepted sequence is written back to the ERP with its justification attached to the production order.

Architecture notes

Solver runs on a 20-minute cadence and on demand. Every published sequence is versioned, so a supervisor can see which constraint changed and why the plan moved. Write-back is idempotent on the order revision, and the human planner retains override authority on any individual job.

constraint programminglearned setup timesERP API write-backconversational replanningon-site discovery

Measured indicators

+14%overall equipment effectiveness
−31%monthly machine setup hours
−4.5 daverage customer lead time
12 hmanual planning work removed weekly
18 wksdiscovery to production rollout
02 · Professional services — accounting firm · 4,200 invoices / month

Straight-through accounts payable

Context & constraint

Supplier invoices arrived by email in eleven distinct layouts, including fax scans of handwritten delivery notes. Seven staff keyed data into the accounting package, matched purchase orders, and worked exceptions through a shared mailbox with no queue discipline. Median approval latency reached 9.4 days, forfeiting early-payment discounts and making the cash-flow forecast unreliable.

Engineering intervention

Ingestion from the shared mailbox with attachment normalization and deduplication by content hash. Schema-constrained extraction produces a typed invoice record with a confidence score per field, followed by deterministic validators: line-item arithmetic, tax computation, vendor master lookup and currency checks. A three-way match then reconciles against the purchase order and the goods receipt.

Invoices where every field clears its threshold and the variance stays inside tolerance post automatically. Everything else lands in a review queue, pre-filled, with the source region of the document highlighted beside the extracted value — a correction is one keystroke, and it feeds the evaluation set used for the next threshold review.

Architecture notes

Thresholds were derived from the client's cost of error, not from a default: a misposted tax code costs more than a delayed invoice, so tax fields hold a tighter gate than description fields. Every posting carries the document hash, model version and rule path in an immutable audit log, which the firm now uses directly during year-end review.

document AIper-field confidence gatingthree-way matchhuman-in-the-loop queueimmutable audit log

Measured indicators

88%invoices posted with no human touch
1.6 dmedian approval latency, from 9.4 d
−92%processing cost per invoice
99.4%field-level accuracy on audited sample
0roles eliminated — staff moved to advisory
03 · Distribution — regional food wholesaler · 6,800 SKUs

Demand forecasting and replenishment policy for perishable inventory

Context & constraint

Reorder points were static values entered years earlier and rarely revisited. Buyers compensated with intuition, which worked for the SKUs they knew well and failed for the long tail. The result was a simultaneous 11% stockout rate on fast movers and significant spoilage write-offs on slow movers — a textbook symptom of a policy problem misdiagnosed as a forecasting problem.

Engineering intervention

A hierarchical forecasting model at SKU-by-location-by-week, reconciled across the category hierarchy so that item-level forecasts sum coherently to the category plan. Promotional calendars, local event data and weather were incorporated as external regressors. Critically, the model outputs prediction intervals rather than point estimates, because safety stock is a function of forecast uncertainty and not of the expected value.

Reorder points and safety stock were then derived per SKU from the client's stated service-level target and the item's shelf life, with an explicit spoilage penalty in the objective. Buyers receive a weekly exception list — only the SKUs whose recommended policy has moved materially — rather than a 6,800-row report nobody would read.

Architecture notes

Forecast accuracy is monitored per SKU segment, with automatic fallback to a simpler seasonal-naive baseline for any item where the model fails to beat it. Buyers can reject a recommendation with a reason code, and those reasons are reviewed monthly — they have twice surfaced upstream data problems the model was correctly reacting to.

hierarchical forecastingprediction intervalsinventory optimizationexception-based workflowmodel fallback

Measured indicators

−38%stockout events on A-class items
−22%spoilage write-offs
−9%working capital tied up in inventory
4 hbuyer review time per week, from 22 h
04 · Insurance — commercial brokerage · 31 service staff

Inbound correspondence triage and policy servicing

Context & constraint

Roughly 900 inbound emails per day hit six shared mailboxes: certificate requests, endorsement instructions, claim notifications, billing questions, renewal documents. Every message was read at least twice — once to classify it, once to act on it. First-response time averaged 31 hours and the assignment of work depended on who happened to open the mailbox.

Engineering intervention

A classification and extraction layer reads each message with its attachments, identifies the request type and urgency, resolves the sender to a client and policy in the broker management system, extracts the actionable parameters, and routes the item into a typed work queue with a suggested action and a drafted response.

Certificate of insurance requests — the single highest-volume category and entirely rule-bound — were automated end to end: the system validates the requested wording against the bound coverage, generates the certificate, and issues it. Anything where coverage interpretation is required is escalated to a licensed broker with the relevant policy sections retrieved and cited.

Architecture notes

Regulatory boundary enforced in code: the system never renders an opinion on coverage. It retrieves, summarizes and cites; a licensed human makes every coverage determination. Guardrails include an allow-list of outbound templates and a hard block on any message containing a coverage assertion that is not a direct quotation from the policy document.

email classificationentity resolutiontemplated generationregulatory guardrailscitation enforcement

Measured indicators

−71%average first-response time
94%certificate requests fully automated
97%routing accuracy on audited sample
+2.1×service requests closed per staff-day
05 · Construction & engineering — mechanical contractor · $140M annual volume

Tender analysis and submittal review

Context & constraint

Estimators received tender packages of 400 to 2,000 pages: drawings, specification divisions, addenda, general conditions. Locating the clauses that carry risk — liquidated damages, unusual warranty terms, non-standard payment schedules, exclusions buried in a specification division — consumed three to five days per bid. Under deadline pressure, packages were sometimes bid on a partial read, and two historical losses were traced directly to a missed clause.

Engineering intervention

Document ingestion with structural parsing that preserves division and section hierarchy, then clause-level indexing with hybrid retrieval. The system compares each package against the contractor's standard risk position — encoded as a library of clause archetypes with acceptable and unacceptable variants — and produces a deviation report ranked by financial exposure, every item hyperlinked to the exact page and paragraph.

A second module extracts the scope of work into a structured take-off skeleton and matches line items against historical unit costs from completed projects, flagging items with no comparable history as requiring manual pricing rather than silently interpolating them.

Architecture notes

Every assertion in the deviation report cites its source location; the estimator verifies rather than trusts. Addenda are processed as diffs against the base package, so a late addendum produces a short delta report instead of a full re-read. Nothing is auto-priced — the system narrows where attention is required and the estimator remains accountable for the number.

structural document parsingclause archetype libraryhybrid retrievaladdendum diffinghistorical cost matching

Measured indicators

−64%estimator hours per tender package
+40%tenders reviewed per quarter, same team
100%packages now receiving a full risk read
+3.2 ptsgross margin on won bids, 12-month cohort
06 · Healthcare administration — multi-site specialty clinic group

Referral intake and prior authorization packaging

Context & constraint

Referrals arrived by fax, secure email and a provincial portal, in no consistent format. Administrative staff transcribed patient demographics and clinical details into the practice management system, then assembled prior authorization packages by hunting for the supporting documentation each payer required. Median time from referral receipt to booked appointment was 14 days, of which roughly 9 were pure administrative queue time. Authorization denials for incomplete submissions ran at 19%.

Engineering intervention

A privacy-preserving intake pipeline running entirely inside the clinic group's own infrastructure with open-weight models — no patient data leaves the environment. Documents are classified, demographics and clinical fields extracted to a validated schema, and the patient resolved against the existing record with a deterministic matching rule set plus human confirmation on any ambiguous match.

A rules engine encodes each payer's documentation requirements per procedure code. The system assembles the authorization package, identifies precisely what is missing, and generates the request to the referring provider for the gap. Clinical content is never generated — only retrieved, organized and cited.

Architecture notes

Self-hosted inference on the clinic group's GPU server; no external API calls in the data path. Every field carries provenance to its source document and page. Patient identity matching is deliberately conservative: false merges are treated as unacceptable, so borderline matches always route to a human. Full access logging satisfied the group's privacy impact assessment.

self-hosted inferenceopen-weight modelsdeterministic patient matchingpayer rules engineprovenance tracking

Measured indicators

−9 dreferral-to-appointment median time
19% → 4%authorization denial rate for incompleteness
0patient records leaving client infrastructure
+28%referrals processed per admin FTE
07 · E-commerce — direct-to-consumer brand · 14,000 tickets / month

Tier-one support resolution and returns disposition

Context & constraint

Support volume scaled linearly with revenue, and the team was hiring to keep pace. Analysis of six months of ticket history showed that 61% of contacts were five repeating intents — order status, delivery exception, size exchange, discount code failure, return initiation — each of which required an agent to open three systems and copy data between them. Median first-response time was 7 hours; seasonal peaks pushed it past 30.

Engineering intervention

An agentic resolution layer with read access to the commerce platform, the carrier tracking APIs and the returns system, and narrowly scoped write access for a defined set of low-risk actions: issuing a prepaid return label, reshipping a confirmed-lost parcel under a value ceiling, applying a documented goodwill credit within a fixed limit.

Every action is bounded. Value ceilings are enforced in code, not in the prompt. Any request outside the competence envelope — damage claims, wholesale accounts, chargebacks, anything touching a legal or regulatory question — is escalated with a written rationale and the full context already assembled for the human agent.

Architecture notes

Responses are grounded exclusively in the brand's published policies, indexed with effective dates so a superseded policy can never be quoted. Tone and content follow a reviewed template library. A continuous sampling audit reviews 2% of automated resolutions weekly, and every escalation reason feeds the monthly envelope review — the scope of what the agent may resolve has been expanded three times on evidence, never on optimism.

agentic tool usevalue ceilings in codepolicy grounding with effective datescontinuous sampling audit

Measured indicators

58%tickets resolved without an agent
4 minmedian first response, from 7 h
+11 ptscustomer satisfaction on automated resolutions
0seasonal contractors hired that year
08 · Transportation — third-party logistics provider · 240 tractors

Freight invoice audit and proof-of-delivery reconciliation

Context & constraint

Carrier invoices were reconciled against rate agreements by two clerks on a sampling basis — roughly 15% of invoices were actually checked, because checking one properly took eleven minutes across three systems. Accessorial charges, fuel surcharge calculations and detention claims were effectively unverified. Separately, proof-of-delivery documents arrived as driver phone photographs of varying legibility, and unmatched PODs blocked customer billing for an average of six days.

Engineering intervention

Every carrier invoice is now audited, not sampled. Line items are extracted and recomputed against the contracted rate table: base linehaul by lane and weight break, fuel surcharge against the published index for the shipment date, and each accessorial against its contractual trigger condition. Discrepancies above a materiality threshold generate a dispute packet with the calculation shown line by line — which is what makes carriers settle quickly.

On the POD side, driver photographs are enhanced, read for signature presence, consignee name, delivery timestamp and exception annotations, then matched to the shipment via load number, address and time window. Legible matches release billing automatically; unreadable captures trigger an immediate re-capture request to the driver while they are still on site rather than three days later.

Architecture notes

Rate table interpretation is deterministic code with a test suite per carrier contract — a model is never asked to decide what a tariff means. The vision model performs perception only: reading the document. Dispute packets are generated but never sent automatically; a human reviews and releases each one, which preserves the carrier relationship.

deterministic rate enginevision-based POD capturefuzzy shipment matchingdispute packet generation

Measured indicators

100%carrier invoices audited, from 15%
2.8%of freight spend recovered in year one
−6 dPOD-blocked billing delay eliminated
5.1 mopayback period on total project cost

A note on these numbers

Every indicator above is measured against a baseline established during the discovery phase, using the same instrumentation before and after deployment. We publish the measurement method with the result, because an improvement claim without a stated baseline is marketing rather than engineering. Client names, exact volumes and identifying details are withheld under confidentiality; the architectures and the measurement approach are described as deployed.

Your constraint is probably on this list.

And if it is not, it is structurally similar to one of them. A measured baseline will tell us which.