How the Library is organised
Governance covers the structures through which an organisation constrains, authorises, controls and remains accountable for how automated AI systems operate. Cards in this series address the fundamental constraints, scope, authority, control, accountability and evidence, without which governance cannot be said to exist.
Scope & Limits covers the characteristics of the AI system itself that determine whether its decisions can be understood, attributed and defended. Cards in this series address intended use, model type, data, outputs, explainability, transparency, robustness and the properties of third-party and vendor components.
Authority and Responsibility covers who is named as responsible for what the system does, how that responsibility is documented and what happens when it cannot be established. Cards in this series address accountability, approval processes, human oversight, delegated authority, responsibility gaps, procurement and board-level obligations.
Control &p; Monitoringcovers the mechanisms that actively constrain system behaviour during operation and provide the means to detect, intervene and respond when something goes wrong. Cards in this series address monitoring, access control, intervention authority, change management, testing and human override.
Evidence and Records covers the records that must exist to reconstruct what a system did, demonstrate that controls were in place and respond to formal challenge. Cards in this series address audit trails, decision records, system logs, incident records, documentation, data retention, traceability and decommissioning.
Legal Exposure covers the specific legal obligations, rights and exposures that attach to automated AI decision-making under current law. Cards in this series address the EU AI Act, GDPR, automated decision rights, product liability, consumer protection, regulatory investigation, legal challenges and sector-specific obligations including SMCR, discrimination law, directors duties, health and safety, works council obligations, post-market monitoring, decommissioning liability and public sector accountability.
The card structure
Every card in the Library follows the same structure. Each field serves a specific purpose.
Code and title
Every card has a unique code, for example GO-01 or LR-24, and a title that names the failure condition. The code is used for cross-referencing and searching. Cards can be retrieved directly by typing their code into the search box.
Description
A precise statement of the failure condition itself. This is not a definition of good practice. It is a description of the specific condition under which a control is absent, inadequate or cannot be demonstrated. The description is the reference point for everything that follows on the card.
Context
An explanation of where this failure sits in relation to other controls. Context explains why the failure matters at this particular point in the governance structure, what depends on it, what it depends on and what its absence means for the controls around it. Context is not background. It is structural positioning.
What is required
The specific requirements that must be in place for the control to be considered present. These are not aspirational standards. They are the minimum conditions that distinguish a control that exists from one that has been described but not implemented. Each item is a specific, demonstrable requirement, something that either exists in a particular organisation or does not.
How do you prove it
The specific records, documents and demonstrable facts that would need to exist to show the control was in place at the time it mattered. This section is written from the perspective of formal scrutiny, what a regulator, court, insurer or board inquiry would need to see. Each item corresponds to evidence that either exists or does not. The absence of any item is a specific gap.
Why does it matter
The governance and evidentiary consequence of the failure. This section explains what the absence of the control means in practice and why it is not merely a policy gap. It is written to explain the failure, not to instruct. It addresses what an organisation cannot show, cannot prove and cannot defend when the failure condition exists.
Advantages
The specific benefits that flow from having this control in place, not as general statements of good governance, but as specific consequences of the control's presence. These are evidentiary and operational benefits, not aspirational ones.
Limitations
The conditions under which this control may be present on paper but ineffective in practice or where the control's scope does not address all relevant risks. Limitations are not reasons not to have the control. They are conditions that require attention for the control to be genuinely effective rather than nominal.
Board and management implications
A separate section addressed directly to the governance level, directors, senior managers and accountable individuals. This section describes what the failure means for the person responsible, in terms of what they would need to show and what they face if they cannot. It does not give advice. It describes the personal accountability position.
Keywords
The terms used by the search engine to surface this card in response to relevant queries. Keywords cover the technical, legal and governance vocabulary associated with the failure condition. They are not visible on the card but drive search results.
Related cards
Other cards in the Library that are directly connected to this failure point, either because they address controls that depend on this one, controls that this one depends on or failure conditions that commonly occur together. Related cards are visible and linked. They are also used by the search engine to surface connected failures when a card is found as a direct match.
The legal exposure structure
Each card carries one or more legal exposure entries. Every entry addresses one legal domain separately. The structure is always the same.Domain the specific legal regime: EU AI Act, GDPR, civil liability, corporate governance, EU Product Liability Directive, health and safety, equality law or others depending on the card.
Trigger the precise condition that brings the legal obligation into play. Not a general statement of what the law covers. The specific factual condition, tied to this failure point, that activates legal exposure.
Requirement what the organisation must be able to show in response to that trigger. What evidence, process or documented decision is required.
Exposure what follows when the organisation cannot show what is required. Specific consequences: fines, enforcement orders, compensation claims, criminal liability, prohibition or injunctive relief, as applicable to the domain.
Across the Library there are 474 distinct legal exposure entries. None are general warnings. Each is specific to the failure condition on the card and the legal domain it addresses.
The EU Product Liability Directive chain
Every card that carries EU Product Liability Directive exposure includes two additional fields.EU PLD articles lists the specific articles of Directive (EU) 2024/2853 that are engaged by this failure condition. The most commonly cited are Article 7(2), which addresses defectiveness, Article 9, which addresses burden of proof and Article 10, which addresses presumption of causation. These are cited precisely, not as general PLD coverage but as the specific articles whose operation is affected by the failure condition on that card.
PLD failure chain is a sequential analysis showing how the absence of this control leads to a defectiveness finding under the Directive. It follows the logical chain: what the absence of the control means for the defectiveness assessment, which article's presumption is engaged, why the organisation cannot rebut that presumption and what the result is. This chain is not a legal opinion. It is a structured description of the evidentiary position.
The framework mappings
Every card is mapped to four frameworks: the EU AI Act, ISO/IEC 42001, NIST AI RMF and OECD AI Principles. The EU Product Liability Directive is not a framework. It is a liability instrument and is addressed separately through the legal exposure entries and PLD chain.For each framework, the card identifies the specific clauses, articles, categories or principles that apply to this failure condition. Each mapping carries a note explaining the specific connection, not what the framework says in general, but how the framework requirement connects to the failure condition on this card.
EU AI Act articles are cited specifically, for example Art. 9 (risk management), Art. 13 (transparency), Art. 14 (human oversight), Art. 72 (post-market monitoring). The risk classification, high, limited or minimal, is also shown where it applies.
ISO/IEC 42001 clauses and controls are cited to the relevant clause of the standard, for example 5.1 (leadership), 6.1 (actions to address risks), 8.1 (operational planning). Where specific Annex A controls apply, those are cited separately. NIST AI RMF functions and categories are cited to the relevant function, GOVERN, MAP, MEASURE, MANAGE, and the specific category within that function, for example GV-1.1 or MP-2.3.
OECD AI Principles are cited by principle number, for example 1.3 (transparency and explainability), 1.4 (robustness, security and safety), 1.5 (accountability).
Cross-references
Every card carries a cross-reference index. This index serves two purposes.First, it consolidates the framework mappings for that card, showing all five framework dimensions in one place. Second, for each framework value on the card, it shows which other cards in the Library share that same value. This means that if a card cites ISO 42001 clause 6.1, the cross-reference index shows every other card that also cites clause 6.1. This allows the full cluster of connected failures to be surfaced, not just the card that was searched for.
The cross-reference index is used by the search engine. When a query includes a card code and a framework value, for example "cards sharing ISO 6.1 with GO-01", the search engine reads the cross-reference index directly and returns the connected cards.
The search engine
The search engine reads across every field on every card. It detects the intent of a query and groups results accordingly. Exact match results are cards whose title or code matches the query directly.
- Direct match results are cards with strong title, keyword or multi-token matches against the query.
- Legally linked results are cards connected to the legal domains, articles or exposure terms in the query.
- Framework linked results are cards mapped to the frameworks referenced in the query.
- Evidence linked results are cards connected to evidentiary terms in the query, prove, audit, record, documentation and related terms.
- Related concepts are cards connected through the related field of the top matching cards, one degree of separation from the direct results.
The depth slider controls how many results are returned and how broadly the search casts. Broad returns the full scope of connected cards across all groups. Standard is the default. Precise returns only the strongest matches.
The intent label above results summarises what the search engine detected in the query, legal exposure, evidence and audit, accountability, framework alignment or cross-reference, and indicates which groups are most relevant.
Cross-reference queries use the format "cards sharing [framework value] with [card code]", for example "cards sharing Art. 9 with GO-02" or "sharing ISO clause 6.1 with SP-01". The search engine reads the cross-reference index directly and returns connected cards in a dedicated group.
Staying current
The Library is updated as legal obligations develop and new failure conditions are mapped. Subscribers are notified when cards are updated, which card changed and when. Nothing more.
What the Library is not
The Library is not a compliance tool. It does not assess whether a specific organisation meets any legal requirement.
- It is not a legal opinion. Nothing in the Library constitutes legal advice.
- It is not a framework guide. It does not summarise what the EU AI Act, ISO 42001, NIST or OECD require in general terms.
- It is not a risk management tool. It does not score, rank or prioritise risks.
- It describes conditions. What follows from those conditions in any specific organisation is a matter for the professionals who use it.
Inside the Library
- Governance
- Scope & Limits
- Authority & Responsibility
- Control & Monitoring
- Evidence & Records
- Legal Exposure
Designed for
- Legal teams
- Insurers
- Governance professionals
- Risk leads
- Directors
- Public bodies