Structuring Powder, Process and Inspection Data: Requirements for an AM-Specific QMS

‍

Most quality management systems are built around a familiar logic: documents, approvals, procedures, forms, deviations, corrective actions, and audit trails. That logic is essential, but in additive manufacturing, it is not enough.

AM quality is not only about whether the right document exists. It is about whether the production evidence behind a part can be connected, queried, and understood across the full process chain. That is where generic QMS tools often begin to struggle.

They can store a report. They can manage a sign-off. They can attach a certificate. But AM quality asks a more difficult question. Can the system model the relationships between powder, process, and inspection data in a way that remains usable at production scale?

For CTOs, IT teams, and integration partners, this distinction matters. If AM quality evidence is treated as a documentation layer only, the architecture becomes fragile very quickly.

AM Data is Not Flat

A conventional QMS is often comfortable with records that behave like files (a procedure, a non-conformance report, a certificate, a release document). AM data behaves more like a network. A single part may connect to a powder batch, a powder reuse cycle, a blend ratio, a build job, a machine, a parameter set, a build layout, an orientation, a maintenance event, a heat treatment route, a machining operation, a cleaning step, CT results, mechanical test results, and customer-specific acceptance criteria.

These relationships are the quality story.

If they are held together through attachments, exported spreadsheets, or custom fields inside a generic system, the data may be stored, but it is not truly structured. That becomes obvious the moment someone asks a production question like “which parts were built with this powder condition, on this machine, under this parameter revision, and how did they perform after post-processing?”

A generic QMS may tell you where the documents are. An AM-specific QMS must tell you what the evidence means.

Why MES and ERP are Not the Answer on their Own

ERP and MES are not the problem. They are necessary parts of the production stack. ERP owns the business reality (orders, inventory, purchasing, costs, finance, customers, and suppliers). MES owns execution (routing, scheduling, WIP, timestamps, sign-offs, and production workflow).

But AM quality evidence sits in a different category. It needs to model material genealogy, machine context, process history, inspection outcomes, qualification status, and stability over time. When that burden is pushed into MES, the system often becomes overloaded. Teams add fields, attach PDFs, build custom reports, and export to Excel for analysis. The result looks functional until production scales, customer requirements increase, or qualification evidence has to be reconstructed across multiple builds.

That is why amsight sits under ERP and alongside MES as the AM-specific quality layer. It does not try to replace business truth or execution truth. It provides the missing quality evidence truth.

Connected Evidence

For AM quality management to work at production level, the system must do more than hold documents. It must connect the chain from powder to part. That means powder data cannot be isolated from build data. Build data cannot be isolated from machine events. Machine events cannot be isolated from inspection outcomes. Inspection outcomes cannot be isolated from part conformity, qualification status, or customer reporting.

This is especially important for powder-bed AM, where variation may be influenced by powder condition, machine state, parameter selection, environmental factors, maintenance, build layout, and post-processing. If the relationships between these factors are not structured, root-cause analysis becomes manual reconstruction.

The system should make the question easy. What changed before quality changed?

Process Qualification as the Architecture Test

The most useful way to explain this to an IT audience is to use Process & Machine Qualification as the test case (https://www.amsight.de/use-cases/process-machine-qualification).

Qualification is where weak data architecture is exposed. It demands repeatability, statistical process control, IQ/OQ/PQ evidence, machine consistency, drift detection, and documentation that can be generated again without rebuilding the story from scratch. If your system can support qualification well, it is probably structuring AM data correctly. If qualification still depends on manual test analysis, copied spreadsheets, one-off charts, and engineers interpreting consistency by “feel”, the issue is not simply workflow, it’s architecture.

amsight’s Process & Machine Qualification use case is powerful because it shows what an AM-specific QMS must provide (built-in SPC, control charts, capability views, trend analysis, automatically linked evidence, and repeatable qualification reports).

This is not a dashboard exercise. It is a data model exercise.

What an AM-Specific QMS Must Provide

An AM-specific QMS should ingest machine data, log files, inspection reports, and production documents automatically wherever possible. It should normalise data across different machines and systems. It should keep the evidence connected at part, build, machine, material, and process level. It should support SPC and root-cause analysis without every investigation becoming a spreadsheet project.

Most importantly, it should fit the existing IT landscape rather than compete with it.

That is why the “quality layer under ERP and alongside MES” framing matters. ERP continues to manage commercial reality. MES continues to manage execution. The AM-specific quality layer manages the evidence chain that AM uniquely requires.

For IT teams, this reduces customisation debt. For QA teams, it reduces manual documentation. For production teams, it makes drift and variation easier to understand. For customers and auditors, it makes quality evidence repeatable rather than reconstructed.

The Category Mistake to Avoid

The biggest mistake is asking a generic QMS to behave like an AM process intelligence system. It can be done temporarily. Many companies start that way. But as the number of machines, materials, builds, customers and regulated requirements increases, the cracks appear. Reporting becomes manual. Traceability becomes dependent on folder discipline. SPC becomes difficult. Root-cause analysis slows down. Qualification evidence becomes harder to reuse.

That is the moment when “we need a better report” is really saying “we need a better quality data architecture.”

AM production does not need another document repository. It needs a structured quality backbone built around the realities of powder, process and inspection data. That is what makes AM quality management different. And it is why generic QMS tools struggle when AM stops being a prototyping activity and becomes real production.