Trust Claim Checklist

Paste the precise sentence into a private review worksheet, then record the page, post, advertisement, sales deck, demo, email, reply, or AI-generated output where it will appear. Include the headline, nearby qualifier, audience, geography, channel, CTA, and planned publication date. A qualifier hidden in another page may not correct a strong headline.

Record who is making the claim and what a reasonable reader could understand it to mean. "Designed to support" differs from "ensures." "Available in a bounded preview" differs from "available." Screenshots, visual labels, pricing cards, charts, demonstrations, and comparisons can communicate claims even when the body copy avoids explicit words.

Assign a content owner who can change or withdraw the wording and an evidence owner who can confirm the source. Name specialist reviewers when the claim touches law, license, privacy, security, compliance, finance, performance, customer results, competition, provider policy, product availability, or a material commercial term.

Set a decision deadline that leaves time for enrichment or removal. Publication pressure is not evidence. If the required owner is unavailable, the safe result is to hold or use wording that does not make the unsupported claim. A model, drafting tool, or marketing operator cannot approve its own high-risk assertion.

Mark whether the statement asserts a product capability, availability, integration, price, package inclusion, capacity, service level, customer outcome, performance result, cost saving, revenue effect, market position, or comparison. Numbers, percentages, rankings, time claims, and superlatives usually need particularly clear scope and current evidence.

Separate observed fact from forecast, target, model, opinion, and aspiration. A roadmap target is not current availability. A local test is not production performance. A calculation from selected inputs is not a customer outcome. A qualitative category thesis can be presented as a point of view when it is not disguised as established market fact.

Mark claims about compliance, certification, security, privacy, data use, encryption, retention, intellectual property, licensing, auditability, reliability, safety, accessibility, employment, financial treatment, or regulatory status. Also mark statements that describe another company, product, executive, financial condition, incident, or alleged conduct.

These topics can create harm even when the wording is technically narrow. A security control can exist without covering every environment. A privacy statement can depend on role, data type, provider, and jurisdiction. "Compliant" can imply a legal conclusion. Route sensitive claims to the qualified owner and retain the decision evidence appropriate to the channel.

Label the claim observed, inferred, modeled, unresolved, or do-not-claim. Observed means current authoritative evidence directly supports the statement. Inferred means sources support a reasoned interpretation but not the exact fact. Modeled means the result depends on assumptions or calculations. Unresolved means required evidence is missing or conflicting. Do-not-claim means the risk or evidence gap makes external use inappropriate.

Record source title, owner, date, location, relevant excerpt or field, environment, method, and limitations. For tests, retain the version, configuration, sample, duration, exclusions, and result. For commercial claims, use the approved current registry or agreement. For deployed capability, distinguish design, code, test, preview, production, entitlement, and healthy operation.

Ask whether the source is authoritative for this subject, current for the publication date, representative of the stated scope, and independent enough for the claim. One internal example rarely supports "always." A provider page may describe its product but not prove Omega integration. A customer quote may support that customer experience under stated conditions but not a universal result.

Set an expiry or review trigger for claims that can drift, including prices, availability, integration status, market data, legal posture, executive roles, provider terms, performance, and security controls. If the source cannot be shared publicly, retain an approved internal reference and use external wording that does not pretend the reader can independently verify more than is available.

Rate potential impact as low, medium, or high. Consider buyer decisions, customer commitments, financial loss, privacy or security exposure, legal or regulatory concern, reputational harm, discrimination, employee effect, partner relationships, and difficulty correcting the statement. Paid ads, press, sales contracts, pricing, high-reach social posts, and AI-generated reuse can propagate quickly.

Rate reversibility separately. A private draft can be corrected before use. A public page may be cached, indexed, quoted, or atomized into other channels. A sales commitment or executed agreement may create obligations that a corrected blog post cannot reverse. High impact or low reversibility requires stronger evidence and named approval.

Route legal, licensing, intellectual-property, comparative, and regulatory claims to the appropriate legal or governance reviewer. Route security, authentication, token, storage, vulnerability, and control claims to security. Route personal-data, consent, retention, and data-use claims to privacy. Route pricing, package, margin, revenue, savings, and accounting claims to commercial or finance owners.

Product owners should verify capability and availability; operations owners should verify reliability and service posture; customer owners should verify testimonials and outcomes; and platform owners should verify advertising, social, API, and provider-policy rules. One review can cover several classes when the person holds the authority, but the decision record should identify which questions were actually reviewed.

For observed current facts, state the specific capability, environment, audience, date, and condition. For inference, use wording such as "suggests," "indicates," or "we believe," and explain the basis. For models, state assumptions and avoid presenting an estimate as an achieved result. For unresolved items, remove the claim or describe the question without implying an answer.

Prefer "designed to support governed review" over "guarantees compliance," "available to approved preview users" over "fully available," and "can reduce this preparation step under the tested conditions" over "saves every company 80 percent." Do not use qualifiers such as "typically" or "up to" as substitutes for evidence, and do not hide material conditions in unreadable text.

Read the headline, chart, image caption, button, price card, and footnote without the body copy. Ask what a reasonable reader would believe. A headline that says "autonomous company" beside a "start now" button can imply released end-to-end autonomy even when a later paragraph describes a waitlist or bounded preview.

Make the CTA match the verified state. Use read, learn, assess, request, reserve, or contact language according to what actually happens. Do not imply purchase, access, download, scheduling, persistence, integration, or automated action when the destination does not provide it. Verify the destination before publication and after deployment.

Draft claim: "OmegaOS autonomously runs your entire company and cuts operating costs by 60 percent." The claim combines universal capability, availability, outcome, and quantified financial performance. It requires product, deployment, entitlement, customer-result, methodology, financial, and legal evidence. Without that record, classify it do-not-claim.

Safer wording based on a verified bounded product posture could be: "OmegaOS is designed to connect governed AI work across company functions. Begin with one owned workflow and measure its operating result before expanding." This does not preserve the unsupported savings number or imply that every company function is currently autonomous. The actual CTA should reflect current access.

Draft claim: "OmegaOS is fully compliant and integrates with every system." "Fully compliant" lacks a law, jurisdiction, role, control, and assessment boundary. "Every system" is an unbounded availability claim. A connector design or API capability cannot support it. Classify both portions unresolved or do-not-claim until qualified evidence exists.

Safer wording may be: "OmegaOS uses governed access, evidence, and review patterns intended to support a company control program. Integration availability depends on the provider, account authorization, package, configuration, and current deployment." Security, privacy, and legal pages should describe verified controls and responsibilities without converting them into a blanket compliance assurance.

Choose approved as written, approved with exact revision, hold for enrichment, or rejected for external use. Record the claim, final wording, evidence references, scope, reviewers, decision date, channel, expiry or trigger, and assets that reuse it. Approval applies to the reviewed context; moving a sentence into an ad, contract, or comparative page can change its meaning and risk.

If held, name the missing evidence, owner, and due date. If rejected, record a do-not-claim instruction and remove or correct derivatives. Do not let an unresolved row become approved through delay. A public claim should remain absent when the evidence owner cannot confirm it.

After publication, check that the deployed wording, metadata, structured data, image text, CTA, and social derivatives match the approved version. Monitor product availability, package changes, provider policy, source freshness, customer feedback, and corrections. Update or withdraw a claim when its conditions change, even if the original statement was accurate.

This self-serve tool supports disciplined preparation but cannot provide professional approval. Escalate consequential claims to qualified reviewers and preserve the evidence according to authorized retention rules. For an OmegaOS commercial claim, confirm the current public communications registry, product evidence, package taxonomy, entitlement, release, and deployment posture before external use.