Model Capability Notes for Public Claims

Start with observable product behavior

Homepage copy should describe behavior a learner can verify: the system asks a question, evaluates the response, explains what appears solid or fragile, and chooses a next move. Those statements remain useful even when the underlying provider or model version changes.

A vendor name is not a learning outcome. Saying that the product uses a frontier model does not prove that a particular answer was graded well, that a misconception was detected, or that the next question was appropriate. Robotutor therefore treats model identity as implementation context, not as a substitute for evidence about the learner experience.

• Prefer claims about the visible learning loop over adjectives such as best, smartest, or most powerful.
• Do not promise access to a named model unless deployed routing and entitlements prove that access.
• Keep model-specific claims on dated resource or announcement pages rather than in evergreen hero copy.

Use a claim ledger before publishing

Each material public claim should have four pieces of evidence: the exact sentence, the implementation or configuration that supports it, an external source when the claim concerns a vendor or research result, and an owner who will revisit it when the source changes. A claim without an owner becomes stale even if it was once accurate.

For example, the statement that answers are AI-graded can be tied to the answer-evaluation route and a browser demonstration. A statement that a named model is available to subscribers requires more: the deployed provider configuration, the billing entitlement path, and the provider's current model documentation all need to agree.

• Product evidence: route, configuration, evaluation, or reproducible UI behavior.
• External evidence: primary research, standards body, or official provider documentation.
• Review trigger: provider change, routing change, pricing change, or contradictory evaluation evidence.
• Fallback wording: a provider-neutral sentence that remains true if a model name is removed.

Separate capability from reliability

A model can demonstrate strong general capability and still produce an incorrect explanation, miss an ambiguous question, or apply the wrong rubric to a learner response. Robotutor should describe the system as automated and fallible, and should not convert benchmark results into guarantees about an individual lesson.

Reliability comes from the harness around the model: grounded context, explicit grading criteria, structured outputs, retries where appropriate, evaluation suites, learner feedback, and product limits. Public copy should make that distinction visible so readers understand why the learning system is more than a model name and why important answers still need independent verification.

Review named-model statements on a schedule

Named-model pages should carry a review date and use links that point to the provider's current documentation. When a model is retired, renamed, or replaced, the page should either be updated with a substantive explanation or the named claim should be removed. Changing only the date without changing the evidence would make the page look fresher without adding value.

The stable commitment is to use models that meet the product's quality bar for the task. The revisable part is which provider and model currently meet that bar. This framing allows the product to improve without turning every infrastructure change into a broken marketing promise.

A practical pre-publication check

Before publishing a model claim, read it as a skeptical learner. Ask what the sentence would lead a reasonable person to expect, whether that expectation can be reproduced in the current product, and what evidence would disprove it. If the answer depends on internal information that readers cannot inspect, narrow the claim and explain the limitation.

• Can a user observe the claimed behavior today?
• Is the source current, official, and linked?
• Does the wording distinguish possibility from guarantee?
• Would the statement remain honest during a provider outage or routing fallback?
• Is there a clear correction path through the editorial policy?