our recipe check trusts whichever insert I say I fitted

The designer can add an asymmetric locating feature. That would stop reversal, but the other product-family insert would still fit the base correctly.

Then that's two different problems. Key the orientation, and get controls to review how installed insert identity is checked against the selected recipe. Don't ask one feature to do both jobs if it can't.

We had been calling both 'wrong nest', which probably explains the argument. I'm splitting them in the review, with seating as another condition to check.

Yes, a recognised insert can still be sitting on a chip. We learned that with a perfectly correct label on a fixture that wasn't down on its supports.

What does the current 'nest present' input actually detect? If it's just metal somewhere near a sensor, don't rename it 'seated' and hope nobody notices the difference.

Fair question. I assumed there wasn't a sensor yet, but you haven't said either way.

Also check how stores names the two inserts, because ours shared a stock description long after the drawings stopped being interchangeable, which made the wrong pick rather easy.

Keep the human-readable identity as well as whatever controls proposes. Maintenance still needs to identify the thing in their hand when it isn't installed.

What should happen if the identity can't be read? Put that in the requirements now. A failed read mustn't quietly mean 'use the last recipe'.

There is no sensor yet, just a proposed present signal. Controls is reviewing identity, seating and unreadable states separately; the last recipe won't count as confirmation of the installed insert.

And who can authorise the changeover after a mismatch? The operator needs an approved way forward, not a box they can tick until the warning goes away.

Our process owner will define that with the operators. We haven't chosen the identification hardware, and I won't pretend the revised wording is a tested system.

Tooling has proposed the asymmetric feature, stores has distinct insert descriptions, and controls has the failure cases. Next is a combined design review, still before automated use.

Include a wrong-family insert fitted the right way in the checks. That's the one your new key deliberately won't stop, so it's a good test of whether the identity check really does its job.