Claims and their disclosures

The mechanism is that a claim and its disclosure are modeled as a single object instead of as two pieces of content that convention keeps together. One value carries the claim text and the disclosure text, and the component that renders the first renders the second. There is no arrangement of the code that produces one without the other, because there is no field to omit.

That is the difference between a policy and a property. A policy says disclosures must accompany claims and is enforced by attention, which is a resource that fluctuates. A property means the unaccompanied claim cannot be expressed — the page will not build, and the failure arrives at the moment of writing, not the moment of publishing.

Where a claim genuinely cannot carry its condition on the page it sits on, the remedy is to remove the claim instead of to shrink the disclosure. Setting required text at eight pixels in a lighter gray satisfies the letter of a requirement while defeating its purpose, and it is legible to a regulator as exactly what it is.

Removing the trigger is treated as a normal option, not a failure. A page arguing that a business is worth calling does not necessarily need to quote a rate; moving the claim and its disclosure together to the page that owns them, and leaving the argument and a link behind, is frequently better copy as well as simpler compliance.

Prescribed wording is reproduced exactly. Where a statute or a licensing body specifies text, it is copied verbatim, including the parts that read awkwardly, because tightening prescribed language is the most common way a compliant disclosure becomes a non-compliant one. The instinct to improve it is strong and is wrong.

Every claim carries its source and the date somebody verified it, stored as fields, not held as an assumption. A disclosure drafted from general knowledge is visually indistinguishable from one drafted from the regulation, and the distinction only becomes apparent when it matters most.

Claims that no longer have a verified source are surfaced, not left in place. A rate accurate in March and unreviewed since is a liability accruing quietly, and the mechanism that catches it is a date on a field, not a person's recollection of when they last looked.

Superlatives and comparatives are treated as claims, because in most jurisdictions they are. "Best", "fastest", "cheapest", "number one" and "leading" each assert something a regulator may ask to see substantiated, and a substantiation nobody can produce is worse than the marketing benefit was worth. The build refuses these outright rather than case by case.

Testimonials, ratings and endorsements are unrepresentable rather than discouraged. There is no type in the configuration for a testimonial, a star rating, or an aggregate review score, so none can be added without somebody deliberately building the capability — which is a decision with a reviewer, not an afternoon's copy edit.

Structured data is held to the same standard as visible text, and it is the more dangerous of the two because a reader cannot see it. Rating markup emitted without real attributable reviews is a claim made directly to a search engine, invisible on the page, and it is the single highest-risk piece of markup available. There is no switch for it.

Where a business operates under a license, the identifier is rendered by a component with a field for the number and no default value. A component that cannot represent an absent license number cannot display a fabricated one, and a page that needs the identifier and lacks it fails to build instead of shipping a plausible blank.

Images carry claims as reliably as text, and they are the ones a text-based check cannot see. A photograph of a vehicle with a price on the windscreen, a screenshot of a dashboard showing a result, a badge rendered as artwork — each asserts something, and none of it is reachable by any check that reads words. The rule that follows is that anything making a claim is expressed as text and styled, never baked into an asset.

Where a page's compliance depends on a claim being present rather than absent — a required notice, a mandatory identification line — the assertion runs in the other direction. The gate checks that the text appears on every page it must appear on, because a check that can only fail on presence will never notice a page that quietly lost its footer.

The gates run against rendered output and not only against source. A claim assembled at render time from three configuration fields is invisible to a scan of the source and plainly visible in what is finally published, and the difference is where a whole class of composed claims hides.

Regulated wording is reviewed by somebody qualified to review it, and that is stated, not implied. We build the mechanism that keeps the wording attached to the claim, present on every page, and dated; what the wording must actually say is a question for a professional, and the mechanism is worth nothing if the text inside it was invented.

The whole approach is auditable by construction, which is the point most easily missed. Because claims live in configuration under version control, the question "when did the site start saying this, and what disclosure accompanied it" is answered by a command, not an investigation — and on a regulated site that history is the difference between demonstrating a practice and asserting one.

None of this makes a business compliant. It makes a specific and common failure — the claim that drifted away from its condition through ordinary editing — structurally unable to occur, which is a narrower promise and one that can actually be kept.