This workbook is designed for practical team use. Its named models are original editorial aids, not scientifically validated scoring systems. Complete the working fields with actual material and replace blanks with inspectable records. Editorial evidence supports a statement within a defined scope. A hypothesis describes an expectation that still needs testing. A measured result identifies an observation, period, definition and limitations. Keep these categories separate throughout the workflow. Fictional examples illustrate decisions and capacity planning; they do not claim customer outcomes. Linked primary sources were checked on 24 October 2026.
1. Set the review depth with CLEAR
The original CLEAR check covers Claim risk, Legibility, Evidence, Accessibility and Responsibility. It is a triage method, not a certification or numerical quality score. Start with the reader's intended task and the consequences of misunderstanding. A product availability claim needs current fact checking; a stable conceptual explanation needs a different review. Give high-impact claims explicit ownership. Every asset still needs a basic clarity and accessibility pass. A small asset is not automatically low risk: a short promotional headline can make a larger promise than a long article. Allocate review effort according to the promise and its consequences rather than the number of pages.
Team fieldwork
For a fast triage meeting, put the proposed headline, strongest claim and intended action on one screen. Ask what a reasonable reader could incorrectly conclude. Name the material consequence of that misunderstanding. This identifies the first review priority. Separate an essential blocker from a stylistic improvement, and record why the distinction was made. CLEAR should reduce ambiguity about the work required; it should not produce a reassuring average that hides one serious unsupported promise.
Review triage
| Risk | Required review | Release decision |
|---|---|---|
| Unsupported central promise | Fact owner and evidence check | Block |
| Task cannot be completed | Content and implementation repair | Block relevant promotion |
| Minor style inconsistency | Editorial cleanup | Schedule if meaning is intact |
Copyable decision worksheet
| Working field | Specific entry | Ownership | Status |
|---|---|---|---|
| Next work | Identify the three most consequential claims and assign a reviewer for each. | [Name the owner] | [open / complete] |
| Decision rule | Hold publication when the central promise has no qualified reviewer. | [Name the decision maker] | [proceed / stop] |
| Evidence | [Add source location, version and permitted use] | [Verify the source] | [observation / hypothesis / measurement] |
| Handover | [Add working file, unresolved question and next date] | [Recipient and backup] | [accepted / blocked] |
2. Classify every material claim
Use four practical classes: descriptive fact, interpretation, recommendation and measured result. A descriptive fact still needs a source if it is important or unstable. An interpretation needs a visible reasoning path. A recommendation needs conditions and exceptions. A measured result needs a definition, period, denominator and source. Hypotheses remain explicitly tentative across all classes. Do not promote a demonstration into a measured business outcome. Do not present an editorial opinion as a customer's quotation. The claim register should make the exact wording inspectable, because a small qualifier can determine whether the supporting evidence is sufficient. Keep its status visible to anyone adapting the material.
Team fieldwork
Copy each central sentence into its own register row. Add claim class, source location, scope, reviewer and status. Preserve qualifiers in the recorded wording. If a reviewer narrows a sentence, update the live draft and every derivative before marking the row complete. Keep unresolved statements out of the publication version. A visible research backlog is safer than bracketed uncertainty embedded in copy that could accidentally be published by another person.
Claim-type minimums
| Type | Required support | Common error |
|---|---|---|
| Fact | Current source or inspectable artifact | Treating availability as permanent |
| Interpretation | Visible reasoning from evidence | Presenting inference as quotation |
| Recommendation | Conditions and exceptions | Universal instruction from one case |
| Measured result | Definition, period, denominator and source | Expectation described as achieved result |
Copyable decision worksheet
| Working field | Specific entry | Ownership | Status |
|---|---|---|---|
| Next work | Label each important statement and attach its exact evidence or open research task. | [Name the owner] | [open / complete] |
| Decision rule | Remove a measured-result label when the material only supports an expectation. | [Name the decision maker] | [proceed / stop] |
3. Check source fitness, not just source existence
A working link is not proof that a claim is supported. Open the source and compare scope, date, population, definitions and conclusion. Prefer original documentation for product behavior and original publishers for research findings. Trace secondary summaries back to their origin where the claim matters. Record whether you checked the whole relevant context or only a search excerpt. When a source cannot be accessed, do not imply it was verified. Replace the claim, narrow it or keep the publication blocked until the required evidence exists. Record the check date and the trigger for a future review, particularly for platform features and availability.
Team fieldwork
Perform a source spot check on the claim most likely to influence a buyer's decision. Read beyond the quoted sentence and inspect definitions. If a statistic concerns surveyed intentions, do not describe it as observed behavior. If official documentation describes an optional feature, do not imply universal availability. Record the exact mismatch and corrected wording. A source check is complete when another reviewer can reconstruct the relationship between evidence and sentence without repeating the original search.
Source fitness checks
| Check | Pass question | Repair |
|---|---|---|
| Scope | Same population and capability? | Narrow statement |
| Recency | Still current for this claim? | Reverify documentation |
| Meaning | Does the source support the exact wording? | Correct interpretation |
| Traceability | Can another editor recover it? | Record precise location and version |
Copyable decision worksheet
| Working field | Specific entry | Ownership | Status |
|---|---|---|---|
| Next work | Compare one important sentence with the source’s actual scope and record any necessary narrowing. | [Name the owner] | [open / complete] |
| Decision rule | Block claims whose cited source discusses a different population, capability or outcome. | [Name the decision maker] | [proceed / stop] |
4. Test the reader’s task and language
Ask a person outside the project to use the content for its intended task. They should explain the decision, apply the criteria or complete the worksheet without the author coaching them. Ask which sentence created each expectation. Replace ambiguous slogans with the actual actor, action and condition. Keep necessary technical distinctions and explain them rather than deleting all specialist language. Google's people-first guidance is a useful editorial reference for whether the content serves an audience; it does not prescribe your word count or guarantee performance. A clear task failure is more actionable than a general request to make the piece punchier.
Team fieldwork
Give the test reader a concrete task and stay silent while they attempt it. Note actions and exact statements before interpretation. If they ask the author what a term means, record that as a usability issue rather than answering and counting the task as independently completed. Afterward, ask what information was missing. Use the result to repair the relevant passage, then repeat only the affected task with a fresh reader where practical.
Copyable decision worksheet
| Working field | Specific entry | Ownership | Status |
|---|---|---|---|
| Next work | Observe one reader completing the intended task and record exact points of hesitation. | [Name the owner] | [open / complete] |
| Decision rule | Revise when readers can repeat the headline but cannot explain the practical next decision. | [Name the decision maker] | [proceed / stop] |
5. Review headings, links and images
Use W3C WAI guidance as a practical reference for writing, page structure and image alternatives. Headings should reveal the organization, links should identify their purpose, and informative images need an appropriate text alternative. A complex diagram may need a fuller explanation of relationships and conclusions, not a decorative label. Do not use color as the only carrier of meaning. Inspect reading order and keyboard navigation in the implemented version. A content checklist is not an accessibility audit or a claim of conformance. Involve people with relevant testing expertise when the scope requires it, and keep known issues visible until repaired.
Team fieldwork
Create an accessibility defect list with location, observed failure, affected task and repair owner. An issue such as the diagram cannot be understood without color is actionable; accessibility needs improvement is not. Recheck the repaired version, including its alternative text and nearby explanation. Keep the distinction between a practical editorial review and a full conformance assessment visible in internal records and any public description of the review.
Accessibility content checks
| Element | Check | Specific defect |
|---|---|---|
| Heading | Describes the section and hierarchy | Visual bold used without semantic heading |
| Link | Purpose is understandable | Several different destinations called here |
| Diagram | Essential meaning has text equivalent | Only color explains ownership |
| Form | Labels and errors explain the task | Placeholder disappears during input |
Copyable decision worksheet
| Working field | Specific entry | Ownership | Status |
|---|---|---|---|
| Next work | Read the heading outline and link labels, then inspect every informative image’s text equivalent. | [Name the owner] | [open / complete] |
| Decision rule | Hold release when essential content cannot be understood without seeing a particular visual. | [Name the decision maker] | [proceed / stop] |
6. Check forms and promised delivery
A resource's editorial promise includes what happens after a CTA. Check form labels, required-field explanations, error recovery and confirmation messages against the actual process. W3C WAI form instructions provide a useful reference. If the invitation promises immediate access, test whether the asset is actually available immediately. A button click is not evidence of successful submission or delivery. Ask whether each required field is necessary for the stated purpose. Avoid hiding a sales request behind a download label. Include a fallback route for fulfillment problems and give it an owner. Test success and failure with the published configuration rather than only the design prototype.
Team fieldwork
Write a fulfillment contract containing the promised item, timing, required information and confirmation message. Compare it with the actual system behavior. Check an invalid submission and an unavailable delivery destination. The fallback owner should know what to send and how to avoid sending an obsolete version. A polished form is not a completed experience until a reader can obtain the right material and understand whether further contact will occur.
Copyable decision worksheet
| Working field | Specific entry | Ownership | Status |
|---|---|---|---|
| Next work | Complete the form once successfully and once with an error; inspect delivery and confirmation. | [Name the owner] | [open / complete] |
| Decision rule | Block promotion if the promised resource cannot reliably be obtained through the stated route. | [Name the decision maker] | [proceed / stop] |
7. Check measurement definitions
Before interpreting a dashboard, inspect what its labels mean. A page view, click, completed download and qualified request are different observations. Google Analytics documents campaign parameters and key events; these support collection and reporting rather than proving causation. Test event triggers and repeated actions. Keep personal data out of URL parameters. Report denominators and periods, and label collection gaps. A percentage without its underlying counts can conceal a very small sample. Separate measured behavior from the hypothesis that content influenced a buying decision. When the measurement changes, annotate the change instead of presenting the series as continuously comparable.
Team fieldwork
Make a small event dictionary before the report is distributed. For each metric, name the event source, trigger, unit counted and deduplication rule. Verify one test action and inspect the resulting record. If a reporting change breaks comparison with the previous period, annotate the break. Keep hypotheses about usefulness in a separate column so a convenient event name does not silently become a claim about motivation or business impact.
Measurement review
| Label | Verify | Do not infer |
|---|---|---|
| Visit | Actual page event | Completed reading |
| Click | Exact trigger | Successful delivery |
| Download | Definition and duplicate handling | Qualified interest |
| Request | Successful submission and fit process | Revenue causation |
Copyable decision worksheet
| Working field | Specific entry | Ownership | Status |
|---|---|---|---|
| Next work | Define the actual action behind each headline metric and perform a controlled test event. | [Name the owner] | [open / complete] |
| Decision rule | Pause performance conclusions when the event records a click but the claim concerns completion. | [Name the decision maker] | [proceed / stop] |
8. Approve meaning and hand over ownership
Give each reviewer a specific job. The expert verifies factual scope, the editor verifies reasoning and clarity, and the implementation owner verifies the live experience. A decision maker resolves material disagreement. Silence is not approval for an important claim. Record the exact approved version and what changed after review. A backup needs access to the evidence, working file, derivative register and correction route. Rehearse a small update before completing handover. The purpose is proportionate control, not an approval ritual for every comma. Routine stylistic changes can be delegated, while a change that expands a promise returns to the relevant fact owner.
Team fieldwork
Use a handover rehearsal: ask the backup to replace one outdated product detail, find its evidence and identify affected excerpts. Observe missing access or uncertain decision rights. Fix those issues and record the tested path. The backup should know when to act independently and when a new factual review is required. A document with every box filled can still fail this rehearsal if its links point to inaccessible files or unclear versions.
Handover acceptance
| Item | Recipient demonstrates | Blocker |
|---|---|---|
| Evidence | Finds the relevant source and version | Missing access |
| Change rights | Explains routine versus renewed review | Unclear authority |
| Derivatives | Locates all affected uses | Untracked sales excerpts |
| Correction | Performs a controlled update | No responsible publisher |
Copyable decision worksheet
| Working field | Specific entry | Ownership | Status |
|---|---|---|---|
| Next work | Name factual, editorial and implementation owners, plus a backup and dispute decision maker. | [Name the owner] | [open / complete] |
| Decision rule | Hold publication if reviewers disagree about the central supported meaning. | [Name the decision maker] | [proceed / stop] |
9. Apply the checklist to a fictional release
FICTIONAL B2B SaaS EXAMPLE: Queuebase publishes a guide about support escalation ownership. All numbers are planning assumptions, not customer results. Assume twelve material claims, one process diagram and one download form. The review finds two unsupported efficiency statements, a diagram without a text explanation and a form confirmation that promises the wrong delivery time. The team narrows the claims, adds a structured explanation and corrects the confirmation before promotion. These are fictional defects chosen to demonstrate prioritization. No improvement rate or business outcome is asserted. The release decision depends on repaired reader tasks and supported meaning, not a perfect-looking checklist score.
Team fieldwork
In the fictional Queuebase example, prioritize the unsupported claims and broken promise before cosmetic wording. Assign one owner to each defect and require a visible repaired version. Retest the diagram explanation with someone who did not see the original. Test the corrected form confirmation against actual delivery. Mark the release as ready only for the scope checked. The exercise illustrates repair sequencing; it does not establish any numerical quality benchmark for another team.
Copyable decision worksheet
| Working field | Specific entry | Ownership | Status |
|---|---|---|---|
| Next work | Classify each defect as blocking, repair before promotion or scheduled improvement, with a reason. | [Name the owner] | [open / complete] |
| Decision rule | Do not trade an unsupported central promise for meeting a publication date. | [Name the decision maker] | [proceed / stop] |
10. Maintain, correct and retire
Assign review dates according to claim volatility and reader consequence. Check product-dependent statements sooner than stable definitions. Google's publication-date guidance is useful when showing meaningful updates; changing a date alone does not renew evidence. Maintain a correction log with the issue, action, owner and affected derivatives. Recheck links and sales references when an asset is merged or archived. Retire unsupported material rather than polishing around a missing foundation. Keep a visible route for reader corrections and acknowledge the boundaries of the review performed. Editorial quality is a maintained relationship between promise, evidence and usable delivery, not a one-time proofreading event.
Team fieldwork
Choose a maintenance action for each asset and a reason tied to evidence or reader need. Keep useful accurate content even when it is old. Merge duplicate answers when they create confusion. Archive an answer that cannot be supported, then check inbound links and derivative owners. Set a next review trigger, such as a product change or source update, rather than relying only on a date that nobody owns.
Copyable decision worksheet
| Working field | Specific entry | Ownership | Status |
|---|---|---|---|
| Next work | Record retain, revise, merge or retire and verify that derivative owners received the decision. | [Name the owner] | [open / complete] |
| Decision rule | Retire an asset when its core evidence cannot be recovered and no accurate narrower version remains. | [Name the decision maker] | [proceed / stop] |
Primary sources and application limits
- Google: Creating helpful, reliable, people-first content — checked 24 October 2026.
- Google: Guidance on generative AI content — checked 24 October 2026.
- Google: Publication dates — checked 24 October 2026.
- W3C WAI: Writing for web accessibility — checked 24 October 2026.
- W3C WAI: Page structure — checked 24 October 2026.
- W3C WAI: Images — checked 24 October 2026.
- Google Analytics: Campaign URL parameters — checked 24 October 2026.
- Google Analytics: About key events — checked 24 October 2026.
- W3C WAI: Form instructions — checked 24 October 2026.
INTERACTIVE / FROM READING TO ACTION
Three checkpoints for your implementation
Choose a checkpoint and track your reading progress. Checks are neither saved nor sent and do not score your business.
CHECKPOINT 01
1. Set the review depth with CLEAR
The original CLEAR check covers Claim risk, Legibility, Evidence, Accessibility and Responsibility.
CHECKPOINT 02
2. Classify every material claim
Use four practical classes: descriptive fact, interpretation, recommendation and measured result.
CHECKPOINT 03
3. Check source fitness, not just source existence
A working link is not proof that a claim is supported.
Frequently asked questions
Who is this resource for?
B2B SaaS editors, content leads and subject-matter reviewers. Use the resource with the people accountable for implementation and approval.
What practical outputs can we create?
A risk-based review brief A claim register with approval status A clarity and accessibility test A publication and correction log
What is included in the PDF?
10 chapters with explanations, decision rules, examples and working materials. 16 designed PDF pages including sources and a transfer canvas.
Are the examples real client results?
No. Cases labelled fictional are used to explain the method. Example figures are assumptions, not industry benchmarks or promised outcomes. Apply the approach to your own evidence.
Are the online edition and download free?
Yes. The complete resource is currently available to read and download without payment or a registration form.
Is there a German edition?
Yes. Use the language switch for the complete German online edition and German PDF.
Sources & context
Primary sources checked 24 October 2026. The working models are editorial decision aids. Fictional examples do not replace your own customer evidence. Verify current platform capabilities before implementation.
