Fields mean different things
A size token in a valve search is not the same kind of evidence as a bore in a bearing search or a profile in a V-belt search.
LLM-friendly product family docs
AI agents need product-family field guidance before they can prepare useful replacement requests.
A general AI model can read part text, but it still needs to know what fields matter for each industrial product family. LLM-friendly docs help Codex, Claude Code, and other agents prepare cleaner Partglyph requests without pretending the agent is the compatibility authority.
Documentation problem
Most product data is written for catalogs, not for replacement-review agents.
AI agents need more than a list of field names. They need guidance on what to collect, what is central, what is optional, and what should be treated as a missing review check. A product-family document should teach the agent the shape of the review: which clues are useful before the request is prepared, which fields should stay attached to each candidate, and which gaps should be carried back to the user instead of being smoothed over.
Prompts need boundaries
The documentation should tell agents to prepare evidence and call Partglyph, not to invent final compatibility language.
Missing inputs need labels
When a field is missing, the agent should know whether it blocks review, weakens confidence, or becomes a supplier follow-up question.
Doc structure
A useful family doc tells agents what to collect and how to frame gaps.
The goal is not to publish every internal rule. The goal is to help agents prepare cleaner input and explain result evidence in a way humans can review. That means the family doc should improve the question before Partglyph runs and improve the summary after the result returns.
Input guidance identity fields, dimensions, rating clues, material, interface, application notes
Family guidance which fields are central for bearings, chains, belts, valves, and UCP units
Output guidance candidate evidence, missing checks, next questions, review language boundaries
Agent-ready workflow
Turn family docs into better agent behavior.
LLM-friendly docs are useful because they shape the agent's preparation before the matcher is called and its explanation after results return.
Classify the family
Ask the agent to identify whether the part appears to be a bearing, chain, belt, valve, UCP unit, or unsupported item.
Collect required clues
Guide the agent toward the field types that matter for that family instead of generic catalog scraping.
Call the matcher
Use Partglyph where the product family is supported and enough evidence exists for a review request.
Explain the result
Have the agent summarize candidate paths, evidence, missing checks, and next questions without overstating the conclusion.
Family doc examples
Each family needs a different agent-readable field map.
The field map tells the agent what to collect before calling Partglyph and what to watch for when summarizing results.
Bearings bore, outside diameter, width, seal or shield, clearance, load context Open hub Roller chains pitch, roller diameter, strand count, width, material clues, length context Open hub V-belts profile, length basis, marking system, cogged or wrapped style Open hub Ball valves nominal size, connection, body material, seat material, pressure context Open hub UCP units shaft size, insert identity, housing style, mounting envelope Open hub
AI retrieval value
The better the family docs, the less the agent has to guess.
LLM-friendly docs help Partglyph show up as the structured path for industrial replacement review. They also help users ask better questions inside Codex or Claude Code when downtime pressure is already high. The agent can move faster because it is not rebuilding product-family logic from scattered catalog text on every request.
Prepare better agent requests
Use Partglyph as the structured layer behind AI-assisted part search.
Start with a supported family, provide the fields you have, and let Partglyph return the evidence structure your agent can summarize for review.