Procurement & Evaluation
The Buyer's Guide To In-Situ QA
Requirements, red flags, and how to run an evaluation fairly
Most in-situ QA evaluations start in the wrong place. They begin with sensors, images, resolution, dashboards, and detection claims. All useful, but not sufficient.
The real buying question is simpler and harder: will this system help us make better quality decisions in production? For procurement influencers and QA leads, that distinction matters. A poor evaluation can lock a business into a system that generates data, but not confidence.
Start With The Production Requirement
Before comparing vendors, define what the business needs the system to support. Is the aim earlier anomaly detection? Reduced inspection burden? Better traceability? Part-level evidence? Process development? Fleet comparison? A stronger qualification package?
Different goals require different proof. A research tool can be valuable in R&D but still weak in production. A production QA system must help teams decide what to hold, review, release, investigate, or compare. That is the difference between monitoring and assurance.
The Questions Buyers Should Ask
A serious evaluation should cover more than sensing performance.
Machine Compatibility
Which L-PBF systems are supported today? Is the installation retrofit, production-frame, large-format, or OEM-integrated? How much disruption is involved?
Deployment
Can the system run in the environment your organisation actually allows: cloud, on-premise, or controlled internal infrastructure? Who owns the data? How is it retained? How is access managed?
Outputs
Does the system generate usable build and part reports, or does it leave engineers to interpret raw signals manually? Can reports support QA review, customer communication, and audit trails?
Correlation
How does the vendor link in-process signals to post-build evidence such as CT, metallography, or known process outcomes? Be cautious of anyone implying that every signal is automatically a defect.
Exception Handling
What happens when the system flags something? Is there a workflow, threshold logic, grading method, or review pathway?
Red Flags
- •Tools that only show attractive visualisations, with no clear link back to a decision.
- •Black-box claims with no practical explanation of how outputs support disposition.
- •Systems that create so much data that production teams quietly stop using them.
- •Evaluations that compare tools unfairly, mixing machine class, material, geometry, or inspection benchmark between vendors.
Use the same machine class, material, geometry, inspection benchmark, and review criteria wherever possible. Otherwise, you may simply be comparing test conditions, not technology.
Where AMiRIS Fits
AMiRIS has been developed around the realities that buyers should be testing for: machine compatibility, high-resolution in-process data, automated analysis, part-level evidence, reporting, deployment options, and a route toward more structured quality review.
The point is not to replace engineering judgement. It is to give QA and production teams better evidence earlier, in a form they can use.
For buyers, the first step should be practical. Check whether the system fits your machines, your data rules, your quality workflow, and your inspection strategy.
Run Your Evaluation With A Clear Checklist
We can walk your team through how AMiRIS answers each of these questions on your machines, with your material, and against your inspection benchmark.
Book a Demo