How the CRA Scope Checker works

A decision tree, not a model

The checker draws on a bank of 10 questions and asks nine of them on most paths — the rest appear only when an earlier answer opens a follow-up. It evaluates them against six tables of rules: verdict, confidence, economic-operator role, product class, key dates and findings. The tables are data, not code branches scattered through the application, and the first rule that matches wins.

The same answers always produce the same result. There is no language model anywhere in the decision: not to pick the verdict, not to weigh the confidence, not to choose which findings you see. That is a deliberate constraint, and it is what makes the next paragraph possible.

Because the path is deterministic, it is auditable. Every assessment records which rules fired, and the result page shows you that list in the margin — the same one the engine used, not a summary written afterwards.

What each verdict means

Likely in scope

A product with digital elements, made available on the EU market in the course of a commercial activity, and not displaced by a sector-specific regime.

Likely out of scope

No EU market path, or purely non-commercial open source, or a service with nothing shipped and no remote data processing the product depends on, or a sector regime of its own.

Edge case — needs analysis

The honest answer for a path the Regulation itself leaves open: hybrid SaaS, monetised open source, a component where substantial modification is arguable, a steward arrangement. When the correct answer is “it depends”, the tool says so and says on what.

What confidence measures

Confidence is about the path, not about the product. It starts high and drops a step for each borderline marker your answers cross — an EU launch that is planned rather than done, a free product tied to a commercial offering, and so on. A verdict rule can also cap it outright.

So confidence answers a different question from the verdict. The verdict says what the assessment concluded; confidence says how much of that conclusion rests on ground the Regulation draws clearly. High confidence on an ambiguous path would be the worst error this engine could make, which is why the penalties are in a table you can read rather than in someone's judgement.

How sources are cited

Every rule carries the sources it rests on. A source is marked verified only when a human has opened the official text and confirmed the reference, with the date recorded. Today that is 38 of 39.

The remaining 1 were read on 12 September 2026 against two independent reproductions of the consolidated text, which agree word for word — but not yet against EUR-Lex itself, so they are recorded as pending rather than verified. They are named one by one in the test that guards this claim: a new unverified source fails the build, and the pending ones cannot quietly become permanent.

References are made at article and annex level, and a paragraph or point number appears only where the text itself is numbered that way. No URL is invented: where there was no reliable link, the field stays empty rather than plausible.

Assessment engine v1.5.0, calibrated against Commission guidance as of 2026-08. Every report records both, because a methodology that changes without a version is a methodology you cannot cite.

Changelog

v1.5.0 — 12 September 2026. Obligations became role-aware. Until v1.4.0 every in-scope result ended with the same three lines — a machine-readable SBOM, technical documentation across releases, and the Article 14 reporting clock. Those are manufacturer obligations, and an importer or distributor was being shown them as their own. They are now shown only where the engine puts you in a manufacturer role, and importers and distributors get theirs instead: verify what the manufacturer did (Article 19 and Article 20), inform the manufacturer of a vulnerability without undue delay and the market surveillance authorities where the risk is significant, and the one thing that turns you into a manufacturer — your own name on the product, or a substantial modification (Article 21).

The same release added the transitional rule of Article 69 to results for products already on the market: the requirements reach a product placed on the market before 11 December 2027 only if it is substantially modified from that date (Article 69(2)), while the Article 14 reporting obligations reach every in-scope product placed on the market before then (Article 69(3)). The definition of a substantial modification is quoted from Article 3, point (30), because the reassuring half of that rule is the half people remember.

v1.4.0. Six rule tables, a generic evaluator, and the confidence penalties in a readable table.

Limits

A scope check is the first question, not the last. It does not read your code, your contracts or your technical documentation — it reasons from the nine answers you gave about the product. Two companies answering identically get the same result, and the details that separate them are exactly what a closer analysis is for.

Product class in particular is an estimate. It follows the Annex III and Annex IV category definitions as your answers describe the product, and the definitive classification depends on specifics the checker never sees. The harmonised standards that will define how to satisfy the requirements are also still being developed, which is why the tool reports a confidence level instead of a verdict dressed as certainty.

What this is not

This is not legal advice, and it is not a certification, a conformity assessment or an opinion on whether you comply with anything. It is an automated regulatory assessment produced for orientation. For a formal determination, the specifics of your product need a qualified professional.

Our Terms of Use say the same thing in the language that binds, and the articles cite their sources the same way the engine does.