Judge a part before you quote it.
One call over the STL, back in seconds, with nothing uploaded and nothing meshed by you. It reports what the geometry alone can tell you: whether the walls sit inside your limits, how far the melt has to travel, and where it arrives last.
The limits are yours to set, so the verdict is yours too. Move the thin-wall limit and a pass becomes a concern, which is the point rather than a quirk.
Read the manufacturability check at https://toolkit.simcon.ai/use-cases/dfm-check and set it up in this folder, following the setup page it links to. My part is the STL in this folder. Run the check against our own wall-thickness limits and tell me what would stop us quoting it, with the place on the part each finding came from.
What it said, and why
These are the verdicts, timings and element counts the check actually returned on eight parts. Pick one and it tells you which check drove the answer.
The wall measures 2 mm against the 1.2 mm you hold to, so it clears that today · take the wall down and the check turns before you reach the limit.
All 9, on every part
All nine checks run on every part, and the report carries each one whether it found anything or not. A consumer parsing the JSON gets the same nine ids every time, so nothing has to be inferred from an absence.
The report verdict is worst-of over the checks that aggregate, and the shipped schema asserts it. Flow path and air traps are information and never move it. On the parts measured here only 2 of them ever moved a verdict, which is why the report verdict has so far been a wall-thickness verdict.
Fast enough to run while someone is talking to you
Time tracks the part rather than the element count · the 39 k cover takes longer than the 59 k one. The licence session costs a few seconds on first use and is then held for the process.
A versioned document, not a print-out
The report is one JSON document with a schema that ships in the wheel and validates the whole 1.x range. It asserts real invariants rather than shapes: the report verdict is worst-of over the aggregating checks, every one of the nine ids appears exactly once, and a skipped check must carry a reason.
Ids are open strings rather than an enum, so a later minor version can add a check and an old consumer ignores it. Pin to major 1 and parse with confidence.
Two things worth knowing
no gate could be suggested, so these could not run · a runtime skip, not a missing feature. With every check built, a skip can only mean the run could not do it on this part · read the reason and you have the whole story.
Gate coordinates are refused unless they project onto the geometry, so a point from a bounding box or a CAD annotation will generally not survive. Snap every gate to the nearest actual vertex and it always works.
The cheapest question to ask first
Before a solver run
Nothing is uploaded and nothing is charged. If the geometry is not closed or the wall is outside your limits, you know before spending a run on it. Then use case 02 puts it through the solver.
Before a gating decision
The flow-path check suggests gates and reports the longest path from each. When that becomes the question rather than a sanity check, use case 03 scores the candidates properly.
Next: put the part through the solver
The geometry passed. Use case 02 runs one filling simulation on it and reads the peak cavity pressure back.