Glossary
Plain-English definitions of the compliance terms used across the Regulated AI Navigator. These are working explanations for orientation, not legal advice — for a concrete deployment, validate the term against the underlying regulation with qualified counsel.
ADM provision AI-law dimension AIMS / ISO 42001 Annex III Annex IV bridge instrument Calibration Confidence band Conformity assessment Contribution credits Crosswalk Cyber & resilience Deployer enforcement intensity Equivalence vs overlap Established vs asserted Evidence artifact Evidence dossier FRIA (fundamental rights impact assessment) GPAI (general-purpose AI model) Harmonised standard Hash chain (release fingerprint) maturity tier (T1–T4) Notified body OJEU citation Practice-derived Presumption of conformity Product safety & liability Provider Regulatory footprint Reuse factor Risk tiers Text-derived the Art. 25 role flip Verifiability ladder Weakest link (aggregation)
- ADM provision
Many jurisdictions have no AI law but do regulate AI outcomes through the automated-decision-making provision of their data-protection statute (GDPR Art. 22, Brazil's LGPD Art. 20, China's PIPL Art. 24, Korea's PIPA Art. 37-2). RAIN records that article explicitly and only pulls the instrument into a conclusion when the use case actually involves personal data or an automated decision — jurisdiction membership alone is never enough.
- AI-law dimension
The AI-law dimension covers the instruments written specifically for AI systems — the EU AI Act with its risk classes and GPAI duties, and comparable statutes such as the Colorado AI Act, the NY local hiring law or the proposed AI liability rules. It is one dimension of the footprint: a use case can be minimal-risk under the AI Act and still carry heavy duties under data protection, DORA or product-liability law.
- AIMS / ISO 42001
ISO/IEC 42001:2023 defines a certifiable AI management system (AIMS), using the same Annex SL harmonized structure and plan-do-check-act logic as other ISO management-system standards, with a synergy discount available where an ISO 27001 information-security management system already exists. It is estimated to cover 40–50% of the AI Act's organizational duties, but certification is an organizational certificate — it does not by itself grant a product-level presumption of conformity under the AI Act.
- Annex III
Annex III of the AI Act lists the categories of AI system that are high-risk because of the area they are used in — for example employment and worker management, access to essential services such as credit or insurance, education, migration, law enforcement, and critical infrastructure. Falling into an Annex III category triggers the full high-risk obligation set (Art. 8–15), a quality management system, conformity assessment, and CE marking, unless the system genuinely poses no significant risk under the narrow carve-outs the Act allows.
- Annex IV
Annex IV sets out the technical file a provider must maintain: system description, architecture, capabilities and limitations, and the risk measures taken. It is meant to be built incrementally during development — reconstructing it retroactively, after the fact, is treated as an audit red flag. Where the notified-body route applies, the file is reviewed as part of that assessment.
- bridge instrument
Bridge instruments are not the law of any single market: they are internationally recognised frameworks that many jurisdictions reference, so a control or artifact built against them travels. RAIN labels them as cross-jurisdiction rather than filtering them by market, and requires recorded uptake evidence — a jurisdiction that recognises, references or has signed the instrument — before it may claim bridge status.
- Calibration
A confidence label is only worth something if it predicts reality. Calibration is the published comparison between the band a claim carried and how often that claim later had to be corrected: claims marked provisional should be corrected more often than claims marked robust. Until enough corrections have been logged to make that comparison meaningful, the track record says there is not enough data yet rather than showing a reassuring figure.
- Confidence band
RAIN does not let anyone type a confidence level. Each step of a derivation is scored from data that already exists on the instruments it rests on: whether the claim has a primary source, how long ago that source was last verified against a revalidation window that reflects how fast the jurisdiction moves, whether the instrument is in force, how much the community has confirmed or disputed it, and whether the step follows a text or an interpretation. The result is reported as one of three bands with the reasons behind it, because a figure like "83 % confident" would claim a precision the underlying data does not have. A step resting on an interpretation can never reach the top band, however well-verified its endpoints are.
- Conformity assessment
There are two conformity-assessment pathways. Internal control self-assessment (Annex VI) covers most Annex III systems — the provider itself verifies its quality management system, technical file, and design consistency. Notified-body assessment (Annex VII) is mandatory for safety components in already-harmonised products (such as medical devices, aviation or rail) and for remote biometric identification. Harmonised standards cited in the OJEU give a presumption of conformity within either pathway.
- Contribution credits
Contribution credits are RAIN's contribute-to-participate currency. They are earned by hardening the graph — an accepted verification, an accepted use case, an accepted peer review, or inviting a colleague who gets verified — and are only credited on acceptance, never on submission alone. Credits are spent on member services such as saving an analysis to a portfolio or requesting an expert review. All balance changes are written server-side, so no client action can mint or remove a credit directly.
- Crosswalk
A crosswalk links obligation-side entries (articles, control objectives, standards, regulations, policies) across regimes — for example an AI Act logging duty and the equivalent DORA record-keeping duty. Same-regime restatements are not crosswalks. Because a mapping is always an interpretation, RAIN requires a rationale, a confidence marker and an open dispute route on every mapping. The practical payoff is reuse: if two duties meet in one artifact, you produce that artifact once.
- Cyber & resilience
The cyber & resilience domain groups the instruments that regulate secure development, incident reporting and operational continuity — the Cyber Resilience Act for products with digital elements, NIS2 for essential and important entities, DORA for financial entities and their ICT third parties, plus eIDAS2 and comparable regimes. These obligations attach to the system as software and service, independently of any AI-specific classification.
- Deployer
Uses the system under its own authority: instructions-compliant use, oversight staffing, input-data control, log retention of at least six months. Beware the Art. 25 role flip.
- enforcement intensity
Enforcement intensity is recorded separately from the maturity tier because a binding law with no supervisory practice and a data law enforced aggressively create very different exposure. "Not yet enforced" marks instruments in force whose supervisory or penalty regime has not started; "dormant" marks regimes that exist on paper but show no observable enforcement. It is a judgement about observed practice, so it is community-verifiable like every other field.
- Equivalence vs overlap
"Equivalent to" means satisfying one duty substantively satisfies the other, so a single artifact can be filed against both. "Overlaps with" means the duties address the same subject but differ in scope, addressee, threshold or depth — the work is reusable, the conclusion is not transferable, and you still have to check the delta. A third relation, "conflicts with", marks the cases where the two regimes pull in different directions and a deliberate choice has to be documented. Reading an overlap as an equivalence is the most expensive mistake in cross-regime work, which is why the graph never collapses the two.
- Established vs asserted
"Established" marks a mapping that rests on an official or standards-body correspondence — a mapping table, guidance, or an explicit cross-reference in the text. "Asserted" marks our own reading of two provisions: plausible, argued in the rationale, and openly disputable. Both are usable; they carry different weight in front of an auditor, and treating an asserted mapping as if it were established is exactly the kind of quiet upgrade RAIN refuses to make. Every mapping of either kind links to the proposal pipeline so a specialist can contest or promote it.
- Evidence artifact
An obligation is a duty; an artifact is what you hand over. RAIN classifies each artifact as a document, assessment, test report, log record, process record or registry entry, so a compliance plan reads as a list of things to produce rather than a list of things to read. Artifacts are never law: they carry no obligation of their own and nothing in the graph may classify, trigger or impose through them.
- Evidence dossier
An exportable file (Markdown or JSON) that lets someone else re-run or contest a conclusion instead of trusting it. It records the inputs exactly as they were entered — description, answered questions, selected target markets — then every step of the derivation with the provision it rests on, its citation link or an explicit "uncited" marker, its verification date and status, its confidence, the limitations of the answer, and the fingerprint of the data version it was computed from. It is a reproducibility record, not a compliance document.
- FRIA (fundamental rights impact assessment)
Fundamental-rights impact assessment (Art. 27, deployer-side), generalized in practice to an AI Impact Assessment: a societal, legal and operational risk evaluation that defines human-oversight intervention parameters and acceptable-use bounds. It is done before deployment and refreshed annually and on major model updates — a stale FRIA is treated as an audit finding, not merely an outdated document.
- GPAI (general-purpose AI model)
A general-purpose AI (GPAI) model is trained on broad data and capable of a wide range of tasks, regardless of how it is later packaged or deployed. The AI Act imposes model-level obligations on GPAI providers — technical documentation, training-content summaries, and copyright-compliance policies — with an additional systemic-risk tier for the most capable models. These duties sit alongside, not instead of, the obligations that apply to whoever later builds a system on top of the model.
- Harmonised standard
A harmonised standard is a technical standard developed by a recognized European standards body (such as CEN-CENELEC) under a mandate from the European Commission to flesh out how a legal obligation should be met in practice. Meeting the standard is voluntary, but a system built to a standard that has been officially cited gets the benefit of a presumption of conformity with the corresponding legal requirement. Until a standard is cited, following it is good practice but does not by itself satisfy the law.
- Hash chain (release fingerprint)
Every release computes a SHA-256 digest over the knowledge data as published and stores it together with the digest of the release before it. Because each entry commits to its predecessor, the release history cannot be quietly rewritten after the fact: an altered past release breaks the chain visibly. Any analysis you export names the fingerprint it was computed from, so a conclusion can always be tied back to the exact published state of the data.
- maturity tier (T1–T4)
Every jurisdiction in the registry carries a maturity tier describing what kind of instrument an operator is actually bound by there. T1 means a binding horizontal AI law is in force (EU, KR, JP, VN). T2 means only binding data-protection or sector law applies to AI, typically through an automated-decision-making provision. T3 means the jurisdiction has published a soft-law framework or guidance with no operator-binding force. T4 means a national strategy or policy exists but no instrument yet. Tiers rank legal status, never regulatory quality or enforcement risk.
- Notified body
A notified body is an independent conformity-assessment organization that a national authority has designated and notified to the European Commission as competent to assess products against a given piece of EU law. For AI systems, notified-body assessment is required only for the narrower set of cases where the Act's Annex VII route applies — most other high-risk systems can rely on the provider's own internal-control self-assessment instead.
- OJEU citation
The Official Journal of the European Union (OJEU) is where the Commission formally publishes the reference number of a harmonised standard once it has assessed and accepted it. A standard only unlocks the presumption of conformity from the date its citation is published in the OJEU — publication of the standard itself by the standards body is a necessary but not sufficient earlier step.
- Practice-derived
Where the text states a duty but not the deliverable, the deliverable comes from audit and assurance practice — a red-teaming report, a due-diligence record, an oversight intervention log. RAIN labels these openly as practice-derived, dispute welcome, and routes each one to the proposal pipeline, because a contestable claim marked as such is worth more than a confident one that hides its source.
- Presumption of conformity
Presumption of conformity is a legal shortcut: if a provider builds and documents its system in line with a harmonised standard that has been cited in the OJEU, regulators presume the corresponding legal requirement is met, without the provider having to separately prove it clause by clause. Without a cited standard, the same requirement still has to be satisfied, but the provider carries the full burden of demonstrating it directly against the law's text.
- Product safety & liability
Product safety & liability covers the instruments that regulate the AI system as a placed-on-market product: the revised Product Liability Directive (which expressly covers software and AI), the General Product Safety Regulation, the Medical Device Regulation and the Machinery Regulation. They add conformity, documentation and defect-liability duties on top of any AI-law classification.
- Provider
Develops (or has developed) and places the system on the market under its own name: full Art. 8–17 burden, technical file, conformity assessment, CE marking.
- Regulatory footprint
A regulatory footprint is the cross-domain shape of a single use case: which instruments it triggers in AI law, data protection, cyber & resilience, product safety & liability, financial services and sector or employment law, plus the standards that support them. RAIN derives the footprint from the knowledge graph rather than asserting it, and shows domains with nothing triggered as "none triggered" instead of omitting them — an empty domain is a finding, not a blank.
- Reuse factor
Computed by counting the evidenced_by edges pointing at each artifact. A high reuse factor is the architectural argument of the evidence layer: an event log or a risk register produced once can satisfy AI Act, GDPR, DORA and sectoral duties simultaneously — comply once, evidence many. It is also a planning number: build the most reused artifacts first.
- Risk tiers
The AI Act sorts AI systems into four risk tiers that set the obligation set that applies. Unacceptable-risk practices (such as social scoring or untargeted facial-image scraping) are banned outright. High-risk systems — safety components in regulated products, and the Annex III use-case list — carry the full obligation set: risk management, technical documentation, a quality management system, conformity assessment and CE marking. Limited-risk systems (chatbots, deepfakes, emotion recognition) carry disclosure and labelling duties. Minimal-risk systems have no AI-Act-specific obligations beyond general AI-literacy duties, though other laws such as the GDPR may still apply.
- Text-derived
A text-derived artifact is read straight off the provision — the technical documentation of Annex IV, the logs of Art. 12, the DPIA of GDPR Art. 35. The claim is verifiable against the text, so a reader can check it without trusting us.
- the Art. 25 role flip
A deployer becomes the provider (full Art. 8–17 duties) by re-branding, changing the intended purpose, or making a substantial modification — for example deep fine-tuning or wiring a model into autonomous agent toolchains.
- Verifiability ladder
The verifiability ladder describes how strongly an evidence artifact can prove it hasn't been tampered with, independent of who vouches for it. Self-asserted means the organization simply states the artifact exists and is accurate. Tamper-evident means manipulation would be detectable after the fact within the organization's own systems (for example hash-chained, append-only logs). Externally-anchored means integrity proofs leave the organization's own trust domain — such as periodic hash anchoring to an external ledger. Independently-attested means an external party has re-performed the verification itself and formally attested the result. Verifiability (what the artifact can prove) and attestation (who vouches for it) are separate, complementary dimensions of evidence strength.
- Weakest link (aggregation)
A derivation chains several steps together: use case to instrument, instrument to duty, duty to control, control to supplier layer. Averaging their confidence would let four solid steps hide the one shaky step a reviewer actually needs to see. RAIN therefore reports the worst step as the confidence of the whole chain, and names which step it was, so the fastest way to raise the answer's standing is visible rather than hidden.