How To Use Partglyph Results

This page explains the shared workflow engineers should follow before reading any product-specific result. Product pages add the exact class, tag, and gate behavior for each matcher.

Core Rule

Partglyph results are evidence-backed recommendations, not automatic procurement approval. A result is only useful after the engineer checks status, product class, evidence quality, blockers, and product-specific caveats.

Result Reading Workflow

1. Check the top-level status.
2. Confirm the resolved reference is the intended product.
3. Read the product-specific result class.
4. Check hard gates, conditional flags, risk tags, missing information, and evidence.
5. Review the technical snapshot fields that drove the decision.
6. Follow the product-specific next action.
7. Do not quote a stronger conclusion than the evidence supports.

Top-Level Status Actions

Status	What it means	Engineer action
OK	Matching completed normally.	Read product class and evidence before recommending anything.
AMBIGUOUS_MATCHES	Input maps to more than one plausible reference or candidate.	Ask for identifying details; do not select a replacement from this result alone.
INPUT_RECHECK_REQUIRED	Input conflicts, is too weak, or is unsafe.	Correct or add source data before interpreting candidates.
NO_REFERENCE	No defensible reference was found.	Request part number, datasheet, nameplate, dimensions, or standard code.
ERROR	Runtime failure.	Treat as no technical result; retry or escalate with request payload and trace.

What Engineers Can Say

• Use “candidate appears compatible” only when the product class supports it and evidence is present.
• Use “requires engineering review” when conditional flags, missing evidence, or advisory classes appear.
• Use “not enough information” for ambiguity, input conflicts, no reference, or low-confidence extraction.
• Use “blocked” or “rejected” only when a product-specific hard gate or policy clearly supports that wording.

What Engineers Must Not Say

• Do not call ambiguous, discovery, or recheck output a replacement recommendation.
• Do not call an advisory class procurement-ready.
• Do not hide missing evidence because the score or rank looks good.
• Do not flatten product-specific classes into a generic “match/no match” answer.
• Do not treat ball valve grouped results as the same shape as bearings, chains, or belts.
• Do not turn a hard safety caveat into a soft note.

Shared Next-Step Language

Use these phrases consistently:

Situation	Recommended wording
Good evidence and product class allows replacement	”This is a supported replacement candidate based on the checked gates.”
Conditional class or warning tag	”This candidate needs engineering review before use.”
Missing decisive field	”Add or verify the missing field before deciding.”
Ambiguous reference	”Confirm the exact reference product before reviewing replacements.”
Input conflict	”The input contains conflicting evidence; resolve the conflict first.”
No reference	”No defensible reference was resolved from the supplied data.”
Ball valve procurement blocker	”This result is not procurement-ready because release blockers remain.”

Evidence Discipline

Every engineer-facing page should separate:

• What the user supplied.
• What the intake system extracted.
• What the canonical product record supplied.
• What the matcher inferred.
• What is still missing or uncertain.

When evidence is uncertain, collect the next piece of proof before making a stronger claim. Good examples include a full part number, OEM datasheet, standard designation, critical dimensions, service requirements, nameplate photo, or catalog row.