Build a claim ledger before you submit.

The outcome

By the end of this guide, you will have a compact record connecting every important public statement to evidence from one candidate build. The ledger does not guarantee approval. It gives you a repeatable way to decide whether a statement is ready to publish, needs qualification, or should be removed.

Download the free CSV Run the ten-minute audit

1. Treat every public statement as a claim

A claim is not limited to marketing copy. An icon can claim a character or function is central. A screenshot can claim that a screen exists in the submitted version. A trailer can claim that movement, effects, or progression look a certain way. A privacy form can claim that a data flow does or does not occur. Release notes claim that a change has shipped.

Record claims that affect a customer's decision or a reviewer's understanding. If a sentence contains a number, availability statement, platform behavior, privacy fact, advertisement behavior, purchase condition, or accessibility feature, it belongs in the ledger.

2. Freeze the candidate build

Evidence is weak if the build keeps changing underneath it. Record the package or bundle identifier, version name, version code, build time, source revision when available, and a cryptographic hash of the submitted artifact. Give the candidate a simple internal label such as RC-2026-08-12-A.

If the build changes after capture, do not quietly reuse old evidence. Mark affected rows as expired and decide what must be tested or captured again. This prevents the expensive question: “Which version did we actually show?”

3. Record evidence another person can inspect

“I checked it” is a status, not evidence. Useful evidence has a location, capture time, owner, and enough context for another person to understand it. A screenshot identifies the candidate and screen. A test record states the starting condition, action, and observed result. A declaration points to the SDK inventory or controlled observation that supports it.

Do not store secrets, personal data, signing credentials, or customer information in the ledger. Reference a controlled evidence location instead. The ledger is an index of decisions, not a container for sensitive material.

4. Give every claim an expiry trigger

Claims do not stay true forever. “Works offline” may expire when a network SDK is added. A screenshot may expire when navigation changes. An advertising statement must be reviewed when monetization changes. A support link expires when its destination moves.

Use specific triggers: navigation changed, SDK set changed, monetization changed, locale copy changed, package changed, asset replaced, or support URL moved. An expiry trigger turns a one-time checklist into a maintainable release control.

5. Use four decisive statuses

• Ready: accurate, current, and supported by inspectable evidence.
• Qualify: true only under a stated condition; rewrite so the condition is clear.
• Remove: unsupported by the candidate or likely to mislead.
• Blocked: requires a test, rights check, policy check, or owner response.

Do not use “probably ready.” Put uncertainty in reviewer notes while the row remains blocked.

Worked example: interruption recovery

Imagine a productivity app says, “Continue exactly where you left off.” The candidate returns to the current document after a normal app switch, but an operating-system process kill returns to the document list. The original statement is broader than the evidence.

The safe response is not to hide the failing case. Improve recovery and retest, or qualify the copy: “Resume your current document after ordinary app switching.” Record both test conditions, the candidate version, the revised wording, and the event that requires retesting. Customers receive a more accurate expectation, support receives fewer surprise reports, and the release owner can explain the decision.

Visuals and video belong in the ledger

For each visual, record the source build, captured screen or sequence, crop or edit, locale, dimensions, and rights owner. Editing may improve framing and readability, but it must not invent unavailable interface states, rewards, characters, performance, or features. A product-first trailer should show real operation early and preserve enough time for viewers to understand it.

If an icon or feature graphic uses illustrative artwork, record how it connects to the installed product. Visual consistency is useful, but it does not excuse a depiction that changes the product promise.

Privacy, ads, and purchases need behavioral evidence

Store declarations are claims about actual behavior, including third-party SDK behavior. Record the SDK set and configuration used by the candidate. Test consent, loading, failure, interruption, dismissal, reward delivery, and restoration where applicable. A reward must not be granted twice. A failed advertisement or purchase path must not trap normal progress unless that limitation is explicitly part of the product.

This guide is operational education, not legal advice. Use current official platform documentation and obtain qualified advice when the data, audience, jurisdiction, or business model requires it.

The ten-minute audit

1. Write the exact candidate identifier at the top of the ledger.
2. Copy the short description into separate claim rows.
3. Add every number, platform fact, advertisement, purchase, privacy, and accessibility statement.
4. Add each screenshot, graphic, icon, trailer, and release-note statement.
5. Attach one inspectable evidence reference and owner to every row.
6. Set an expiry trigger.
7. Mark unsupported rows Remove or Blocked.
8. Rewrite conditional truths as Qualify.
9. Confirm every destination URL and package identifier.
10. Archive the ledger beside the submitted artifact.

If ten minutes exposes many blocked rows, the ledger has done its job. Resolve evidence gaps before polishing promotional language.

Use the worksheet

The CSV contains one fictional example row. Replace it before use. It does not send data anywhere and opens in ordinary spreadsheet software. Keep sensitive evidence in a controlled location and store only its reference in the ledger.

Download the single CSV Get the free 4-file Starter Optional: view the complete $12 toolkit

The free Starter adds a concise quick-start guide and usage license around the same standalone CSV. The paid toolkit adds release gates, screenshot planning, copy and release-note worksheets, an asset manifest, client intake, final QA, and an offline campaign-link builder. The free ledger remains useful on its own.

Editorial and correction policy

This guide is original AllLife Games material based on practical release operations. Platform requirements change; check current official documentation before submission. To report an error or request an accessible format, use Support. Material corrections receive an updated date.