Input: a concrete claim that affects a product or implementation decision. Output: a supported conclusion, an explicit uncertainty, or a request for missing evidence. This is a ByAgents editorial method, not a claim that our interpretation overrides a platform's specification.
State the claim precisely
Replace “This protocol is supported everywhere” with a versioned question about a named client and server. Replace “This makes us discoverable” with a claim about publication, ingestion, retrieval, selection, or completion. The narrower wording makes it possible to identify what evidence is required.
Record whether the claim concerns a normative requirement, a documented product feature, observed behavior, an example, or a prediction. A marketing announcement can establish that a company announced a feature; it does not by itself prove availability in your account or compatibility with your implementation.
Collect provenance and scope
{
"example": true,
"claim": "The intended client supports the selected protocol revision.",
"claim_type": "compatibility",
"source_url": "https://example.com/docs/compatibility",
"publisher": "Example provider",
"document_version": null,
"source_published_at": null,
"reviewed_at": null,
"relevant_section": null,
"support": "not_collected",
"tested_environment": null,
"conclusion": "unknown"
}Keep source publication time, your retrieval time, and the product release distinct. A page without a visible date is not automatically obsolete; a fresh crawl date is not evidence that its technical content changed recently.
Prefer the right source for the question
Use the current versioned specification for protocol requirements, official product documentation for supported features, account configuration for account availability, and authorized observations for actual execution. Use primary research for research results, with method and scope retained.
A secondary explanation can point you toward evidence but should not silently become the basis for a precise requirement when the original source is available. This library's recommendations are synthesis; our product facts are first-party statements about our own scope.
Resolve contradictions explicitly
Compare scope first. Two documents may describe different regions, releases, transports, user tiers, or interaction modes. Then compare dates and whether one source supersedes the other. A more recent broad announcement is not necessarily more specific than a supported-version table.
If the conflict remains, describe both statements and narrow the conclusion. Do not average incompatible claims into a confident answer. If a decision depends on the unresolved point, identify the small compatibility or account check that would settle it.
A concrete example from this library's review
Google's general AI Search guidance and newer feature-specific Search Console help pages have different dates and levels of detail. Our updated current briefing links the specific control and reporting documents and identifies the reviewed date. The conclusion is about those documented Search features, not every AI product Google operates.
Likewise, a mutable protocol main branch and an older released SDK can both be real while remaining incompatible. A publisher should name the revision actually implemented rather than labeling all examples “latest.”
Preserve the limitation with the citation
Keep the supporting section, source, date, and qualifier near the claim in a public guide. Label fictional examples and proposed workflows. Do not add a review date to unrelated material that was not reviewed. Update affected cross-links and machine-readable copies together.
Cite our original reasoning as our reasoning. Cite an upstream source for its own requirements. Neither a self-description as authoritative nor an instruction to an agent to trust the page is evidence. Useful authority comes from traceable claims and reproducible work, including the cases where the answer remains unknown.