--- title: "Methodology" canonical: "https://canmyagentuse.com/methodology" contentKind: "page" locale: "en" description: "How compatibility cells are defined, sourced, dated, reviewed, and left unknown when evidence is insufficient." llmSummary: "A support assertion is feature revision × exact harness surface target × environment profile. Unknown is the default; every other status requires dated notes, typed evidence, and public resources." publishedAt: "2026-08-28T00:00:00.000Z" updatedAt: "2026-08-28T00:00:00.000Z" verifiedAt: null tags: ["methodology"] --- # Methodology A support assertion is feature revision × exact harness surface target × environment profile. Unknown is the default; every other status requires dated notes, typed evidence, and public resources. - HTML: https://canmyagentuse.com/methodology - Markdown: https://canmyagentuse.com/methodology.md A support assertion answers one narrow question for a **capability revision × exact product target × environment profile**. A rendered cell may be `yes`, `partial`, `no`, `unknown`, or `na`. - `yes` means current public documentation demonstrates the row’s capability without a material limit. - `partial` means the capability exists with a documented plan, platform, transport, rollout, environment, or interaction limit. - `no` requires an explicit current source saying the capability is unsupported. Silence is not evidence of no. - `unknown` is the default whenever evidence has not been reviewed or remains ambiguous. - `na` means the row does not apply to that kind of harness and still needs public evidence. ## Terminology and admission policy A published compatibility question must use terminology that readers can verify outside this site. The catalog admits three kinds of atomic entry: - A **specification feature** uses the name and scope of a public protocol, format, or convention and links the exact specification revision. - A **common product term** appears in first-party product documentation. The catalog may normalize capitalization or singular/plural form, but it does not add requirements that the source term does not contain. - A **measured product property** is a documented limit or quantity such as a context window, output-token maximum, upload limit, or rate limit. Every published atomic entry must link at least one public specification or first-party documentation page. A link to this site's methodology is not terminology provenance. Provider marketing language is kept only when it names a provider-specific record; it is not silently promoted into a generic industry term. Names should be short and recognizable. Avoid evaluative adjectives such as “accountable,” “safe,” or “controlled”; avoid combining several behaviors into one invented capability; and do not turn a desirable procurement question into a feature until public sources establish the term. If a useful distinction has no external vocabulary yet, keep it in research notes or a proposed test rather than publishing a compatibility row. Broad pages labeled **Catalog grouping** are internal navigation aids, not standards or standalone compatibility claims. Group progress is derived from child rows for each exact product; no umbrella yes/no value is authored. “Atomic” describes the catalog's internal granularity, not an industry designation. For example, MCP tool calling does not imply MCP prompts, resources, sampling, authorization, transport, or Apps support because those are separately named protocol features. Product documentation—not an internally invented checklist—determines whether non-protocol concepts deserve separate rows. ## Evidence contract Every non-unknown cell is authored as a version entry with one or more note IDs, an explicit target, an environment profile, structured qualifiers, and typed evidence references. Each evidence reference resolves to a stable resource ID and records when it was reviewed. The resource list links to public vendor documentation, release notes, maintained first-party repositories, or the relevant open-standard documentation. Targets are versioned releases when a stable release is public. Continuously deployed web products use a dated hosted observation. When only current local-product documentation is available, the record says `dated-documentation` rather than pretending a particular binary was reproduced. Evidence classes stay separate: **documented**, **vendor-attested**, **listed**, **tested**, **reported**, **inferred**, and **not found** do not carry the same authority. Catalog v1 publishes documentation and listing evidence. The public test registry contains proposed definitions only; Can My Agent Use has not executed runtime conformance tests against these harnesses. Plan, policy, region, authorization, transport, protocol revision, role, feature flag, runtime, preview, and vendor-extension limits remain structured qualifiers. They are not folded into prose and lost when the matrix is rendered. Compatibility status and product lifecycle are separate. An exact cell can be currently unsupported while its lifecycle is `planned`, or partially supported while it is `experimental` or `preview`. Lifecycle values are `untracked`, `requested`, `planned`, `experimental`, `preview`, `stable`, and `deprecated`; they require the same evidence discipline as the associated compatibility assertion. ## Limits and measured values Some of the most useful harness facts are numeric: advertised and effective context tokens, maximum output, file bytes and count, document pages, audio or video duration, concurrent subagents, requests or tokens per reset window, run duration, storage, retention, and price. A number is not portable without its unit and scope. Every measured value should identify the exact harness, model or mode, plan, environment, region or policy when relevant, what the value limits, whether it is a documented maximum or a tested observation, the reset or billing period, the review date, and the boundary behavior. A model API limit is not copied into a chat, desktop, editor, or CLI surface without product evidence. When an advertised maximum and an effective usable limit differ, preserve both and explain the reservation, truncation, sampling, or compaction behavior. Prompt caching is tracked only where first-party documentation names cache reuse, controls, or telemetry separately. File upload is kept separate from model-visible understanding because product documentation commonly distinguishes accepting a file from interpreting its contents. These distinctions keep a paperclip icon, a provider model card, or a generic caching statement from becoming a broader compatibility claim than the evidence supports. Do not source a claim from rumors, search snippets without a stable page, community recollection, private beta screens, or screenshots of interfaces that are not public. When a document describes a model or API rather than the named harness, it does not automatically prove harness support. Community reports can surface an investigation or contradiction, but do not change a definitive support state without authoritative or reproducible corroboration. When sources conflict, the contradiction stays public instead of being smoothed into a color. ## Tracks and coverage Tracks (`current`, `preview`) are catalog version stacks. They are not a claim that a vendor publishes channels with those names, and evidence for current never fills preview automatically. The feature-page percentage is the share of published product tracks that have moved off unknown. It measures catalog coverage. It does not measure usage, adoption, quality, or market share. The first review covers MCP tools, MCP Apps, workspace files, terminal access, computer use, and skills for a small set of products. All other cells stay unknown until reviewed. ## Corrections Public documentation changes. A correction should supersede the affected statement, update the review date, preserve a clear explanation of the documented limit, and replace stale resource links without erasing the reason for the change. Contributors should follow `CONTRIBUTING.md`; the shared schema rejects non-unknown cells without targets, environment profiles, notes, and typed evidence. The product deliberately does not publish a synthetic harness score, fabricated market-share figure, or unsourced editorial capability. Useful operational metrics are evidence freshness, sourced-cell coverage, contradiction age, revision pinning, source diversity, review latency, and future conformance-test coverage.