# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-26T11:04:18Z", "synthesisSha256": "cccaaeb603b524e97d00dde768ae1c061744ced323f21bd89e681a4365eff1fa", "providerMode": "dual-provider", "providers": [ "Claude", "Grok" ], "waivedProviders": [] }, "metaModel": { "id": "WM-AI-001", "registryId": "vr.wm-ai-001", "name": "AI System", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Information and virtual systems", "industry": [ "Cross-industry" ], "domain": [ "INF.AI.SYS" ], "tags": [ "ai", "system", "inf.ai.sys" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-ai-001-ai-system/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-ai-001", "model": { "registry_id": "vr.wm-ai-001", "model_id": "WM-AI-001", "name": "AI System", "entry_kind": "aggregate", "purpose": "Describe a governed AI-enabled system as a unit of accountability that is larger than any single model artifact: its identity, declared purpose, composition, classification, lifecycle, operation, oversight, assurance evidence and retirement.", "scope_statement": "WM-AI-001 covers the machine-based system that infers from input how to generate outputs influencing physical or virtual environments, taken together with the provider/deployer arrangements, configuration baseline, human oversight, logging, evaluation evidence and regulatory status that make it operable and auditable. It is format-neutral: JSON, YAML, Markdown, HTML, Git, MCP and MongoDB are projections of the same semantics. It stops at the boundary of the model artifact, the agent actor, the dataset and the incident report, which are separately modelled and linked by typed edges.", "in_scope": [ "Authoritative system identity, trade name, identification reference and public registration identifiers", "Declared intended purpose, conditions of use, excluded uses and reasonably foreseeable misuse", "Autonomy and adaptiveness profile, output types and the environments outputs can influence", "Regulatory and internal risk classification, including derogation claims and profiling flags", "Versioned configuration baseline and the component set frozen in it (AI bill of materials)", "Binding to model artifacts, upstream providers and external model services", "Input data dependencies, input specifications and deployer-controlled input governance", "Operator roles: provider, deployer, importer, distributor, authorised representative and internal AI actor functions", "Lifecycle stage, market status, change control and substantial-modification determination", "Deployment topology, processing locations, integration interfaces and market jurisdictions", "Automatic event logging, runtime operational state and containment triggers", "Human oversight measures, assignment, competence and intervention mechanisms", "Performance metrics, declared accuracy, validation and testing evidence", "Cybersecurity controls and adversarial threat posture", "Conformity assessment, declarations, standards applied and public registration records", "Transparency disclosure to affected persons and machine-readable marking of synthetic output", "Risk management system and impact assessment on persons and fundamental rights", "Post-market monitoring, serious incident detection and reporting linkage", "Retention, decommissioning, withdrawal and deletion" ], "out_of_scope": [ "Internal structure, weights, architecture, training run and evaluation of the model artifact itself (WM-SFT-004)", "Agent actor goals, tool repertoire, planning loops and autonomous task execution semantics (WM-AI-002)", "The AI incident report record and its regulatory narrative content (WM-AI-010)", "Dataset content, dataset licensing and dataset lineage as first-class records", "Legal entity, organisational structure and personnel records of the provider or deployer", "Generic software product packaging, release engineering and non-AI functionality inherited from WM-SFT-002", "Data subject, natural person and consent records", "Enterprise risk register, audit programme and management-system certification scope of the organisation", "Hardware/device product records where the AI system is only an embedded safety component", "Contract, procurement and commercial terms records" ], "boundary_notes": [ { "neighbor": "AI model artifact (WM-SFT-004)", "distinction": "The model artifact is a versioned trained object with parameters and a training provenance chain. WM-AI-001 records only the binding: which artifact version is invoked, in which role, under which access mode. Regulators separate the two regimes explicitly, treating general-purpose models and AI systems as distinct objects of obligation.", "source_refs": [ "SRC-001", "SRC-018" ] }, { "neighbor": "AI agent (WM-AI-002)", "distinction": "An AI system may expose zero, one or many agent actors. Agent-specific semantics (goal decomposition, tool invocation, memory, delegation) belong to WM-AI-002; WM-AI-001 records only that agent actors exist, their autonomy envelope and the containment controls around them.", "source_refs": [ "SRC-013", "SRC-014" ] }, { "neighbor": "AI incident report (WM-AI-010)", "distinction": "WM-AI-001 owns detection, classification and the reporting obligation state for the system; the incident report record itself, with its narrative, causal analysis and authority correspondence, is a separate record that names the affected AI system.", "source_refs": [ "SRC-006" ] }, { "neighbor": "Software product or service (WM-SFT-002)", "distinction": "WM-AI-001 specialises the software parent with the elements that only apply when a system infers outputs rather than executing fully specified rules: inference-derived behaviour, adaptiveness after deployment and autonomy. Deterministic rule engines without an inference step are out of scope even when embedded in the same product.", "source_refs": [ "SRC-013", "SRC-014" ] }, { "neighbor": "Dataset / training corpus record", "distinction": "WM-AI-001 records the input data specification and the identifiers of datasets relied upon, not the dataset contents, collection method or labelling procedure, which are documented in the model artifact and dataset models.", "source_refs": [ "SRC-002" ] }, { "neighbor": "Conformity certificate and notified-body record", "distinction": "Certificates are issued to a version of a system by an external body and have their own identity and expiry. WM-AI-001 holds the reference and status, not the certificate lifecycle of the issuing body.", "source_refs": [ "SRC-003", "SRC-002" ] }, { "neighbor": "Medical device or other sectoral product record", "distinction": "Where the AI system is a device software function, sectoral lifecycle regimes add pre-authorised change control constructs that are not present in the horizontal regime; WM-AI-001 carries a change-plan reference rather than duplicating sectoral device documentation.", "source_refs": [ "SRC-020" ] } ] }, "sources": [ { "id": "SRC-001", "title": "Article 3: Definitions — Regulation (EU) 2024/1689 (AI Act)", "organization": "European Commission — AI Act Service Desk", "url": "https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-3", "version_or_date": "Regulation (EU) 2024/1689, in force 1 August 2024", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Normative definitions of AI system, provider, deployer, intended purpose, substantial modification, serious incident and general-purpose AI model that set the model boundary." }, { "id": "SRC-002", "title": "Annex IV: Technical Documentation referred to in Article 11(1) — AI Act", "organization": "European Commission — AI Act Service Desk", "url": "https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-4", "version_or_date": "Regulation (EU) 2024/1689, Annex IV", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Enumerates the required documentation items for a high-risk AI system: general description, development, monitoring and control, metrics, risk management, lifecycle changes, standards, declaration and post-market plan." }, { "id": "SRC-003", "title": "Annex VIII: Information to be submitted upon registration of high-risk AI systems — AI Act", "organization": "European Commission — AI Act Service Desk", "url": "https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-8", "version_or_date": "Regulation (EU) 2024/1689, Annex VIII Sections A, B, C", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Defines the public registration data set for provider and deployer, including trade name, identification reference, status, certificate data and impact assessment summaries." }, { "id": "SRC-004", "title": "Article 12: Record-keeping — AI Act", "organization": "European Commission — AI Act Service Desk", "url": "https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-12", "version_or_date": "Regulation (EU) 2024/1689, Article 12", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Requires automatic event logging over the lifetime of the system and specifies minimum log content for remote biometric identification, including start and end date and time of each use." }, { "id": "SRC-005", "title": "Article 26: Obligations of deployers of high-risk AI systems — AI Act", "organization": "European Commission — AI Act Service Desk", "url": "https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-26", "version_or_date": "Regulation (EU) 2024/1689, Article 26", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Deployer duties: use per instructions, assign competent human oversight, ensure input data relevance and representativeness, monitor, retain logs at least six months, inform workers and affected persons." }, { "id": "SRC-006", "title": "Article 73: Reporting of serious incidents — AI Act", "organization": "European Commission — AI Act Service Desk", "url": "https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-73", "version_or_date": "Regulation (EU) 2024/1689, Article 73", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Sets awareness-triggered reporting deadlines (15 days general, 2 days for widespread infringement or critical infrastructure disruption, 10 days for death) and the subsequent investigation duty." }, { "id": "SRC-007", "title": "Article 6: Classification rules for high-risk AI systems — AI Act", "organization": "European Commission — AI Act Service Desk", "url": "https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-6", "version_or_date": "Regulation (EU) 2024/1689, Article 6", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Two classification routes (product safety and listed use case), the four derogation conditions, the profiling exception and the duty to document a non-high-risk assessment before placing on the market." }, { "id": "SRC-008", "title": "Article 50: Transparency obligations for providers and deployers of certain AI systems — AI Act", "organization": "European Commission — AI Act Service Desk", "url": "https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-50", "version_or_date": "Regulation (EU) 2024/1689, Article 50", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Requires disclosure of AI interaction, machine-readable marking of synthetic audio, image, video and text, deep fake disclosure and notification for emotion recognition and biometric categorisation." }, { "id": "SRC-009", "title": "Article 72: Post-market monitoring by providers and post-market monitoring plan — AI Act", "organization": "European Commission — AI Act Service Desk", "url": "https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-72", "version_or_date": "Regulation (EU) 2024/1689, Article 72", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Requires a proportionate post-market monitoring system, systematic collection of performance data over the lifetime including data from deployers, and inclusion of the plan in the technical documentation." }, { "id": "SRC-010", "title": "AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://www.nist.gov/itl/ai-risk-management-framework", "version_or_date": "AI RMF 1.0, 26 January 2023, DOI 10.6028/NIST.AI.100-1", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Voluntary framework structured as GOVERN, MAP, MEASURE and MANAGE covering design, development, use and evaluation of AI products, services and systems across the lifecycle." }, { "id": "SRC-011", "title": "AI Risks and Trustworthiness — NIST AI RMF section 3", "organization": "NIST AI Resource Center (AIRC)", "url": "https://airc.nist.gov/airmf-resources/airmf/3-sec-characteristics/", "version_or_date": "AI RMF 1.0 knowledge base, 2023", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Defines the seven trustworthiness characteristics — valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, fair with harmful bias managed — used as evaluation dimensions." }, { "id": "SRC-012", "title": "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2 E2025", "organization": "National Institute of Standards and Technology (NIST)", "url": "https://csrc.nist.gov/pubs/ai/100/2/e2025/final", "version_or_date": "NIST.AI.100-2e2025, final 24 March 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Attack taxonomy (evasion, poisoning, privacy, abuse/misuse) tied to lifecycle stages of attack and to attacker goals, capabilities and knowledge; grounds the AI-specific threat model." }, { "id": "SRC-013", "title": "What is AI? Can you make a clear distinction between AI and non-AI systems?", "organization": "OECD.AI Policy Observatory", "url": "https://oecd.ai/en/wonk/definition", "version_or_date": "Updated OECD AI system definition, adopted November 2023", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Element-by-element reading of machine-based, explicit or implicit objectives, inference, output types, influence on physical or virtual environments, and varying autonomy and adaptiveness after deployment." }, { "id": "SRC-014", "title": "Explanatory memorandum on the updated OECD definition of an AI system (OECD Artificial Intelligence Papers No. 8)", "organization": "Organisation for Economic Co-operation and Development (OECD)", "url": "https://www.oecd.org/en/publications/explanatory-memorandum-on-the-updated-oecd-definition-of-an-ai-system_623da898-en.html", "version_or_date": "No. 8, published 5 March 2024, DOI 10.1787/623da898-en", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Authoritative rationale for each definitional element and for the lifecycle framing that separates design and development from deployment, operation and monitoring." }, { "id": "SRC-015", "title": "PROV-O: The PROV Ontology", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/prov-o/", "version_or_date": "W3C Recommendation, 30 April 2013", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Entity/Activity/Agent model with wasGeneratedBy, used, wasDerivedFrom, wasAttributedTo, wasAssociatedWith, startedAtTime and endedAtTime; the alignment target for system provenance and change history." }, { "id": "SRC-016", "title": "RFC 3339: Date and Time on the Internet: Timestamps", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc3339", "version_or_date": "RFC 3339, July 2002", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Normative timestamp grammar requiring four-digit years, seconds and an explicit UTC offset or Z, with -00:00 reserved for an unknown local offset." }, { "id": "SRC-017", "title": "ECMA-424: CycloneDX Bill of Materials Specification", "organization": "Ecma International", "url": "https://ecma-international.org/publications-and-standards/standards/ecma-424/", "version_or_date": "2nd edition, December 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Standardised inventory format for components, services, dependencies, vulnerabilities and machine learning models; the interoperability target for the system component inventory." }, { "id": "SRC-018", "title": "CycloneDX Machine Learning Bill of Materials (ML-BOM / AI-BOM)", "organization": "OWASP CycloneDX", "url": "https://cyclonedx.org/capabilities/mlbom/", "version_or_date": "Capability page, accessed 2026-08-26", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Describes documenting datasets, models and configurations for AI systems to support bias, data integrity and model security risk assessment across the AI supply chain." }, { "id": "SRC-019", "title": "ISO/IEC 42001:2023 Information technology — Artificial intelligence — Management system", "organization": "ISO/IEC JTC 1/SC 42", "url": "https://www.iso.org/standard/81230.html", "version_or_date": "First edition, 2023", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Management-system requirements (clauses 4-10) and Annex A controls covering AI policy, impact assessment, lifecycle, data management, third-party relationships and operational monitoring; used only as an alignment, not a conformance claim." }, { "id": "SRC-020", "title": "Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions", "organization": "U.S. Food and Drug Administration (FDA)", "url": "https://www.fda.gov/regulatory-information/search-fda-guidance-documents/marketing-submission-recommendations-predetermined-change-control-plan-artificial-intelligence", "version_or_date": "Final guidance, 4 December 2024", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T12:00:00Z", "relevance": "Non-EU counterexample for change governance: a pre-authorised plan of Description of Modifications, Modification Protocol and Impact Assessment lets a system evolve without a new submission." }, { "id": "SRC-021", "title": "Regulation (EU) 2024/1689 of the European Parliament and of the Council (Artificial Intelligence Act), consolidated", "organization": "European Union", "url": "https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng", "version_or_date": "consolidated 2026-07-27; original OJ L 2024/1689 of 12.7.2024", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T18:30:00Z", "relevance": "Binding definitions of AI system, provider, deployer and related operators; intended purpose; substantial modification; high-risk requirements including technical documentation, logging, human oversight, post-market monitoring, documentation keeping, registration, recall and withdrawal." }, { "id": "SRC-022", "title": "OECD Framework for the Classification of AI systems", "organization": "Organisation for Economic Co-operation and Development", "url": "https://www.oecd.org/en/publications/oecd-framework-for-the-classification-of-ai-systems_cb6d9eca-en.html", "version_or_date": "2022-02-22; OECD Digital Economy Papers No. 323", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T18:30:00Z", "relevance": "Policy classification dimensions People and Planet, Economic Context, Data and Input, AI Model, and Task and Output, used to characterise a deployed AI system without collapsing it to a model." }, { "id": "SRC-023", "title": "Artificial Intelligence Risk Management Framework (AI RMF 1.0)", "organization": "National Institute of Standards and Technology", "url": "https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf", "version_or_date": "NIST AI 100-1, 2023-01-26", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T18:30:00Z", "relevance": "Voluntary lifecycle risk management for organisations designing, developing, deploying or using AI systems; Govern-Map-Measure-Manage functions; trustworthiness characteristics; AI actors across the lifecycle." }, { "id": "SRC-024", "title": "ISO/IEC 22989:2022 Information technology — Artificial intelligence — Artificial intelligence concepts and terminology", "organization": "ISO/IEC JTC 1/SC 42", "url": "https://www.iso.org/standard/74296.html", "version_or_date": "ISO/IEC 22989:2022, 2022-07-19", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T18:30:00Z", "relevance": "Foundational terminology for AI system, AI agent, model, lifecycle stages from inception to retirement including continuous validation and re-evaluation, and the engineered-system view of AI." }, { "id": "SRC-025", "title": "Council of Europe Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law", "organization": "Council of Europe", "url": "https://eur-lex.europa.eu/eli/agree_internation/2026/1081/oj/eng", "version_or_date": "CETS No. 225; EU OJ L 2026/1081 of 13.5.2026; opened for signature 2024-09-05", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T18:30:00Z", "relevance": "Binding treaty definition of an artificial intelligence system aligned to the OECD text, covering lifecycle activities with potential to interfere with human rights, democracy and the rule of law, and excluding national defence." }, { "id": "SRC-026", "title": "ISO/IEC 42005:2025 Information technology — Artificial intelligence (AI) — AI system impact assessment", "organization": "ISO/IEC JTC 1/SC 42", "url": "https://webstore.iec.ch/en/publication/107659", "version_or_date": "ISO/IEC 42005:2025, 2025-05-28", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-26T18:30:00Z", "relevance": "Guidance for performing and documenting AI system impact assessments on individuals and societies across lifecycle stages, integrable with AI risk management and an AI management system." } ], "structure": { "bundles": [ { "id": "identity-purpose-and-classification", "name": "Identity, Purpose and Classification", "description": "What this AI system is, which version of it is in force, what it is declared to do, and how it is classified for risk and behaviour.", "rationale": "Nothing downstream is decidable until the system is uniquely identified, its intended purpose is fixed and its regulatory class is settled; both the horizontal regulation and the OECD definition make purpose, inference, autonomy and adaptiveness the discriminating attributes.", "source_refs": [ "SRC-001", "SRC-002", "SRC-007", "SRC-013" ], "layers": [ { "id": "system-identity-and-versioning", "name": "System Identity and Versioning", "description": "Authoritative and public identifiers for the system and the versioned configuration baseline they resolve to.", "source_refs": [ "SRC-002", "SRC-003" ], "findings": [ { "id": "ai-system-identity", "name": "AI system identity and designation", "description": "The identifier set that pins one AI system as an accountable object: the master-system key, the commercial trade name, the provider's internal identification reference and any public registry entry identifiers.", "source_refs": [ "SRC-002", "SRC-003", "SRC-001" ], "questions": [ { "id": "q-identity-master-key", "text": "Which identifier is the authoritative master-system identifier for this AI system, and which system of record issues it?", "kind": "identity", "answer_data": [ "Issuing system-of-record name", "Identifier value", "Identifier scheme or namespace", "Issuance timestamp" ] }, { "id": "q-identity-trade-name", "text": "What trade name and identification reference distinguish this system from other systems supplied by the same provider?", "kind": "identity", "answer_data": [ "Trade name", "Provider identification reference", "Provider legal entity identifier" ] }, { "id": "q-identity-vs-artifact", "text": "How is the system-level identity kept distinct from the identities of the model artifacts it invokes and the product it is embedded in?", "kind": "relationship", "answer_data": [ "Model artifact identifier list", "Parent product identifier", "Boundary rule statement" ] }, { "id": "q-identity-registry-reconciliation", "text": "Which external registries hold an identifier for this system, and how are those identifiers reconciled with the master key?", "kind": "interoperability", "answer_data": [ "External registry name", "External entry identifier or URL", "Reconciliation rule", "Last reconciliation timestamp" ] } ], "data_elements": [ { "id": "de-system-master-id", "name": "System master identifier", "description": "Identifier issued by the authoritative system of record for the AI system.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-system-trade-name", "name": "Trade name", "description": "Commercial name under which the system is placed on the market or put into service.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-system-identification-reference", "name": "Provider identification reference", "description": "Unambiguous reference used by the provider to identify the system in documentation and registration.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-external-registry-entry", "name": "External registry entry", "description": "Reference to a public or sectoral registry entry representing this system.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "system-identity-record", "name": "System identity record", "description": "Canonical record binding master identifier, trade names, provider references and external registry entries, independent of storage format.", "media_or_form": [ "structured record", "registry entry", "document section" ], "serial": false, "identity_strategy": "Authoritative master-system identifier issued by the provider's system of record; a governed public registration entry identifier is carried as an alias, never as the primary key.", "source_refs": [ "SRC-003", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "version-and-configuration-baseline", "name": "Version and configuration baseline", "description": "The released, frozen combination of software, firmware, model versions, prompts and policies that constitutes 'this system as placed on the market', together with its integrity evidence and effective dates.", "source_refs": [ "SRC-002", "SRC-015", "SRC-017" ], "questions": [ { "id": "q-baseline-current", "text": "Which version and configuration baseline of the system is currently placed on the market or put into service?", "kind": "state", "answer_data": [ "System version label", "Baseline identifier", "Market/service status at this version" ] }, { "id": "q-baseline-components", "text": "Which component versions — model, software, firmware, prompts, policies — are frozen in this baseline?", "kind": "composition", "answer_data": [ "Component identifier", "Component version", "Component role in baseline" ] }, { "id": "q-baseline-integrity", "text": "How is the integrity of the released baseline demonstrated, and by which build or signing provenance?", "kind": "provenance", "answer_data": [ "Digest algorithm and value", "Signature or attestation reference", "Build activity identifier", "Responsible agent" ] }, { "id": "q-baseline-supersession", "text": "When did this baseline take effect and when did it supersede the previous baseline?", "kind": "temporal", "answer_data": [ "Effective-from timestamp", "Superseded baseline identifier", "Supersession timestamp" ] } ], "data_elements": [ { "id": "de-system-version", "name": "System version", "description": "Version label of the AI system as a whole, distinct from any component version.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-baseline-component-set", "name": "Baseline component set", "description": "Enumerated component identifiers and versions frozen in the baseline.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002", "SRC-017" ] }, { "id": "de-baseline-digest", "name": "Baseline integrity digest", "description": "Cryptographic digest or attestation covering the baseline manifest.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "de-baseline-effective-from", "name": "Baseline effective-from", "description": "Time from which the baseline is the operative configuration.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-016" ] } ], "artifacts": [ { "id": "configuration-baseline-manifest", "name": "Configuration baseline manifest", "description": "Immutable manifest enumerating every component version, prompt, policy and firmware level in a released baseline, with integrity values.", "media_or_form": [ "structured manifest", "signed attestation", "document" ], "serial": true, "identity_strategy": "Master system identifier plus system version label; a content digest of the canonical manifest is the tie-breaker when a version is re-issued.", "source_refs": [ "SRC-002", "SRC-017" ] } ], "inline_only_rationale": null } ] }, { "id": "intended-purpose-and-operating-domain", "name": "Intended Purpose and Operating Domain", "description": "The declared purpose, conditions of use, exclusions and foreseeable misuse that bound every later assessment.", "source_refs": [ "SRC-001", "SRC-002" ], "findings": [ { "id": "intended-purpose-and-use-context", "name": "Intended purpose and operating domain", "description": "The provider's declared use, including specific context and conditions of use, the intended user groups and environments, and the excluded uses and reasonably foreseeable misuses against which risk is assessed.", "source_refs": [ "SRC-001", "SRC-002", "SRC-005" ], "questions": [ { "id": "q-purpose-declared", "text": "What is the intended purpose declared by the provider, including the specific context and conditions of use?", "kind": "definition", "answer_data": [ "Intended purpose statement", "Conditions of use", "Intended user group", "Deployment context description" ] }, { "id": "q-purpose-exclusions", "text": "Which uses are explicitly excluded, and which reasonably foreseeable misuses have been identified?", "kind": "constraint", "answer_data": [ "Excluded use statement", "Foreseeable misuse description", "Mitigation reference" ] }, { "id": "q-purpose-population", "text": "Which sectors, environments and affected populations does the declared purpose reach?", "kind": "spatial", "answer_data": [ "Sector code", "Operating environment type", "Affected population description" ] }, { "id": "q-purpose-change-authority", "text": "Who may change the declared intended purpose, and what re-assessment does such a change trigger?", "kind": "authority", "answer_data": [ "Authorising role", "Change trigger rule", "Required re-assessment activities" ] } ], "data_elements": [ { "id": "de-intended-purpose-statement", "name": "Intended purpose statement", "description": "Provider's declaration of the use for which the system is intended, with context and conditions.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-excluded-use", "name": "Excluded use", "description": "A use the provider states the system must not be put to.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-foreseeable-misuse", "name": "Reasonably foreseeable misuse", "description": "An identified misuse that risk management and instructions for use must address.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-intended-user-group", "name": "Intended user group", "description": "Category of deployer or end user for whom the system and its interface are designed.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "instructions-for-use", "name": "Instructions for use", "description": "Deployer-facing instructions covering intended purpose, conditions of use, interface description, limitations and required oversight measures.", "media_or_form": [ "document", "structured record", "electronic instructions" ], "serial": true, "identity_strategy": "System master identifier plus system version plus document revision; electronic instructions carry a resolvable location for registration purposes.", "source_refs": [ "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null } ] }, { "id": "risk-and-behavioural-classification", "name": "Risk and Behavioural Classification", "description": "How the system is classified for regulatory risk and how its inference behaviour, autonomy and adaptiveness are characterised.", "source_refs": [ "SRC-007", "SRC-013", "SRC-014" ], "findings": [ { "id": "regulatory-risk-classification", "name": "Regulatory and risk classification", "description": "The determination of which regime applies — prohibited practice, high-risk by product-safety route, high-risk by listed use case, transparency-only, or minimal — including any derogation claim and the profiling exception that defeats it.", "source_refs": [ "SRC-007", "SRC-008", "SRC-003" ], "questions": [ { "id": "q-class-route", "text": "Under which classification route does the system fall, and which listed use case or harmonisation instrument triggers it?", "kind": "classification", "answer_data": [ "Risk class code", "Classification route", "Triggering annex entry or instrument" ] }, { "id": "q-class-derogation", "text": "If a derogation from high-risk classification is claimed, which condition is relied on and what evidence supports it?", "kind": "decision", "answer_data": [ "Derogation condition selected", "Supporting grounds summary", "Assessing role", "Assessment timestamp" ] }, { "id": "q-class-profiling", "text": "Does the system perform profiling of natural persons, which removes any derogation?", "kind": "exception", "answer_data": [ "Profiling flag", "Profiling description", "Legal basis reference" ] }, { "id": "q-class-reassessment", "text": "Which events require the classification to be reassessed before the system continues in service?", "kind": "lifecycle", "answer_data": [ "Reassessment trigger", "Responsible role", "Deadline rule" ] } ], "data_elements": [ { "id": "de-risk-class-code", "name": "Risk class code", "description": "Coded regulatory risk classification assigned to the system.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-classification-route", "name": "Classification route", "description": "Which route produced the classification: embedded product safety component, listed use case, transparency-only or minimal.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-derogation-condition", "name": "Derogation condition", "description": "The narrow-procedural-task, prior-human-work, pattern-detection or preparatory-task condition relied on.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-profiling-flag", "name": "Profiling flag", "description": "Whether the system performs profiling of natural persons.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-classification-assessed-at", "name": "Classification assessment time", "description": "Time at which the classification determination was made.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-016" ] } ], "artifacts": [ { "id": "classification-assessment-record", "name": "Classification assessment record", "description": "Documented assessment of classification and any non-high-risk determination, prepared before placing on the market and retained for authorities.", "media_or_form": [ "document", "structured record" ], "serial": true, "identity_strategy": "System master identifier plus assessment sequence number; superseded assessments are retained rather than overwritten.", "source_refs": [ "SRC-007", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "autonomy-and-adaptiveness-profile", "name": "Autonomy and adaptiveness profile", "description": "Characterisation of how much the system decides without a human decision point, whether it changes its own behaviour after deployment, what output types it produces and which physical or virtual environments those outputs can influence.", "source_refs": [ "SRC-013", "SRC-014", "SRC-011" ], "questions": [ { "id": "q-autonomy-level", "text": "What level of autonomy does the system exercise between human decision points, and where are those points placed?", "kind": "classification", "answer_data": [ "Autonomy level code", "Human decision point description", "Scope of unattended operation" ] }, { "id": "q-adaptiveness-mode", "text": "Does the system adapt after deployment, and through which mechanism — online learning, retrieval updates, or prompt and policy changes?", "kind": "state", "answer_data": [ "Adaptiveness flag", "Adaptation mechanism", "Adaptation frequency", "Control over adaptation" ] }, { "id": "q-inference-boundary", "text": "How is the boundary drawn between inference-derived behaviour and deterministic rule execution inside this system?", "kind": "definition", "answer_data": [ "Inference component list", "Deterministic component list", "Boundary justification" ] }, { "id": "q-environment-influence", "text": "Which physical or virtual environments can the system's outputs influence, and through which actuators or downstream integrations?", "kind": "constraint", "answer_data": [ "Output type", "Actuator or integration identifier", "Influence scope description", "Reversibility of effect" ] } ], "data_elements": [ { "id": "de-autonomy-level", "name": "Autonomy level", "description": "Coded degree of independent operation between human decision points.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "de-adaptiveness-mode", "name": "Adaptiveness mode", "description": "How, if at all, system behaviour changes after deployment.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-013", "SRC-014" ] }, { "id": "de-output-type", "name": "Output type", "description": "Kind of output generated: prediction, content, recommendation or decision.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-013" ] }, { "id": "de-environment-influence-scope", "name": "Environment influence scope", "description": "Description of the physical or virtual environment affected by outputs and the mediating integration.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013" ] } ], "artifacts": [ { "id": "system-behaviour-profile", "name": "System behaviour profile", "description": "Record characterising inference boundary, autonomy level, adaptiveness mechanism, output types and environmental reach; the basis for deciding whether the object is in scope for AI-specific governance at all.", "media_or_form": [ "structured record", "document section" ], "serial": false, "identity_strategy": "System master identifier plus system version; re-derived whenever the baseline changes an inference or actuation path.", "source_refs": [ "SRC-013", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "ai-system-definition-adoption", "name": "AI system definition", "description": "An AI system is a machine-based or engineered system that, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments. OECD, the EU AI Act and the Council of Europe Framework Convention share this inference-centred wording; ISO/IEC 22989 uses engineered system and human-defined objectives without the verb infers.", "source_refs": [ "SRC-021", "SRC-013", "SRC-024", "SRC-025" ], "questions": [ { "id": "ai-system-definition-adoption-q01", "text": "Which definition of AI system is adopted for this instance and how is it distinguished from ordinary rule-executing software?", "kind": "definition", "answer_data": [ "adopted definition text", "source alignment codes", "non-AI exclusion rationale" ] }, { "id": "ai-system-definition-adoption-q02", "text": "Does this instance infer how to generate predictions, content, recommendations or decisions from inputs in a way that can influence physical or virtual environments?", "kind": "classification", "answer_data": [ "inference present boolean", "output types", "environment influence modes" ] }, { "id": "ai-system-definition-adoption-q03", "text": "Which definitional conflicts between OECD, EU, ISO/IEC 22989 and NIST AI RMF 1.0 are recorded for this instance rather than claimed as conformance?", "kind": "interoperability", "answer_data": [ "aligned instruments", "conflict notes", "conformance claims with evidence references" ] } ], "data_elements": [ { "id": "ai-system-definition-adoption-data01", "name": "Adopted definition text", "description": "The definition text used to admit this record as an AI system.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-021", "SRC-013" ] }, { "id": "ai-system-definition-adoption-data02", "name": "Definition alignment codes", "description": "Instruments this instance is aligned to, such as OECD-2023, EU-2024-1689 Art 3(1), ISO-22989-3.1.4, CoE-CETS-225 Art 2, NIST-AI-RMF-1.0.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-021", "SRC-013", "SRC-023", "SRC-024", "SRC-025" ] }, { "id": "ai-system-definition-adoption-data03", "name": "Output types", "description": "Whether the system produces predictions, content, recommendations, decisions or other declared outputs.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-021", "SRC-013" ] }, { "id": "ai-system-definition-adoption-data04", "name": "Environment influence", "description": "Whether outputs can influence physical environments, virtual environments, or both.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-021", "SRC-013", "SRC-025" ] } ], "artifacts": [ { "id": "ai-system-definition-adoption-artifact01", "name": "Definition alignment note", "description": "Record of the adopted definition, aligned instruments and unresolved wording conflicts.", "media_or_form": [ "structured record", "markdown note" ], "serial": true, "identity_strategy": "authoritative master-system identifier of the AI system plus definition-note revision", "source_refs": [ "SRC-021", "SRC-013", "SRC-024" ] } ], "inline_only_rationale": null }, { "id": "socio-technical-classification-profile", "name": "OECD classification dimensions", "description": "The OECD framework classifies AI systems along People and Planet, Economic Context, Data and Input, AI Model, and Task and Output. NIST AI RMF 1.0 reuses these socio-technical dimensions to map lifecycle risk. The profile characterises a deployment; it is not itself a legal risk class.", "source_refs": [ "SRC-022", "SRC-023" ], "questions": [ { "id": "socio-technical-classification-profile-q01", "text": "Who uses the system, who is impacted, and what human-rights, wellbeing, labour or environmental effects are in scope?", "kind": "relationship", "answer_data": [ "user competency", "impacted stakeholders", "human rights and wellbeing effects", "environmental effects" ] }, { "id": "socio-technical-classification-profile-q02", "text": "In which industrial sector, business function and technical-maturity setting is the system deployed?", "kind": "classification", "answer_data": [ "industrial sector", "business function", "technical maturity or TRL" ] }, { "id": "socio-technical-classification-profile-q03", "text": "What tasks does the system perform, does it combine tasks into a composite or autonomous control system, and what action does it take on the environment?", "kind": "classification", "answer_data": [ "tasks", "composite-system flag", "action on environment", "optionality of human decision" ] }, { "id": "socio-technical-classification-profile-q04", "text": "Does this socio-technical profile justify treating the system as in-scope for heightened governance even if no high-risk legal class applies?", "kind": "decision", "answer_data": [ "heightened-governance boolean", "rationale", "risk-tolerance reference" ] } ], "data_elements": [ { "id": "socio-technical-classification-profile-data01", "name": "Impacted stakeholders", "description": "Individuals and groups who interact with or are affected by the applied AI system.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-022" ] }, { "id": "socio-technical-classification-profile-data02", "name": "Industrial sector", "description": "Sector of deployment such as finance, health, public administration or agriculture.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "socio-technical-classification-profile-data03", "name": "System tasks", "description": "Tasks performed, such as recognition, event detection, forecasting, content generation or control.", "value_kind": "collection", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-022" ] }, { "id": "socio-technical-classification-profile-data04", "name": "Human rights and wellbeing effects", "description": "Documented potential effects on human rights, wellbeing, society and the world of work.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-025" ] } ], "artifacts": [ { "id": "socio-technical-classification-profile-artifact01", "name": "Socio-technical classification profile", "description": "Completed OECD-style profile of people, economic context, data, model and task for this deployment.", "media_or_form": [ "structured record" ], "serial": true, "identity_strategy": "authoritative master-system identifier plus profile revision", "source_refs": [ "SRC-022", "SRC-023" ] } ], "inline_only_rationale": null }, { "id": "gpai-system-boundary", "name": "General-purpose AI system boundary", "description": "A general-purpose AI system is an AI system based on a general-purpose AI model and capable of serving a variety of purposes, for direct use or for integration in other AI systems. The GPAI model itself is not this entity. Downstream providers integrate a model into their AI system.", "source_refs": [ "SRC-021", "SRC-013" ], "questions": [ { "id": "gpai-system-boundary-q01", "text": "Is this record a general-purpose AI system, a single-purpose system, or a downstream system that integrates a GPAI model?", "kind": "classification", "answer_data": [ "system generality code", "gpai model reference", "downstream-provider flag" ] }, { "id": "gpai-system-boundary-q02", "text": "Which general-purpose or other models are integrated, and is integration vertical or contractual with another entity?", "kind": "composition", "answer_data": [ "integrated model identifiers", "integration mode", "provider of each model" ] }, { "id": "gpai-system-boundary-q03", "text": "Is any integrated model still in research, development or prototyping before being placed on the market, and therefore outside GPAI-model placing rules?", "kind": "exception", "answer_data": [ "research-or-prototype flag", "placing-on-market status of model" ] } ], "data_elements": [ { "id": "gpai-system-boundary-data01", "name": "GPAI system flag", "description": "Whether the AI system is based on a GPAI model and can serve a variety of purposes.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-021" ] }, { "id": "gpai-system-boundary-data02", "name": "Downstream provider flag", "description": "Whether this system's provider integrates an AI model supplied by another entity or by itself.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-021" ] }, { "id": "gpai-system-boundary-data03", "name": "Integrated GPAI model references", "description": "References to general-purpose or other models composed into this system.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-021", "SRC-013" ] } ], "artifacts": [ { "id": "gpai-system-boundary-artifact01", "name": "GPAI system-model boundary note", "description": "Statement of system generality and linked model artifacts, without storing model internals.", "media_or_form": [ "structured record" ], "serial": true, "identity_strategy": "authoritative master-system identifier plus boundary-note revision", "source_refs": [ "SRC-021" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "composition-and-supply-chain", "name": "Composition and Supply Chain", "description": "What the system is made of, which models and data it depends on, and which parties are accountable for each part.", "rationale": "Technical documentation and registration both require the constituent parts and the responsible operators to be enumerable; supply-chain transparency formats exist precisely to make this inventory machine-readable.", "source_refs": [ "SRC-002", "SRC-003", "SRC-017", "SRC-018" ], "layers": [ { "id": "system-composition-and-dependencies", "name": "System Composition and Dependencies", "description": "Component inventory, model artifact bindings and the input data the system consumes in operation.", "source_refs": [ "SRC-002", "SRC-017", "SRC-018" ], "findings": [ { "id": "component-inventory-and-ai-bom", "name": "Component inventory and AI bill of materials", "description": "The enumerated set of models, libraries, services, hardware and data stores that constitute the system in a given baseline, with supplier, version, licence and vulnerability status, expressed in a machine-readable bill-of-materials format.", "source_refs": [ "SRC-017", "SRC-018", "SRC-002" ], "questions": [ { "id": "q-bom-components", "text": "Which components constitute the system in the released baseline, and which are third-party rather than self-developed?", "kind": "composition", "answer_data": [ "Component identifier", "Component type", "Supply origin (internal, third-party, service)", "Component version" ] }, { "id": "q-bom-provenance", "text": "For each component, what is its supplier, licence and origin of supply?", "kind": "provenance", "answer_data": [ "Supplier name and identifier", "Licence identifier", "Source repository or distribution channel" ] }, { "id": "q-bom-format", "text": "In which machine-readable bill-of-materials format and specification version is the inventory published?", "kind": "interoperability", "answer_data": [ "BOM format name", "Specification version", "BOM document reference", "Serial number of BOM" ] }, { "id": "q-bom-vulnerability", "text": "Which components carry known vulnerabilities or an unsupported end-of-life status at the time of release?", "kind": "security", "answer_data": [ "Vulnerability identifier", "Affected component", "Severity", "Support status" ] } ], "data_elements": [ { "id": "de-component-entry", "name": "Component entry", "description": "One inventoried constituent of the system with type, version and supply origin.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-017" ] }, { "id": "de-component-licence", "name": "Component licence", "description": "Licence under which a component is used or redistributed.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "de-bom-format-identifier", "name": "BOM format identifier", "description": "Name and version of the bill-of-materials specification used.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-017" ] }, { "id": "de-component-vulnerability", "name": "Component vulnerability reference", "description": "Known vulnerability affecting an inventoried component.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [ { "id": "ai-bill-of-materials", "name": "AI bill of materials", "description": "Machine-readable inventory of components, services, datasets, models and configurations with dependency relationships and vulnerability data.", "media_or_form": [ "structured document", "machine-readable inventory", "signed attestation" ], "serial": true, "identity_strategy": "BOM serial number plus BOM version, bound to the system master identifier and baseline manifest digest.", "source_refs": [ "SRC-017", "SRC-018" ] } ], "inline_only_rationale": null }, { "id": "model-artifact-binding", "name": "Model artifact binding", "description": "Which model artifacts and versions the system invokes, in which functional role, under which access mode and commercial terms, and how upstream model changes reach the system.", "source_refs": [ "SRC-001", "SRC-018", "SRC-002" ], "questions": [ { "id": "q-model-binding-roles", "text": "Which model artifacts and versions does the system invoke, and in which role — primary, fallback, guardrail or embedding?", "kind": "relationship", "answer_data": [ "Model artifact identifier", "Model version", "Functional role", "Invocation path" ] }, { "id": "q-model-supply-mode", "text": "Is each model artifact self-developed, obtained from an upstream provider, or consumed as an external hosted service?", "kind": "ownership", "answer_data": [ "Supply mode code", "Upstream provider identifier", "Service endpoint reference" ] }, { "id": "q-model-terms", "text": "What licence or contractual terms govern use, modification and redistribution of each bound model artifact?", "kind": "authority", "answer_data": [ "Licence or contract reference", "Permitted use scope", "Restriction statement" ] }, { "id": "q-model-change-propagation", "text": "How are upstream model changes detected and propagated into the system baseline?", "kind": "process", "answer_data": [ "Notification channel", "Detection method", "Revalidation requirement", "Propagation lead time" ] } ], "data_elements": [ { "id": "de-model-artifact-ref", "name": "Model artifact reference", "description": "Reference to a model artifact record and version invoked by the system.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-model-role", "name": "Model functional role", "description": "Role the bound model plays within the system pipeline.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-model-access-mode", "name": "Model access mode", "description": "Whether the model is embedded, hosted internally or consumed as an external service.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-upstream-provider-id", "name": "Upstream provider identifier", "description": "Identifier of the entity that supplied the model to the downstream provider.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "model-binding-register", "name": "Model binding register", "description": "Register of every model artifact version bound into a system baseline with role, access mode, supplier and change-notification channel.", "media_or_form": [ "structured record", "register table" ], "serial": false, "identity_strategy": "System master identifier plus baseline identifier; each row keyed by model artifact identifier and version.", "source_refs": [ "SRC-002", "SRC-001" ] } ], "inline_only_rationale": null }, { "id": "input-data-dependencies-and-governance", "name": "Input data dependencies and governance", "description": "The data streams the system consumes in operation, who controls them, the input specifications published to deployers, and the representativeness and personal-data properties that determine whether operation stays within the declared purpose.", "source_refs": [ "SRC-002", "SRC-005", "SRC-008" ], "questions": [ { "id": "q-input-streams", "text": "Which input data streams does the system consume in operation, and which party controls each stream?", "kind": "composition", "answer_data": [ "Input stream identifier", "Data category", "Controlling party role", "Ingestion frequency" ] }, { "id": "q-input-representativeness", "text": "How is input data shown to be relevant and sufficiently representative in view of the intended purpose?", "kind": "quality", "answer_data": [ "Representativeness criterion", "Assessment method", "Assessment result", "Assessing role" ] }, { "id": "q-input-personal-data", "text": "Which input fields contain personal or special-category data, and what lawful basis and safeguards apply?", "kind": "privacy", "answer_data": [ "Field identifier", "Data category", "Lawful basis reference", "Safeguard description" ] }, { "id": "q-input-specification", "text": "What input data specifications are published to deployers so that operation remains inside the validated envelope?", "kind": "requirement", "answer_data": [ "Specification statement", "Accepted value ranges", "Rejection or fallback behaviour" ] } ], "data_elements": [ { "id": "de-input-stream-descriptor", "name": "Input stream descriptor", "description": "Description of one operational input stream including format, source and cadence.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-input-controller-role", "name": "Input controller role", "description": "Which operator role controls the input data for a stream.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "de-input-data-specification", "name": "Input data specification", "description": "Stated specification of input data expected by the system.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-personal-data-category", "name": "Personal data category", "description": "Category of personal or special-category data present in inputs.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "input-data-specification-sheet", "name": "Input data specification sheet", "description": "Deployer-facing description of required input data, its representativeness expectations and personal-data handling constraints.", "media_or_form": [ "document", "structured record" ], "serial": true, "identity_strategy": "System master identifier plus system version plus sheet revision.", "source_refs": [ "SRC-002", "SRC-005" ] } ], "inline_only_rationale": null } ] }, { "id": "actors-roles-and-accountability", "name": "Actors, Roles and Accountability", "description": "Which legal entities and internal functions hold which duties for this system, and when a role changes hands.", "source_refs": [ "SRC-001", "SRC-005", "SRC-010" ], "findings": [ { "id": "operator-roles-and-responsibility-assignment", "name": "Operator roles and responsibility assignment", "description": "Assignment of provider, deployer, importer, distributor and authorised representative roles to legal entities, mapped onto the internal functions that design, develop, test, deploy, operate, oversee and govern the system, plus the conditions under which a deployer becomes a provider.", "source_refs": [ "SRC-001", "SRC-005", "SRC-010" ], "questions": [ { "id": "q-roles-entities", "text": "Which legal entity holds each operator role for this system in each market where it is supplied?", "kind": "ownership", "answer_data": [ "Role code", "Legal entity identifier", "Market or jurisdiction", "Contact details" ] }, { "id": "q-roles-accountable-person", "text": "Which named role is accountable for placing the system on the market and for keeping technical documentation current?", "kind": "authority", "answer_data": [ "Accountable role title", "Person or office identifier", "Delegation reference", "Effective period" ] }, { "id": "q-roles-internal-functions", "text": "Which internal functions — design, development, test and evaluation, deployment, operation, human oversight, governance — are staffed for this system?", "kind": "relationship", "answer_data": [ "Function name", "Staffing status", "Responsible organisational unit", "Competence evidence reference" ] }, { "id": "q-roles-transfer-trigger", "text": "Under which conditions does a deployer or distributor assume provider obligations for this system?", "kind": "exception", "answer_data": [ "Trigger condition", "Resulting obligation set", "Notification requirement", "Effective timestamp" ] } ], "data_elements": [ { "id": "de-provider-entity-id", "name": "Provider entity identifier", "description": "Legal entity that develops or places the system on the market under its own name or trademark.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-deployer-entity-id", "name": "Deployer entity identifier", "description": "Legal entity using the system under its own authority in a professional capacity.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-authorised-representative", "name": "Authorised representative", "description": "Representative appointed where the provider is established outside the market jurisdiction.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-role-transfer-trigger", "name": "Role transfer trigger", "description": "Recorded condition that moves provider obligations to another operator.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "accountability-assignment-matrix", "name": "Accountability assignment matrix", "description": "Matrix binding operator roles and internal AI actor functions to entities, offices and named accountable persons, with effective periods.", "media_or_form": [ "structured record", "matrix table", "document section" ], "serial": false, "identity_strategy": "System master identifier plus effective-period start; historical versions retained for audit rather than overwritten.", "source_refs": [ "SRC-001", "SRC-005", "SRC-010" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "lifecycle-change-and-deployment", "name": "Lifecycle, Change and Deployment", "description": "Where the system is in its life, how change to it is authorised, and where it actually runs.", "rationale": "Both the horizontal regulation and sectoral device regimes make the lifecycle change record a documentation requirement, and the OECD framing treats deployment and operation as distinct phases from design and development.", "source_refs": [ "SRC-002", "SRC-014", "SRC-020" ], "layers": [ { "id": "lifecycle-state-and-change-control", "name": "Lifecycle State and Change Control", "description": "Lifecycle stage, market status and the governance of modifications including pre-authorised change plans.", "source_refs": [ "SRC-002", "SRC-003", "SRC-020" ], "findings": [ { "id": "lifecycle-state-and-transitions", "name": "Lifecycle state and transitions", "description": "The current lifecycle stage and market status of the system, the history of transitions between them, who authorised each transition, and the gate criteria that must be met before advancing.", "source_refs": [ "SRC-014", "SRC-003", "SRC-010" ], "questions": [ { "id": "q-lifecycle-stage", "text": "Which lifecycle stage is the system in — design and development, data handling, verification and validation, deployment, or operation and monitoring?", "kind": "lifecycle", "answer_data": [ "Lifecycle stage code", "Stage entry timestamp", "Responsible function" ] }, { "id": "q-lifecycle-market-status", "text": "What is the current market or service status: on the market, in service, no longer placed on the market, recalled, or withdrawn?", "kind": "state", "answer_data": [ "Market status code", "Status effective timestamp", "Status reason" ] }, { "id": "q-lifecycle-transition-authority", "text": "Who authorised each recorded state transition, and on what evidence?", "kind": "provenance", "answer_data": [ "Authorising role", "Authorisation timestamp", "Evidence reference", "Activity identifier" ] }, { "id": "q-lifecycle-gate-criteria", "text": "Which gate criteria must be satisfied before the system may move to the next stage?", "kind": "process", "answer_data": [ "Gate criterion statement", "Verification method", "Pass or fail outcome" ] } ], "data_elements": [ { "id": "de-lifecycle-stage-code", "name": "Lifecycle stage code", "description": "Coded lifecycle stage of the system.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-014" ] }, { "id": "de-market-status-code", "name": "Market status code", "description": "Coded market or service availability status.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-transition-event", "name": "State transition event", "description": "Recorded transition with prior state, new state, authoriser and time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-016" ] }, { "id": "de-stage-gate-criterion", "name": "Stage gate criterion", "description": "Condition required before advancing to the next lifecycle stage.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "lifecycle-state-log", "name": "Lifecycle state log", "description": "Append-only record of lifecycle and market-status transitions with authorising agent, evidence reference and both event and record times.", "media_or_form": [ "append-only log", "structured record" ], "serial": true, "identity_strategy": "System master identifier plus monotonically increasing transition sequence number; entries are never mutated.", "source_refs": [ "SRC-015", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "change-control-and-substantial-modification", "name": "Change control and substantial modification", "description": "The determination of whether a proposed change is a substantial modification requiring renewed conformity assessment, the pre-authorised change envelope where one exists, and the impact assessment and test evidence that gate each release.", "source_refs": [ "SRC-001", "SRC-002", "SRC-020" ], "questions": [ { "id": "q-change-substantiality", "text": "Does the proposed change constitute a substantial modification that was not foreseen in the initial conformity assessment?", "kind": "decision", "answer_data": [ "Change classification", "Justification", "Affected requirement list", "Deciding role" ] }, { "id": "q-change-preauthorised", "text": "Which changes are covered by a pre-authorised change plan, and under which modification protocol are they executed?", "kind": "process", "answer_data": [ "Description of modifications", "Modification protocol reference", "Data management and retraining steps", "Update deployment procedure" ] }, { "id": "q-change-impact-evidence", "text": "What impact assessment supports the change, and which tests must pass before the new baseline is released?", "kind": "evidence", "answer_data": [ "Impact assessment reference", "Required test set", "Acceptance criteria", "Result disposition" ] }, { "id": "q-change-planned-sequence", "text": "What sequence of planned changes over the system lifetime is recorded in the technical documentation?", "kind": "temporal", "answer_data": [ "Planned change item", "Expected window", "Trigger condition", "Documentation section reference" ] } ], "data_elements": [ { "id": "de-change-request-id", "name": "Change request identifier", "description": "Identifier of a proposed or executed change to the system.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-change-classification", "name": "Change classification", "description": "Whether the change is routine, pre-authorised or substantial.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-020" ] }, { "id": "de-change-protocol-ref", "name": "Modification protocol reference", "description": "Reference to the protocol governing execution and verification of a pre-authorised change.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-020" ] }, { "id": "de-planned-change-schedule", "name": "Planned change schedule", "description": "Documented sequence of foreseen changes over the system lifetime.", "value_kind": "collection", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "change-control-plan", "name": "Change control plan", "description": "Plan describing the modifications foreseen, the protocol used to implement and verify them and the assessment of their impact on safety, performance and compliance.", "media_or_form": [ "document", "structured record" ], "serial": true, "identity_strategy": "System master identifier plus plan revision identifier; each authorised revision is retained with its approval time.", "source_refs": [ "SRC-020", "SRC-002" ] } ], "inline_only_rationale": null } ] }, { "id": "deployment-topology-and-jurisdiction", "name": "Deployment Topology and Jurisdiction", "description": "Where and on what the system runs, what it integrates with, and which legal regimes apply in each market.", "source_refs": [ "SRC-002", "SRC-003" ], "findings": [ { "id": "deployment-environment-and-jurisdictional-placement", "name": "Deployment environment and jurisdictional placement", "description": "The environments and locations in which the system is deployed and processing occurs, the hardware and runtime resources it requires, the interfaces through which it interacts with other software, hardware and AI systems, and the jurisdictions where it is placed on the market or put into service.", "source_refs": [ "SRC-002", "SRC-003", "SRC-005" ], "questions": [ { "id": "q-deploy-locations", "text": "In which environments and physical or cloud locations is the system deployed, and where is inference processing actually performed?", "kind": "spatial", "answer_data": [ "Environment name", "Hosting location or region", "Processing location", "Data residency constraint" ] }, { "id": "q-deploy-hardware", "text": "Which hardware and computational resources does the system require to operate as intended?", "kind": "composition", "answer_data": [ "Hardware specification", "Compute resource requirement", "Minimum runtime prerequisites" ] }, { "id": "q-deploy-interfaces", "text": "Through which interfaces does the system interact with other software, hardware or AI systems that are not part of it?", "kind": "interoperability", "answer_data": [ "Interface identifier", "Protocol or contract", "Direction of flow", "Counterparty system identifier" ] }, { "id": "q-deploy-jurisdictions", "text": "In which jurisdictions is the system placed on the market or put into service, and which regulatory regime governs each?", "kind": "authority", "answer_data": [ "Jurisdiction code", "Applicable regime", "Local status", "Registration reference" ] } ], "data_elements": [ { "id": "de-deployment-environment", "name": "Deployment environment", "description": "Named environment in which a system instance runs.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-processing-location", "name": "Processing location", "description": "Geographic or regional location where inference and data processing occur.", "value_kind": "geometry", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-hardware-requirement", "name": "Hardware requirement", "description": "Hardware on which the system is intended to run.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-market-jurisdiction", "name": "Market jurisdiction", "description": "Jurisdiction in which the system is made available.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-integration-interface", "name": "Integration interface", "description": "Interface through which the system exchanges data with external hardware, software or AI systems.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "deployment-topology-description", "name": "Deployment topology description", "description": "Description of environments, instances, hardware, processing locations, integration interfaces and jurisdictional placement for a system baseline.", "media_or_form": [ "document", "structured record", "diagram" ], "serial": false, "identity_strategy": "System master identifier plus baseline identifier plus environment name.", "source_refs": [ "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "operation-oversight-and-assurance", "name": "Operation, Oversight and Assurance", "description": "How the system behaves in service, how humans keep control of it, how well it performs and how resilient it is to attack.", "rationale": "Logging, human oversight, accuracy and cybersecurity are the operative technical requirements in the horizontal regime, and the trustworthiness characteristics and adversarial taxonomy give them measurable structure.", "source_refs": [ "SRC-004", "SRC-005", "SRC-011", "SRC-012" ], "layers": [ { "id": "runtime-operation-and-logging", "name": "Runtime Operation and Logging", "description": "Automatic event recording over the system lifetime and the live operational state of deployed instances.", "source_refs": [ "SRC-004", "SRC-009" ], "findings": [ { "id": "automatic-event-logging-capability", "name": "Automatic event logging capability", "description": "The technical capability to record events automatically over the lifetime of the system at a granularity sufficient to identify risk situations, support post-market monitoring and enable deployer-side operational monitoring, with distinct event and record times and protected integrity.", "source_refs": [ "SRC-004", "SRC-009", "SRC-016" ], "questions": [ { "id": "q-log-event-types", "text": "Which events does the system automatically record over its lifetime, and at what granularity?", "kind": "requirement", "answer_data": [ "Event type code", "Recorded attributes", "Granularity statement", "Sampling or completeness rule" ] }, { "id": "q-log-time-semantics", "text": "How are event time and record or ingestion time captured and distinguished in each log entry?", "kind": "temporal", "answer_data": [ "Event timestamp", "Record or ingestion timestamp", "Clock source", "Offset handling rule" ] }, { "id": "q-log-access-control", "text": "Who may read operational logs, under which controls, and for which purposes?", "kind": "access", "answer_data": [ "Authorised role", "Purpose limitation", "Access control mechanism", "Access audit requirement" ] }, { "id": "q-log-integrity", "text": "How is log integrity protected against alteration or deletion during the retention period?", "kind": "security", "answer_data": [ "Integrity mechanism", "Tamper evidence method", "Custodian role" ] } ], "data_elements": [ { "id": "de-log-event-type", "name": "Log event type", "description": "Coded class of automatically recorded event.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-log-event-time", "name": "Log event time", "description": "Time at which the recorded occurrence took place, including start and end times for a period of use.", "value_kind": "timestamp", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004", "SRC-016" ] }, { "id": "de-log-record-time", "name": "Log record time", "description": "Time at which the event was written or ingested by the logging store.", "value_kind": "timestamp", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-016" ] }, { "id": "de-log-subject-reference", "name": "Log subject reference", "description": "Reference to the input data, reference database or verifying persons associated with the event, where the use case requires it.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-log-integrity-control", "name": "Log integrity control", "description": "Mechanism protecting log entries from undetected alteration.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [ { "id": "operational-event-log", "name": "Operational event log", "description": "Automatically generated log stream covering periods of use, inputs, decisions and verification actions over the lifetime of the system.", "media_or_form": [ "append-only log stream", "structured record set" ], "serial": true, "identity_strategy": "System instance identifier plus log stream identifier plus monotonic sequence number; entries carry both event and record timestamps.", "source_refs": [ "SRC-004", "SRC-005" ] } ], "inline_only_rationale": null }, { "id": "runtime-operational-state", "name": "Runtime operational state", "description": "The live state of each deployed instance, the indicators observed continuously, and the conditions that trigger automatic containment, fallback or shutdown.", "source_refs": [ "SRC-009", "SRC-011", "SRC-005" ], "questions": [ { "id": "q-runtime-instance-state", "text": "What is the current operational state of each deployed instance — active, degraded, suspended or offline?", "kind": "state", "answer_data": [ "Instance identifier", "Operational state code", "State-effective timestamp", "Observation timestamp" ] }, { "id": "q-runtime-indicators", "text": "Which runtime indicators are observed continuously to detect deviation from validated behaviour?", "kind": "measurement", "answer_data": [ "Indicator name", "Observation method", "Observation frequency", "Baseline value" ] }, { "id": "q-runtime-containment", "text": "Which runtime conditions trigger automatic containment, fallback or shutdown of the system?", "kind": "event", "answer_data": [ "Trigger condition", "Automatic action", "Notification target", "Recovery procedure" ] } ], "data_elements": [ { "id": "de-instance-id", "name": "System instance identifier", "description": "Identifier of a running deployment of the system baseline.", "value_kind": "identifier", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "de-operational-state", "name": "Operational state", "description": "Coded live state of an instance.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "de-runtime-indicator", "name": "Runtime indicator observation", "description": "Observed value of a monitored runtime indicator with its observation time.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-containment-trigger", "name": "Containment trigger", "description": "Defined condition that causes automatic suspension, fallback or shutdown.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "runtime-status-snapshot", "name": "Runtime status snapshot", "description": "Point-in-time record of instance states and indicator observations used for operational monitoring and post-market analysis.", "media_or_form": [ "structured record", "time-series observation" ], "serial": true, "identity_strategy": "Instance identifier plus observation timestamp; snapshots are immutable observations, not mutable status fields.", "source_refs": [ "SRC-009", "SRC-016" ] } ], "inline_only_rationale": null } ] }, { "id": "human-oversight-and-intervention", "name": "Human Oversight and Intervention", "description": "Built-in and deployer-implemented oversight measures, the persons assigned to them and the mechanisms by which they intervene.", "source_refs": [ "SRC-002", "SRC-005", "SRC-011" ], "findings": [ { "id": "human-oversight-measures-and-controls", "name": "Human oversight measures and intervention controls", "description": "The oversight measures designed into the system, those that must be implemented by the deployer, the persons assigned with the necessary competence, training, authority and support, and the mechanisms by which they can interrupt, override or reverse system behaviour.", "source_refs": [ "SRC-002", "SRC-005", "SRC-011" ], "questions": [ { "id": "q-oversight-split", "text": "Which oversight measures are built into the system by the provider and which must be implemented by the deployer?", "kind": "requirement", "answer_data": [ "Measure description", "Implementing party", "Technical or organisational nature", "Dependency on interface features" ] }, { "id": "q-oversight-assignment", "text": "Which natural persons are assigned oversight duties, and what competence, training and authority do they hold?", "kind": "ownership", "answer_data": [ "Assigned role or person reference", "Competence evidence", "Training record reference", "Authority scope" ] }, { "id": "q-oversight-intervention", "text": "How can an overseer interrupt, override or reverse a system output, and within what time window?", "kind": "process", "answer_data": [ "Intervention mechanism", "Invocation path", "Maximum time to effect", "Post-intervention state" ] }, { "id": "q-oversight-automation-bias", "text": "How is automation bias in overseers detected and mitigated for this system?", "kind": "quality", "answer_data": [ "Detection method", "Mitigation measure", "Review frequency", "Evidence reference" ] } ], "data_elements": [ { "id": "de-oversight-measure", "name": "Oversight measure", "description": "A specific human oversight measure applicable to the system.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-oversight-assignee-role", "name": "Oversight assignee role", "description": "Role assigned to exercise human oversight in operation.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-intervention-mechanism", "name": "Intervention mechanism", "description": "Technical means by which a human halts, overrides or reverses system behaviour.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-oversight-competence-evidence", "name": "Oversight competence evidence", "description": "Evidence that assigned overseers have the necessary competence and training.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "human-oversight-plan", "name": "Human oversight plan", "description": "Plan describing designed-in and deployer-implemented oversight measures, assignments, intervention mechanisms and competence requirements.", "media_or_form": [ "document", "structured record" ], "serial": true, "identity_strategy": "System master identifier plus deployment context plus plan revision; deployer-specific instances reference the provider plan revision they implement.", "source_refs": [ "SRC-002", "SRC-005" ] } ], "inline_only_rationale": null } ] }, { "id": "performance-measurement-and-evaluation", "name": "Performance Measurement and Evaluation", "description": "Declared metrics and the test and validation evidence that substantiates them.", "source_refs": [ "SRC-002", "SRC-011" ], "findings": [ { "id": "performance-metrics-and-declared-accuracy", "name": "Performance metrics and declared accuracy", "description": "The metrics chosen to express accuracy, robustness and fairness for the intended purpose, the justification of their appropriateness, the levels declared to deployers and the conditions and degradation modes under which those levels hold.", "source_refs": [ "SRC-002", "SRC-011", "SRC-016" ], "questions": [ { "id": "q-metrics-appropriateness", "text": "Which metrics express accuracy, robustness and fairness for this intended purpose, and why are they appropriate?", "kind": "measurement", "answer_data": [ "Metric name and definition", "Appropriateness justification", "Trustworthiness characteristic addressed" ] }, { "id": "q-metrics-declared-levels", "text": "What levels of accuracy and robustness are declared to deployers, and under which conditions do they hold?", "kind": "quality", "answer_data": [ "Declared metric value", "Confidence interval or tolerance", "Applicable condition set", "Population or subgroup scope" ] }, { "id": "q-metrics-limitations", "text": "What are the known limitations, degradation conditions and reasonably foreseeable unintended outcomes?", "kind": "constraint", "answer_data": [ "Limitation statement", "Degradation condition", "Unintended outcome description", "Affected group" ] }, { "id": "q-metrics-recomputation", "text": "How often are metrics recomputed in operation, and against which reference period and dataset?", "kind": "temporal", "answer_data": [ "Recomputation frequency", "Reference period", "Reference dataset identifier", "Observation timestamp" ] } ], "data_elements": [ { "id": "de-metric-definition", "name": "Metric definition", "description": "Definition of a performance, robustness or fairness metric used for the system.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-declared-metric-value", "name": "Declared metric value", "description": "Value of a metric declared in instructions for use or documentation.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-metric-condition", "name": "Metric applicability condition", "description": "Condition under which a declared metric value is valid.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-degradation-condition", "name": "Degradation condition", "description": "Circumstance in which performance is known to degrade.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "performance-metric-statement", "name": "Performance metric statement", "description": "Declared metric set with values, conditions, subgroup breakdowns and limitations for a given system version.", "media_or_form": [ "document section", "structured record" ], "serial": true, "identity_strategy": "System master identifier plus system version plus statement revision; each value carries its observation timestamp.", "source_refs": [ "SRC-002", "SRC-011" ] } ], "inline_only_rationale": null }, { "id": "test-validation-and-evaluation-evidence", "name": "Test, validation and evaluation evidence", "description": "The executed validation and testing procedures, the datasets used, the retained test logs and reports dated and countersigned by responsible persons, and the disposition of results that failed acceptance criteria.", "source_refs": [ "SRC-002", "SRC-011", "SRC-015" ], "questions": [ { "id": "q-eval-procedures", "text": "Which validation and testing procedures were executed, on which datasets, and with what results?", "kind": "evidence", "answer_data": [ "Procedure identifier", "Dataset identifier and version", "Result values", "Execution timestamp" ] }, { "id": "q-eval-signoff", "text": "Which test logs and reports are retained, dated and countersigned by the responsible persons?", "kind": "validation", "answer_data": [ "Report identifier", "Retention location", "Signatory role", "Signature timestamp" ] }, { "id": "q-eval-data-separation", "text": "How are evaluation datasets shown to be separated from training data and fit for the evaluation claim made?", "kind": "provenance", "answer_data": [ "Separation method", "Contamination check result", "Dataset provenance reference" ] }, { "id": "q-eval-failures", "text": "Which evaluation results failed acceptance criteria, and how were those failures dispositioned before release?", "kind": "exception", "answer_data": [ "Failed criterion", "Deviation magnitude", "Disposition decision", "Approving role" ] } ], "data_elements": [ { "id": "de-evaluation-run-id", "name": "Evaluation run identifier", "description": "Identifier of one executed evaluation activity.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-evaluation-dataset-ref", "name": "Evaluation dataset reference", "description": "Reference to the dataset and version used in an evaluation run.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-acceptance-criterion", "name": "Acceptance criterion", "description": "Threshold or condition an evaluation result must satisfy for release.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-evaluation-signoff", "name": "Evaluation sign-off", "description": "Countersignature by the responsible person with role and time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "evaluation-report", "name": "Evaluation report", "description": "Dated test and validation report with procedures, datasets, results, acceptance decisions and responsible-person sign-off.", "media_or_form": [ "document", "structured record", "test log" ], "serial": true, "identity_strategy": "Evaluation run identifier issued by the evaluation system of record, bound to system master identifier and system version.", "source_refs": [ "SRC-002", "SRC-015" ] } ], "inline_only_rationale": null } ] }, { "id": "security-and-adversarial-resilience", "name": "Security and Adversarial Resilience", "description": "Protective controls and the AI-specific threat posture of the system.", "source_refs": [ "SRC-002", "SRC-012", "SRC-011" ], "findings": [ { "id": "security-controls-and-adversarial-threat-posture", "name": "Security controls and adversarial threat posture", "description": "The cybersecurity measures protecting the system and the explicit mapping of its exposure to adversarial attack classes — evasion, poisoning, privacy and abuse — with the resilience test results and the detection and response path for AI-specific security events.", "source_refs": [ "SRC-002", "SRC-012", "SRC-011" ], "questions": [ { "id": "q-security-controls", "text": "Which cybersecurity measures protect the system against unauthorised access, model theft and infrastructure compromise?", "kind": "security", "answer_data": [ "Control identifier", "Control description", "Assurance level", "Verification evidence" ] }, { "id": "q-security-threat-classes", "text": "Which adversarial attack classes are in the threat model for this system, and which residual exposures are accepted?", "kind": "classification", "answer_data": [ "Attack class code", "Attacker capability and knowledge assumption", "Applicable lifecycle stage", "Acceptance decision" ] }, { "id": "q-security-resilience-testing", "text": "How is resilience against each in-scope attack class tested, and with what measured result?", "kind": "measurement", "answer_data": [ "Test method", "Attack success rate or equivalent", "Test timestamp", "Tester role" ] }, { "id": "q-security-response-path", "text": "What is the detection and response path for a security event that alters AI-specific behaviour rather than infrastructure?", "kind": "event", "answer_data": [ "Detection signal", "Escalation path", "Containment action", "Interface to incident reporting" ] } ], "data_elements": [ { "id": "de-security-control", "name": "Security control", "description": "Implemented technical or organisational control protecting the system.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-threat-class-mapping", "name": "Threat class mapping", "description": "Mapping of the system to an adversarial machine learning attack class and lifecycle stage of attack.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-resilience-test-result", "name": "Resilience test result", "description": "Measured outcome of an adversarial resilience test.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-security-event-path", "name": "Security event response path", "description": "Defined escalation and containment path for AI-specific security events.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "ai-threat-model-and-security-dossier", "name": "AI threat model and security dossier", "description": "Dossier recording the threat model, control set, adversarial test results and residual risk acceptance for a system baseline.", "media_or_form": [ "document", "structured record" ], "serial": true, "identity_strategy": "System master identifier plus baseline identifier plus dossier revision; superseded revisions retained for audit.", "source_refs": [ "SRC-012", "SRC-002" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "governance-conformity-and-transparency", "name": "Governance, Conformity and Transparency", "description": "The assurance case, the public record and what affected people are told.", "rationale": "Conformity evidence, public registration and transparency to affected persons are distinct obligations with distinct data sets, and the management-system standard places impact assessment and risk management alongside them.", "source_refs": [ "SRC-002", "SRC-003", "SRC-008", "SRC-019" ], "layers": [ { "id": "conformity-and-public-registration", "name": "Conformity and Public Registration", "description": "Assessment route, declarations, standards applied and the public registry record.", "source_refs": [ "SRC-002", "SRC-003" ], "findings": [ { "id": "conformity-assessment-and-declaration", "name": "Conformity assessment and declaration", "description": "The assessment procedure followed, any notified body involved, the certificate and its expiry, the harmonised standards or common specifications applied, the justification where alternatives were adopted, and the declaration of conformity issued for a specific version.", "source_refs": [ "SRC-002", "SRC-003", "SRC-019" ], "questions": [ { "id": "q-conformity-route", "text": "Which conformity assessment procedure was followed, and was a notified body involved?", "kind": "evidence", "answer_data": [ "Assessment procedure code", "Notified body identification number", "Assessment completion timestamp" ] }, { "id": "q-conformity-declaration", "text": "Which declaration of conformity and marking has been issued, by which entity, and for which system version?", "kind": "authority", "answer_data": [ "Declaration identifier", "Issuing entity", "Covered system version", "Marking applied" ] }, { "id": "q-conformity-standards", "text": "Which harmonised standards or common specifications were applied, and where an alternative solution was adopted, how is equivalence justified?", "kind": "validation", "answer_data": [ "Standard reference and version", "Clause coverage", "Alternative solution description", "Equivalence justification" ] }, { "id": "q-conformity-expiry", "text": "When does the certificate expire and which events force re-assessment before that date?", "kind": "temporal", "answer_data": [ "Certificate expiry date", "Re-assessment trigger", "Responsible role" ] } ], "data_elements": [ { "id": "de-conformity-route", "name": "Conformity assessment route", "description": "Procedure used to demonstrate conformity.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-notified-body-id", "name": "Notified body identifier", "description": "Identification number of the body that issued the certificate.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-certificate-reference", "name": "Certificate reference", "description": "Certificate type, number and issuing body.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-certificate-expiry", "name": "Certificate expiry date", "description": "Date on which the certificate ceases to be valid.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-standard-applied", "name": "Standard applied", "description": "Harmonised standard or specification applied, with version.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "declaration-of-conformity", "name": "Declaration of conformity", "description": "Signed declaration by the provider that a specified system version meets the applicable requirements, with the standards applied and any certificate references.", "media_or_form": [ "document", "scanned certificate", "structured record" ], "serial": true, "identity_strategy": "Declaration identifier issued by the provider, bound to system master identifier and covered system version.", "source_refs": [ "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "public-registration-record", "name": "Public registration record", "description": "The public database entry representing the system, the split of registration duties between provider and deployer, which fields are publicly visible and how currency of the entry is maintained.", "source_refs": [ "SRC-003", "SRC-005", "SRC-007" ], "questions": [ { "id": "q-registration-entry", "text": "Which public database entry represents this system, and what is its resolvable identifier or URL?", "kind": "identity", "answer_data": [ "Registration entry identifier", "Entry URL", "Registering entity", "Registration timestamp" ] }, { "id": "q-registration-fields", "text": "Which registration fields must be supplied and kept up to date by the provider, and which by the deployer?", "kind": "requirement", "answer_data": [ "Field name", "Responsible party", "Update obligation", "Section of the registration schema" ] }, { "id": "q-registration-visibility", "text": "Which registration data are publicly visible and which are restricted to authorities?", "kind": "access", "answer_data": [ "Field name", "Visibility class", "Restriction basis", "Exempt use case" ] }, { "id": "q-registration-currency", "text": "When was the registration entry created and last updated, and what triggers a mandatory update?", "kind": "temporal", "answer_data": [ "Created timestamp", "Last updated timestamp", "Update trigger", "Responsible role" ] } ], "data_elements": [ { "id": "de-registration-entry-url", "name": "Registration entry URL", "description": "Resolvable location of the public registration entry for the system.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-registration-section", "name": "Registration section", "description": "Which registration section applies: provider high-risk, provider non-high-risk determination, or deployer.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-registration-status", "name": "Registered status", "description": "Status recorded in the public entry: on the market, in service, no longer available, recalled.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-registration-updated-at", "name": "Registration last-updated time", "description": "Time at which the registration entry was last updated.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-016" ] } ], "artifacts": [ { "id": "registration-submission-record", "name": "Registration submission record", "description": "Record of what was submitted to the public database, by whom, when, and which version of the entry it produced.", "media_or_form": [ "structured record", "registry entry", "submission receipt" ], "serial": true, "identity_strategy": "Registration entry identifier issued by the operating authority as the governed external identifier; the system master identifier remains the internal key.", "source_refs": [ "SRC-003", "SRC-007" ] } ], "inline_only_rationale": null } ] }, { "id": "transparency-and-disclosure", "name": "Transparency and Disclosure", "description": "What affected people are told and how machine-generated output is marked.", "source_refs": [ "SRC-008", "SRC-005" ], "findings": [ { "id": "disclosure-to-users-and-content-marking", "name": "Disclosure to affected persons and content marking", "description": "How natural persons are informed that they interact with an AI system or are subject to its decisions, how synthetic audio, image, video and text output is marked in a machine-readable and detectable form, which exemptions are relied on and how disclosure meets accessibility requirements.", "source_refs": [ "SRC-008", "SRC-005" ], "questions": [ { "id": "q-disclosure-interaction", "text": "How and at what moment are natural persons informed that they are interacting with an AI system?", "kind": "requirement", "answer_data": [ "Disclosure mechanism", "Disclosure wording", "Timing relative to first interaction", "Channel" ] }, { "id": "q-disclosure-marking", "text": "How is synthetic output marked in a machine-readable format that is detectable as artificially generated or manipulated?", "kind": "interoperability", "answer_data": [ "Marking technique", "Technical standard referenced", "Coverage by output type", "Robustness of marking" ] }, { "id": "q-disclosure-exemptions", "text": "Which disclosure exemptions are relied on for this system, and what safeguards replace disclosure?", "kind": "exception", "answer_data": [ "Exemption basis", "Scope of exemption", "Compensating safeguard", "Authorising role" ] }, { "id": "q-disclosure-accessibility", "text": "How is the disclosure made accessible to persons with disabilities and to persons subject to automated decisions?", "kind": "access", "answer_data": [ "Accessibility measure", "Applicable accessibility requirement", "Verification evidence" ] } ], "data_elements": [ { "id": "de-disclosure-mechanism", "name": "Disclosure mechanism", "description": "Means by which AI interaction or AI-assisted decision-making is disclosed.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-disclosure-timing", "name": "Disclosure timing", "description": "Point relative to first interaction or exposure at which disclosure occurs.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-content-marking-method", "name": "Content marking method", "description": "Machine-readable marking technique applied to synthetic outputs.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-disclosure-exemption", "name": "Disclosure exemption", "description": "Recorded basis for not disclosing, with compensating safeguards.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "transparency-notice", "name": "Transparency notice", "description": "The user-facing notice content and its delivery configuration, together with the marking configuration applied to generated outputs.", "media_or_form": [ "notice text", "structured record", "embedded metadata" ], "serial": true, "identity_strategy": "System master identifier plus notice revision plus locale; marking configuration is versioned with the baseline.", "source_refs": [ "SRC-008" ] } ], "inline_only_rationale": null } ] }, { "id": "risk-management-and-impact-assessment", "name": "Risk Management and Impact Assessment", "description": "The continuous risk process and the assessment of effects on persons and their rights.", "source_refs": [ "SRC-002", "SRC-003", "SRC-019" ], "findings": [ { "id": "risk-management-system", "name": "Risk management system", "description": "The continuous iterative risk process maintained across the system lifetime: identification and characterisation of risks by probability and severity of harm, the treatment measures adopted, the residual risks accepted and by whom, and the review cadence and out-of-cycle triggers.", "source_refs": [ "SRC-002", "SRC-001", "SRC-010", "SRC-019" ], "questions": [ { "id": "q-risk-process", "text": "How is the risk management system established, documented and maintained as a continuous iterative process across the lifetime of the system?", "kind": "process", "answer_data": [ "Process description", "Documentation reference", "Ownership", "Iteration cadence" ] }, { "id": "q-risk-characterisation", "text": "How is each identified risk characterised in terms of probability of occurrence and severity of harm?", "kind": "measurement", "answer_data": [ "Risk identifier", "Probability rating", "Severity rating", "Rating scale definition" ] }, { "id": "q-risk-residual-acceptance", "text": "Which residual risks are accepted, by which role, and on what documented grounds?", "kind": "decision", "answer_data": [ "Residual risk statement", "Accepting role", "Grounds", "Acceptance timestamp" ] }, { "id": "q-risk-review-trigger", "text": "What cadence governs risk review, and which events force an out-of-cycle reassessment?", "kind": "temporal", "answer_data": [ "Review cadence", "Out-of-cycle trigger", "Last review timestamp", "Next review due" ] } ], "data_elements": [ { "id": "de-risk-entry", "name": "Risk entry", "description": "One identified risk with source, affected parties and treatment status.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "de-risk-severity", "name": "Risk severity", "description": "Rated severity of harm for a risk entry.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-risk-probability", "name": "Risk probability", "description": "Rated probability of occurrence for a risk entry.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001" ] }, { "id": "de-risk-treatment", "name": "Risk treatment measure", "description": "Measure adopted to eliminate or reduce a risk.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-residual-risk-acceptance", "name": "Residual risk acceptance", "description": "Recorded acceptance of a residual risk with accepting role and time.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "risk-management-file", "name": "Risk management file", "description": "Living file describing the risk management system, the risk register for the system, treatment measures and residual risk acceptances.", "media_or_form": [ "document", "structured record", "register" ], "serial": false, "identity_strategy": "System master identifier plus file revision; entries carry their own risk identifiers and revision history.", "source_refs": [ "SRC-002", "SRC-019" ] } ], "inline_only_rationale": null }, { "id": "impact-assessment-on-persons", "name": "Impact assessment on persons and rights", "description": "Whether an impact assessment on fundamental rights is required for a given deployment, what it covers, how it relates to the data protection impact assessment, which groups are affected and how the findings summary reaches the authority.", "source_refs": [ "SRC-003", "SRC-005", "SRC-019" ], "questions": [ { "id": "q-impact-required", "text": "Is an impact assessment on fundamental rights required for this deployment, and what must it cover?", "kind": "requirement", "answer_data": [ "Requirement trigger", "Deployer category", "Scope of assessment", "Due timing relative to first use" ] }, { "id": "q-impact-dpia-relation", "text": "How does the AI impact assessment relate to and reuse the data protection impact assessment for the same processing?", "kind": "relationship", "answer_data": [ "DPIA reference", "Reused sections", "Complementary elements", "Non-duplication rationale" ] }, { "id": "q-impact-affected-groups", "text": "Which categories of persons or groups are likely to be affected, and how were they or their representatives consulted?", "kind": "ownership", "answer_data": [ "Affected group description", "Consultation method", "Consultation date", "Outcome summary" ] }, { "id": "q-impact-summary-submission", "text": "What summary of findings is submitted to the competent authority, and where is the full assessment retained?", "kind": "evidence", "answer_data": [ "Summary content", "Submission channel", "Submission timestamp", "Retention location" ] } ], "data_elements": [ { "id": "de-impact-assessment-scope", "name": "Impact assessment scope", "description": "Processes, purposes, frequency and affected persons covered by the assessment.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-affected-group", "name": "Affected group", "description": "Category of persons likely to be affected by use of the system.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-dpia-reference", "name": "Data protection impact assessment reference", "description": "Reference to the DPIA covering the same processing.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-impact-summary-ref", "name": "Impact assessment summary reference", "description": "Reference to the summary of findings submitted upon registration.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "impact-assessment-report", "name": "Impact assessment report", "description": "Assessment of the effect of a specific deployment on persons and their fundamental rights, with the summary of findings prepared for the authority.", "media_or_form": [ "document", "structured record" ], "serial": true, "identity_strategy": "Deployer entity identifier plus system master identifier plus assessment revision; the submitted summary references the full report revision.", "source_refs": [ "SRC-003", "SRC-005" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "post-market-incidents-and-retirement", "name": "Post-market, Incidents and Retirement", "description": "How the system is watched after release, what happens when it harms, and how it ends.", "rationale": "Post-market monitoring, awareness-triggered incident reporting and log retention are explicit continuing obligations that outlive the release event and must be modelled as ongoing state, not one-off documents.", "source_refs": [ "SRC-009", "SRC-006", "SRC-005" ], "layers": [ { "id": "post-market-monitoring-and-incidents", "name": "Post-market Monitoring and Incidents", "description": "The monitoring plan and signal set, and the detection and reporting of serious incidents.", "source_refs": [ "SRC-009", "SRC-006" ], "findings": [ { "id": "post-market-monitoring-plan", "name": "Post-market monitoring plan and signals", "description": "The proportionate monitoring system that actively collects and analyses performance data over the lifetime of the system, including data supplied by deployers, the thresholds that trigger investigation, and the integration with pre-existing sectoral post-market systems.", "source_refs": [ "SRC-009", "SRC-005", "SRC-002" ], "questions": [ { "id": "q-pmm-plan-content", "text": "What does the post-market monitoring plan require to be collected, analysed and reviewed over the system's lifetime?", "kind": "process", "answer_data": [ "Collected data category", "Analysis method", "Review cadence", "Responsible function" ] }, { "id": "q-pmm-deployer-feed", "text": "Which data do deployers supply to the provider, through which channel and at what frequency?", "kind": "relationship", "answer_data": [ "Data item", "Channel", "Frequency", "Contractual basis" ] }, { "id": "q-pmm-thresholds", "text": "Which thresholds in monitored data trigger investigation or corrective action?", "kind": "measurement", "answer_data": [ "Signal name", "Threshold value", "Trigger action", "Escalation owner" ] }, { "id": "q-pmm-sector-integration", "text": "How is monitoring integrated with pre-existing sectoral post-market systems without duplicating obligations?", "kind": "interoperability", "answer_data": [ "Sectoral system reference", "Overlap statement", "Equivalence justification", "Consolidated reporting route" ] } ], "data_elements": [ { "id": "de-monitoring-plan-ref", "name": "Post-market monitoring plan reference", "description": "Reference to the monitoring plan forming part of the technical documentation.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-monitored-signal", "name": "Monitored signal", "description": "A signal collected and analysed in post-market monitoring.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-deployer-feedback-channel", "name": "Deployer feedback channel", "description": "Channel through which deployers supply monitoring data to the provider.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-monitoring-threshold", "name": "Monitoring threshold", "description": "Threshold on a monitored signal that triggers investigation or corrective action.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "post-market-monitoring-plan-document", "name": "Post-market monitoring plan", "description": "Plan describing systematic collection, documentation and analysis of performance data over the lifetime of the system, forming part of the technical documentation.", "media_or_form": [ "document", "structured record" ], "serial": true, "identity_strategy": "System master identifier plus plan revision; plan revisions are bound to the technical documentation version they accompany.", "source_refs": [ "SRC-009", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "serious-incident-detection-and-reporting", "name": "Serious incident detection and reporting", "description": "What counts as a serious incident for this system, how awareness is established and timestamped, which reporting deadline class applies, which authority receives the report, and what investigation and corrective action follow.", "source_refs": [ "SRC-006", "SRC-001", "SRC-005" ], "questions": [ { "id": "q-incident-definition", "text": "What qualifies as a serious incident for this system, and by which detection route is it recognised?", "kind": "event", "answer_data": [ "Incident category", "Harm type", "Detection route", "Detecting party" ] }, { "id": "q-incident-deadline", "text": "By which deadline must the incident be reported after awareness, and which deadline class applies?", "kind": "temporal", "answer_data": [ "Awareness timestamp", "Deadline class", "Report due timestamp", "Actual report timestamp" ] }, { "id": "q-incident-authority", "text": "To which market surveillance authority is the report addressed, and who signs it on behalf of which operator?", "kind": "authority", "answer_data": [ "Authority identifier", "Member State or jurisdiction", "Signing role", "Operator role reporting" ] }, { "id": "q-incident-followup", "text": "What investigation, risk assessment and corrective action follow the report, and how is the outcome recorded?", "kind": "process", "answer_data": [ "Investigation reference", "Causal link determination", "Corrective action identifier", "Outcome timestamp" ] } ], "data_elements": [ { "id": "de-incident-case-id", "name": "Incident case identifier", "description": "Identifier of an incident case affecting this system.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-incident-severity-class", "name": "Incident deadline class", "description": "Which reporting deadline class applies: general, accelerated for widespread infringement or critical infrastructure disruption, or death.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-incident-awareness-time", "name": "Awareness timestamp", "description": "Time at which the reporting operator became aware of the incident, which starts the deadline clock.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-016" ] }, { "id": "de-reporting-authority", "name": "Reporting authority", "description": "Market surveillance authority to which the report is submitted.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-corrective-action-ref", "name": "Corrective action reference", "description": "Reference to the corrective action taken following an incident.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "serious-incident-report-submission", "name": "Serious incident report submission", "description": "Record of the submission of an incident report naming this system, with awareness time, deadline class, authority and acknowledgement; the report narrative itself is owned by the incident model.", "media_or_form": [ "submission record", "structured record", "correspondence" ], "serial": true, "identity_strategy": "Incident case identifier issued by the reporting operator's system of record, cross-referenced to the authority's acknowledgement reference where one is issued.", "source_refs": [ "SRC-006" ] } ], "inline_only_rationale": null } ] }, { "id": "retention-decommissioning-and-deletion", "name": "Retention, Decommissioning and Deletion", "description": "How long records are kept, how the system is withdrawn and how personal data is disposed of without destroying auditability.", "source_refs": [ "SRC-005", "SRC-003", "SRC-008" ], "findings": [ { "id": "record-retention-and-decommissioning", "name": "Record retention and decommissioning", "description": "Retention periods and legal bases for logs, technical documentation and evaluation evidence; the withdrawal, recall and decommissioning procedure including deployer notification and data disposition; and the terminal status record that keeps a withdrawn system discoverable.", "source_refs": [ "SRC-005", "SRC-003", "SRC-004" ], "questions": [ { "id": "q-retention-periods", "text": "How long are logs, technical documentation and evaluation evidence retained, and under which legal or contractual basis?", "kind": "retention", "answer_data": [ "Record class", "Retention period", "Legal or contractual basis", "Custodian role" ] }, { "id": "q-decommission-steps", "text": "What steps decommission the system, including withdrawal from market, deployer notification and disposition of data and models?", "kind": "process", "answer_data": [ "Decommission step", "Responsible role", "Notification recipients", "Completion timestamp" ] }, { "id": "q-deletion-personal-data", "text": "How are personal data in logs, caches and derived stores deleted or minimised while preserving audit capability?", "kind": "privacy", "answer_data": [ "Data store", "Deletion or minimisation technique", "Residual audit record", "Verification evidence" ] }, { "id": "q-terminal-status", "text": "What terminal status is recorded for a withdrawn system, and where does that record remain discoverable?", "kind": "state", "answer_data": [ "Terminal status code", "Effective timestamp", "Discovery location", "Superseding system reference" ] } ], "data_elements": [ { "id": "de-retention-period", "name": "Retention period", "description": "Duration for which a class of record is retained, with the minimum where one is prescribed.", "value_kind": "duration", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "de-retention-basis", "name": "Retention basis", "description": "Legal, regulatory or contractual basis for the retention period.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-005" ] }, { "id": "de-decommission-plan-ref", "name": "Decommissioning plan reference", "description": "Reference to the plan governing withdrawal and decommissioning.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-deletion-record", "name": "Deletion record", "description": "Evidence that data disposition was executed for a store.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-terminal-status", "name": "Terminal status", "description": "Final recorded status of the system after withdrawal or recall.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "decommissioning-and-retention-record", "name": "Decommissioning and retention record", "description": "Record of retention schedules per record class and of the executed decommissioning steps, notifications, deletions and terminal status.", "media_or_form": [ "structured record", "document", "retention schedule" ], "serial": true, "identity_strategy": "System master identifier plus decommissioning event sequence; the record survives the system it describes for the length of the longest retention period.", "source_refs": [ "SRC-005", "SRC-003" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "register-ai-system", "name": "Register AI system", "description": "Create the governed record for an AI system, assign its master identifier and bind provider, trade name, identification reference and intended purpose.", "inputs": [ "Provider legal entity identifier", "Trade name and identification reference", "Intended purpose statement", "Initial classification input" ], "outputs": [ "System master identifier", "System identity record", "Initial lifecycle state" ], "preconditions": [ "Provider role is assigned to a legal entity", "Intended purpose is declared in writing" ], "effects": [ "A uniquely identified AI system record exists", "Downstream artifacts can reference a stable system key" ], "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "classify-risk-and-regulatory-status", "name": "Classify risk and regulatory status", "description": "Determine the applicable regime and record the classification route, any derogation condition, the profiling flag and the assessment evidence.", "inputs": [ "Intended purpose statement", "Use-case and product context", "Profiling determination" ], "outputs": [ "Risk class code", "Classification assessment record", "Derogation grounds summary where claimed" ], "preconditions": [ "Intended purpose is fixed", "Deployment jurisdictions are known" ], "effects": [ "Obligation set for the system is determined", "Registration and documentation duties are triggered or excluded" ], "source_refs": [ "SRC-007", "SRC-003" ] }, { "id": "assemble-component-inventory", "name": "Assemble component inventory", "description": "Produce a machine-readable bill of materials for a baseline covering models, libraries, services, hardware, datasets and their suppliers, licences and vulnerabilities.", "inputs": [ "Baseline component set", "Supplier and licence data", "Vulnerability feed" ], "outputs": [ "AI bill of materials", "Component vulnerability list" ], "preconditions": [ "A configuration baseline has been declared", "BOM specification version is selected" ], "effects": [ "Supply-chain composition is inspectable by machine", "Change detection on components becomes possible" ], "source_refs": [ "SRC-017", "SRC-018" ] }, { "id": "baseline-configuration", "name": "Baseline configuration", "description": "Freeze and attest a configuration baseline, recording component versions, integrity digests and effective dates, and superseding the prior baseline.", "inputs": [ "Component version set", "Build and signing evidence", "Effective-from time" ], "outputs": [ "Configuration baseline manifest", "Supersession record" ], "preconditions": [ "All components resolve to fixed versions", "Release gate criteria have passed" ], "effects": [ "The operative system version is unambiguous", "Later evidence can be bound to a specific baseline" ], "source_refs": [ "SRC-002", "SRC-017", "SRC-015" ] }, { "id": "evaluate-and-record-performance", "name": "Evaluate and record performance", "description": "Execute validation and testing against declared metrics and acceptance criteria and retain dated, signed evaluation evidence.", "inputs": [ "Evaluation procedures", "Evaluation datasets", "Acceptance criteria" ], "outputs": [ "Evaluation report", "Declared metric values", "Failure dispositions" ], "preconditions": [ "Metrics are defined and justified as appropriate", "Evaluation data are separated from training data" ], "effects": [ "Declared accuracy is substantiated", "Release decisions have documented evidence" ], "source_refs": [ "SRC-002", "SRC-011" ] }, { "id": "emit-and-retain-operational-logs", "name": "Emit and retain operational logs", "description": "Record events automatically over the system lifetime with distinct event and record times, protect their integrity and retain them for the prescribed minimum period.", "inputs": [ "Runtime events", "Logging configuration", "Retention schedule" ], "outputs": [ "Operational event log", "Retention status per log stream" ], "preconditions": [ "Logging capability is enabled in the baseline", "Clock source and offset handling are defined" ], "effects": [ "Traceability of operation is preserved", "Post-market analysis and incident reconstruction are possible" ], "source_refs": [ "SRC-004", "SRC-005", "SRC-016" ] }, { "id": "assess-and-authorise-change", "name": "Assess and authorise change", "description": "Classify a proposed change as routine, pre-authorised or substantial, run the required impact assessment and tests, and authorise or refuse the new baseline.", "inputs": [ "Change request", "Change control plan", "Impact assessment", "Test results" ], "outputs": [ "Change classification", "Authorisation decision", "New baseline or refusal record" ], "preconditions": [ "Current baseline is identified", "Acceptance criteria are defined" ], "effects": [ "Conformity status after change is determined", "Re-assessment and re-registration duties are triggered where needed" ], "source_refs": [ "SRC-001", "SRC-002", "SRC-020" ] }, { "id": "publish-registration-record", "name": "Publish registration record", "description": "Submit and maintain the public registration entry for the system, splitting provider and deployer fields and keeping status and instructions current.", "inputs": [ "Registration data set", "Declaration of conformity", "Impact assessment summary where applicable" ], "outputs": [ "Registration entry identifier or URL", "Registration submission record" ], "preconditions": [ "Classification determines a registration duty", "Conformity evidence exists for the version being registered" ], "effects": [ "The system is publicly discoverable to authorities and, where applicable, the public", "Status changes become externally visible" ], "source_refs": [ "SRC-003", "SRC-007" ] }, { "id": "detect-and-report-serious-incident", "name": "Detect and report serious incident", "description": "Recognise a serious incident, timestamp awareness, select the applicable deadline class, submit the report to the competent authority and drive investigation and corrective action.", "inputs": [ "Incident signal", "Awareness determination", "Causal link assessment" ], "outputs": [ "Serious incident report submission", "Corrective action reference", "Investigation outcome" ], "preconditions": [ "Incident categories are defined for the system", "Reporting authority is identified for the jurisdiction" ], "effects": [ "Statutory reporting deadlines are met or a deviation is recorded", "An incident report record is created and linked to this system" ], "source_refs": [ "SRC-006", "SRC-005" ] }, { "id": "withdraw-and-decommission-system", "name": "Withdraw and decommission system", "description": "Withdraw or recall the system, notify deployers and authorities, execute data disposition under the retention schedule and record the terminal status.", "inputs": [ "Withdrawal decision", "Deployer register", "Retention schedule" ], "outputs": [ "Terminal status record", "Deletion records", "Decommissioning and retention record" ], "preconditions": [ "Authorisation to withdraw exists", "Retention obligations are identified per record class" ], "effects": [ "The system stops being placed on the market or put into service", "Auditability is preserved for the required retention period" ], "source_refs": [ "SRC-005", "SRC-003" ] }, { "id": "authorise-placement", "name": "Authorise placing on the market or putting into service", "description": "Confirm technical documentation, human oversight, verification and validation, and conformity evidence before first making available or first use.", "inputs": [ "technical documentation", "V&V reports", "oversight procedure", "conformity evidence" ], "outputs": [ "placement or service authorisation", "declaration of conformity where required" ], "preconditions": [ "Risk class and intended purpose are current; prohibited uses are blocked" ], "effects": [ "Placing-on-market or putting-into-service event time is recorded; the system may be used under its envelope" ], "source_refs": [ "SRC-021" ] }, { "id": "operate-with-human-oversight", "name": "Operate with human oversight", "description": "Run the system inside its operating envelope with designated human interpretation, override and halt paths.", "inputs": [ "input data", "oversight procedure", "operating envelope" ], "outputs": [ "outputs to the environment", "oversight actions", "operation logs" ], "preconditions": [ "Authorised deployer and overseers are in place; access policy permits operation" ], "effects": [ "Outputs are produced under logged oversight; out-of-envelope use is an exception" ], "source_refs": [ "SRC-021", "SRC-023" ] }, { "id": "assess-risk-and-impact", "name": "Assess risk and impact", "description": "Identify harms, treat risks, and perform or update AI system impact assessments and fundamental-rights assessments as required.", "inputs": [ "intended purpose", "foreseeable misuse", "stakeholder set", "existing controls" ], "outputs": [ "risk management file", "impact assessment" ], "preconditions": [ "Intended purpose and affected persons are identified" ], "effects": [ "Residual risk and mitigations are recorded against risk tolerance" ], "source_refs": [ "SRC-021", "SRC-023", "SRC-026" ] }, { "id": "monitor-post-market-performance", "name": "Monitor post-market performance", "description": "Collect experience of use, measure drift and accuracy, and identify corrective or preventive actions, including linkage to incident reports.", "inputs": [ "operation logs", "performance metrics", "incident references", "user feedback" ], "outputs": [ "monitoring findings", "corrective or preventive action requests" ], "preconditions": [ "A post-market monitoring plan exists for systems that require one" ], "effects": [ "Performance evidence is updated; serious incidents can be referenced without absorbing the incident file" ], "source_refs": [ "SRC-021", "SRC-023" ] }, { "id": "assemble-conformity-evidence", "name": "Produce and disclose conformity evidence", "description": "Assemble technical documentation, instructions, logs, declarations and registration data for deployers, competent authorities or the EU database.", "inputs": [ "system record", "current artifacts" ], "outputs": [ "evidence package", "registration payload where required" ], "preconditions": [ "Identity, class and documentation revision are current" ], "effects": [ "An inspectable evidence package exists with integrity protection" ], "source_refs": [ "SRC-021" ] } ], "composition": [ { "target": "WM-SFT-002", "relation": "CHILD", "purpose": "AI System specialises the software-product parent with inference-derived behaviour, autonomy and adaptiveness; non-AI packaging, release and functional semantics stay in the parent.", "required": true, "source_refs": [ "SRC-013", "SRC-014" ] }, { "target": "WM-SFT-004", "relation": "COMPOSE", "purpose": "An AI system uses one or more model artifacts; this model holds the binding (version, role, access mode, upstream provider) and delegates parameters, training provenance and model-level evaluation to the artifact model.", "required": true, "source_refs": [ "SRC-001", "SRC-002", "SRC-018" ] }, { "target": "WM-AI-002", "relation": "COMPOSE", "purpose": "An AI system may expose agent actors; this model records their existence, autonomy envelope and containment controls while agent goals, tools and delegation semantics live in the agent model.", "required": false, "source_refs": [ "SRC-013", "SRC-014" ] }, { "target": "WM-AI-010", "relation": "REFERENCE", "purpose": "An AI incident report names affected AI systems; this model holds detection, awareness time, deadline class and submission linkage, not the report narrative or authority correspondence.", "required": false, "source_refs": [ "SRC-006" ] }, { "target": "Organisation / legal entity model", "relation": "REFERENCE", "purpose": "Provider, deployer, importer, distributor and authorised representative are legal entities resolved by reference; this model stores role assignment and effective period only.", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "target": "Dataset model", "relation": "REFERENCE", "purpose": "Evaluation datasets and operational input sources are referenced by identifier and version; dataset content, collection and labelling remain in the dataset model.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "W3C PROV-O provenance mix-in", "relation": "MIX-IN", "purpose": "Baseline generation, change authorisation, evaluation runs and state transitions are expressed as Entity/Activity/Agent with wasGeneratedBy, used, wasAttributedTo, wasAssociatedWith, startedAtTime and endedAtTime.", "required": true, "source_refs": [ "SRC-015" ] }, { "target": "Regulation (EU) 2024/1689 technical documentation (Annex IV)", "relation": "ALIGN", "purpose": "Findings are mapped to the nine Annex IV documentation points as an alignment; no conformance is claimed and mapping gaps are recorded rather than asserted as satisfied.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "Regulation (EU) 2024/1689 EU database registration (Annex VIII)", "relation": "ALIGN", "purpose": "Registration data elements are aligned to Sections A, B and C so a projection can populate a public entry without redefining the fields locally.", "required": false, "source_refs": [ "SRC-003" ] }, { "target": "NIST AI RMF 1.0 (AI 100-1)", "relation": "ALIGN", "purpose": "Trustworthiness characteristics and the GOVERN/MAP/MEASURE/MANAGE functions are used as an evaluation and governance vocabulary; the framework is voluntary and creates no conformance obligation.", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] }, { "target": "NIST AI 100-2 E2025 adversarial ML taxonomy", "relation": "ALIGN", "purpose": "The threat-class mapping data element draws its controlled vocabulary from the evasion, poisoning, privacy and abuse taxonomy and its lifecycle stages of attack.", "required": false, "source_refs": [ "SRC-012" ] }, { "target": "ECMA-424 CycloneDX Bill of Materials Specification", "relation": "ALIGN", "purpose": "The component inventory finding projects to a standard machine-readable BOM rather than defining a private inventory schema.", "required": false, "source_refs": [ "SRC-017", "SRC-018" ] }, { "target": "ISO/IEC 42001:2023 AI management system", "relation": "ALIGN", "purpose": "Organisation-level AI policy, impact assessment and supplier controls are supplied by the management system; this model consumes them by reference and does not restate management-system clauses.", "required": false, "source_refs": [ "SRC-019" ] }, { "target": "Sectoral device lifecycle regime (FDA PCCP)", "relation": "EXTEND", "purpose": "Where the AI system is a device software function, the change-control finding extends to carry a pre-authorised Description of Modifications, Modification Protocol and Impact Assessment.", "required": false, "source_refs": [ "SRC-020" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "The adopting Dimension must name a single accountable owner package for WM-AI-001 that holds the system-of-record for system master identifiers and resolves collisions between provider-internal and public registry identifiers.", "The owner package must declare, per jurisdiction, which regulatory regime instance applies and which authority is the competent recipient for registration and incident reporting, because obligation sets are jurisdiction-bound.", "The owner package must publish the controlled vocabularies it governs (risk class, autonomy level, adaptiveness mode, lifecycle stage, market status, threat class, deadline class) with versioning and deprecation rules.", "The owner package must define the split of custody between provider-held and deployer-held records, including who retains logs and for how long, before any instance record is created." ], "namespace_guidance": "Use a stable namespace of the form /ai-system/ for the aggregate and <...>/ai-system// for version-scoped artifacts. Never mint identifiers from trade names, dates or deployment hostnames. External identifiers (public registration entry, certificate number, notified body number) are stored as typed aliases with their issuing authority, not merged into the local key space.", "registry_links": [ "vr.wm-ai-001 is the registry entry of record; nav path NAV.INF.AI.SYS and domain tag INF.AI.SYS are the navigational keys.", "Typed edges to WM-SFT-004, WM-AI-002, WM-AI-010 and WM-SFT-002 are maintained in planning/VERCY-MODEL-RELATIONS.csv and must be resolvable before an instance is published.", "Alignment links to external standards are held as references with version and access date, never as embedded copies of standard text." ] }, "canon_and_patch": { "canonicalization_rules": [ "Canonical form is the format-neutral record graph: bundles, layers, findings, questions, data elements and artifacts with stable lower-kebab-case local IDs. JSON, YAML, Markdown, HTML, Git trees, MCP resources and MongoDB documents are projections and must round-trip to the same graph.", "Property order, whitespace and container syntax are not semantic. Integrity digests are computed over a canonical serialisation with sorted keys, normalised Unicode (NFC) and RFC 3339 timestamps normalised to an explicit offset.", "Controlled-vocabulary values are stored as codes plus the vocabulary version that issued them; display labels are presentation, not canon.", "Empty, absent and 'not applicable' are distinct: absence means unasserted, an explicit not-applicable value means asserted-as-inapplicable with a reason." ], "patch_rules": [ "Every change to a published record is expressed as an additive patch carrying the actor, the authorising role, the reason, the event time and the record time; in-place mutation without a patch record is prohibited.", "Patches that alter intended purpose, risk classification, autonomy or adaptiveness, bound model artifacts, or human oversight measures must reference a change-control decision and are refused without one.", "Correcting an erroneous prior assertion produces a superseding assertion plus a retraction marker; the erroneous value stays retrievable for audit.", "Log entries, evaluation reports, registration submissions and incident submissions are append-only; they are corrected by a new serial entry, never by editing an existing one." ], "compatibility_rules": [ "Adding a finding, question, data element or optional artifact is a minor change. Removing one, tightening cardinality, changing a value_kind, or narrowing a controlled vocabulary is a breaking change requiring a major version and a migration note.", "Local IDs are permanent once published; renaming produces a new ID plus an alias edge to the retired one.", "Alignment targets may change version without breaking this model, but a mapping that no longer resolves must be demoted to a recorded gap rather than silently dropped.", "Consumers must ignore unknown properties and must not infer meaning from ordering." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the system of record that owns the AI system record — for example the provider's product or system register key; this is always the primary key.", "Governed global identifier or IRI issued by a recognised authority — for example a public AI database registration entry identifier, a notified-body certificate number, or a namespaced IRI — carried as a typed alias with its issuing authority.", "UUID or ULID minted by the adopting Dimension, used only when neither of the above exists; it must be recorded as Dimension-assigned so it is never mistaken for an external identifier.", "Content digests of a canonical serialisation may disambiguate re-issued artifacts but never serve as the primary identifier.", "A date, a version label, a trade name or a hostname is not an identifier and must not be used as a key." ], "timestamp_rule": "All time values are recorded as RFC 3339 date-time with explicit seconds and an explicit numeric UTC offset or 'Z'; '-00:00' is used only where UTC is known but the local offset is genuinely unknown. Event time (when the occurrence happened, such as the start and end of a period of use, or the moment an operator became aware of a serious incident) is recorded separately from observation or ingestion time (when the platform observed, received or wrote the record), and both are stored whenever they differ; deadline arithmetic runs from the recorded awareness event time, never from ingestion time.", "serial_naming_rule": "Serial artifacts are named // and, where the artifact is version-scoped, ///. The sequence is issued by the owning system of record, is gap-free within a stream, and is never derived from a timestamp; the effective time is a separate field.", "integrity_rule": "Every artifact carries a digest over its canonical serialisation, the identifier of the generating activity and the responsible agent, expressed as PROV Entity/Activity/Agent. Append-only artifacts (logs, evaluation reports, registration and incident submissions) additionally carry tamper-evident chaining so that deletion or reordering is detectable; a broken chain invalidates the assurance claims that rest on it and must be raised as a validation failure, not repaired silently." }, "policies": [ "No conformance to any external standard or regulation is asserted by this model. Alignments are mappings only; a conformance claim requires an assessment record with an assessor, scope, date and result, and absent that record the status is 'aligned, unassessed'.", "Regulatory obligations are jurisdiction-scoped. An instance must not inherit an obligation set from the model defaults; the applicable regime is resolved per market jurisdiction and recorded, and where no regime applies the instance is marked 'no statutory regime identified' rather than left blank.", "Provider-held and deployer-held records are governed separately. A deployer record must not overwrite provider assertions; conflicting assertions are held side by side with their asserting role until reconciled by the accountable owner.", "Personal data appearing in logs, inputs or incident records is minimised at capture, and retention is set by the longest applicable statutory basis; deletion must preserve a non-personal audit residue sufficient to prove the deletion occurred.", "Any change to intended purpose, risk classification, bound model artifacts, autonomy or human oversight is treated as potentially substantial and requires an explicit change-control decision before the new baseline may be released.", "External standards and laws are alignments; do not claim conformance without stored evidence.", "Separate the AI system record from model artifacts, agent actors and incident files.", "Default-deny access to technical documentation, logs and impact assessments except for accountable operators, designated overseers and competent authorities.", "Do not operate outside the current intended-purpose and risk-class envelope; out-of-envelope use is an exception requiring a decision record.", "Preserve documentation and logs for the applicable keep-until time, including the ten-year high-risk documentation duty where Regulation (EU) 2024/1689 applies." ], "crud": { "read": [ "Resolve an AI system by master identifier or by a typed alias (registration entry, certificate number) and return its current baseline, classification and lifecycle state.", "Retrieve the full documentation set for a given baseline: identity, purpose, composition, oversight, metrics, evidence, conformity and monitoring plan.", "Query systems by risk class, market jurisdiction, market status, bound model artifact or open incident state.", "Reconstruct the state of a system as at a given event time from the append-only transition, log and patch records." ], "create": [ "Register a new AI system record and mint or bind its master identifier.", "Declare a new configuration baseline with its component manifest and integrity evidence.", "Open an evaluation run, a change request, an impact assessment or an incident case against a system.", "Create a registration submission and record the resulting external entry identifier." ], "update": [ "Amend intended purpose, classification, oversight measures or bound model artifacts through an authorised change-control patch.", "Update market status, lifecycle stage and registration currency, recording authoriser, event time and record time.", "Attach new evaluation, monitoring or incident evidence to an existing system or baseline.", "Record residual risk acceptance, certificate renewal or expiry, and alignment mapping revisions." ], "delete": [ "Logical deletion only: a system record is withdrawn and given a terminal status; it is never removed while any retention obligation is live.", "Personal data within logs and derived stores may be erased or minimised on a documented legal basis, leaving a deletion record that names the store, technique, executor and time.", "Erroneous assertions are retracted by superseding records, not deleted.", "Physical destruction of records is permitted only after the longest applicable retention period has expired and is itself recorded in the decommissioning and retention record." ] }, "roles": [ { "name": "Model steward (WM-AI-001)", "responsibilities": [ "Maintain the model structure, controlled vocabularies and alignment mappings", "Adjudicate boundary disputes with WM-SFT-004, WM-AI-002 and WM-AI-010", "Approve breaking changes and publish migration notes" ] }, { "name": "Accountable provider owner", "responsibilities": [ "Own the system master identifier, intended purpose and classification determination", "Keep technical documentation, declarations and registration entries current", "Authorise baselines and substantial modifications" ] }, { "name": "Deployment and oversight lead", "responsibilities": [ "Assign competent human oversight and maintain intervention mechanisms", "Ensure input data relevance and monitor operation against declared metrics", "Suspend use and notify the provider and authorities when risk emerges" ] }, { "name": "Assurance and conformity officer", "responsibilities": [ "Maintain evaluation evidence, risk management file and impact assessments", "Manage conformity assessment, certificates and standards-applied records", "Record conformance claims only where an assessment record exists" ] }, { "name": "Records and retention custodian", "responsibilities": [ "Operate append-only log, evidence and submission stores with integrity chaining", "Apply retention schedules and execute documented deletion or minimisation", "Preserve auditability across decommissioning" ] }, { "name": "Incident reporting officer", "responsibilities": [ "Determine awareness time and applicable deadline class", "Submit reports to the competent authority and track acknowledgement", "Drive investigation, causal analysis and corrective action to closure" ] } ], "access": { "default_rule": "Deny by default. Read and write are granted per scope to named roles against a stated purpose; every grant is time-bounded, attributable to a person or service identity, and recorded. Personal data in logs, inputs and incident records is additionally purpose-limited and is not readable under a general system-read grant.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Competent authorities receive access to technical documentation, logs and incident material on a reasoned request; the grant is recorded with the requesting authority, legal basis, scope and period.", "Public registration fields are openly readable by design; electronic instructions for use are withheld from the public entry for law enforcement, migration, asylum and border-control use cases while remaining available to authorities.", "Deployers receive read access to instructions for use, declared metrics, limitations and oversight requirements without access to provider trade-secret design material.", "Emergency containment permits an on-call operator to suspend a system and read the minimum runtime state needed to do so, with retrospective authorisation required within a defined window.", "Security researchers and internal red teams may be granted scoped, time-boxed access to threat-model and adversarial-test artifacts under confidentiality terms.", "Market surveillance and other competent authorities may access technical documentation, logs and declarations for the keep-until period", "Serious-incident investigation may open otherwise restricted artifacts through the WM-AI-010 linkage", "Regulatory sandbox or real-world-testing supervisors may access plans and monitoring data under the agreed plan", "Whistleblowing and fundamental-rights authorities may access impact assessments as provided by applicable law" ], "audit_requirements": [ "Every read of personal data or of restricted assurance artifacts is logged with actor identity, purpose, scope, event time and record time.", "Every access grant, extension and revocation is recorded with the authorising role and the basis.", "Access logs are held under the same integrity chaining and retention rules as operational logs and are reviewed on a defined cadence.", "Authority disclosures are recorded as a distinct event class so the full set of external disclosures for a system is retrievable.", "Failed and denied access attempts against restricted scopes are retained and surfaced to the security event response path.", "Record actor, scope, artifact identifier, event time and ingestion time for every read or write of restricted artifacts", "Audit changes to identity, intended purpose, risk class, oversight mode and exit mode", "Retain access audit logs at least as long as the documentation they protect" ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID and registry ID", "Owner and accountable contact", "Controlled vocabulary index URL", "Alignment and conflict register URL" ], "read_order": [ "AGENTS.md — resolve Name, Type, Specification URL, Storage type URL, Interface URL and Processes URL before any other action.", "Specification URL — load the format-neutral model definition: bundles, layers, findings, questions, data elements and artifact rules.", "Storage type URL — learn the concrete projection in use (JSON, YAML, Markdown, HTML, Git, MCP or MongoDB) and its canonicalisation and patch conventions.", "Interface URL — learn the read, create, update and delete operations, authentication and access scopes actually exposed.", "Processes URL — learn the governed workflows: baseline release, change authorisation, registration, evaluation, incident reporting and decommissioning.", "Controlled vocabulary index and alignment/conflict register — resolve codes and check recorded conflicts before asserting any classification or conformance." ] } }, "coverage": { "claim": "Claude's structure, extended with three Grok classification findings and five Grok operating functions, covers the governed AI system as an accountable aggregate: identity and configuration baseline, declared purpose and misuse envelope, definitional admission, socio-technical and regulatory classification, composition and supply chain, operator roles, lifecycle and change control, deployment placement, runtime logging and state, human oversight, performance and evaluation evidence, adversarial security, conformity and public registration, transparency and content marking, risk and impact assessment, post-market monitoring, serious-incident reporting and retirement. Evidence base spans the EU AI Act, OECD definition and classification framework, NIST AI RMF and adversarial-ML taxonomy, ISO/IEC SC 42 catalogue entries, CoE CETS 225, PROV-O, RFC 3339 and CycloneDX. This is a defensible working draft, not a complete account: sector overlays, non-EU regimes, AI literacy duties, sandbox and real-world-testing regimes, documentation escrow on provider cessation and energy footprint remain unmodelled and are named as such.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Master-system identifier first, governed external identifiers as typed aliases, Dimension-minted UUID/ULID last; trade name, provider identification reference and registry entry identifiers are separated. Explicit rule that dates, versions and hostnames are not identifiers." }, { "dimension": "lifecycle", "status": "covered", "notes": "Lifecycle stage and market status modelled separately, with an append-only transition log, stage gates, change classification (routine/pre-authorised/substantial) and a decommissioning terminal state." }, { "dimension": "relationships", "status": "covered", "notes": "Typed edges to model artifact, agent, incident report and software parent; operator-role assignment to legal entities; integration interfaces to external systems; upstream/downstream provider chain." }, { "dimension": "temporal", "status": "covered", "notes": "RFC 3339 with seconds and explicit offset; event time separated from observation/ingestion time; awareness time drives incident deadline arithmetic; baseline effective-from and supersession recorded." }, { "dimension": "provenance", "status": "covered", "notes": "PROV-O mix-in over baselines, change authorisations, evaluations and transitions; build and signing attestation on baselines; BOM records supplier and origin per component." }, { "dimension": "ownership", "status": "covered", "notes": "Provider, deployer, importer, distributor and authorised representative roles with effective periods, plus the trigger conditions under which a deployer assumes provider obligations." }, { "dimension": "validation", "status": "covered", "notes": "Evaluation runs, acceptance criteria, failure disposition, countersigned test reports, standards-applied with equivalence justification, and a policy that conformance is unasserted without an assessment record." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default across bundle, layer, finding and artifact scopes, with authority-disclosure, public-registration, deployer, emergency-containment and red-team exceptions, all audited." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention per record class with legal basis and a prescribed minimum for deployer-held logs; logical deletion only while obligations are live; deletion records preserve non-personal audit residue." }, { "dimension": "interoperability", "status": "covered", "notes": "BOM projection to a standard inventory format, registration projection to the public database field set, machine-readable marking of synthetic output, PROV-O alignment and format-neutral canonical graph." }, { "dimension": "classification", "status": "covered", "notes": "Regulatory route, derogation conditions, profiling exception, plus a behavioural classification (autonomy, adaptiveness, output type, environmental reach) that decides whether the object is an AI system at all." }, { "dimension": "security", "status": "covered", "notes": "Control set plus explicit adversarial threat-class mapping (evasion, poisoning, privacy, abuse) with resilience test results and an AI-specific event response path distinct from infrastructure incident handling." }, { "dimension": "measurement and evaluation", "status": "covered", "notes": "Metric appropriateness justification, declared values with conditions and subgroup scope, degradation conditions, recomputation cadence and reference period." }, { "dimension": "human oversight", "status": "covered", "notes": "Provider-built versus deployer-implemented split, assignee competence and authority, intervention mechanism with time-to-effect, and automation-bias mitigation." }, { "dimension": "transparency to affected persons", "status": "covered", "notes": "Interaction disclosure with timing, machine-readable marking of synthetic content, exemption basis with compensating safeguards, and accessibility of the notice." }, { "dimension": "environmental and energy footprint", "status": "gap", "notes": "Compute and energy consumption of training and inference are not modelled. No fully verified primary requirement was retrieved for system-level (as opposed to general-purpose model) energy reporting, so this is recorded as a gap rather than asserted as structure." }, { "dimension": "cost and commercial terms", "status": "not-applicable", "notes": "Pricing, procurement and contractual commercials belong to a commercial model; only licence and permitted-use constraints on bound components are retained here." } ], "known_omissions": [ "Sources SRC-014 (OECD explanatory memorandum), SRC-019 (ISO/IEC 42001:2023) and SRC-020 (FDA PCCP final guidance) could not be retrieved in full text during this research: SRC-014 and SRC-019 returned HTTP 403 and SRC-020 returned HTTP 404 on direct fetch. Their titles, identifiers and dates were confirmed via publisher catalogue and site-restricted search metadata. No structural node depends on these three alone.", "ISO/IEC 22989 (AI concepts and terminology), ISO/IEC 5338 (AI system life cycle processes), ISO/IEC 23894 (AI risk management) and ISO/IEC 42005 (AI system impact assessment) are paywalled and were not consulted. Terminology here therefore follows the OECD and EU definitions, which may diverge from SC 42 vocabulary in places.", "General-purpose AI model obligations (systemic-risk thresholds, model documentation to downstream providers, training-content summaries, codes of practice) are deliberately excluded: they attach to the model, not the system, and belong to WM-SFT-004.", "Energy, compute and environmental footprint reporting is not modelled.", "Conformity assessment procedure detail, notified-body designation and market-surveillance procedural law are referenced but not decomposed.", "Sector-specific overlays beyond the medical-device change-control example (financial services, employment, education, critical infrastructure, law enforcement) are not enumerated.", "Accessibility requirements are referenced only where transparency obligations invoke them; a full accessibility conformance surface is not modelled.", "Human-subject research ethics, worker consultation procedure and collective bargaining interfaces are out of scope.", "Full ISO/IEC 42001 Annex A control catalogue and exact control numbering are not reproduced because the paid standard text was not used as a primary extract; secondary numbering of Annex A domains conflicts and is treated as a gap.", "ISO/IEC 22989 full clause text for AI system 3.1.4 and human-in/on/over-the-loop definitions remains paywalled; the model uses official scope, preview terms and EU Art. 14 documentation requirements.", "Sector overlays such as medical-device AI, aviation, automotive UNECE WP.29 and financial-services model risk are not expanded.", "People's Republic of China generative-AI and algorithm-filing rules, Canada's AIDA, and other non-EU national bills are not modelled as classes.", "AI software bill of materials formats (SPDX, CycloneDX) and the draft ISO/IEC 24970 logging standard are emerging and not treated as canonical.", "Compute, energy and environmental footprint are only a People-and-Planet hint, not a measurement model.", "Military and national-defence systems are excluded by CETS 225 and are not given a specialised profile.", "Open-source GPAI exemptions, multi-agent systems of systems, and shadow-AI discovery methods are noted as operating risks rather than fully specified findings." ], "conflicts": [ "Definitional scope: the OECD definition and the EU regulation align on machine-based inference producing predictions, content, recommendations or decisions, but the FDA glossary definition retrieved via secondary reporting frames AI around human-defined objectives and omits the adaptiveness clause. An instance classified as an AI system under one definition may not be under another; the behavioural profile finding records the deciding definition explicitly.", "Model versus system boundary: the regulation treats general-purpose AI models and AI systems as separate objects with separate obligations, but common industry practice documents them together in a single model or system card. This model keeps them separate and links by reference; adopters who merge them will double-count obligations.", "Voluntary versus binding: the NIST AI RMF is explicitly voluntary while the EU regime is binding. Trustworthiness characteristics are used here as an evaluation vocabulary only; using them as evidence of legal conformity would be unsupported.", "Log retention: the deployer-side minimum retrieved is at least six months unless other law applies, while sectoral and data-protection law may require shorter minimisation or longer retention. The retention finding therefore stores a period plus its basis rather than a single global default.", "Registration transparency: registration data are broadly public, but instructions for use are withheld for certain law enforcement and border-control use cases. A single 'public entry' assumption would be wrong; visibility is modelled per field.", "Change control: the horizontal regime treats unforeseen changes as substantial modifications triggering renewed conformity assessment, whereas the sectoral device regime permits pre-authorised modification envelopes. Both are represented; an adopter must state which governs, and the two can produce opposite answers for the same change.", "ISO/IEC 22989:2022 defines an engineered system generating outputs for human-defined objectives, without the OECD/EU/CoE verb infers and without stressing post-deployment adaptiveness in the definition sentence.", "NIST AI RMF 1.0 still uses an older OECD-like definition that omits content as an output type and the infers wording of the 2023 OECD revision.", "Secondary summaries of ISO/IEC 22989 sometimes list seven lifecycle stages and omit continuous validation; the ANSI preview table of contents lists eight stages including continuous validation and re-evaluation.", "The EU AI Act uses a product-safety risk-tier scheme; NIST AI RMF uses contextual, non-tiered risk and must not be treated as equivalent classification.", "A general-purpose AI model is not an AI system; collapsing the two would break Chapter V versus Chapter III duties.", "An ISO/IEC 42001 AIMS is an organisational management system, not the AI system instance it governs.", "Regulation (EU) 2026/1744 (Digital Omnibus on AI) amended some application dates and literacy wording; it did not rewrite the AI system definition used here, but date-sensitive operating calendars must be checked against the consolidated act." ], "regional_assumptions": [ "The regulatory backbone of this model is the EU horizontal regime; findings that assume registration in a public database, CE-style declarations, notified bodies, market surveillance authorities and awareness-triggered incident deadlines are EU-specific and must be re-mapped elsewhere.", "Incident reporting deadline classes (general, accelerated, death) as modelled reflect the EU provisions retrieved; other jurisdictions use different triggers and clocks.", "The medical-device change-control extension reflects US FDA practice and does not generalise to other sectors or regions.", "No Chinese, UK, Japanese, Korean, Canadian, Brazilian or Indian AI regimes were consulted; obligations there are unmodelled.", "Personal-data handling assumes an EU-style controller/processor and impact-assessment framing; jurisdictions with different data-protection architectures will need a different mapping.", "Accessibility and worker-consultation duties assume EU-style requirements.", "The EU AI Act is treated as the most operational legally binding product-safety-style regime for system duties, not as a global law.", "The OECD definition is treated as the intergovernmental alignment hub used by the EU and the Council of Europe.", "NIST AI RMF 1.0 is treated as a voluntary United States-origin framework usable by any organisation, not as a statutory class.", "Council of Europe CETS 225 is treated as a human-rights, democracy and rule-of-law overlay on lifecycle activities, with national defence out of scope.", "ISO/IEC 22989, 42001 and 42005 are treated as international terminology, management-system and impact-assessment alignments that organisations may adopt regardless of jurisdiction." ], "adversarial_checks": [ "Counterexample to the aggregate framing: a deterministic rule engine with no inference step can satisfy most findings here while not being an AI system at all. The autonomy-and-adaptiveness finding forces an explicit inference-boundary answer so such objects are excluded rather than silently admitted.", "Counterexample to identity: an organisation running many tenant instances of one hosted system has one system identity but many runtime instances with different oversight, jurisdictions and logs. The model separates system master identity from instance identifiers and scopes runtime state and deployment placement to instances.", "Counterexample to versioning: a system whose behaviour changes through prompt, retrieval-corpus or policy edits without any code or model change would appear frozen under a code-centric baseline. The baseline manifest explicitly enumerates prompts and policies as components.", "Counterexample to the model/system split: a thin wrapper around a third-party hosted model is largely composed of things it does not control. The model-binding finding captures access mode, upstream provider and change-propagation channel so the accountability gap is visible rather than hidden.", "Counterexample to the documentation-centric reading: treating findings as file types would collapse the model into an Annex IV table of contents. Findings are defined as answerable bodies of context and several (runtime state, autonomy profile, role transfer triggers, log time semantics) have no corresponding statutory document.", "Counterexample to classification stability: a derogation-based non-high-risk determination is defeated by profiling, and a purpose change can flip the class after release. Classification carries an assessment timestamp, a profiling flag and explicit reassessment triggers rather than being a static attribute.", "Counterexample to timestamp handling: deriving an incident reporting deadline from ingestion time rather than awareness time would produce a compliant-looking but wrong deadline. The timestamp rule states that deadline arithmetic runs from recorded awareness event time.", "Rejected structure: a separate 'ethics' or 'responsible AI' bundle was considered and rejected — no retrieved primary source defines it as a distinct governable surface, and its content decomposes without residue into risk management, impact assessment, fairness metrics and transparency, where it is already covered.", "Would a rules-only calculator or OCR pipeline be wrongly admitted as an AI system, or a genuinely inferential system excluded because it is simple?", "Would a GPAI model record be stored here instead of as WM-SFT-004, hiding Chapter V duties?", "Would an agent persona be stored here instead of as WM-AI-002, hiding actor-level controls?", "Would fine-tuning, prompt-level productisation, or putting a third-party system under a new trademark silently fail to trigger provider duties or substantial-modification assessment?", "Would continuous learning after deployment invalidate placement-time assurances without a predetermined-change envelope?", "Would a third-country system whose outputs are used in the Union escape inventory because the provider is not established in the Union?", "Would shadow or unsanctioned deployments exist outside this inventory while still affecting persons?", "Would research, sandbox or personal non-professional use be over- or under-classified as placing on the market or as deployer use?" ] }, "researchAdjudication": { "providerMode": "dual-provider", "activeProviders": [ "claude", "grok" ], "waivedProviders": [], "providerPolicy": {}, "boundaryDecision": { "entry_kind": "aggregate", "status": "accepted", "rationale": "Both providers independently converge on aggregate, and the boundary holds under test: the object of accountability is the composite of model artifacts, software, data interfaces, configuration baseline, operator roles and oversight arrangements taken together, not any single artifact. The four exclusions are drawn on regime lines rather than convenience — model artifact internals to WM-SFT-004 (separate obligation regime for models versus systems), agent actor semantics to WM-AI-002, incident case files to WM-AI-010, and the organisational AI management system to a separate governance model. The admission test is the inference criterion: an object that only executes fully specified rules without inferring how to generate environment-influencing outputs is not admitted, which is enforced by the accepted definition-adoption finding rather than left implicit." }, "decisions": [ { "concept": "Base provider selection", "disposition": "Claude adopted as base", "rationale": "Claude carries seven neighbour boundary notes each with source refs, a 19-item in-scope and 10-item out-of-scope list, and unbroken coverage through transparency, conformity, registration, post-market monitoring, incident reporting and retirement — the surfaces Grok either compresses or omits. Grok's two boundaries the base lacks explicitly (AIMS, GPAI model) are already handled in Claude's out-of-scope list and known omissions, so no boundary completeness is lost by this choice; size was not the deciding factor." }, { "concept": "Entry kind", "disposition": "Aggregate, accepted without reclassification", "rationale": "Both providers independently reached aggregate and both draw the same four exclusions on regime lines rather than convenience, so there is no split, merge or reclassification pressure to resolve before accepting nodes." }, { "concept": "Adopted definition and definitional divergence register", "disposition": "Accepted from Grok as ai-system-definition-adoption", "rationale": "The base claims the deciding definition is recorded but supplies no question that records it; this converts an asserted control into an answerable one and is where the OECD/EU/ISO/NIST wording divergence is stored per instance instead of being claimed as conformance." }, { "concept": "OECD socio-technical classification profile", "disposition": "Accepted from Grok as socio-technical-classification-profile", "rationale": "A named, published multi-dimensional profile (People and Planet, Economic Context, Data and Input, AI Model, Task and Output) that the base does not carry in any form; it supports heightened governance decisions where no legal high-risk class applies, which the base has no place to record." }, { "concept": "GPAI system versus GPAI model flag", "disposition": "Accepted from Grok as gpai-system-boundary", "rationale": "The base names the model/system seam in prose and excludes model-side duties, but never records which side of it this instance sits on or whether it is a downstream integrator, which is the fact that determines a distinct duty set." }, { "concept": "Value chain, third parties and agent surface", "disposition": "Rejected as a node; agent-linkage element deferred", "rationale": "Grok's f-value-chain-third-parties largely restates the base operator-roles finding, including the deployer-becomes-provider trigger. The one non-duplicative element — enumerating linked WM-AI-002 agent records — belongs as a typed edge, not a finding, and is deferred rather than admitted as duplicate structure." }, { "concept": "Provider, deployer and AI literacy measures", "disposition": "Rejected as a node; AI literacy deferred to research", "rationale": "The provider/deployer/accountable-owner content duplicates the base accountability finding. AI literacy is a genuine base omission but importing the whole Grok finding to carry it would create a second roles finding; it is deferred for targeted evidence work instead." }, { "concept": "Trustworthiness, performance and security as one finding", "disposition": "Rejected in favour of the base three-way split", "rationale": "The base separates declared metrics, evaluation evidence and adversarial security, which keeps a NIST voluntary vocabulary from being read as conformity evidence and preserves the distinct adversarial threat-class mapping backed by NIST AI 100-2. Grok's single finding would merge those regimes back together." }, { "concept": "Access, retention, deletion and interoperability as one finding", "disposition": "Rejected as a node; provider-cessation escrow deferred", "rationale": "Access, retention and interoperability are each already carried in the base across logging, registration visibility, retention and BOM/marking findings. The one absent element — documentation escrow or keep-until arrangements if the provider ceases activity — is deferred rather than imported inside a mostly duplicative node." }, { "concept": "Recall, withdrawal and retirement", "disposition": "Rejected as duplicative of base record-retention-and-decommissioning", "rationale": "The base already distinguishes withdrawal, recall, decommissioning, personal-data deletion and terminal status, and stores retention as period-plus-basis rather than a single global default. Grok's ten-year documentation figure is treated as a verification input to that basis field, not as a competing node." }, { "concept": "Model and component composition; data, input and runtime interfaces", "disposition": "Both rejected as duplicative", "rationale": "The base covers these through component-inventory-and-ai-bom, model-artifact-binding, input-data-dependencies-and-governance and deployment-environment-and-jurisdictional-placement. Grok's placement-forms element (embedded, download, API) is a value for the base deployment questions, and its training-data provenance content correctly belongs to WM-SFT-004 under the accepted boundary." }, { "concept": "Sandbox and real-world testing lifecycle states", "disposition": "Node rejected; element deferred", "rationale": "Grok's f-lifecycle-state is highly similar to the base lifecycle finding, but the base has no way to record that a system is in a regulatory sandbox or real-world testing regime that does not itself constitute placing on the market — a distinction that changes which duties attach. Deferred to decide state-value versus separate finding." }, { "concept": "Grok-only bundle for roles, ownership and human oversight", "disposition": "Not adopted as a bundle", "rationale": "The base already places operator roles under composition and supply chain and human oversight under operation, oversight and assurance. Adopting a third top-level bundle would split those surfaces without adding evidence." }, { "concept": "Source-set reconciliation for the merged draft", "disposition": "EUR-Lex consolidated act promoted to canonical AI Act citation", "rationale": "The base cites the AI Act through the Commission's Service Desk article and annex pages while Grok cites the consolidated EUR-Lex text with an explicit consolidation date. The consolidated act is the authoritative version; Service Desk pages are retained as convenience references. The three accepted additions cite Grok source IDs absent from the base source list, so OECD SRC-003, ISO/IEC 22989 and CETS 225 must be admitted and remapped before the additions can carry evidence." }, { "concept": "Separate ethics or responsible-AI bundle", "disposition": "Rejected, endorsing the base's own rejection", "rationale": "No retrieved primary source defines it as a distinct governable surface, and its content decomposes without residue into risk management, impact assessment, fairness metrics and transparency, all already present." }, { "concept": "Blocking status of recorded conflicts", "disposition": "No critical conflicts declared", "rationale": "Every contradiction the providers surfaced is either resolved by design (definitional divergence recorded per instance, NIST used as vocabulary only, retention stored as period plus basis, registration visibility modelled per field, horizontal versus sectoral change control both represented) or is a source and live-version question, which the rules route to publication holds rather than to blocking conflicts." } ], "publicationHolds": [ "Source verification: re-fetch and pin every accepted source to a live URL with an explicit version or consolidation date before publication. Reconcile the base's AI Act Service Desk article and annex citations against the EUR-Lex consolidated text (consolidated 2026-07-27) so article and annex references in the merged draft point at the authoritative version.", "Live-version check: Grok records that Regulation (EU) 2026/1744 (Digital Omnibus on AI) amended application dates and AI-literacy wording without rewriting the AI system definition. Confirm the effect on every date-sensitive construct in the merged draft — incident reporting deadline classes, registration duties, retention periods and change-control triggers — before publishing.", "Unretrieved evidence: the base could not fetch SRC-014 (OECD explanatory memorandum, HTTP 403), SRC-019 (ISO/IEC 42001, HTTP 403) or SRC-020 (FDA PCCP, HTTP 404) in full text, and Grok's ISO/IEC 22989, 42001 and 42005 citations are paywalled catalogue pages. Confirm that no node — including the three accepted additions — depends solely on unretrieved text, and mark any that do.", "New-source admission: the accepted additions cite OECD Framework for the Classification of AI Systems, ISO/IEC 22989 and CoE CETS 225, which are not in the base source list. These must be fetched, pinned and remapped into the base source namespace before the additions carry evidence; do not publish additions with dangling source references.", "Multi-profile validation: exercise the merged model against at least four distinct instance profiles — an Annex III high-risk deployment, a transparency-only generative system, an AI system embedded as a safety component of a regulated product, and a third-country provider whose outputs are used in the Union — plus one negative case (a deterministic rule engine) that the definition-adoption finding must exclude." ], "deferredResearch": [ "AI literacy obligations (EU AI Act Art. 4, as amended): the base has no coverage at all. Determine from the consolidated act whether literacy measures attach to the AI system record or to the organisation-level AI management system, then site them accordingly rather than importing Grok's roles finding wholesale.", "Regulatory sandbox and real-world testing regimes: decide whether 'in sandbox' and 'in real-world testing, not placed on the market' are lifecycle state values in lifecycle-state-and-transitions or warrant a separate finding, and pin the governing articles.", "Documentation escrow and keep-until on provider cessation or insolvency, including authorised-representative and Member State arrangements — absent from the base retention and decommissioning finding.", "Agent-surface linkage: whether WM-AI-001 should carry an explicit question enumerating linked WM-AI-002 agent records as typed edges, without importing agent semantics.", "Energy, compute and environmental footprint: both providers record this as a gap. Search for a primary system-level (not general-purpose-model-level) reporting requirement; if none is found, keep it as a declared gap rather than asserting structure.", "Non-EU regimes and the CoE CETS 225 overlay: UK, China generative-AI and algorithm filing, Canada AIDA, Korea, Japan, Brazil and India are unmodelled, and CETS 225 is present in Grok's evidence but carries no accepted structure in the merged draft.", "Sector overlays beyond the medical-device change-control example already in the base: financial services model risk, aviation, automotive UNECE WP.29, employment, education, law enforcement and critical infrastructure." ] }, "statistics": { "sources": 26, "bundles": 6, "layers": 16, "findings": 29, "questions": 113, "artifacts": 29, "functions": 15 } }