A Claim-and-Proof Content Model Editors Cannot Drift

By Simeon Matheka, Founder & Creative Director · Published 2026-10-01 · Updated 2026-10-01 · 12 min read

A claim and its proof should travel together in the content management system (CMS). Seven fields, one publish gate, and a review date stop a quote from being reworded, a number from being copied off a deck, and a claim from outliving its evidence.

Someone on your team copies a number from last year’s deck into the homepage. A quote gets a little punchier in the edit. A client logo stays on the site after the contract ended. None of these edits felt like lying. All of them made the page say something you could not back up on a call.

The usual fix is a policy. Policies fail in the week someone is in a hurry. The better fix is a content model in your content management system (CMS) where a claim cannot be published without its proof. This builds on a content model editors cannot break, which locks layout and type. That post decides what an editor can touch. This one decides what makes a statement of fact publishable.

Claim and proof are one object

Framework. On most marketing sites the claim lives in a headline field and the proof lives somewhere else: a testimonial block, a logo row, a case study card. Different fields, different editors, different dates. They drift apart, and nobody notices until the claim is false.

Store them together. A claim block has the statement, the proof that backs it, and enough metadata to check both later. The template renders them as a pair. The editor edits them as a pair.

flowchart LR
        C["Claim"] --> T["Proof type"]
        T --> S["Source + permission"]
        S --> K["Scope note"]
        K --> G{"Publish gate"}
        G -->|Complete| P["Published"]
        G -->|Missing| D["Stays draft"]
        P --> R["Review date"]
        R --> C

The seven fields

Source, permission, and the review date are internal. They do not render on the page. They are what an editor, a reviewer, and your future self read when they ask "can we still say this?"

The scope field is the one people resist, and the one that pays back fastest. It forces a sentence like "this describes one engagement, not every client" or "figure is from our own site, last 30 days." If you cannot write that sentence, the claim is wider than the evidence.

Five proof types, ranked by how much they can carry

Framework. Not all proof does the same job. The model uses a fixed list so editors pick a type instead of inventing one.

The publish gate

The gate is a rule the system checks on save, not a reminder in a style guide. Four rules cover most of the drift.

1. No claim without proof. If proofType is anything but "none yet," proofBody must be filled in. If it is "none yet," the block does not render.
2. No quote, name, or logo without a dated permission entry.
3. No block without a scope line and a review date that is in the future.
4. Editing the claim text resets the review state. A reworded claim is a new claim and goes back through the gate.

The fourth rule is the one that catches quote drift. If an editor touches the words, the block flips back to draft and the reviewer has to see it again. It adds a few seconds to a legitimate edit. It removes the silent ones.

{
  "claim": "Fixed-scope website builds for service firms.",
  "proofType": "process description",
  "proofBody": "Every build starts with a signed brief and a page list. Scope changes go through a written change order.",
  "source": "Studio operating process, v3",
  "permission": { "needed": false },
  "scope": "Describes how we work, not a result for any client.",
  "reviewBy": "2027-01-15",
  "reviewOwner": "Simeon"
}

// Returns a list of problems. Empty list means the block may publish.
const PROOF_TYPES = [
  'artifact link',
  'permissioned fact',
  'quote',
  'process description',
  'none yet',
];

export function validateClaimBlock(block, today = new Date()) {
  const problems = [];

  if (!block.claim?.trim()) problems.push('claim is empty');
  if (!PROOF_TYPES.includes(block.proofType)) {
    problems.push('proofType must be one of: ' + PROOF_TYPES.join(', '));
  }
  if (block.proofType !== 'none yet' && !block.proofBody?.trim()) {
    problems.push('proofBody is required for this proofType');
  }
  if (!block.source?.trim()) problems.push('source is empty');
  if (!block.scope?.trim()) problems.push('scope line is empty');

  const needsPermission = ['quote', 'permissioned fact'].includes(block.proofType);
  if (
    needsPermission &&
    !(block.permission?.grantedOn && block.permission?.grantedBy)
  ) {
    problems.push('permission needs a date and a name');
  }

  const review = new Date(block.reviewBy);
  if (Number.isNaN(review.getTime()) || review <= today) {
    problems.push('reviewBy must be a future date');
  }
  if (!block.reviewOwner?.trim()) problems.push('reviewOwner is empty');

  return problems;
}

Where the drift comes from

Framework. These are the common patterns on marketing sites and the reason each field exists. They are not counted from a dataset, and no frequency is claimed.

• The deck number: a figure moves from a slide to the site without its date or conditions. The source and scope fields make that a visible gap.
• The polished quote: someone trims it for length and changes the meaning. The reset-on-edit rule stops it.
• The ghost logo: the engagement ended, the logo stayed. The permission date and the review date make someone look.
• The stretched fact: a true result from one project gets written as if it applies to all of them. The scope line is there for exactly this.
• The orphan proof: the claim is rewritten, the proof stays, and now they disagree. Because they are one object, the rewrite touches both.

Reviews that actually happen

A review date nobody sees is decoration. Make the system surface it. A weekly list of blocks whose reviewBy falls in the next 30 days, sent to the named owner, is enough. The review itself is three questions: is it still true, is the permission still good, does the proof still open?

If the answer to any is no, the block goes back to draft and the page renders without it. A missing proof section is better than a wrong one.

Reusing the same claim in more than one place

Store each claim once and reference it. If the homepage, the service page, and the sales deck all use the same statement, the review happens once and the update lands everywhere. That is also how you keep the site and the deck saying the same thing, which is the job of sales deck to website message parity. Where the block sits on a page is covered in service page proof architecture.

What this does not do

The model cannot tell you whether a claim is true. It forces someone to write down where the proof is and who agreed it could be shown. A determined editor can still type a false source. The point is to make drift deliberate instead of accidental, and to leave a trail when someone asks.

Print the claim and proof field checklist and walk the five most visible claims on your site through it. If you want the model built into a template your team can use, that is website work. The wording behind the claims starts with positioning. You can also send us the list and we will tell you which claims would not pass the gate.

Tags: content model, CMS, proof, editorial governance, website planning