How should a page distinguish native features from integrations?
Say which product performs the task and whether a connected product, module or plan is required. In Procore's page comparison read on 8 October 2026, 28 of 92 construction criteria were unknown. Those totals do not identify 28 integration problems; they show why a page should make the supported capability and its boundary explicit.
What we measured
Measured. Study 7's method extracted AI-stated criteria before the first vendor name from 2,093 eligible answers across 14 categories, captured on 22 and 23 September 2026. It then compared the criteria with dated vendor pages. For construction captures from 22 September, the Procore page read on 8 October classified 20 of 92 criteria stated, 44 not stated and 28 unknown. The method preserves product-scope uncertainty; it does not independently test native or connected capabilities. The criteria are not independently verified requirements, and team review remains in progress.
What this means for you
Reasoned. Write the capability as a short responsibility statement. Name the base product, the task it performs and the source that supports that claim. If a connected tool performs part of the task, name that tool and the role of the connection. Do not let a sentence about the whole stack imply that every function belongs to the base product.
Keep module and plan conditions beside the feature. A capability stated for a suite may not resolve the narrower product a buyer is comparing. Likewise, the existence of a connection does not establish the direction, detail or outcome of every possible task. Use documentation that matches the particular claim rather than expanding from a logo on an integration list.
When the evidence is incomplete, state the unanswered question. That could concern the product boundary, the required plan or which step the connected tool performs. The 28 unknown page comparisons cannot tell you which of these applies to an individual row; inspect that row's evidence before explaining it.
This is a writing and source-scope check. A page can accurately describe a connection without demonstrating an end-to-end test, and a reader should be able to tell which kind of evidence you are presenting.
- For a vendor: put the feature's product, module and plan in the same supported statement.
- For a comparison publisher: preserve the dependency instead of reducing it to an unqualified Yes.
- For a buyer: ask which part of your task is native, connected or still unresolved.
Also asked as
How should a page distinguish native features from integrations?
Related
- Procore's dated comparison
- Study 7 source rules
- Handle unknown comparison features
- Keep vendor facts scoped
Next step
Use the Free 10-question check (one engine). No email is needed; runs are limited per network and per day, and by the site's daily allowance. Check the specific product claim and the linked source together.
To correct one feature statement with its dependency made clear, Fix one answer, $490.
Our answer-study method, v1.1.
Claiming or correcting a vendor record is free and never depends on a purchase.
Prepared by the Broadcastwell team.
Page owner: Rohan Iyer, AI Engineer. Corrections: hello@broadcastwell.com