Product-Truth Release Checklist: Keep SaaS Product Claims in Sync

A product release is not operationally complete when the feature ships. It is complete when every affected representation of the changed fact has been identified and either verified, marked not applicable or carried as a visible, owned exception.

The problem is practical. A feature can ship correctly while the pricing page, a help-centre article, structured data, a sales deck or a support macro still describes the old product. Each is a separate place an old fact can survive, and each may have its own owner.

This is not a software-deployment checklist. It starts once a product change has been approved, and asks the same question of every place the change reaches: does it now state the new fact correctly, and has someone checked?

Documented marks a technical point supported by the linked Google or OpenAPI documentation; Recommendation marks CoreAEX's operating method, which is not an industry standard.

What counts as a product fact

A product fact is a verifiable statement about the product. It concerns:

• Price, billing basis, packaging, entitlements and usage limits
• Feature behaviour and availability
• Integrations and supported connection methods
• Security or compliance status, service levels and policies
• Product identity or naming, APIs and technical interfaces

Positioning, opinion and aspiration are not product facts. In “the simplest way to automate approvals, now on the Team plan,” the plan claim is a fact to record; the positioning is reviewed separately. Recommendation

Track the fact, not the page

One release can change several facts. Moving a feature to another plan, renaming a module and deprecating an API operation are three facts, and each reaches different surfaces: pricing tables and sales decks, help-centre titles, API reference. A page updated for one fact can still carry another, so open one record per changed fact.

System of record and designated public reference

• System of record - the internal record that controls the fact, such as a billing catalogue entry or entitlement setting. Customers may not be able to read it.
• Designated public reference - the published location customers should rely on for the fact, such as a pricing or documentation page. The company chooses it, and not every fact has one.

No single public page is authoritative for every audience. A list price does not necessarily govern a negotiated contract, and a developer may rely on API reference rather than a feature page. Wording can differ by audience; scope, units, qualifiers and effective date must not.

What belongs in the release record

Groups 1-5 are recorded once per changed fact. Groups 6-8 are recorded once for each affected location. An unknown value is acceptable only when someone is assigned to resolve it; a blank is not. Recommendation

The ten release gates

Each gate asks one question, names what to record, and says what happens if it fails. Recommendation

Run the checklist in order. Technical, external and specialist-approval steps apply only when the changed fact reaches them. Mark an irrelevant branch not applicable and record why. Scale the record to the change and its risk: a limit change needs a short record, a repackaging a longer one.

1. Define the changed fact
2. Name the authority
3. Find affected surfaces
4. Assign owners
5. Update human-readable representations
6. Update technical representations
7. Track external surfaces
8. Verify the live truth
9. Coordinate timing and approvals
10. Close the record or carry visible exceptions

The owners named are suggestions, and one person can hold several roles. Where practical, name a person rather than a team.

Gate 1: Define the changed fact

What exactly changes, from what to what, for whom, and when?

A ticket title is not a testable fact. “Team plan packaging update” cannot be checked. “Automation, previously on Pro, is available on Team and Pro for new subscriptions worldwide from October 1, 2026, 09:00 UTC; legacy annual contracts are unchanged until renewal” can.

• Record: old value, new value, fact type, effective date and time, plans, regions, versions and known exceptions.
• Passes when: the statement is specific enough for another person to test.
• If it fails: clarify the statement, or block the record.
• Applies to: every fact record. Suggested owner: release owner.

Gate 2: Name the authority

Which internal record controls the fact, and which public reference should customers rely on?

The fact approver confirms the value, not the copy. If product and billing disagree about the value, content work cannot settle it.

• Record: system of record, designated public reference where there is one, and fact approver.
• Passes when: authority and approval are explicit, and any dispute is resolved or escalated.
• If it fails: escalate. While authority is disputed, the record stays blocked or escalated.
• Applies to: every fact record. Suggested owner: product owner.

Gate 3: Find affected surfaces

Where is the old fact stated, implied, encoded or reused?

