The Quality Agent

What it is, and what it is not

An agent scoped to quality records: nonconformances, complaints, corrective actions, supplier corrective action requests, audit findings and the evidence attached to each.

It is not a decision maker about product acceptance. Disposition — use-as-is, rework, scrap, return to vendor — is a judgement made by a person with authority and inventory in front of them, and no permission tier makes that the agent's call.

It also does not close anything. A CAPA closes when verification evidence exists and a human accepts it, and that constraint is enforced by the process rather than by the agent's restraint. An agent that could close a quality record would make the closure requirement negotiable.

What it actually does

Clusters what people described differently. Intermittent no-boot, unit fails at final test, power, PSU dropout on cold start and board dead on arrival may be one failure mode recorded by four people who were not talking to each other. Semantic similarity over descriptions, joined to the part at its revision, finds the cluster.

Drafts the 8D. Given an issue with evidence attached, it prepares the structured write-up — problem statement, containment taken, root cause candidates, corrective action proposed — with each element cited to the record it came from. A person edits and owns it.

Flags what is about to go wrong. CAPAs approaching a verification date with no evidence attached, issues in containment longer than the policy allows, SCARs where the supplier has not responded. These are rules over dates and states, not judgements.

Answers the recurrence question. Asked whether a new failure has been seen before, it traverses to prior issues on the same part, the same manufacturer part, the same process step — and reports whether their corrective actions were ever verified effective.

The failure it prevents

A batch fails inspection. An NCR is raised, the batch quarantined, a supplier process drift identified, a SCAR issued and answered, the NCR closed. Sixteen weeks of work, and it seemed to work.

Fourteen months later the same part fails the same way. The new investigation starts from nothing, because the previous NCR closed against a free-text description and searching for that description returns forty unrelated records. Nobody involved was there the first time.

The whole cost of the first investigation is paid again — and the second one reaches the same conclusion, because the first corrective action was never verified as effective and nobody knew to check. Surfacing that in the first hour rather than the fourth week is most of what this agent is for.

How it meets the rest of the product

Clustering works because issues attach to real objects — the part at the revision that failed, the supplier and manufacturer part, the process step, the requirement violated — rather than to a description. Semantic similarity narrows the candidates; the object graph confirms them.

Where a corrective action requires a design change, the agent drafts a real ECO through the ordinary process rather than describing one. The impact set is computed deterministically by a service with no model in its path, so the affected objects on an agent-drafted change are byte-identical to those a person would get.

Every claim cites the issues, parts and revisions behind it, and because the underlying queries are deterministic a reviewer can re-run them and get the same result. That matters more in quality than elsewhere: a clustering claim that cannot be checked is a story about the data rather than a finding.

Agent actions land in the same hash-chained audit trail as everything else, naming the agent, its tier, the tools it called and the revisions it read. An auditor asking how a record was created gets an answer that is not “the AI did it”.

How it meets your ERP

Quantities and stock context come from your ERP and are cited as such. When the agent reports that a nonconformance affects a batch, the on-hand, committed and open-order figures beside it are a cached read of somebody else's master record with an as-of stamp, not something Manufacturing PLM vouches for.

That context is what makes a containment recommendation useful rather than abstract. Quarantining a lot with four units in stock is a different conversation from one with eleven weeks of coverage and two purchase orders in flight, and the agent shows both rather than reporting the defect alone.

It will not transact. No inventory holds, no quarantine movements, no returns to vendor. Disposition is recorded in Manufacturing PLM as a decision with an owner and a quantity; the stock movement happens in your ERP where it belongs.

Where the boundary is

It does not determine root cause. It proposes candidates from the evidence and the history, and a clustering result is a hypothesis that an engineer confirms or rejects. Two failures that look identical in the data can have different causes, and an agent asserting otherwise would send an investigation down the wrong path with unearned confidence.

It also cannot see what was never recorded. An issue resolved in a corridor conversation and never raised as a record is invisible, which is the ordinary limit of every feature here — and the reason the honest output is “nothing found” rather than “no prior occurrence”.