DevTools Accuracy Framework

Gracker checks the technical claims in your developer content against the thing that actually defines them - the package registry, the source repository, or the specification - and pins each one to the versions it is true in.

A claim without a version is not a claim

This is the whole framework in one line. Everything else follows from it.

"React batches state updates" is not true or false. It is true from 18, and it was not true before. "Node supports require() of ESM" is not true or false either. "The flag is deprecated" begs the question: since which release, and removed in which?

Developer content is written in the present tense about software that has no single present. The reader is on a version, your docs are about a version, and the blog post is about whichever version was current when someone wrote it. That gap is where almost every wrong technical claim lives, and none of it looks wrong on the page.

So the first thing Gracker does to any technical claim is try to bound it. A claim that cannot be bounded to a version range cannot be verified, and is flagged rather than cited.

The three questions

1. Does it exist?

Is there such an API, flag, option, method, package or config key at all - not "does it sound plausible", but is it in the artifact people actually install?

Resolved against the registry entry and the published types or source, never against documentation prose. Documentation lags, and documentation for a thing that was renamed will happily describe the old name for years.

2. In which versions?

The claim gets a range: introduced in x, changed in y, removed in z. A range that ends before the version your reader is on makes the sentence wrong for them even though it was right when written.

Version ranges come from release metadata, changelogs, and the compatibility data projects that exist precisely for this - MDN's browser-compat-data for web platform features, caniuse for browser support, the language proposal trackers for anything not yet shipped.

3. Is it still supported?

Separate from whether it works. A runtime past end of life still runs; recommending it is still wrong. Support windows are published as data, not prose: Node 26 released 2026-05-05, enters LTS 2026-10-28, end of life 2029-04-30 - three dates, one lookup, no recollection involved.

One claim, checked

The draft says: use the built-in fetch instead of node-fetch.

What ships:

Node has provided a global fetch since 18, so node-fetch is no longer needed on any currently supported release line.

A version bound and a support statement, where the draft had a bare recommendation.

What a finding looks like

Not a score. A list of sentences, what the registry or source actually says, and the edit.

Findings from a page about replacing HTTP client dependencies:

Every sentence in that left column is something a competent engineer would write, and none of them is invented. That is the point: developer content fails on version scope, not on truth.

Two patterns account for most of it. An unbounded claim - true today, silently false for readers on a different release, and fixable with one clause. And a proposal written as shipped - real, documented, discussed at length, and not yet available to anyone reading you.

What Gracker checks against

All of these are public and machine-readable, which is what makes this vertical checkable at all. There is no regulator here; the registry is the closest thing developer tooling has to a system of record, and it is a good one.

What this does not check

• Whether the advice is good. Whether a library suits your architecture is judgment. This checks that the facts under the advice are true.
• Performance claims without methodology. Flagged as unverifiable rather than wrong.
• Private and internal APIs. Nothing published, nothing to check against.
• Prerelease behaviour. Nightlies, canaries and betas change under the claim; they are noted as unstable rather than verified.
• Non-technical brands, and non-articles. Nothing runs.

In the product

Page Audit grades every technical claim, shows what the registry or source says, and gives the edit. Deprecated packages and ones carrying open advisories are called out separately, since those are the findings that cost a reader real time.

Visibility Diagnosis names the version ranges and compatibility facts competitor pages carry on a topic where they outrank you.

Content Generation writes version bounds into the draft as it goes. No API, flag or package is named unless it resolves on the registry, and no support claim is made without the published end-of-life date.

FAQ