Reading the pre-scan report

The report always has the same nine parts, in the same order: the cover with the profile badges, the verdict, the prohibited-practice check, the duties table, the obligations, the AI components found in code, the register draft, the provenance block, and — only when a model actually wrote one — the narrative.

Read it in that order. The verdict rests on the answers, the duties table rests on the obligation mappings, and the provenance block tells you which versions of everything produced this document. Nothing further down changes anything above it.

Seven tiers are possible. The tier is computed from the answers alone; no model is involved.

• Undetermined. A classification question is unanswered, so no tier is asserted. This is not a low tier in disguise — the report lists exactly which questions are missing and what each one decides.
• Outside the Act's scope. A scope exclusion under Art. 2(3) or 2(6) is claimed. The report honours it, says in as many words that it is narrow and self-declared, and states that data-protection law and national law continue to apply to the same system.
• Prohibited practice — review required. At least one Art. 5 prohibition is corroborated by this project's own answers or code and nobody has approved it. This is not a tier to manage; it must be resolved before the system may be used.
• High risk. The system is used in an area listed in Annex III, so Art. 6(2) classifies it as high risk. This is where a benefits or allowances scoring system lands.
• High risk unless the Art. 6(3) derogation is documented. See the section on the derogation below.
• Limited risk (transparency duties). No Annex III area, but at least one Art. 50 feature — a chatbot, emotion recognition, biometric categorisation, a deep fake or AI-written public-interest text.
• Minimal risk. Neither of the above on these answers. The horizontal duties still apply, notably AI literacy under Art. 4.

An unanswered question never resolves downwards. That is the single most important property of the tier: the report would rather say it does not know than say the risk is low.

Every prohibition in Art. 5 applies to every deployer of an AI system. That is what a prohibition is. If the report escalated on applicability alone, every project would read "prohibited practice" and the tier would carry no information.

So the report separates two things. An Art. 5 row with no corroboration is listed as an attestation item: confirm in writing that you do not do this. It does not change the tier. A row becomes a finding only when something corroborates it:

• Code. The scan found face-recognition or emotion-detection code, with the file and line.
• Answers. You said the system infers emotions and is used in employment or education, which is the exact Art. 5(1)(f) case; or you selected biometric categorisation; or an Annex III biometrics or law-enforcement use; or one of the two social-scoring consequences.
• A person. The mapping is marked as requiring review, carries an unresolved ambiguity, or was rejected. A reviewer who stopped to ask is not a routine attestation.

One combination is deliberately not treated as corroboration: automated decisions with legal effect plus essential public services. Deciding benefit eligibility from relevant data is the canonical high-risk case under Annex III point 5(a), not social scoring, and an earlier version of this rule classified exactly that kind of system as a prohibited practice. Art. 5(1)(c) needs a score built from unrelated behaviour and applied in a detached context, which is what the social-scoring question asks about directly.

Whether "applicable but uncorroborated is an attestation item, not a tier change" is the right call for a regulator-facing report is an open founder decision. It is stated here so a reader can disagree with it knowingly.

Art. 6(3) is the only route out of high risk for a use listed in Annex III, and it is narrow. Landfall gives it a tier of its own — high risk unless the derogation is documented — rather than a footnote on "high risk", because the reader's real position is different in the two cases and the register entry and the classification card word it differently.

How the tier is reached:

• If no derogation case is selected, the tier is plain high risk.
• If a case is selected and the answers indicate the system profiles natural persons, the derogation is not available at all: the last subparagraph of Art. 6(3) makes such a system always high risk, and the tier stays high risk. Landfall reads profiling from the personalisation and recommendation answers and from the evaluation-and-scoring screening criterion.
• If a case is selected and nothing in the answers establishes whether the system profiles people, the tier also stays high risk. An unasked question is not read as a "no".
• Only when a case is selected and nothing indicates profiling does the tier become high risk unless the derogation is documented — and the report says plainly that the documentation must exist before the system is put into service, and the system registered, as Art. 6(4) requires.

Everything that gates treats this tier exactly as high risk. The CI check fails on the same unapproved Art. 6, 27 and 49 mappings, because a claimed but undocumented derogation is a reason to look, not a pass.

The duties table has six rows, each showing Yes, No or Requires review, with the basis it was derived from. "Requires review" is never a quiet no: it means the inputs do not decide it.

• Fundamental-rights impact assessment (Art. 27). Derived from the Annex III area, the deployer role and the kind of body. In the Netherlands this is the row that maps onto the IAMA.
• EU database registration as provider (Art. 49(1)). Only for a provider placing the system on the market. A body that buys a system does not owe it.
• EU database registration as a public-authority deployer. This is the registration duty that attaches to a public authority deploying a high-risk system. Landfall labels it Art. 49(3); the exact numbering of the provider and public-deployer registration duties is on the open legal-review list, so check the article number against the regulation before citing it in correspondence.
• General-purpose AI model provider duties (Art. 53, and Art. 55 where the model carries systemic risk). Derived from Q21 (do you provide a general-purpose model), Q22 (systemic risk) and the scope-exclusion answer. It is independent of the risk tier: a general-purpose model used in no Annex III area reports as limited or minimal risk and still owes the Chapter V duties.
• Data-protection impact assessment (GDPR Art. 35). Derived from the Art. 22 answer and the European screening criteria. Two or more criteria, or an automated decision with legal effect, indicate a DPIA. An AI system never screens out on the answers alone, because innovative use of new technology is itself one of the criteria.
• Prior consultation (GDPR Art. 36). Never "yes" from screening. Art. 36 turns on high residual risk after the DPIA, which no questionnaire answer can establish, so it is "no" when no DPIA is indicated and "requires review" otherwise.

