# Designesy — /learn/what-is-design-verification Canonical page: https://www.designesy.org/learn/what-is-design-verification --- ## What is design verification? The automated evaluation of a live site against a published design system contract. Design verification sits between three established practices — design linting, visual regression, and heuristic design review — and does something none of them do alone: it asks whether a live site keeps the promises its own design system makes, and returns a grade that any visitor can read. ## Working definition Design verification is the automated evaluation of a live site against a published design system contract, returning a score and per-check findings that resolve to a single letter grade. Three words in that sentence do the work. *Automated* means the same checks run the same way for every URL, with no human reviewer in the loop. *Live* means the input is the site your visitors receive, not a source tree or a screenshot. *Published contract* means the standard is public, versioned, and citable — the same one for every site it scores. ## The four-part contract A design system contract, in the verification sense, is not a Figma library. It is a layered agreement a site makes about how it will look, feel, and behave — and a checklist that scores whether it keeps that agreement. ### Tokens Named values — color, type, spacing, radius, motion, depth — that a site promises to use and no others. Drift here is the cheapest signal to catch. ### Rules Anti-patterns and required patterns the contract forbids or mandates — no raw hex, no magic numbers, focus-visible everywhere a pointer can go. ### Behavior How an interface responds to touch, keyboard, sound, and reduced-motion preferences. Poise, Takt, Cadence, and Acoustics are the names Designesy gives these layers. ### Verification A runnable checklist — 42 automated checks in Designesy's case — that scores a live URL against the tokens, rules, and behavior above and returns a letter grade. ## What distinguishes it Three properties, each absent from at least one adjacent practice. ### It runs against a live URL, not a source tree Design linting reads your code. Visual regression diffs your screenshots. Design verification fetches your production site the way a visitor would, then runs checks against the CSS and HTML the browser actually receives. ### It scores against a published contract, not a private baseline Regression compares to last week's snapshot. Verification compares to a contract that is published, versioned, and citable — the same contract for every site it scores. ### It returns a grade, not a diff Linting emits warnings. Regression emits pixel deltas. Verification emits a letter grade with a per-check breakdown that resolves to a single, scorable, comparable number. ## What it is not ### Not design linting ### Not visual regression ### Not heuristic review ## Why it matters A design system without verification is a document. A verified design system is a contract. The difference is whether anyone can run the same checks against the same URL and get the same grade — including the people who wrote the contract. This is why Designesy publishes its own score on the same terms as everyone else’s. The /score engine runs against designesy.org every time a visitor asks, against the same contract every other site is scored against. The same checks that grade your site grade ours. ## Where to see it - [Score a URL — Run the 42-check engine against any live site, including this one](https://www.designesy.org/score) - [Read the contract — Designesy design system v0.4.0 — tokens, rules, behavior, verification](https://www.designesy.org/contracts/design-system) - [Comparison article — Design verification vs design linting vs visual regression](https://www.designesy.org/learn/design-verification-vs-linting-vs-visual-regression) - [Why a public score — The argument for publishing the grade instead of keeping it internal](https://www.designesy.org/learn/why-we-built-a-public-design-score)