Architecting an AM Software Stack Around a Production-Level Quality Management Software

A mature software stack is not defined by how many systems it contains, but rather by whether each critical responsibility has an owner.

That matters in additive manufacturing because AM creates a class of information that sits awkwardly between enterprise systems, production quality evidence. ERP can hold the commercial context. MES can orchestrate work. QMS can govern procedures, approvals, and non-conformance. Yet none of these functions, by themselves, answer the question an AM organisation eventually has to defend, what evidence proves that this machine, material, parameter set and process route were capable of producing conforming parts consistently?

That is not simply reporting, it’s an architectural responsibility.

Think in planes, not products

For CTO and IT teams, a useful model is to separate four planes. ERP is the enterprise plane, orders, inventory, purchasing and cost. MES is the execution plane, jobs, routing, status and production flow. QMS is the governance plane, procedures, approvals, deviations, and CAPA.

amsight occupies the AM quality evidence plane beneath the enterprise layer and alongside execution. Its job is not to duplicate the systems above it, but to make the technical relationships below them usable (material history, machine condition, build context, parameter revisions, specimens, post-processing, inspection, and conformity evidence).

The distinction is important. A workflow tells you what should happen and records that an operation occurred. An evidence chain shows what actually happened in sufficient technical context to support a quality decision.

This changes integration thinking. Instead of forcing every machine, inspection source, and AM-specific data structure into MES custom fields, or reducing them to PDFs attached to a QMS record, the quality layer becomes a specialist service. It structures the evidence once, then makes meaningful outputs available to the wider stack.

Qualification is the architecture test

Process & Machine Qualification is where this model becomes concrete.

Qualification cannot be reduced to “build completed” or “report approved”. It must establish repeatability and continued control. That means comparing results across builds, machines, specimens, and conditions; applying SPC; identifying drift; preserving the context behind IQ, OQ, and PQ evidence; and reproducing the analysis later without rebuilding it manually.

If your architecture cannot do that cleanly, the problem is probably not the dashboard, it’s evidence ownership.

This is why amsight’s place in the stack matters. By providing the AM-specific quality software, it allows ERP to remain ERP, MES to remain MES, and QMS to remain QMS, while giving production and quality teams a structured system for the evidence those platforms were never intended to model deeply.

For CTOs, that means less customisation debt and cleaner integration. For AM leadership, it means qualification evidence that becomes reusable operational infrastructure rather than a project assembled for the next audit.

The most revealing question when reviewing an AM software architecture may therefore be simple, when the workflow says the job is complete, which system can prove the process was still under control?

Explore amsight Process & Machine Qualification.‍