Search for the old value and the terms around it: product and plan names, identifiers, and machine-readable values such as SKUs, schema properties and API fields. A changed number can appear without its surrounding words, so also check shared templates, data feeds and what surface owners know. Use the surface matrix as a prompt. A search shows where you looked, not that nothing else exists.

Scope follows the fact. A pricing unit changing from per workspace to per user reaches pricing tables, calculators and quote templates, and may not reach API reference at all. If the search finds more than one version of the old fact, reconciling conflicting product information across your own site is a separate job.

• Record: search terms, surface inventory, exact URLs, files or records, and an applicability reason for each group.
• Passes when: the relevant surface groups were checked and each result is recorded.
• If it fails: expand the search, or record its limitation.
• Applies to: every fact record. Suggested owner: release owner with the surface owners.

Gate 4: Assign owners

Who changes each surface, and who is accountable for closing the record?

The update owner changes one location. The accountable release owner closes the whole record. One person can hold both roles; the record still names each.

• Record: update owner for each surface, due date, and accountable release owner.
• Passes when: every applicable row has a named owner and a due date.
• If it fails: assign the work, or escalate rows nobody owns.
• Applies to: every fact record. Suggested owner: release owner.

Gate 5: Update human-readable representations

Do public, support, sales and internal materials state the approved fact correctly?

Change the affected claims and the context needed to keep them accurate, not unrelated positioning.

• Public pages. Pricing, product, solution, landing and campaign pages, wherever the fact is stated or necessarily implied. For comparison pages, take the changed claims through Maintaining SaaS Competitor Comparison Pages.
• Documentation and help. Reference docs, help centre, onboarding, release notes and changelogs that describe the changed behaviour. A release note alone may not correct an evergreen help article.
• Integrations. Check availability, connection method, provider or maintainer, capabilities, limits and relevant listings. Record overlapping methods instead of forcing one label. Marketplace presence does not prove vendor authorship, and a general API does not prove a named integration. CoreAEX's integration accuracy research explains why type and ownership need careful checking.
• Sales, success and support. Decks, one-pagers, proposal templates, demo scripts, CRM snippets, support macros and training that repeat or depend on the fact. Record file versions so old copies can be retired.

• Record: required action, draft or revision, approvals and publication state.
• Passes when: affected human-readable surfaces are updated or carried as visible exceptions.
• If it fails: correct the content, withdraw it, or record an exception.
• Applies to: every fact record. Suggested owner: the owner of each surface.

Gate 6: Update technical representations

Do structured data, feeds, specifications, sitemaps, URLs and other machine-readable outputs match the change?

Titles, meta descriptions, canonicals and product feeds that repeat the fact belong here. Five further checks apply only where the change reaches them: Documented

• Structured data. Google's general structured data guidelines say: Provide up-to-date information. We won't show a rich result for time-sensitive content that is no longer relevant. They also say Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly according to the Rich Results Test. Update the markup with the visible page.
• XML sitemap lastmod. Only where the page appears in an XML sitemap using lastmod. Google's sitemap guidance says Google uses the <lastmod> value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate. and that the <lastmod> value should reflect the date and time of the last significant update to the page. For example, an update to the main content, the structured data, or links on the page is generally considered significant, however an update to the copyright date is not. Not every release requires a new value, and the value does not guarantee crawling.
• Permanent URL moves. When a URL changes permanently, Google's redirect guidance says if you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible. and that the 301 and 308 status codes mean that a page has permanently moved to a new location. Record whether the move is permanent or temporary, plus the old URL, target and verification. Google does not promise that a redirect preserves every search signal or outcome.
• Retired URLs and 4xx responses. Google's documentation on HTTP status codes, and network and DNS errors says Google doesn't index URLs that return a 4xx status code, and URLs that are already indexed and return a 4xx status code are removed from the index. It treats 404 and 410 alike: All 4xx errors, except 429, are treated the same: Google crawlers inform the next processing system that the content doesn't exist. That is crawler handling; what customers and other clients should see is a separate decision. If a relevant replacement exists, evaluate a redirect.
• OpenAPI descriptions. Only if the product maintains an OpenAPI description. The OpenAPI Specification v3.2.1 defines a deprecated boolean for operations: Declares this operation to be deprecated. Consumers SHOULD refrain from usage of the declared operation. Default value is false. Setting it is one row in the record, not the whole deprecation: API reference, SDK docs and customer notices are rows of their own.

