Skip to content
Mohammad Al-Araidah

Case study 04 · Product & engineering

AutoOps AI

Applying AI to manufacturing operations and quality workflows. Built from 35 discovery interviews to a 20-user pilot at a manufacturing company — and the reason I now believe manufacturing quality is as much an information-architecture problem as an analytical one.
Personal ProductVisit AutoOps ↗

Problem

Every quality method I have used in a plant assumes the evidence is available. 5-Why assumes you can see what changed. FMEA assumes you know the historical failure modes. CAPA effectiveness checks assume you can find out whether the defect recurred. In practice that evidence is scattered across an ERP system, a MES, a dozen spreadsheets, inspection PDFs, supplier certificates and shift notes.

The consequence is not that engineers use bad methods. It is that they spend the majority of an investigation assembling context, and then run a good method on a thin slice of the evidence, because that was the slice they could reach before the meeting. The method is fine. The retrieval is the bottleneck.

Hypothesis

Manufacturing teams do not primarily need another dashboard. They need a reasoning layer over their own operational data — one that can assemble the context an RCA, an FMEA or a CAPA actually requires, and cite where every claim came from.

The citation requirement is not a nicety. A quality conclusion that cannot be traced to a record is not usable in a quality system, so anything generated has to be attributable back to source data or it fails the only test that matters.

Discovery

Thirty-five interviews with manufacturing, quality and operations people before building the parts that mattered.

Three findings changed the product:

Nobody wanted a replacement quality system. They had one, usually mandated. What they wanted was something that made the one they had usable — which moved the product from “system of record” to “layer on top of the records.”

Output without provenance was worthless. An unsourced answer, no matter how correct, created work instead of removing it, because someone still had to go verify it. Citation moved from a feature to a constraint on the whole design.

The ERP integration was the hard requirement for organizations, and a blocker for individuals. That split produced the two-track structure: a complete quality toolkit that works on a team’s own uploaded data, and an organizational tier that adds the ERP layer.

What I built

Product surface
AreaWhat it doesStatus
OperationsSAP-connected dashboard with grounded insights, recommended actions and plant-level operating context.Core
ShiftBriefDaily shift handoff and tier-meeting material generated from the plant context available to the team.Beta
FMEAFailure-mode records with AI-assisted scoring and structured evidence rather than a free-form chat transcript.Beta
CAPA LensCorrective and preventive action records with staged ownership, evidence and effectiveness checks.Beta
EscalationsTime-based evaluation of overdue CAPAs with tiered notifications, acknowledgement and resolution states.Beta
PlaybooksStep-by-step response procedures with roles, timing and execution history for repeatable plant response.Beta

Scroll table horizontally →

The repository also contains an SAP OData client, scheduled synchronization, sync state and logs, cached entity snapshots, and an approval-queue path for quality-notification write-back. That integration has been exercised primarily against the mock connector; true incremental synchronization and production SAP hardening remain in progress. SAP remains the intended system of record.

Architecture

The shape that matters is the pipeline: raw operational sources become structured manufacturing context before any reasoning happens, and every output carries its citations back out.
  1. Sources

    ERP (SAP), uploaded documents and spreadsheets, inspection records, supplier certificates.

  2. Ingestion & sync

    Scheduled read-only ERP sync plus document upload into private storage; access is granted through server-minted signed URLs rather than public links.

  3. Structured manufacturing context

    Normalized into a relational model — the step that makes the rest possible. This is the part that actually took the time.

  4. Reasoning layer

    A hosted LLM API used for report generation, chat over context, and FMEA/CAPA assistance — always over retrieved records, never from memory.

  5. Quality & operations workflows

    FMEA, CAPA, RCA, nonconformance, escalation sweeps, reporting.

  6. Cited output

    Every generated claim resolvable to the record it came from, so it can survive a quality review.

Implementation
LayerTechnology
FrontendReact 19 + Vite + TypeScript, tRPC client with React Query
BackendNode / Express single process, tRPC server, Drizzle ORM
DatabasePostgres (Supabase), roughly 32 tables, migrations applied as idempotent scripts
StoragePrivate object storage buckets; all access via server-minted signed URLs
ReasoningHosted LLM API — streaming chat, report generation, FMEA/CAPA assists
SchedulersERP sync with write-back reconcile; quality sweep for escalation evaluation
PlatformCookie sessions, Google and Microsoft SSO, Stripe billing, transactional email, audit trail
HostingSingle Node process behind nginx with TLS, process-managed on a VPS

Scroll table horizontally →

Validation

A 20-user pilot at a manufacturing company. The pilot was scoped deliberately around the quality workflows rather than the chat surface, because the workflows are where a wrong answer has a consequence and therefore where the design had to be proven.

What held up: structured records with provenance, and the escalation sweep — the least glamorous feature and the one that changed behaviour, because it made aging items visible without anyone having to remember to look.

What did not: my first version assumed people would ask open questions. They mostly did not. They wanted the system to produce the artifact they already owed someone — a report, a CAPA, an FMEA row — which is a much narrower and much more useful product.

Engineering judgment

What decision had to be made?

Whether AutoOps should be a system of record for quality, or a reasoning layer over existing systems of record. This is the decision the entire architecture hangs on, and it had to be made before the data model.

What evidence mattered?

Discovery was decisive. Every organization with a real quality function already had a mandated system, frequently tied to an ISO certification, and none of them were going to move their records into a new platform for a pilot. The binding constraint was therefore not feature coverage — it was that any output had to be traceable to the existing record. That points to a layer, not a replacement.

What would cause me to change the decision?

If the pilot had shown that teams were maintaining quality records predominantly in spreadsheets rather than in a governed system, the answer flips: the record itself is the gap, and the right product is a lightweight system of record. I also treat one result as a live risk to the current answer — if the write-back path to the ERP proves unreliable in production, then the layer cannot close the loop, and the honest response is to narrow the product to read-and-advise rather than pretend the integration works.

What I learned

Manufacturing quality depends as much on information architecture as on analytical technique. The methods are well established and mostly taught correctly. The reason investigations are shallow is that the evidence is expensive to assemble, and that is an architecture problem.

Traceability is a product requirement, not a compliance checkbox. An answer that cannot be sourced cannot be used in a quality decision, so citation had to be designed into the data model rather than added to the output.

The unglamorous feature won. A scheduled sweep that makes aging items visible changed more behaviour than anything generative, which is consistent with everything I have seen on a shop floor: the control that runs without being remembered is the one that works.

Building the product changed how I do the day job. Having to model nonconformance, CAPA and FMEA as data forced precision about what those records actually require — which is now how I think about closure evidence in a plant.

Tools & methods

  • TypeScript
  • React
  • Node / Express
  • tRPC
  • Postgres
  • Drizzle ORM
  • LLM APIs
  • SAP integration
  • Customer discovery
  • Product design

Related

The quality methods this product operationalizes are the ones applied by hand in the scrap reduction case study and in the 8D investigation.

Disclosure

AutoOps AI is my own product. Nothing on this page describes any customer’s data, configuration or quality records, and the pilot organization is not named.