Frequently askedquestions

It reads a sample of your design system documentation (up to 40 pages, chosen across your sections rather than in order), scores it against twelve guidelines drawn from the Design System Documentation Spec, then gives a coding agent eight real jobs a developer would bring to your docs and shows you the transcripts. You get a machine-readability percentage, a count of jobs that passed, and what to improve.

Because it already does. Coding agents in Cursor, Claude Code, Copilot and the like search your docs, open a handful of pages and answer from what they find, once, under time pressure. If the fact a developer needs is not stated somewhere a machine can find and quote, the agent guesses, and the guess ends up in a pull request. DS ARC shows you where that happens.

Yes. Running a check is free and needs no account. The scores and the list of jobs are on the report for anyone with the link; the full findings, with each failing transcript and its fix, are behind an email address, and come with a PDF.

zeroheight, the design system documentation platform. DS ARC is a free tool, not a feature of the product: it works on any documentation, wherever it lives. There is more on that at the foot of the landing page.

A public documentation site, which we crawl the way an agent would. A folder of markdown, uploaded (a zip is unpacked in your browser; the file itself is never sent). A zeroheight styleguide, read through zeroheight’s API after you sign in. A GitHub repository, public or, after connecting the app, private. Or a published Storybook, where we read the docs pages.

About five minutes. The crawl takes a minute or so, then the eight jobs run, several times each, and the report is built. You can watch it happen; the page hands over to the report when it is ready, and the link works from the moment you submit.

A documentation site can run to thousands of pages, and the point is how an agent copes with yours, not how patient we are. We sample up to 40 pages across your sections: components, foundations, tokens, patterns, accessibility. The report says exactly which pages were read, and a finding is never called a gap until we have gone back and checked the pages outside the sample too.

Not by crawling, no. Use the upload route for markdown, connect zeroheight or GitHub to read directly through their APIs, or point at a Storybook if you publish one. We never ask for a password to someone else’s site.

Usually the site draws its content with JavaScript and serves an empty shell to anything that is not a browser, which is what an agent gets too. That is itself a finding, but we stop rather than score an empty crawl. Try the Storybook route, connect the source directly, or upload the markdown.

Yes, because each run costs us real money. 10 checks a day from one person, and 10 a day against any one documentation site across everyone. The refusal tells you when you can try again, and links the latest report for that site if there is one.

Yes. Every report has a Run it again link that takes you back with the same source filled in, and when the same docs have been checked more than once the report shows the score history, so you can see whether a change moved the number.

A weighted score across twelve guidelines, each a plain question about whether a fact an agent needs is present and reachable as data: is the component API on the page or behind a link, are the allowed values of a variant listed, is keyboard behaviour stated key by key, are token values available as data. It does not depend on what any one agent did; it is about the documentation itself. The rubric page lists all twelve.

Choosing the right component for a need described in plain language. Choosing between two components a developer could confuse. Telling two similarly named things apart. Listing a component’s props with their types and defaults. Listing the exact allowed values of a variant. Naming the token for a purpose. Saying which keys a component supports. And refusing to describe a component that does not exist. Each is asked up to five times, so an answer that changes run to run is caught. The battery page has an example of each.

Claude Sonnet 4.5, through Anthropic’s API, with two tools: search the pages we read, and open one of them. It cannot fetch anything live, and it sees only what the crawl saw. The model is named on every report.

Because we do not set the model’s temperature to zero. Run-to-run variance is a finding, not noise to suppress: if the agent lands on a different component each time, nothing in your docs says clearly enough which one owns that job, and a developer reading the same pages could pick differently too. The report calls that ambiguity and shows the runs.

Each run reads a fresh sample of pages and asks the agent afresh, so small movements are noise. A change in how many jobs pass is not. The score history on the report shows both side by side.

No. Almost nobody has published a DSDS document, so a real conformance run would come back “not applicable” for nearly everything. We take the reasoning behind each DSDS field, the fact some consumer needs in a retrievable place, and ask whether that fact is findable in your docs however they are built. The DSDS field each guideline came from is cited on the report.

We could not write a checkable question for that job against your docs, usually because the crawl found nothing to anchor it to, so rather than guess we left it out and counted only the jobs that were asked. The report says which job and why.

Enter a work email on the report page. That unlocks every failing transcript with its fix and what each amber or red guideline is missing, and we send you the link and a PDF. The email goes into zeroheight’s CRM so we can send it; marketing only ever follows the consent you give on that form.

The text we read and the agent’s transcripts for 14 days, then deleted. The report itself, the scores and findings, for as long as the link is live, so a share link keeps working. A salted hash of your IP address, never the address, to enforce the limits. Your email only if you unlock the full report. The whole of it is on how we handle your data.

No. The text is sent to Anthropic’s API to run the jobs, and Anthropic does not train on what is sent through its API. We do not send it anywhere else.

Anyone with the link, which is unguessable, marked so search engines do not index it, and expires 14 days after the run. Nothing is listed anywhere. You can unpublish the link from the report page at any time.

We read only the styleguide or repository you choose, only for this check, and only to read; the access token is encrypted, used once by the run, and deleted the moment the run finishes, whether it succeeds or fails. We cannot write to anything of yours.

An opt-in, off by default, to include your run, anonymised, in zeroheight’s annual State of Design System Documentation report. Anonymised means we keep the scores and the counts and drop everything that could identify the system: its name, URL, pages, transcripts and your email. We publish totals across many systems, never a single row, and you can withdraw a run by emailing us.

With the “What to improve” list on the full report: the changes that move the score most, in order. Across the systems we have run, the most common gaps are keyboard behaviour described as “accessible” with no keys named, token values that live only in a swatch, and allowed values of a variant that are shown but never listed.

It should not. Every guideline is something a developer wants too: the props table on the page, the exact values, the keys, which of two components to use and when. Stating a fact plainly, once, somewhere findable, is good documentation either way.

zeroheight is where that context lives for teams who use it: Figma and Storybook plug in, so designs, code, tokens and guidelines sit together on one published page, and the zeroheight MCP serves all of it to whichever AI tools your team uses. DS ARC works on any documentation; zeroheight is one way to fix what it finds.