• Record: technical surface, required action, deployment reference and URL handling.
• Passes when: applicable technical outputs are changed and testable.
• If it fails: fix the deployment, or document why the surface is not applicable.
• Applies to: web, API, feed and identity changes. Suggested owner: engineering or web owner.

Gate 7: Track external surfaces

Are material third-party profiles or directories affected?

Claimed review profiles, third-party marketplaces, partner directories and partner data feeds may not be directly editable. Request the correction and keep the row open until it is confirmed: a submitted request is not a corrected surface. Limit this to material or claimed profiles. Not finding a mention does not show that none exists.

• Record: external URL, request owner, request date, provider status and next check.
• Passes when: each material external item is confirmed, pending with an owner, or accepted as an exception.
• If it fails: submit the correction and keep the row open.
• Applies to: listings, marketplaces and profiles. Suggested owner: partnerships or marketing owner.

Gate 8: Verify the live truth

Does the live result match the approved fact, including its scope and qualifiers?

Check the live surface, not the CMS draft, the merge or the deployment log. Compare scope, units, qualifiers, effective date and terminology across surfaces, with particular care over plan, region and version qualifiers.

• Record: verifier, verified date, evidence, result and defect notes.
• Passes when: a person other than the updater, or a check explicitly separate from the update, confirms the live state.
• If it fails: reopen the row and correct it.
• Applies to: every fact record. Suggested owner: verifier.

Gate 9: Coordinate timing and approvals

Are sequencing, effective dates and specialist approvals controlled?

Embargoes, staged rollouts, grandfathered customers and regional launches can make old and new statements both accurate for a period. Record that window and who owns it. Changes to price, contracts, SLAs, security, privacy or compliance may need specialist approval. Who approves depends on the claim, the market and your company's controls, and not every wording change needs it.

• Record: publication time, rollout notes, approvals and any accepted coexistence window.
• Passes when: timing is intentional and required approval is recorded.
• If it fails: delay, narrow the scope, or accept a documented exception.
• Applies to: staged or higher-risk changes. Suggested owner: release owner or approver.

Gate 10: Close the record or carry visible exceptions

Can every surface row close, or is the remaining work visible and owned?

The record can close only when every surface row is:

• Verified
• Marked not applicable, with a reason
• Carried as a visible exception, with an owner, a rationale, the person authorised to accept it, and a next check date or review condition

Blanks are not decisions. An external correction still pending at closure stays visible as an exception. Where indexing, external publication, a cache refresh, a marketplace review or a staged rollout prevents verification at launch, name the condition, owner and next check date; this is a scheduled check, not open-ended monitoring.

Evidence records what was checked at a stated time. A screenshot or archived copy does not show that a surface is still correct. Closing the record does not prove that no surface was missed.

• Record: final status, exception owner, accepting authority, rationale, next check and closure sign-off.
• Passes when: no applicable row is blank, and every open item has an owner and a next check date or condition.
• If it fails: keep the record open, or accept an exception under your own risk authority.
• Applies to: every fact record. Suggested owner: accountable release owner.

The affected-surface matrix

Use the matrix at gate 3 as a discovery aid, not proof that every location has been found. Your own list may need groups this one lacks. Recommendation

Updated, published and verified are different states

The full status list is Not assessed, Not applicable, Assigned, In progress, Updated, Published, Verified, External request pending, Blocked and Accepted exception. These five must not be merged into a single “Complete”: Recommendation

Shipping changes the product

Shipping changes the product. The checklist gives each affected representation an owner, a status and a verification step.

---

Sources