Process / engineering note
How we decide what to make
Every marketplace has an algorithm that tries to infer your part from an upload. Every small shop can make the opposite mistake and wait for a person to inspect everything from scratch. We analyse the actual geometry, derive a manufacturing proposal from it, and then put that proposal in front of a person who runs the machines.
First, establish whether the geometry says what it thinks it says
The manufacturing conversation starts with a coherent physical volume.
A file can look plausible on screen and still be a poor manufacturing input. A missing face may show only as a line. Two surfaces can occupy the same place. An assembly export can contain overlapping bodies, reversed normals or parts at a different scale from the drawing that accompanied it. The first job is to determine whether the mesh or solid represents a coherent physical volume.
We inspect topology, connected components, bounds and orientation before discussing material. This does not replace engineering responsibility for the design. It makes sure the manufacturing conversation starts with the same object you intended to send. If the geometry needs repair or its units cannot be established, that becomes a flag and we contact you before work continues.
For an engineer, STEP is especially useful here: it preserves design intent as editable surfaces and solids. A mesh can still be a perfectly good input, but it asks us to infer more of that intent from triangles. The file requirements page explains the practical difference.
Then, make slicing a consequence of the part
Slicer settings follow the part’s visible and functional surfaces.
Slicing is not merely converting geometry into machine movements. The choices determine where layers meet, which surfaces receive support, where the nozzle slows, and whether the part is being favoured for surface appearance, feature definition, robust deposition or a more aggressive reduction in print time.
Our internal product-to-manufacturing system, called Nidavellir, examines the mesh and combines that reading with the selected material, nozzle and print goal to derive a settings recommendation. It records why the proposal was made, so a reviewer sees more than a profile name. The system is internal and still in development. It assists a decision that remains accountable to the person reviewing the job.
The normal slicing modes are finish-preserving. The most aggressive mode is deliberately treated differently: if a proposed change may affect visible finish, the tooling must surface it as a quality risk. It is not permitted to silently trade a visible face for speed. That distinction matters when the part is a customer-facing housing, a reference fixture or simply something you need to inspect honestly.
Route selection is tied to evidence
Recorded requirements make a proposed route explainable.
There is more than one way to place the same part on a build surface, choose a nozzle, select a material or divide a large form. The plausible choice is not always the right one. A route is selected against recorded evidence about the material and the actual requirements you declare, rather than a remembered default or a salesperson’s preference.
That evidence-bound approach has a deliberately mundane benefit: it makes the explanation reproducible. If the proposed route depends on a material requirement, orientation risk or support strategy, the reviewer can see the reason and test it against the file. Where the evidence does not support a choice, we ask rather than making the assumption for you.
It also gives revision control its proper weight. A changed wall, bore, interface or material callout can invalidate the old decision. A new revision goes back through the same reading, even when it resembles the last one. Repetition is useful only when the inputs are still the same.
Why a person still holds the decision
The missing context is often the decision itself.
Automated analysis can find a thin feature, but it cannot know whether that feature is a disposable locating tab or the one surface that must seal against another part unless you tell us. It can identify an overhang, but not whether its underside will ever be seen. It can propose a material route, but it cannot settle an incomplete service requirement by pretending the missing information is irrelevant.
The reviewer’s job is to read the evidence in context, ask the question that changes the decision, and write the consequence in plain language. That is why the review email names what we would change. The handoff is not a ceremonial approval after automation. It is the point at which the geometry, the intended use and the manufacturing plan become one decision.
What a useful decision record contains
Another engineer should be able to understand the route.
A good review leaves a trail another engineer can understand. It identifies the received file and revision, the geometry findings, the proposed orientation and nozzle, the material rationale, any support or segmentation consequence, and each flag or warning. The review does not claim that a generic configuration can answer every unknown. It records what is known and calls out what is not.
This is the difference between a fast response and a guess. The goal is not to make the conversation longer. It is to make the first answer carry the information that lets you decide what to do next.
Where the time goes
Useful automation keeps interpretation and validation together.
The work is not saved by asking a machine to write CAD without context. It is saved by carrying the interpretation of the reference material, the validation result and the slicer setup in the same record. When a physical fit finds a correction, that correction can go back into generation instead of being reconstructed by hand from a disconnected file and remembered settings.
That chain is visible in the factory scale model, switchbox enclosure and resin projects. It includes the parts that are easy to skip in a summary: what the reference material did not say, what the validation gate found, and what changed once a part was handled on the bench.
Start with the actual part
Send the file, or explain the requirement and the environment it must serve. We will read it before we make anything.