Case study 04 · Product & engineering
AutoOps AI
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
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
| Area | What it does | Status |
|---|---|---|
| Operations | SAP-connected dashboard with grounded insights, recommended actions and plant-level operating context. | Core |
| ShiftBrief | Daily shift handoff and tier-meeting material generated from the plant context available to the team. | Beta |
| FMEA | Failure-mode records with AI-assisted scoring and structured evidence rather than a free-form chat transcript. | Beta |
| CAPA Lens | Corrective and preventive action records with staged ownership, evidence and effectiveness checks. | Beta |
| Escalations | Time-based evaluation of overdue CAPAs with tiered notifications, acknowledgement and resolution states. | Beta |
| Playbooks | Step-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
- Sources
ERP (SAP), uploaded documents and spreadsheets, inspection records, supplier certificates.
- 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.
- Structured manufacturing context
Normalized into a relational model — the step that makes the rest possible. This is the part that actually took the time.
- Reasoning layer
A hosted LLM API used for report generation, chat over context, and FMEA/CAPA assistance — always over retrieved records, never from memory.
- Quality & operations workflows
FMEA, CAPA, RCA, nonconformance, escalation sweeps, reporting.
- Cited output
Every generated claim resolvable to the record it came from, so it can survive a quality review.
| Layer | Technology |
|---|---|
| Frontend | React 19 + Vite + TypeScript, tRPC client with React Query |
| Backend | Node / Express single process, tRPC server, Drizzle ORM |
| Database | Postgres (Supabase), roughly 32 tables, migrations applied as idempotent scripts |
| Storage | Private object storage buckets; all access via server-minted signed URLs |
| Reasoning | Hosted LLM API — streaming chat, report generation, FMEA/CAPA assists |
| Schedulers | ERP sync with write-back reconcile; quality sweep for escalation evaluation |
| Platform | Cookie sessions, Google and Microsoft SSO, Stripe billing, transactional email, audit trail |
| Hosting | Single 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.