Teach your agent to set a process window it can defend.
A new mould, trials tomorrow. Three things have to be decided before anyone touches the machine: which parameters to vary, where to centre them, and how wide the bounds may be. That used to mean standard settings ±10 % and a guess, because there was never time to simulate.
This example is that method written down for an agent to follow. One config file, and out comes a mapped design space, a defensible centre point, bounds justified against a physical failure boundary, and the runs that confirm them.
Right tool
- The process window has to survive being questioned.
- Somebody will ask why those bounds and not others.
- The part is new, so experience gives no starting point.
- Machine time is the expensive resource and simulation is not.
Reach for something else
- One answer about one setting - that is example 02, a single run.
- The gate layout is the open question - example 03.
- Warpage or packing behaviour is the question. The AI solver does not cover it - the numerical engine does, and it is the right tool for that job.
- You need matched AI-to-numerical accuracy. The AI solver is used here to exclude regions. Absolute values come from the numerical confirmation set.
Run the campaign
Eight stages on the bundled part. Press run to watch the design space fill in, or click any stage to see what it settles and what it leaves on disk.
Your agent drives the stages. You decide whether the window is one you would sign off.
A space-filling design over injection rate, melt temperature and mould wall temperature. Each result is scored down to a small record and the heavy file deleted, so the whole campaign costs a few megabytes of scratch.
One config file, then the stages in order
Point the config at your STL and material grade. Every command below is safe to re-run: finished work is recognised and skipped.
$ python src/inspect_part.py your_part.stl$ python src/run_epsilon_floor.py configs/your_part.yaml$ python src/probe_proxy.py configs/your_part.yaml$ python src/run_sweep.py configs/your_part.yaml$ python src/run_screening.py configs/your_part.yaml$ python src/run_refine.py configs/your_part.yaml$ python src/run_confirm.py configs/your_part.yaml$ python src/emit.py configs/your_part.yaml
Four artefacts, all readable
The checks that make it defensible
A recommendation is only as good as what would have caught it being wrong. Four independent checks run inside the campaign, on a sample part shipped with the example.
The bounds go to the physics solver to check
Centre, six box faces and probes outside the edge, on the same mesh as the AI runs.
A hidden input error shifts everything equally
So every rank and ratio passes through unchanged · ordering agreement 1.0.
Refinement finds the boundary, not the middle
It lands on the feasibility edge 25 times more often than blind sampling.
The safety margin is reported as zero
No constraint is active at the centre, so nothing was invented to fill the gap.
Three rules, enforced in code
A lint enforces them: break one and the run fails. They are the part most worth copying into your own pipeline.
Relative statements only. Every criterion is a rank, a ratio or a comparison. An absolute pressure threshold in any criterion fails the run, because the AI solver under-reads absolute pressure on multi-gate parts.
Noise floor derived per part. Measured for this part, and applied relatively - a fixed absolute figure under-protects the high-pressure corner.
Limitations attached automatically. Any claim resting on absolute values carries its caveat into the dossier without anyone remembering to add it.
Known limits · read before quoting a number
- Three variables are exposed on the AI filling endpoint currently, with more coming. Switchover, holding pressure and time, and cooling enter through the numerical confirmation set in the meantime.
- Machine limits annotate the recommended box. They never include or exclude a point.
- The material card drives the box, the gate and the pack nominals - change the grade and all three move.
- Cooling inside the sweep is analytic. Where it needs to be simulated properly, it runs on the numerical path.
Adapting it to your part
Start at G0. If fill time and freeze time are not close on your geometry, the sweep will not discriminate and the campaign is not worth running - that check is free and takes seconds.