Each row prints its own basis. If a mapping exists for the duty, the basis names the mapping and its human-review state; if not, the basis says the row is screening only and names the answers it came from.

Every obligation row carries a human-review state, and it means exactly one thing: what a person has done with the mapping, not whether the underlying duty is met.

• none — no approval has been requested. The mapping is the engine's verdict and nobody has looked at it.
• pending — it has been submitted for approval, or escalated, and is waiting for a reviewer.
• approved — a reviewer signed it off. This is the only state that closes a gate.
• rejected — a reviewer disagreed with the engine's verdict.

A report in which the classification obligations are still "pending" is a draft, and the report labels it as one. It is perfectly usable in that state — the point of a pre-scan is to read it while the system can still change — but do not attach it to a decision as though it had been reviewed.

For a public-sector project the report carries a draft Algoritmeregister entry, and the export page offers the same content in the shape the national register publishes: the standard's own property names, its Dutch labels and its categories, as a Dutch two-column table or as JSON.

The field set follows the Algoritmeregister publication standard version 1.0.0 — 32 properties, 18 of them mandatory — read from the ministry's published schema rather than reconstructed. Every field prints where its value came from.

Eight fields come out as the literal Dutch placeholder because Landfall genuinely does not know them: status, start date, contact, purpose and impact, considerations, legal basis, data, and supplier. The contact field is left empty deliberately even though the report has an author: the standard asks for a general contact point and explicitly not a personal e-mail address.

What is derived, and how: the publication category is filled as the high-risk category only when the computed tier is high risk — categories B and C are the publishing body's own judgement and stay empty; human intervention comes from the Art. 14 or Art. 26(2) mapping, whichever applies; risk management from the tier, the applicable obligations and the number of unanswered questions; impact assessments from the DPIA, FRIA/IAMA and prior-consultation flags, with the engine's own basis strings carried across unchanged; technical operation from the files where the scan found AI components.

Whether deriving the high-risk publication category from the computed tier is the right call at all, rather than leaving every publication category to a human, is an open founder decision. So is using the Landfall project id as the source identifier. Check both before publishing.

The Dutch export is offered only for a public-sector project, in HTML and in JSON. The JSON carries both an annotated field list — label, category, whether the standard requires it, and where the value came from — and a flat object keyed by the standard's own property names, which is the shape a machine import expects.

The impact-assessment field prints the FRIA and the IAMA together, because Landfall's position is that one assessment record can serve the IAMA, the Art. 27 FRIA and the GDPR DPIA, with a section map showing which part of the IAMA answers which heading. The generated work item for the Art. 27 assessment carries that instruction, and the evidence checklist asks for the IAMA record's identifier, because the register expects the reference.

The reverse direction exists too. If this algorithm is already published, paste the entry — JSON, a CSV with a header row, or plain key and value lines, with either the Dutch labels or the standard's property names — into the questionnaire's intake panel. Closed fields become deterministic suggestions with the field value as the quote; the free-text fields go through the same document extraction, with the same verbatim-quote requirement, as any other document. Nothing writes an answer, and fields still holding the Dutch placeholder are read as unfilled.

A colleague, a supplier or a supervisory contact without a Landfall account can be given a guest link from the same export card. Give the link a label, pick an expiry of 7, 30, 60 or 90 days, and copy the URL.

What the guest gets, and what they do not:

• The report, with a banner inside the document naming the organisation it was generated for, who shared it, when, the label it was shared for, and the expiry date. Because the banner is inside the document, a printed or forwarded copy still carries it.
• The link opens the pre-scan and nothing else. An audit-packet link does not open the pre-scan and vice versa; an unknown token and a wrong-scope token get the same response, so a holder cannot even learn that another artefact exists.
• No e-mail addresses, and no model is ever called on the guest path.
• The link renders the project's current answers, mappings and scan each time it is opened. It is not a frozen copy — a pre-scan describes a system while it is still changing, and a frozen copy would quietly show a colleague a verdict the project has moved past. If you need a frozen artefact, download the authenticated HTML, which is stored with its own integrity hash.
• Every view is counted and logged, and the link can be revoked at any time from the same dialog.

Evidence is not a box that stays ticked. Each evidence requirement states how often the artefact behind it must be re-assessed: technical testing quarterly, policies and documented assessments annually, and nothing at all for a one-off registration such as the Art. 49 database entry — those do not go stale with age, they are either still on file or they are not.

Against that interval every artefact reads as fresh, due for re-assessment (the last fifth of the interval), or past re-assessment. Only the last one is a problem: a verified artefact whose window has elapsed no longer demonstrates the obligation is met, and the report says so instead of counting it as current. The audit report prints the state and the date it was due; the obligation's health badge turns to stale evidence for the same reason.

Evidence also has a kind: legal (policies, contracts, notices, documented assessments), technical (configuration, code, logs, test output), process (records that a process actually ran, audits, training) and adversarial test (a dated third-party red-team, jailbreak or robustness report, which Art. 9 and Art. 15(5) ask for by name). The requirement says which kind it needs, so when something is missing the report can say which kind — "technical evidence missing" — rather than the unhelpful "no evidence".

If your engineers wire the decision check into the pipeline, the same verdict becomes an exit code. An undetermined tier fails, because a system nobody has classified cannot ship. A corroborated prohibited practice fails. A high-risk system with an unapproved Art. 6, 27 or 49 mapping fails. A limited-risk system with an unapproved Art. 50 mapping warns, and fails in strict mode. A claimed scope exclusion sitting on top of corroborated prohibited-practice signals warns rather than passing silently. A separate evidence-freshness check ages the verified evidence on approved obligations against their re-assessment intervals: past the interval fails, inside the last fifth of it warns, and in strict mode both fail. Everything else passes.

That is the whole compliance layer between an experiment and production: approve the classification decisions, and the gate goes green.