Towards Certification
From Monitoring To Assurance
Defining decision-ready QA: release logic, thresholds, and accountability
Metal AM does not have a shortage of monitoring data. It has a shortage of decisions people can stand behind.
That is the uncomfortable truth behind many in-situ monitoring projects. A system is installed, it captures signals, it generates layer images, heatmaps, plots, alerts, and anomaly scores. The technical team is interested. Then Quality asks the question that defines the whole business case: “what decision does this support?”
If the answer is vague, the system is monitoring. If the answer is clear, repeatable, documented, and connected to release logic, it is moving toward assurance.
That distinction matters because production AM is not an academic exercise. Quality, metallurgy, and manufacturing engineering teams are not paid to admire data. They are paid to protect the process, release good parts, investigate risk, and avoid late-stage surprises that create rework, over-inspection, and schedule drag.
The Three Questions That Define Assurance
A production QA system must answer three questions.
First: What Happened, Where, And When?
A useful system must localise the event. Which part? Which region? Which layer? Which build area? Which time in the process? “Something looked abnormal” is not enough. Without localisation, NDT cannot target intelligently, metallurgy cannot interpret context, and manufacturing engineering cannot investigate root cause.
Second: Does It Matter?
This is where many monitoring systems struggle. Not every unusual signal is a quality event. Metal AM is noisy, thermal, dynamic, and often more resilient than people give it credit for. Some signals matter. Some are process variation. Some may correlate with risk only in specific geometries, materials, or process windows.
That is why thresholds matter. They do not need to be perfect on day one, but they must exist. What triggers review? What triggers hold? What requires correlation with CT, metallography, or mechanical testing? What is simply archived? Without agreed thresholds, the system becomes an argument generator.
Third: Who Owns The Next Decision?
This is the accountability question. If an anomaly is flagged, who reviews it? Quality? Manufacturing engineering? Metallurgy? NDT? The operator? What is the escalation route? What gets recorded? What evidence supports release?
A decision-ready QA system must fit the organisation, not float above it.
Release Logic Beats Dashboard Theatre
Too much in-situ monitoring is sold through impressive visuals, but the problem is that visuals do not release parts. Release logic does.
A decision-ready report should show build context, part-level evidence, anomaly localisation, severity, trend behaviour, comparison to known good behaviour, and a clear exception pathway. It should help the team decide whether to:
- •Proceed
- •Hold
- •Audit
- •Escalate
- •Investigate
That does not mean in-situ QA replaces NDT overnight. It means NDT becomes better informed. Instead of treating uncertainty as a reason to inspect everything more heavily, teams can use in-process evidence to focus attention where it is justified.
That is where the economics start to change. The cost of poor quality is not just scrap. It's extra inspection, delayed release, rework loops, lost machine time, and programme disruption. Earlier evidence helps reduce the cost of learning too late.
Where AMiRIS Fits
AMiRIS is built around this shift from monitoring to assurance. It captures layer-by-layer L-PBF process data and converts it into structured outputs that support review, traceability, comparison, and quality decision-making. The value is not simply in seeing the build. It's in making build behaviour usable: helping teams understand where risk may have emerged, whether it warrants action, and what evidence should be retained.
For Quality and metallurgy teams, that means fewer blind investigations. For manufacturing engineering, it means faster feedback on process behaviour. For production leaders, it means a more disciplined route to reducing uncertainty before it becomes expensive.
The practical test for any in-situ QA system is simple: ask to see the report. Not the sensor, not the dashboard, but the report. Because the report reveals whether the system supports release logic, thresholds, traceability, and accountability, or whether it simply produces more data for someone else to interpret later.
Request A Sample AMiRIS Report
Check compatibility with your machines, or see a real build report and how it supports release logic, thresholds, traceability, and accountability.
Request a Sample Report