Separate formal support from test execution
A single green checkmark leaves two different questions unanswered. Does the product owner formally support this configuration? Has anyone performed the stated test on this exact configuration? Keep separate columns for those answers.
Use supported for a documented support statement, tested for an executed test, and untested when no test was performed. These are editorial labels recommended here, not fixed search-engine or Schema.org enumerations. They are not mutually exclusive levels: a configuration can be supported and untested, or tested while outside formal support.
Also distinguish “not supported” from “no support statement located.” The first needs an explicit applicable statement; the second describes missing information. When execution cannot be confirmed, write “test status not verified” rather than asserting that testing never occurred.
A fictional matrix with two independent answers
Every identifier, version, document, procedure and result below is a fictional placeholder. The rows demonstrate wording only; no actual product or test is represented. Document and record labels are placeholders to replace with real evidence locations.
| Configuration, all fictional | Formal support and source | Test execution | Method and recorded result | Conditions and evidence location |
|---|---|---|---|---|
| Adapter A, firmware 2.1, Host R3 | Supported by Doc A, section 2 | Untested for this configuration | No procedure executed; result not applicable | Cable T required; support statement at Doc A, section 2; execution status at Record A |
| Adapter B, firmware 3.0, Host R3 | Supported by Doc B, section 4 | Tested in this configuration | Procedure P: connection failed in the recorded run | Cable U only; one start-up check; support at Doc B, section 4; run details at Record B |
| Adapter C, firmware 1.4, Host R2 | Outside formal support, per Doc C, section 1 | Tested in this configuration | Procedure Q: connection established | Cable V only; no sustained-load test; support boundary at Doc C, section 1; observations at Record C |
| Adapter D, firmware 4.0, Host R1 | Explicitly not supported by Doc D, section 3 | Untested for this configuration | No procedure executed; result not applicable | This firmware/host pairing only; exclusion at Doc D, section 3; execution status at Record D |
The supported row with a failed run preserves both facts. A formal support statement does not erase a recorded failure. The successful run outside formal support does not create a support commitment. An explicit exclusion should remain visible even when no test has been performed.
Make each configuration carry its own evidence
Build the entry around the precise combination a buyer needs to evaluate. Use a short summary in the matrix and an adjacent detail block when the evidence will not fit comfortably in a cell.
- Identify the product variant, host environment, software or firmware versions, accessories and relevant settings. A family name cannot stand in for all of them.
- Attach the formal support statement to its applicable document version and section. Record the conditions that narrow it, including exceptions.
- State whether testing occurred. If it did, supply the test configuration, procedure, execution date, result and evidence location. If it did not, say so and leave method and result marked not applicable.
- Put critical restrictions beside the configuration and result. Distinguish a public evidence link from a record that exists but is not publicly available; do not invent a link to fill the field.
Google's helpful-content guide uses product reviews as an example: it can build trust with readers when they understand how many products were tested, what the results were and how the tests were conducted, with evidence of the work. That advice concerns describing how content was produced. It does not prescribe a compatibility-table layout or these labels.
Broader planning for a technical answer is covered in the technical evidence brief. For evidence links that change later, citation verification and updates addresses keeping the reference usable.
Keep a narrow test result narrow
“Connection established with firmware 1.4 and Cable V” supports a statement about that observed combination. It cannot establish that every firmware release, cable or product in the series works. Do not replace the configuration-specific result with a series-wide compatibility badge.
Choose a result description that matches the procedure: “connection established,” “file transfer completed,” or “failed at installation,” as applicable. A partial procedure should identify what was checked and what remains unchecked. Avoid turning a limited observation into the broader word “compatible” without its conditions.
Read each row as if it were copied on its own. Can the reader still identify the versions, formal support position, test status and essential limitation? If a restriction disappears when the page introduction is removed, repeat it in the relevant cell. Keep the condition in the row so that it remains part of the text if that row is excerpted on its own, including as a fragment in an AI answer. This makes the condition available in a short excerpt; it cannot control how a search engine or AI service later summarizes it.
FAQ
Can a blank test-result cell mean the configuration is unsupported?
No. A blank cell is ambiguous. State the applicable support position separately and write “untested” only when that execution status is known. If the record is unavailable, identify that evidence gap.
Should a successful test outside formal support be hidden?
Report it with the precise configuration, method and result, alongside the formal support boundary. The observed result and support position answer different buyer questions.
Want to see how AI engines describe your brand today?
Get a free growth audit