Manufacturing Quality Intelligence Platform with Grounded RCA Agent

Investigation Workflow

Incident triage → Evidence review → AI-assisted RCA recommendation → Human engineering review → Corrective-action tracking → Effectiveness validation

The application structures the investigation before any provider call. A user opens an incident, reviews severity and defect movement, follows lot-to-unit process lineage, distinguishes suspected origin from detection, and compares baseline, issue, and validation windows. The assembled context includes process and equipment events, traceability, test history, bounded evidence rows, corrective-action records, and explicit evidence limitations.

The provider recommendation and the corrective-action record remain separate workflow artifacts. An engineer reviews the structured recommendation before accepting it or connecting it to an action. Post-action metrics are then compared with the issue period to assess effectiveness and recurrence.

What the AI Layer Does

• The application assembles typed incident evidence before creating a provider request.
• The configured provider receives bounded evidence and limitations as context, not the expected scenario answer.
• The provider returns a constrained RCA recommendation with classification, process roles, causal chain, confidence, limitations, corrective-action assessment, and evidence references.
• The asynchronous API streams workflow and status updates to the frontend while provider processing continues; these are progress events, not token-by-token model output.
• The server validates the final structured response, and an engineer reviews it before acceptance or corrective-action linkage.

No custom model was trained. The engineering focus was provider integration, evidence grounding, constrained structured output, workflow reliability, and human review. This is LLM application engineering rather than supervised model training: the project has no training loss, custom fine-tuned model, or claimed model-accuracy business metric.

Evidence boundary and hidden evaluation

Expected classification, origin and detection processes, required concepts, prohibited claims, and scenario-specific correctness criteria remain outside provider-visible prompts and tool results. Hidden evaluation runs only after schema, taxonomy, self-consistency, process-role, provenance, unsupported-statistical-claim, and evidence-grounding checks pass. The model receives evidence, not the expected answer.

A response can satisfy structure and grounding checks while still reaching a semantically weak conclusion. The server preserves that model-quality result rather than silently replacing it with the expected answer. Provider or validation failures are not represented as accepted conclusions, and the page makes no claim of automatic retry behavior.

Machine-verifiable evidence references

Each provider-generated reference contains a canonical tool_name and an RFC 6901 JSON Pointer path. The server confirms that the tool ran, checks that the path appeared in the referenceable catalog, resolves the scalar from the exact model-visible evidence snapshot, attaches a server-owned display label, and returns the resolved value. Duplicate, unavailable, container, or invalid references are rejected.

This contract reduces the risk of rounded, reformatted, altered, or hallucinated copied values. It provides server-resolved, machine-verifiable references; it is not cryptographic proof of causality.

Taxonomy alignment

PROCESS_NONCONFORMANCE means a required process state, record, control, verification, or manufacturing requirement is missing, invalid, unmaintained, or unverifiable. PROCESS_ESCAPE requires an independently established defect or nonconformance to pass an intended detection, containment, or control step. Downstream detection alone does not prove process escape.

In one controlled live 4552 acceptance, the provider returned PROCESS_NONCONFORMANCE, origin M031, detection M130, and HIGH confidence. All 12 references were accepted, the server did not overwrite the conclusion, and hidden evaluation passed. This is one acceptance case—not a universal accuracy claim, proof that all six scenarios received live-provider validation, or a guarantee that future responses will pass.

Architecture

The runtime request path moves from the user through the React frontend on Cloudflare Pages to the FastAPI service on Cloud Run. The API reads and writes Neon PostgreSQL and invokes the configured AI provider through a typed adapter. Database and provider credentials remain behind the API boundary.

The provider abstraction includes a DeepSeek Chat Completions adapter and an OpenAI Responses-compatible adapter. Both target the same structured analysis contract, keeping provider-specific transport separate from evidence assembly, validation, and human review.

Cloud Run Jobs sit outside the user request path and web-service startup. They run controlled Alembic schema migration and baseline/scenario initialization for the baseline dataset and six quality-investigation scenarios. Artifact Registry, Secret Manager, and Cloud Logging support build, secrets, and structured diagnostics without adding unused runtime infrastructure.

Data Model and Scenario Design

The initialized baseline contains 1,218 production-lot records, 10,000 PCB arrays, 80,000 detailed array units, and exactly 4,000,000 represented lot units. It also contains 276,415 baseline test runs and 2,124 baseline test-failure rows, providing large-scale analytical coverage for repeatable investigation and validation.

Six controlled quality-scenario overlays introduce physical defects, false-fail conditions, process nonconformance, equipment-related abnormality, upstream origin with downstream detection, corrective-action tracking, and validation behavior.

Key Screens

The incident registry gives engineers one review queue for comparing severity, defect movement, process roles, investigation state, and validation status before opening the detailed evidence workspace.

The corrective-action view keeps the intervention record separate from the provider recommendation and evaluates it against comparable issue and validation windows.

Operational Characteristics

Cloudflare Pages serves the frontend, Cloud Run serves the FastAPI API, and Neon supplies PostgreSQL over pooled TLS connections. The deployment uses managed container artifacts and server-side secret injection; credentials never become browser variables. Production raw RCA debug capture is disabled.

Cloud Run is configured with zero minimum instances and one maximum instance. Liveness performs no database or provider work; readiness checks database connectivity and the applied Alembic head. Request-correlated JSON logs record route, method, status, latency, and bounded RCA validation categories without provider content, prompts, reasoning, evidence rows, credentials, or connection strings.

The deployed cloud environment exposes the six-incident registry and detailed investigation views. In one controlled live-provider run, the request completed with HTTP 200 and emitted request-correlated structured logs, confirming the deployed path across the frontend, API, database, provider integration, validation pipeline, and rendered response.

The asynchronous RCA path exposes streamed workflow-status feedback so processing remains visible while the provider request runs. The final structured recommendation is separate from those progress events and still requires server validation and human review. Observed end-to-end investigation latency was approximately 49 seconds: a current runtime characteristic and provider-latency optimization opportunity—not an SLA, performance achievement, or cross-provider benchmark. The measured path includes provider latency; provider/model selection, context size, and asynchronous execution remain optimization opportunities.