A tool library can contain a technically valid JSON document and still describe an unsafe or unqualified insert substitution. The useful software problem is not to guess whether two inserts fit. It is to prevent an incomplete review from silently becoming an approved assembly record.
Consider a hypothetical replacement for a shoulder-milling cutter. Two insert descriptions share a size fragment such as 1604. A string-prefix comparison would accept them. But it knows nothing about the cutter pocket, clamping screw, support surfaces, corner envelope or the operation being released.
Validate evidence, not a resemblance
Keep three questions separate:
- Is the exact cutter/insert pairing approved in an identified source?
- Has the physical assembly and cutting envelope been checked?
- Has the defined operation passed its first-piece checks?
An unknown pairing is not a failed test cut. It is a reason not to run that test yet. A known incompatible pairing is a different state again.
Here is a deliberately small Python validator for the record. It does not certify a physical tool or generate machine instructions.
def review_state(record): pairing = record.get("pairing_status", "unknown") if pairing == "incompatible": return "blocked", ["Catalog pairing is incompatible"] missing = [] if pairing != "verified": missing.append("Exact pairing has not been verified") fields = ( "body_code", "insert_code", "pairing_reference", "fastener_reference", "assembly_measurement_reference", "cam_revision", "operation_id", "first_piece_reference", ) for field in fields: value = record.get(field) if not isinstance(value, str) or not value.strip(): missing.append(f"Missing {field}") for field in ("seat_checked", "envelope_checked", "first_piece_passed"): if record.get(field) is not True: missing.append(f"Unconfirmed {field}") if missing: return "hold", missing return "ready_for_authorized_review", [] The return value intentionally does not say safe_to_machine. Non-empty references can still be wrong, stale or fabricated. An authorized reviewer must examine their contents and the actual tool. In a production system, references would point to controlled records with revisions, ownership and access checks.
Test the default-deny behavior
assert review_state({})[0] == "hold" assert review_state({"pairing_status": "incompatible"})[0] == "blocked" # A string is not a confirmed physical check. bad = {"pairing_status": "verified", "seat_checked": "true"} state, reasons = review_state(bad) assert state == "hold" assert "Unconfirmed seat_checked" in reasons Using is True is intentional here: a truthy string such as "false" must not pass a checkbox-style gate. Also, a blank reference must not satisfy a requirement just because the key exists. The function checks both shape and a narrow meaning; it does not pretend to verify the document behind the string.
Why the operation ID belongs in the record
An assembly released for an open shoulder is not automatically released for a closed pocket. Different programs can introduce a collision, a deeper engagement or an inaccessible root even while calling the same tool number.
Treat a change to insert radius, body configuration, measured edge position or CAM envelope as a reason to revisit the affected operation records. Do not approve a whole tool family from one first-piece result. Equally, avoid claiming a universal numerical runout limit without the cutter maker's data and the feature's tolerance budget.
For a concrete geometry discussion, the related APKT/APMT interrupted-shoulder example shows why a familiar designation is not the same as a qualified cutting arrangement. The bench review checklist separates catalog pairing, fastener evidence and the resulting corner envelope.
The useful output of this little validator is a list of missing evidence, not an automatic machine release. That boundary is the feature.
Disclosure: this article and its illustrative code were generated with ChatGPT. The examples are hypothetical; the validator was tested for the stated record checks and is not a machine-safety system.
