Every product carries a structured compatibility record. This page is the legend for those fields — what each one means and how to use it. The authoritative, per-product data lives in one place: /agent/compatibility.json (and inside each product record). This page does not restate that matrix — there is a single source of truth.
Who the kit is designed for. Match it to the buyer_type captured in buyer context.
The agent/assistant classes the kit is built to run with. It states classes, not universal compatibility.
Generic automation/agent workflows the kit slots into. Pair with workflow recipes.
What must be present for the kit to work — inputs, metadata, or companion files.
Relative effort to install and adopt. Use it to set operator expectations, not as a guarantee.
Whether adopting or operating the kit needs a named human approver for its risky actions.
Explicit anti-fit cases. If the buyer matches a not-for note, do not recommend the kit.
The suggested action once a fit is confirmed — today, a plan pending human approval.
Take a candidate product id, open its record in compatibility.json, and walk the fields top to bottom. A fit means: buyer type matches, agent type and workflow are supported, required files are available, difficulty and risk are acceptable to the operator, no not-for warning applies, and the human-approval requirement is understood.
There are no universal-compatibility claims here. A missing match is a real "not compatible", not an omission — treat it as a stop, and record why.