{ "dataset": { "meta": { "domain": "knowledge", "domain_slug": "knowledge", "domain_number": 11, "title": "Apeiris Knowledge Control Matrix", "description": "Apeiris Knowledge Control Matrix: 49 machine-readable controls across 6 layers.", "version": "1.2.0", "published": "2026-07-02", "layers": 6, "controls_count": 49, "baseline_controls": [ "KS-01", "KS-08", "KI-01", "KI-08", "KR-01", "KR-08", "KC-01", "KC-08", "KM-01" ], "canonical_prefix": "apeiris://knowledge/controls/", "attestation_artifact": "KnowledgeAttestation", "attestation_control": "KG-08", "alias_domain": "knowledgeverifier.ai", "frameworks": [ "anthropic_transparency", "aws_bedrock_kb", "c2pa", "dama_dmbok", "databricks_unity", "eu_ai_act", "google_vertex_rag", "iso_27002", "iso_30401", "iso_42001", "itil_4", "microsoft_azure_ai", "openai_transparency", "openlineage", "w3c_prov" ], "lenses": [ "legal_counsel", "data_scientist", "grc_auditor", "it_operations", "knowledge_engineer" ], "license": "CC BY 4.0", "source": "https://apeiris.ai/domains/knowledge/", "integration_endpoint": "https://apeiris.ai/integration/domains/knowledge-controls-full.json", "source_freshness": { "status": "current", "checked_on": "2026-07-02", "review_cadence": "quarterly" }, "baseline_control_count": 9, "generated_at": "2026-07-02T00:00:00.000Z", "subtitle": "apeiris.ai/domains/knowledge \u2014 Apeiris Knowledge", "site": "https://apeiris.ai/domains/knowledge", "corpus_url": "https://apeiris.ai/integration/domains/knowledge-controls-full.json", "schema_version": "1.1.0", "schema_extended_on": "2026-06-29", "extended_schema_fields": [ "validation_objective", "evidence_required", "machine_tests", "human_review", "blocking_effect", "normative_status", "anti_patterns", "update_status" ] }, "controls": [ { "id": "KS-01", "layer": "KS", "plane": "control", "name": "Knowledge Source Authorization Register", "plain": "Every knowledge source permitted for AI retrieval must have an authoritative register entry recording its owner, license, authority rating, access credentials reference, and lifecycle status before any AI system may query it.", "threat": { "tags": [ "unauthorized-source-access", "license-violation", "shadow-knowledge-base" ], "desc": "Without a centralized authorization register, AI systems accumulate connections to unvetted external sources. Unlicensed or deprecated sources introduce copyright liability and inaccurate outputs. Attackers who inject rogue sources into untracked retrieval pipelines gain persistent influence over AI responses with no governance visibility." }, "standard": [ { "id": "iso_42001", "section": "\u00a76.1.2", "title": "AI risk assessment" }, { "id": "dama_dmbok", "section": "Ch. 3", "title": "Data Governance \u2014 asset inventory and stewardship" }, { "id": "iso_30401", "section": "\u00a74.4.2", "title": "Knowledge development \u2014 acquiring new knowledge" }, { "id": "eu_ai_act", "section": "Art. 10(3)", "title": "Training and validation data governance requirements" } ], "sources": [ { "id": "aws_bedrock_knowledge_bases_2024", "title": "Amazon Bedrock Knowledge Bases", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_knowledge_bases_2024", "relationship": "informative_reference", "rationale": "Establishes Amazon Bedrock Knowledge Bases requirements informing the apeiris://knowledge/controls/KS-01 Knowledge Source Authorization Register control.", "reviewed_on": "2026-07-01" }, { "id": "c2pa_spec_2_1", "title": "C2PA \u2014 Coalition for Content Provenance and Authenticity Technical Specification 2.1", "authority": "Coalition for Content Provenance and Authenticity (C2PA)", "source_type": "standard", "normative_force": "best-practice", "version": "2.1", "published_on": "2024-09-20", "retrieved_on": "2026-06-29", "canonical_url": "https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html", "license": "open-access", "status": "current", "flagship": false, "source_id": "c2pa_spec_2_1", "relationship": "informative_reference", "rationale": "Establishes C2PA \u2014 Coalition for Content Provenance and Authenticity Technical Specification 2.1 requirements informing the apeiris://knowledge/controls/KS-01 Knowledge Source Authorization Register control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Append-only source register with version-controlled entries; each entry includes source URI, owner, license type, authority rating, access credentials reference, first-indexed date, and lifecycle status (active/suspended/retired).", "steps": [ "Deploy an append-only source register backed by a version-controlled data store with full audit trail.", "Integrate the register into RAG pipeline configuration so retrieval connectors are blocked from querying any source URI not present as an active register entry.", "Assign each register entry an authority rating (primary/secondary/tertiary) and a license classification at onboarding time.", "Schedule quarterly reconciliation reviews to confirm active sources remain licensed, accessible, and within authorized scope." ], "knowledge_engineer": { "summary": "The authorization register is the single source of truth for all knowledge sources the AI may consult. Build it before onboarding any source and enforce it as a hard gate in the retrieval pipeline.", "actions": [ "Create and maintain the source register schema covering URI, owner, license, authority rating, and lifecycle status.", "Block retrieval pipeline connectors from querying any unregistered source URI at the connector resolution layer.", "Automate register completeness checks in the deployment pipeline as a build gate." ], "failure_signals": [ "Register completeness rate below 100% of active retrieval connectors.", "Any active connector references a source URI not present in the register.", "Reconciliation gaps not resolved within 30 days." ] }, "data_scientist": { "summary": "Every corpus your retrieval models query must trace to an active register entry. Unregistered sources contaminate evaluation baselines and make retrieval-quality regressions impossible to attribute to a governed source.", "actions": [ "Join retrieval logs against the register to confirm every queried source URI resolves to an active entry before building evaluation sets.", "Carry register metadata (authority rating, lifecycle status) into retrieval evaluation and error analysis so quality issues can be traced to specific sources.", "Route any new corpus proposed for an experiment through register onboarding before it is indexed for evaluation runs." ], "failure_signals": [ "Evaluation sets contain documents whose source URI has no active register entry.", "A relevance regression traces to a source that was onboarded without an authority rating or license classification." ] }, "it_operations": { "summary": "The register is enforced in pipeline configuration: retrieval connectors must fail closed for any source URI not present as an active register entry, and credential references must resolve through the managed secrets store.", "actions": [ "Wire connector configuration to the register so activating an unregistered or suspended source fails closed.", "Audit and rotate the access credentials referenced by register entries on the platform rotation schedule.", "Alert when production retrieval traffic touches a source whose register entry is suspended or retired." ], "failure_signals": [ "A production connector serves queries against a source that is absent from the register.", "Register entries hold credential references that no longer resolve in the secrets manager." ] }, "grc_auditor": { "summary": "The source register is the primary artifact for demonstrating AI knowledge governance. It must be complete, versioned, and reconcilable against deployed connectors.", "actions": [ "Request a full register export and cross-reference against active retrieval pipeline connector configurations.", "Sample 15% of register entries and verify license documentation is on file.", "Confirm that no connector queries a source absent from the register." ], "metrics": [ "Register completeness rate: target 100% of active connectors covered.", "License documentation coverage: target 100% of active entries.", "Mean time to register a new source: target \u22645 business days." ], "failure_signals": [ "Any unregistered source found in active retrieval connector configuration.", "License documentation missing for more than 2% of active entries.", "New sources in production without a register entry for more than 5 business days." ] }, "legal_counsel": { "summary": "The register documents license and usage rights for every knowledge source, providing the evidentiary basis for copyright compliance and contractual obligations.", "actions": [ "Review license classifications assigned to each source category and confirm they align with permitted AI retrieval and generation uses.", "Flag sources with ambiguous or restrictive licenses for legal review before activation.", "Ensure attribution requirements embedded in source licenses are captured in the register and propagated to KS-07." ], "failure_signals": [ "Sources with restrictive or ambiguous licenses activated without legal sign-off.", "Attribution requirements not captured for licensed sources.", "Register entries lacking license type classification." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises have no formal inventory of knowledge sources permitted for AI retrieval; connectors accumulate without governance." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Knowledge Engineering Team", "Platform Engineering", "Legal / IP Counsel" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a76.1.2", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a76.1.2 requires organizations to establish and apply an AI risk assessment process that identifies risks associated with AI systems and their inputs. A source authorization register gives that assessment a complete, governed inventory of the knowledge sources in scope \u2014 without it, organizations cannot demonstrate that AI retrieval is bounded to authorized content.", "normative_force": "certification-standard", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 3", "fit": "direct", "rationale": "DAMA-DMBOK 2nd edition Chapter 3 (Data Governance) establishes data asset inventories and stewardship as foundational governance practices, requiring each asset to have an accountable owner and documented metadata. Applied to AI knowledge sources, the source authorization register operationalizes this stewardship model for retrieval systems.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10(3)", "fit": "partial", "rationale": "EU AI Act Art. 10(3) requires high-risk AI systems to use training and validation data that is governed, relevant, and representative. A source authorization register provides the documented governance record required to demonstrate compliance with this data source control provision.", "normative_force": "binding-law", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_30401", "requirement_id": "\u00a74.4.2", "fit": "direct", "rationale": "ISO 30401:2018 \u00a74.4.2 requires the knowledge management system to cover knowledge development activities, including acquiring new knowledge from identified sources. Registering and authorizing knowledge sources is the AI-specific implementation of governed knowledge acquisition.", "normative_force": "certification-standard", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_bedrock_kb", "requirement_id": "Knowledge Base data source configuration", "fit": "adjacent", "rationale": "Amazon Bedrock Knowledge Bases enforces explicit data source configuration as a prerequisite to any retrieval, requiring organizations to formally declare permitted sources before connectors can be activated. This platform control directly maps to the authorization register pattern defined in this control.", "normative_force": "best-practice", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "c2pa", "requirement_id": "Content Credentials (C2PA manifests)", "fit": "direct", "rationale": "C2PA Content Credentials provide cryptographic provenance attestation for content via C2PA manifests; the KS-01 authorized source register should capture C2PA manifests where content provenance verification is required.", "normative_force": "best-practice", "source_version": "2.1", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KS-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every knowledge source URI queried by any AI retrieval connector must have a corresponding active entry in the source authorization register with owner, license_type, authority_rating, credentials_reference, and lifecycle_status fields fully populated. No retrieval connector may be active for a source URI absent from the register.", "evidence_required": [ "source_authorization_register_export listing all active connector source URIs with owner, license_type, authority_rating, credentials_reference, lifecycle_status, and first_indexed_date fields populated", "retrieval_connector_configuration_snapshot showing all active connector source URIs cross-referenced against register entries to confirm 100% coverage with no unregistered URIs", "register_audit_log showing all additions, modifications, and lifecycle status changes with timestamps and reviewer identity for the review period", "quarterly_reconciliation_report confirming all active connectors map to active register entries and documenting disposition of any gaps identified" ], "machine_tests": [ "Configure a retrieval connector to query a source URI absent from the authorization register \u2192 assert retrieval pipeline returns blocked status and emits a boundary_violation event in the audit log", "Export active register entry URIs and active connector URIs, compute set difference \u2192 assert the difference set is empty (zero unregistered connectors)", "Query the register for entries where owner, license_type, or authority_rating fields are null or empty \u2192 assert zero active-status entries returned" ], "human_review": [ "Sample 15% of active register entries and verify license documentation on file matches the license_type field recorded in the register", "Confirm the quarterly reconciliation review was completed within the defined review cycle with findings documented and gaps resolved within 30 days", "Assess that the source onboarding workflow enforces register entry creation as a gate before any new retrieval connector is activated in any environment" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Maintaining the authorization register in a disconnected spreadsheet or wiki that is updated after connectors are activated, allowing ungoverned retrieval windows between connector creation and register entry", "Including the source URI in the register but leaving license_type, authority_rating, or owner fields as placeholder or empty values for sources already active in production", "Treating the register as an annual documentation artifact rather than a real-time enforcement gate wired into the retrieval pipeline at connector resolution time", "Allowing exception processes that temporarily activate connectors without register entries, creating ungoverned retrieval windows that are invisible to governance review", "Registering broad URL patterns or entire domains rather than specific source URIs, obscuring the actual scope of authorized knowledge access from auditors" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KS" }, { "id": "KS-02", "layer": "KS", "plane": "control", "name": "Source Authority Classification", "plain": "All knowledge sources must be classified into authority tiers \u2014 primary, secondary, or tertiary \u2014 based on documented criteria covering source quality, editorial rigor, and information currency, and retrieval systems must expose tier metadata in results and apply tier-based ranking weights.", "threat": { "tags": [ "authority-conflation", "low-quality-source-promotion", "epistemic-contamination" ], "desc": "Without explicit authority classification, retrieval systems treat a peer-reviewed standard and an informal blog post as equivalent sources. This conflation degrades output quality and creates reputational and liability exposure when low-authority sources are cited as definitive. Adversaries can exploit unclassified source registries to inject low-authority content that displaces authoritative references in retrieval rankings." }, "standard": [ { "id": "iso_30401", "section": "Clause 8", "title": "Operation" }, { "id": "iso_42001", "section": "A.7.4", "title": "Quality of data for AI systems" }, { "id": "dama_dmbok", "section": "Ch. 13", "title": "Data Quality \u2014 accuracy and source authority" }, { "id": "itil_4", "section": "\u00a75.1.4", "title": "Knowledge management practice" } ], "sources": [ { "id": "google_vertex_ai_rag_2024", "title": "Google Vertex AI RAG & Grounding", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/vertex-ai/docs/generative-ai/grounding/overview", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_vertex_ai_rag_2024", "relationship": "informative_reference", "rationale": "Establishes Google Vertex AI RAG & Grounding requirements informing the apeiris://knowledge/controls/KS-02 Source Authority Classification control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Tiered classification taxonomy with documented scoring criteria; each source in the authorization register receives a tier label (primary/secondary/tertiary) assigned by a knowledge steward and reviewed annually, with tier metadata exposed in retrieval results.", "steps": [ "Define classification criteria for each tier: primary sources include official standards bodies, regulatory publications, and peer-reviewed research; secondary includes authoritative commentary and vetted industry publications; tertiary includes community content, vendor blogs, and informal references.", "Apply tier labels to all entries in the KS-01 source authorization register as part of the source onboarding workflow.", "Configure retrieval systems to expose tier metadata in retrieval result records and apply tier-based ranking weights in relevance scoring.", "Review classifications at least annually or whenever a source undergoes a significant change in editorial policy, ownership, or publication standards." ], "knowledge_engineer": { "summary": "Authority classification is a mandatory schema attribute on every source register entry. Build tier metadata into the retrieval pipeline so downstream consumers can filter and rank by authority tier.", "actions": [ "Extend the source register schema with a tier field accepting primary, secondary, or tertiary values.", "Implement retrieval pipeline configuration to include tier in the result metadata returned alongside retrieved passages.", "Document the scoring rubric used to assign tier labels and store it in the register as a versioned policy document." ], "failure_signals": [ "Sources with no tier label present in the register.", "Retrieval results returned without tier metadata.", "Classification rubric not documented or not versioned." ] }, "data_scientist": { "summary": "Tier labels should inform retrieval ranking and confidence scoring. Use authority tier as a weighted feature in relevance models and citation confidence calculations.", "actions": [ "Incorporate tier metadata into retrieval ranking models as a weighted feature with documented weight values.", "Document the quantitative mapping from tier label to ranking weight in the retrieval model card.", "Evaluate retrieval quality stratified by tier to confirm primary sources are correctly prioritized over secondary and tertiary." ], "failure_signals": [ "Retrieval experiments show tertiary sources ranking above primary sources for authoritative queries.", "Tier weight mapping not documented in model card.", "No tier-stratified quality evaluation present in retrieval benchmarks." ] }, "it_operations": { "summary": "Authority tiers are operational metadata: ingestion and indexing services must propagate the tier label into the serving index so ranking and conflict-resolution logic can honor it at query time.", "actions": [ "Propagate authority tier labels from the source register through ingestion into index document metadata.", "Fail ingestion jobs for sources that have no assigned authority tier rather than defaulting them.", "Monitor the tier distribution of the serving index and alert on unexplained shifts after re-indexing." ], "failure_signals": [ "Index documents are missing tier metadata after a re-indexing run.", "Ranking logic silently treats unlabeled sources as authoritative." ] }, "grc_auditor": { "summary": "Authority classification provides evidence that the organization distinguishes between high-confidence and low-confidence knowledge sources and has controls to prevent undue reliance on low-authority content.", "actions": [ "Confirm that the classification rubric is documented and approved by a knowledge governance owner.", "Sample 20% of register entries and verify tier assignments are consistent with the documented rubric.", "Request retrieval system configuration evidence confirming tier metadata is exposed in results and used in ranking." ], "metrics": [ "Tier label coverage: target 100% of active register entries.", "Classification rubric review cadence: at least annual.", "Primary source representation in top-10 retrieval results: target \u226560% for authoritative query types." ], "failure_signals": [ "Tier label missing on more than 5% of active register entries.", "Classification rubric has not been reviewed in more than 18 months.", "Audit sample reveals tier assignments inconsistent with documented rubric for more than 10% of sampled entries." ] }, "legal_counsel": { "summary": "Authority classification determines whose statements the AI repeats as fact. Misclassifying commentary or marketing content as authoritative creates misrepresentation and professional-advice exposure in regulated contexts.", "actions": [ "Review the tier rubric to require primary-source tiers for legal, regulatory, and medical content classes.", "Require documented rationale for each tier assignment so classification decisions are defensible after an incident.", "Confirm customer-facing disclaimers align with the authority level of the sources actually used." ], "failure_signals": [ "Customer-facing answers cite tertiary or commentary sources for regulated topics.", "No documented rationale exists for the tier assigned to a disputed source." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises lack formal authority tiering for AI knowledge sources; ad-hoc relevance scoring without authority weighting is the current default." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Knowledge Engineering Team", "Data Science Team", "Information Architecture" ], "frameworks": [ { "framework": "iso_30401", "requirement_id": "Clause 8", "fit": "direct", "rationale": "ISO 30401:2018 Clause 8 (Operation) requires organizations to plan, implement and control the processes needed to meet knowledge management requirements. Source authority classification is such an operational control, applied to the reliability of the knowledge sources feeding AI retrieval.", "normative_force": "certification-standard", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.7.4", "fit": "direct", "rationale": "ISO/IEC 42001:2023 Annex A control A.7.4 requires organizations to define and apply quality criteria for data used in AI systems. Authority classification operationalizes source quality as a managed dimension, implementing this data-quality control for retrieval-augmented systems.", "normative_force": "certification-standard", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 13", "fit": "partial", "rationale": "DAMA-DMBOK 2nd edition Chapter 13 (Data Quality) identifies accuracy and the credibility of sources as data quality concerns requiring measurement and management. Authority classification applies this quality discipline to AI retrieval sources, making source authority a managed organizational attribute.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "itil_4", "requirement_id": "\u00a75.1.4", "fit": "adjacent", "rationale": "The ITIL 4 knowledge management practice (5.1.4) aims to maintain and improve the effective use of information and knowledge, which requires distinguishing authoritative from non-authoritative sources. This service management principle maps directly to the tiered classification model for AI knowledge sources.", "normative_force": "industry-framework", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_vertex_rag", "requirement_id": "RAG grounding quality configuration", "fit": "adjacent", "rationale": "Google Vertex AI RAG supports grounding quality configurations that weight sources by reliability and relevance. Authority tier classification provides the semantic metadata that enables these platform-level quality controls to be configured with principled, governance-approved weighting.", "normative_force": "best-practice", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KS-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every active entry in the knowledge source authorization register must carry a documented authority tier label (primary, secondary, or tertiary) assigned using the organization's approved classification rubric. The retrieval pipeline must expose this tier in result metadata for every returned passage and apply documented tier-based ranking weights in relevance scoring.", "evidence_required": [ "source_register_tier_coverage_report confirming tier label (primary/secondary/tertiary) is populated for 100% of active register entries with assigned steward and assignment date", "classification_rubric_document defining criteria for each tier covering source type, publisher credentials, editorial rigor, and peer-review standards \u2014 version-controlled and governance-approved", "retrieval_result_sample_set of 50 responses showing tier metadata field populated for every returned passage alongside source_id and passage text", "retrieval_ranking_model_card documenting the numeric weight assigned to each tier in the relevance scoring function with rationale for weight values" ], "machine_tests": [ "Query the authorization register for active entries where tier field is null or empty \u2192 assert zero results returned", "Execute 50 representative retrieval queries and inspect response result metadata \u2192 assert tier field is present and non-null in 100% of result records", "Submit 10 authoritative domain queries and inspect top-5 results per query by tier label \u2192 assert primary-tier sources appear in at least 60% of top-5 positions across the query set" ], "human_review": [ "Sample 20% of active register entries and verify tier assignments are consistent with the documented classification rubric for the source's publisher type, editorial process, and peer-review status", "Review the tier-based ranking weight configuration and confirm weight values are governance-approved, proportionate to authority differentiation, and not left at arbitrary platform defaults", "Assess whether the classification rubric has been reviewed within the last 18 months and remains current with respect to the organization's knowledge source portfolio and evolving source types" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Assigning all sources to the secondary tier by default to avoid classification overhead, defeating authority differentiation and producing equal ranking weights across all source types", "Applying tier labels once at source onboarding without periodic review, allowing sources that have declined in editorial quality or changed ownership to retain primary-tier status indefinitely", "Using tier labels for display or documentation purposes only while retrieval ranking ignores tier and treats all sources with identical relevance weights", "Delegating tier assignment entirely to automated tools without human knowledge steward review, producing tier labels derived from statistical signals rather than editorial judgment", "Implementing non-standard tier vocabularies that cannot be mapped to authority classification models required by external frameworks or regulatory disclosure requirements" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KS" }, { "id": "KS-03", "layer": "KS", "plane": "control", "name": "Source Currency and Maximum Age Policy", "plain": "The organization must define and enforce a maximum acceptable age for each authority tier of knowledge source, automatically flagging and blocking retrieval from sources whose content has not been refreshed within the applicable staleness threshold.", "threat": { "tags": [ "stale-knowledge-retrieval", "currency-decay", "outdated-regulatory-reference" ], "desc": "Knowledge sources that have exceeded their currency threshold present substantively incorrect information as current fact. In regulated domains, outdated regulatory or compliance sources cause AI systems to generate guidance that reflects superseded requirements. Stale sources compound risk silently \u2014 without automated governance signals, staleness is typically only discovered post-incident when erroneous outputs are reported." }, "standard": [ { "id": "iso_42001", "section": "A.7.4", "title": "Quality of data for AI systems" }, { "id": "dama_dmbok", "section": "Ch. 13", "title": "Data Quality \u2014 timeliness and currency" }, { "id": "iso_30401", "section": "\u00a77.5.3", "title": "Control of documented knowledge \u2014 version and currency" } ], "sources": [ { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 A.7.4 requirements informing the apeiris://knowledge/controls/KS-03 Source Currency and Maximum Age Policy control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 13 requirements informing the apeiris://knowledge/controls/KS-03 Source Currency and Maximum Age Policy control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 10(3) requirements informing the apeiris://knowledge/controls/KS-03 Source Currency and Maximum Age Policy control.", "reviewed_on": "2026-07-02" }, { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements \u00a77.5.3 requirements informing the apeiris://knowledge/controls/KS-03 Source Currency and Maximum Age Policy control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Per-tier maximum age thresholds defined in policy, enforced by automated freshness monitoring that flags stale sources in the authorization register and blocks retrieval connectors from querying sources that have exceeded their tier threshold.", "steps": [ "Define maximum age thresholds by tier in the knowledge governance policy: recommended defaults are primary \u226412 months, secondary \u226424 months, tertiary \u226436 months, with shorter thresholds mandated for high-risk or rapidly evolving domains.", "Extend the source authorization register with last_verified_date, freshness_threshold_days, and staleness_status fields, and configure automated daily monitoring to compute and update staleness_status.", "Integrate freshness status into retrieval pipeline configuration, blocking queries to sources with staleness_status set to stale or expired until they are reviewed and refreshed.", "Establish a refresh queue workflow that routes stale source notifications to the responsible knowledge steward with an SLA for review and re-verification." ], "knowledge_engineer": { "summary": "Currency policy requires adding staleness tracking fields to the source register and wiring the retrieval pipeline to enforce staleness gates before any connector query is resolved.", "actions": [ "Extend the source register schema with last_verified_date, freshness_threshold_days, and staleness_status fields.", "Implement automated monitoring that computes staleness_status daily and updates the register record.", "Configure retrieval connectors to skip sources with staleness_status=stale or staleness_status=expired at query time." ], "failure_signals": [ "Sources with no last_verified_date field in the active register.", "Retrieval pipeline resolving queries against sources with staleness_status=expired.", "No automated monitoring job present for daily freshness computation." ] }, "data_scientist": { "summary": "Stale sources degrade retrieval quality in ways that are hard to detect in aggregate metrics. Log source age at retrieval time and monitor the distribution of source ages in result sets to detect drift toward staler content.", "actions": [ "Add source age at retrieval time as a logged feature in the retrieval evaluation pipeline.", "Monitor the p95 source age in retrieval result sets to detect slow drift toward staler content over time.", "Flag evaluation sets where stale sources appear disproportionately in top-ranked results." ], "failure_signals": [ "P95 source age at retrieval exceeds the applicable tier threshold for more than 5% of queries.", "Stale sources appearing in top-3 retrieval results in any evaluation set.", "No source age distribution metric present in the retrieval quality dashboard." ] }, "it_operations": { "summary": "Maximum-age policy is enforced by scheduled jobs: currency scans must run on cadence, expiry actions must execute automatically, and failures must page rather than silently skip.", "actions": [ "Schedule currency scans against every active source and treat scan failures as incidents, not skipped runs.", "Automate the expiry action (suppress, quarantine, or re-fetch) so breaching content leaves the serving path without manual steps.", "Expose per-source age telemetry on the operations dashboard with alerts at policy thresholds." ], "failure_signals": [ "Currency scan jobs fail repeatedly without paging anyone.", "Content past its maximum age remains retrievable because expiry automation was disabled." ] }, "grc_auditor": { "summary": "Currency policy provides evidence that the organization has defined and operationalized staleness thresholds, preventing AI systems from silently drawing on outdated knowledge without a governance signal.", "actions": [ "Confirm that maximum age thresholds are documented in policy and approved by a governance owner.", "Request a register export filtered to sources with staleness_status=stale or expired and verify none are active in retrieval connectors.", "Review the refresh queue workflow to confirm stale sources are being remediated within the defined SLA." ], "metrics": [ "Stale or expired source rate in active retrieval connectors: target 0%.", "Mean time to refresh a stale source: target \u226430 business days.", "Currency policy review cadence: at least annual." ], "failure_signals": [ "Any stale or expired source found active in a retrieval connector.", "Refresh SLA exceeded for more than 10% of stale source queue items.", "Currency policy not reviewed in more than 18 months." ] }, "legal_counsel": { "summary": "Stale authoritative content is a legal exposure: outdated regulatory guidance or superseded policy retrieved as current can put the organization and its customers in breach.", "actions": [ "Set maximum-age requirements for regulated content classes jointly with compliance, and document the basis for each threshold.", "Require that superseded regulatory material be suppressed from retrieval, not merely flagged.", "Review currency incident reports for matters that may require customer notification or remediation." ], "failure_signals": [ "The AI cites a superseded regulation or policy version as current.", "Regulated content classes have no documented maximum-age threshold." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Currency policy for AI knowledge sources is largely absent in enterprise practice; staleness is typically only discovered post-incident after erroneous outputs are reported." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Knowledge Engineering Team", "Platform Engineering", "GRC Team" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "A.7.4", "fit": "direct", "rationale": "ISO/IEC 42001:2023 Annex A control A.7.4 requires organizations to define and apply quality requirements for data used in AI systems; currency is a recognized quality dimension. A maximum age policy with automated enforcement is the operational mechanism for managing that dimension in retrieval-augmented systems.", "normative_force": "certification-standard", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 13", "fit": "direct", "rationale": "DAMA-DMBOK 2nd edition Chapter 13 (Data Quality) identifies timeliness and currency as core data quality dimensions requiring defined thresholds and monitoring. Currency policy for AI knowledge sources directly operationalizes this dimension at the retrieval index layer.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10(3)", "fit": "partial", "rationale": "EU AI Act Art. 10(3) requires training and knowledge data for high-risk AI systems to be relevant and up-to-date. A defined maximum age policy with per-tier thresholds and automated enforcement is one mechanism for demonstrating compliance with this currency requirement to regulators.", "normative_force": "binding-law", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_30401", "requirement_id": "\u00a77.5.3", "fit": "adjacent", "rationale": "ISO 30401:2018 \u00a77.5.3 requires organizations to control documented knowledge including ensuring it remains current and fit for purpose. Currency policy for AI knowledge sources is the operational implementation of this control requirement applied to machine-readable retrieval indexes.", "normative_force": "certification-standard", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KS-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The organization must have a documented per-tier maximum age policy with specific staleness thresholds, and automated daily monitoring must compute and update a staleness_status field for every active source register entry. No retrieval connector may successfully query a source with staleness_status of 'stale' or 'expired' at query execution time.", "evidence_required": [ "currency_policy_document defining maximum age thresholds by authority tier (e.g., primary \u226412 months, secondary \u226424 months, tertiary \u226436 months) with governance approval date and effective date", "source_register_staleness_report showing staleness_status (current/stale/expired) and days_since_last_verified for all active entries, generated within the last 25 hours", "retrieval_pipeline_enforcement_configuration showing staleness gate logic that blocks queries to sources with staleness_status of stale or expired at connector resolution time", "refresh_queue_workflow_log showing all open stale source tickets with assigned knowledge steward, SLA due date, and current remediation status" ], "machine_tests": [ "Set last_verified_date on a test source to a date exceeding the applicable tier threshold \u2192 assert staleness_status updates to 'stale' within 25 hours and retrieval pipeline returns blocked status for that source", "Query the source register for entries with staleness_status='stale' or staleness_status='expired' that are referenced by active retrieval connectors \u2192 assert zero results", "Trigger the daily staleness monitoring job and verify execution \u2192 assert last_computed_at timestamp is updated for all active register entries within a 25-hour window" ], "human_review": [ "Review the refresh queue and confirm all stale sources have an assigned knowledge steward, a documented remediation plan, and are on track to be resolved within the 30-business-day SLA", "Verify that currency thresholds are appropriately calibrated for high-risk or rapidly evolving knowledge domains (e.g., regulatory, cybersecurity, clinical) where the standard tier thresholds may be insufficient", "Confirm the currency policy has been reviewed within the last 18 months and no significant gap exists between documented thresholds and the organization's current risk tolerance for stale knowledge" ], "blocking_effect": "blocks-runtime-action", "normative_status": "certification-standard", "anti_patterns": [ "Defining maximum age thresholds in policy documents without wiring them into automated monitoring, leaving staleness detection dependent on manual periodic reviews that are easily deferred", "Using a single universal staleness threshold regardless of source tier, applying identical currency expectations to primary regulatory publications and tertiary community content", "Flagging stale sources in governance dashboards while allowing retrieval connectors to continue querying them without a blocking gate, reducing staleness enforcement to advisory status", "Meeting staleness thresholds by updating the last_verified_date timestamp in the register without re-verifying the actual content currency of the source at the origin URI", "Excluding rapidly evolving knowledge domains such as regulatory updates or security advisories from per-tier currency controls by treating them as outside the policy scope" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KS" }, { "id": "KS-04", "layer": "KS", "plane": "data", "name": "Source Provenance Documentation", "plain": "Every knowledge source in the authorization register must have complete provenance documentation covering its origin, ingestion method, license terms, access rights, usage restrictions, and chain of custody from source to retrieval index, with integrity hashes at each transformation step.", "threat": { "tags": [ "provenance-gap", "chain-of-custody-break", "unlicensed-content" ], "desc": "Incomplete provenance documentation prevents the organization from demonstrating that knowledge sources are legitimately licensed, accurately attributed, and have not been tampered with in transit. A chain-of-custody gap between the original source and the retrieval index allows unauthorized content injection that is invisible to governance processes. Legal liability from unlicensed content is undetectable without complete provenance records, and regulatory inspections cannot be satisfied by reconstructed or partial lineage." }, "standard": [ { "id": "w3c_prov", "section": "PROV-DM \u00a72", "title": "Provenance data model \u2014 entity and origin" }, { "id": "dama_dmbok", "section": "Ch. 12", "title": "Metadata Management \u2014 lineage and origin" }, { "id": "iso_27002", "section": "\u00a75.12\u20135.13", "title": "Classification and labelling of information" }, { "id": "eu_ai_act", "section": "Art. 10(2)(b)", "title": "Data collection processes and the origin of data" } ], "sources": [ { "id": "databricks_unity_catalog_2024", "title": "Databricks Unity Catalog (Knowledge Gov.)", "authority": "Databricks, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.databricks.com/en/data-governance/unity-catalog/index.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "databricks_unity_catalog_2024", "relationship": "informative_reference", "rationale": "Establishes Databricks Unity Catalog (Knowledge Gov.) requirements informing the apeiris://knowledge/controls/KS-04 Source Provenance Documentation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Structured provenance records for each source following W3C PROV-DM entities, with mandatory fields for origin URI, ingestion method, license identifier, access rights scope, usage restrictions, and SHA-256 integrity hashes at each ingestion pipeline transformation step.", "steps": [ "Define a provenance record schema for each knowledge source based on W3C PROV-DM, including prov:Entity for the source document, prov:Activity for each ingestion stage, and prov:Agent for the ingesting system.", "Require a completed provenance record as a prerequisite gate for activating any new source in the KS-01 authorization register.", "Instrument the ingestion pipeline to compute and store SHA-256 integrity hashes at each transformation stage \u2014 raw download, parsing, chunking, and embedding \u2014 storing all hashes in the provenance record.", "Integrate provenance records with the source authorization register so each register entry contains a linked reference to its complete provenance document stored in an immutable audit log." ], "knowledge_engineer": { "summary": "Provenance documentation requires instrumenting the ingestion pipeline to generate W3C PROV-DM records and chain-of-custody hashes at every transformation step before a source can be activated.", "actions": [ "Implement provenance record generation in the ingestion pipeline using the W3C PROV-DM entity-activity-agent model.", "Store provenance records in an immutable audit log and link each record to its corresponding source register entry.", "Compute and store SHA-256 integrity hashes at every ingestion pipeline stage and embed them in the provenance record." ], "failure_signals": [ "Active sources with incomplete or missing provenance records.", "Ingestion pipeline stages without integrity hash generation.", "Provenance records not linked to their corresponding register entries." ] }, "data_scientist": { "summary": "Provenance metadata is an analysis surface: corpus debugging, contamination tracing, and dataset documentation all depend on complete origin records for every document in the index.", "actions": [ "Use provenance records to trace anomalous retrievals back to their originating source and ingestion run.", "Include provenance completeness as a dataset quality metric in corpus health reports.", "Document evaluation corpora with their provenance chains so results are reproducible and attributable." ], "failure_signals": [ "Anomalous index content cannot be traced to an originating source or ingestion run.", "Evaluation datasets circulate without provenance documentation." ] }, "it_operations": { "summary": "Provenance documentation depends on infrastructure controls ensuring that ingestion pipelines connect only to authorized source endpoints and that chain-of-custody is maintained through the infrastructure layer.", "actions": [ "Ensure ingestion pipeline infrastructure logs all network connections to source endpoints with timestamps and connection metadata.", "Implement egress controls that restrict ingestion pipeline network access to authorized source URI ranges only.", "Monitor for ingestion pipeline failures that could break chain-of-custody continuity and alert the knowledge engineering team for remediation." ], "failure_signals": [ "Ingestion pipeline making connections to source URIs not in the authorization register.", "Chain-of-custody gaps due to pipeline failures not captured with error provenance records.", "Missing network-level logs for ingestion pipeline connection events." ] }, "grc_auditor": { "summary": "Provenance documentation is a primary evidence artifact for demonstrating that knowledge sources are authorized, licensed, and have not been tampered with. It is directly required by several regulatory frameworks.", "actions": [ "Request provenance records for a random sample of active sources and verify completeness against the defined schema.", "Re-compute integrity hashes for sampled source artifacts and compare against hashes stored in provenance records.", "Verify that provenance record completeness is enforced as a gate on source activation in the register workflow." ], "metrics": [ "Provenance record completeness rate: target 100% of active sources.", "Chain-of-custody integrity hash verification pass rate: target 100% on sampled sources.", "Mean time to complete provenance documentation for new sources: target \u22645 business days." ], "failure_signals": [ "Active sources with incomplete provenance records.", "Integrity hash mismatches discovered during provenance record verification.", "Sources activated without completed provenance records." ] }, "legal_counsel": { "summary": "Provenance documentation is the evidentiary foundation for license compliance and defense against intellectual property claims. Complete records must be in place before any knowledge source enters production.", "actions": [ "Review the provenance record schema to confirm it captures all license metadata required for compliance and litigation defense, including license identifier, usage restrictions, and access rights scope.", "Confirm that usage restrictions captured in provenance records are propagated to runtime controls preventing out-of-scope use.", "Establish a provenance record retention policy aligned with applicable IP statutes of limitations and regulatory requirements." ], "failure_signals": [ "Provenance records lacking license identifier or usage restriction fields.", "Usage restrictions in provenance records not enforced at runtime.", "Provenance records not retained for required duration." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Provenance documentation for AI retrieval sources is nascent; most enterprises capture basic ingestion metadata but lack formal chain-of-custody records with integrity hashes." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Knowledge Engineering Team", "Platform Engineering", "Legal / IP Counsel" ], "frameworks": [ { "framework": "w3c_prov", "requirement_id": "PROV-DM \u00a72", "fit": "direct", "rationale": "W3C PROV-DM \u00a72 defines the provenance data model for documenting entities, activities, and agents in data lineage chains. Applying PROV-DM to knowledge source documentation provides an internationally recognized, standards-compliant foundation for origin and chain-of-custody records that can be understood and validated by external auditors.", "normative_force": "voluntary-standard", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10(2)(b)", "fit": "direct", "rationale": "EU AI Act Art. 10(2)(b) requires data governance practices covering data collection processes and the origin of data. Source provenance documentation is the direct operational implementation of this mandate for knowledge sources used in retrieval-augmented AI systems.", "normative_force": "binding-law", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 12", "fit": "direct", "rationale": "DAMA-DMBOK 2nd edition Chapter 12 (Metadata Management) establishes lineage and origin metadata as a core discipline, requiring traceability from data origin through all transformations to its current state. Applied to AI knowledge sources, this requires full lineage from original source through ingestion pipeline stages to the retrieval index.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "iso_27002", "requirement_id": "\u00a75.12\u20135.13", "fit": "partial", "rationale": "ISO/IEC 27002:2022 \u00a75.12 requires information to be classified and \u00a75.13 requires it to be labelled in accordance with the classification scheme. Provenance documentation for knowledge sources carries the classification and labelling metadata these controls require.", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "databricks_unity", "requirement_id": "Data lineage and catalog metadata", "fit": "adjacent", "rationale": "Databricks Unity Catalog provides automated lineage tracking and catalog metadata capabilities that directly support knowledge source provenance documentation in data-intensive AI pipelines. Organizations using Unity Catalog should leverage its lineage capture features to generate and maintain the provenance records required by this control.", "normative_force": "best-practice", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KS-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every active knowledge source must have a complete W3C PROV-DM provenance record stored in an immutable audit log covering origin URI, ingestion method, license identifier, access rights scope, usage restrictions, and SHA-256 integrity hashes at each ingestion pipeline transformation stage. Source activation in the authorization register must be gated on provenance record completeness.", "evidence_required": [ "provenance_record_completeness_report confirming all active sources have provenance records with prov:Entity, prov:Activity per ingestion stage (raw_download, parsing, chunking, embedding), prov:Agent, and license_id fields populated", "integrity_hash_chain_log showing SHA-256 hashes computed at raw_download, parsing, chunking, and embedding stages for each source with pipeline stage timestamps and algorithm identifier", "source_activation_gate_log confirming provenance record completeness verification was recorded as a prerequisite step before each source was transitioned to active lifecycle status", "provenance_record_immutability_evidence such as append-only store audit trail, write-once storage confirmation, or cryptographic record sealing log demonstrating records cannot be retroactively modified" ], "machine_tests": [ "Attempt to set a source to active lifecycle status in the authorization register without a linked provenance record \u2192 assert activation is blocked with error code 'provenance_incomplete'", "Re-compute SHA-256 hash of raw download artifact for a sample of 10 sources \u2192 assert computed hashes match the raw_download_hash field stored in each source's provenance record with zero mismatches", "Query the provenance record store for records missing any required field (origin_uri, license_id, ingestion_method, or any stage integrity_hash) \u2192 assert zero results for active sources" ], "human_review": [ "Verify usage restrictions captured in provenance records for a sample of 10 active sources are enforced at runtime and cannot be overridden without documented legal sign-off", "Confirm the provenance record store uses a genuine immutability mechanism (append-only log, write-once storage, or cryptographic sealing) that has been tested and cannot be bypassed by operational staff", "Assess whether the provenance record retention period aligns with applicable IP statutes of limitations and regulatory requirements for all jurisdictions in which the AI system operates" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Generating provenance metadata only for the final indexed artifact without tracking intermediate transformation stages, creating chain-of-custody gaps between the original source and the retrieval index", "Storing provenance records in mutable database tables that can be updated after the fact, undermining the integrity guarantee that makes provenance records defensible in legal or regulatory proceedings", "Capturing license metadata at source onboarding without propagating usage restrictions to runtime enforcement controls, allowing out-of-scope use to proceed through the retrieval pipeline", "Treating provenance record generation as a post-ingestion documentation step rather than an inline pipeline requirement, allowing sources to be indexed and queried before provenance is complete", "Using ad-hoc provenance schemas not mapped to W3C PROV-DM, producing records that external auditors cannot interpret or cross-reference with internationally recognized lineage standards" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KS" }, { "id": "KS-05", "layer": "KS", "plane": "control", "name": "Competing Source Conflict Resolution", "plain": "The organization must maintain documented procedures for detecting and resolving contradictions between knowledge sources, including automated conflict detection in the indexing pipeline, a tiered escalation path by authority differential, and auditable resolution records for every identified conflict.", "threat": { "tags": [ "epistemic-conflict", "source-contradiction", "unresolved-factual-ambiguity" ], "desc": "When AI retrieval systems surface contradictory claims from different knowledge sources without a resolution mechanism, the system either arbitrarily selects one claim, presents both without guidance, or synthesizes an incoherent hybrid. In regulated domains, unresolved contradictions between official standards and outdated references produce compliance guidance that accurately reflects neither source. Without documented resolution procedures, conflict handling is inconsistent and cannot be audited." }, "standard": [ { "id": "iso_30401", "section": "\u00a74.4.2", "title": "Knowledge development \u2014 handling invalid or outdated knowledge" }, { "id": "dama_dmbok", "section": "Ch. 13", "title": "Data Quality \u2014 issue management and remediation" }, { "id": "iso_42001", "section": "\u00a79.1", "title": "Monitoring and evaluation of AI system outputs" }, { "id": "itil_4", "section": "\u00a75.1.4", "title": "Knowledge management practice" } ], "sources": [ { "id": "anthropic_model_cards_2024", "title": "Anthropic Model Cards & Knowledge Disclosure", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/transparency", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_transparency", "relationship": "informative_reference", "rationale": "Establishes Anthropic Model Cards & Knowledge Disclosure requirements informing the apeiris://knowledge/controls/KS-05 Competing Source Conflict Resolution control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Documented conflict resolution procedure with automated conflict detection in the indexing pipeline based on semantic similarity scoring and assertion polarity analysis, a tiered escalation path by authority differential, and an auditable resolution record for every identified conflict.", "steps": [ "Define conflict detection criteria: two sources are in conflict when they make contradictory factual claims within the same knowledge domain, identified by semantic similarity above a tuned threshold combined with opposing assertion polarity.", "Implement automated conflict detection in the indexing pipeline that flags candidate conflicts, records them in a conflict register, and routes them to the appropriate resolution authority.", "Define resolution authority tiers: primary-vs-primary conflicts require knowledge governance review; primary-vs-secondary conflicts are resolved in favor of primary with a logged exception if secondary is demonstrably more current; secondary-vs-tertiary are resolved by the knowledge steward.", "Require a documented resolution record for every conflict containing the conflicting claims, resolution decision, rationale, reviewer identity, and linked source register entries." ], "knowledge_engineer": { "summary": "Conflict resolution requires semantic conflict detection in the indexing pipeline and a conflict register that tracks open and resolved conflicts with full resolution history linked to source entries.", "actions": [ "Implement semantic conflict detection in the indexing pipeline using embedding similarity and assertion polarity analysis.", "Build a conflict register that tracks detected conflicts, their resolution status, and complete resolution history.", "Link each conflict register entry to both conflicting source register entries." ], "failure_signals": [ "No automated conflict detection present in the indexing pipeline.", "Conflicts detected but not logged in a conflict register.", "Open conflicts unresolved for more than 30 days." ] }, "data_scientist": { "summary": "Conflict detection accuracy depends on embedding quality and polarity detection methods. Tune detection thresholds on labeled test sets to minimize false positives while capturing genuine contradictions.", "actions": [ "Evaluate conflict detection precision and recall on a labeled test set of known contradictory source pairs before production deployment.", "Document the similarity threshold and polarity detection method used for conflict identification in the pipeline configuration.", "Monitor conflict detection rate over time to identify anomalous spikes that may indicate source quality degradation." ], "failure_signals": [ "Conflict detection precision below 70% on labeled test set.", "No labeled test set available for conflict detection evaluation.", "Detection threshold not documented or not calibrated on a representative sample." ] }, "it_operations": { "summary": "Conflict detection runs as pipeline jobs: contradiction scans must execute on ingest and on schedule, and unresolved conflicts must flow into an owned escalation queue rather than accumulating silently.", "actions": [ "Operate contradiction detection as part of ingestion and as a scheduled full-corpus scan.", "Route detected conflicts into a ticketed escalation queue with an accountable owner and SLA.", "Track queue depth and resolution latency; alert when unresolved conflicts age past the SLA." ], "failure_signals": [ "The conflict queue grows for weeks with no resolutions recorded.", "Contradiction scans were disabled to speed up ingestion and never re-enabled." ] }, "grc_auditor": { "summary": "Conflict resolution procedures provide evidence that the organization has governance controls preventing unresolved knowledge contradictions from persisting silently in the retrieval index.", "actions": [ "Confirm that conflict resolution procedures are documented and approved by a knowledge governance owner.", "Request the conflict register and verify all open conflicts are within the defined resolution SLA.", "Sample 10% of resolved conflicts and verify resolution records are complete with rationale and reviewer identity." ], "metrics": [ "Open conflict resolution rate within SLA (30 days): target 100%.", "Resolution record completeness rate: target 100% of resolved conflicts.", "Conflict detection coverage: target 100% of indexed knowledge domains covered by the detection pipeline." ], "failure_signals": [ "Open conflicts exceeding the 30-day resolution SLA.", "Resolution records missing rationale or reviewer identity.", "Conflict detection not operational for one or more indexed knowledge domains." ] }, "legal_counsel": { "summary": "Unresolved contradictions between sources mean the AI may give different answers to the same regulated question. Precedence rules for legal and policy content are a legal-risk decision, not just an engineering one.", "actions": [ "Define precedence rules for conflicting legal, regulatory, and policy sources with counsel sign-off.", "Review high-impact conflict resolutions affecting regulated content before they take effect.", "Preserve conflict resolution records as evidence of diligence for disputes and examinations." ], "failure_signals": [ "The AI alternates between contradictory answers on a compliance question.", "Precedence between an internal policy and an external regulation was decided without counsel review." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Automated conflict detection for AI knowledge sources is not yet standard practice; most conflicts are discovered reactively after erroneous outputs are reported by end users." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Knowledge Engineering Team", "Data Science Team", "Knowledge Governance Board" ], "frameworks": [ { "framework": "iso_30401", "requirement_id": "\u00a74.4.2", "fit": "direct", "rationale": "ISO 30401:2018 \u00a74.4.2 includes handling of invalid or outdated knowledge among the knowledge development activities a knowledge management system must cover. Competing-source conflict resolution operationalizes this activity for AI retrieval contexts, providing a systematic process for detecting and resolving contradictory knowledge.", "normative_force": "certification-standard", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 13", "fit": "partial", "rationale": "DAMA-DMBOK 2nd edition Chapter 13 (Data Quality) addresses data quality issue management and remediation, including procedures for resolving conflicting data records. Applied to AI knowledge sources, this requires the documented detection, escalation, and resolution procedures defined in this control.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "iso_42001", "requirement_id": "\u00a79.1", "fit": "partial", "rationale": "ISO/IEC 42001:2023 \u00a79.1 requires monitoring and evaluation of AI system outputs to detect performance degradation. Conflict resolution procedures contribute to this requirement by ensuring that knowledge-level contradictions are identified and resolved before they manifest as inconsistent or erroneous system outputs.", "normative_force": "certification-standard", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "itil_4", "requirement_id": "\u00a75.1.4", "fit": "adjacent", "rationale": "The ITIL 4 knowledge management practice (5.1.4) treats knowledge as an asset whose accuracy must be actively maintained; conflicting knowledge articles must be identified and resolved through a defined process. This operational model applies directly to AI knowledge source conflict handling.", "normative_force": "industry-framework", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_transparency", "requirement_id": "Model card \u2014 known limitations disclosure", "fit": "adjacent", "rationale": "Anthropic's model cards disclose known limitations of deployed models, including that outputs can be inconsistent across related queries. Conflict resolution procedures address one upstream cause \u2014 contradictory retrieval sources \u2014 before contradictions reach the generation stage. The fit is adjacent as model cards disclose limitations rather than prescribe source governance.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KS-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The indexing pipeline must include automated conflict detection that identifies contradictory factual claims between knowledge sources using semantic similarity and assertion polarity analysis, logs all detected conflicts in a conflict register, and routes them to the appropriate resolution authority. All detected conflicts must have a documented resolution record with rationale and reviewer identity within the defined SLA period.", "evidence_required": [ "conflict_detection_pipeline_configuration showing semantic similarity threshold, polarity detection method, and labeled test set precision/recall calibration results used to tune the detection parameters", "conflict_register_export showing all detected conflicts with fields: conflicting_source_ids, detected_at, conflict_type, resolution_authority_tier, resolution_status, and SLA_due_date", "conflict_resolution_record_sample for 10 resolved conflicts each containing conflicting_claims_text, resolution_decision, rationale, reviewer_identity, resolution_timestamp, and linked source_register_entry_ids", "conflict_detection_evaluation_report on a labeled test set of known conflicting and non-conflicting source pairs documenting precision and recall at the configured detection threshold" ], "machine_tests": [ "Inject two sources with documented contradictory factual claims into the test index and run the conflict detection pipeline \u2192 assert both sources appear as a conflict pair in the conflict register within one indexing processing cycle", "Query the conflict register for open conflicts where detected_at is older than the defined resolution SLA \u2192 assert zero results", "Run the conflict detection pipeline against the labeled evaluation set \u2192 assert precision \u2265 0.70 and recall \u2265 0.65 at the configured similarity threshold" ], "human_review": [ "Review a random 10% sample of resolved conflicts and confirm each resolution record documents the specific conflicting claims, the resolution rationale, and the reviewer's identity \u2014 not merely a status field update", "Assess whether the conflict detection threshold is calibrated to surface genuine factual and regulatory contradictions without generating false positives that exceed the resolution queue's processing capacity", "Confirm resolution authority assignments are appropriate for the organization's governance structure and that individuals holding resolution authority have subject-matter competence in the relevant knowledge domain" ], "blocking_effect": "requires-review", "normative_status": "certification-standard", "anti_patterns": [ "Relying on retrieval ranking to implicitly resolve conflicts by promoting the higher-authority source, without detecting the conflict or creating an auditable resolution record", "Setting the conflict detection similarity threshold so permissively that the system misses genuine regulatory or factual contradictions between sources covering the same domain topic", "Populating a conflict register but providing no SLA, no resolution authority assignment, and no escalation path, allowing detected conflicts to age indefinitely without governance action", "Treating primary-vs-secondary conflicts as automatically resolved in favor of the primary source without creating a resolution record, eliminating the audit trail for cases where the secondary source is demonstrably more current", "Running conflict detection only at initial source ingestion without re-running when existing sources are refreshed, missing new contradictions introduced by source content updates" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KS" }, { "id": "KS-06", "layer": "KS", "plane": "control", "name": "Knowledge Domain Boundary Definition", "plain": "The organization must formally define the knowledge domains the AI system is authorized to retrieve from, the conditions under which retrieval is permitted, and the categories of knowledge that are explicitly prohibited, with enforcement at the retrieval pipeline layer that blocks and logs out-of-boundary access attempts.", "threat": { "tags": [ "domain-boundary-violation", "unauthorized-retrieval", "out-of-scope-knowledge-access" ], "desc": "Without explicit domain boundaries, AI retrieval systems expand over time to query sources outside their intended scope \u2014 including confidential internal documents, restricted regulatory databases, and domains with significant liability exposure. Boundary drift is incremental and rarely detected until a governance incident surfaces content that should never have been retrievable. Attackers can exploit undefined boundaries through prompt injection to force retrieval from high-sensitivity domains that were never intended to be accessible." }, "standard": [ { "id": "iso_27002", "section": "\u00a75.10", "title": "Acceptable use of information and assets" }, { "id": "iso_42001", "section": "\u00a74.3", "title": "Determining the scope of the AI management system" }, { "id": "eu_ai_act", "section": "Art. 9(2)", "title": "Risk management system \u2014 scope definition" } ], "sources": [ { "id": "microsoft_azure_ai_search_2024", "title": "Microsoft Azure AI Search & Grounding", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/azure/search/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_azure_ai_search_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Azure AI Search & Grounding requirements informing the apeiris://knowledge/controls/KS-06 Knowledge Domain Boundary Definition control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Formally documented knowledge domain boundary policy with allowlist and denylist configurations enforced at the retrieval pipeline layer; all retrieval attempts outside authorized boundaries are blocked and logged for governance review.", "steps": [ "Define a knowledge domain taxonomy covering all candidate knowledge areas for the AI system, with each domain classified as authorized, conditionally authorized (with explicit access conditions), or prohibited.", "Implement allowlist-based source filtering in the retrieval pipeline so only sources in authorized domains can be queried, regardless of how connectors are configured.", "Enumerate prohibited domain categories explicitly in policy, including personal data stores, privileged legal communications, personnel records, insider-information domains, and jurisdictionally restricted content.", "Instrument boundary enforcement to log all blocked retrieval attempts with domain classification, source URI, and requesting context; review blocked attempt logs quarterly and update the boundary policy if patterns indicate misaligned scope expectations." ], "knowledge_engineer": { "summary": "Domain boundary enforcement requires an allowlist-based retrieval architecture where the pipeline can only resolve source URIs that are both registered in KS-01 and classified as authorized in the boundary policy.", "actions": [ "Implement domain classification as a mandatory field in the source authorization register, with values: authorized, conditionally-authorized, or prohibited.", "Configure the retrieval pipeline to enforce the domain allowlist at the connector resolution layer, blocking any source URI not classified as authorized.", "Instrument boundary enforcement to log all blocked retrieval attempts with domain classification, source URI, and requesting context." ], "failure_signals": [ "Retrieval pipeline lacking domain allowlist enforcement at the connector resolution layer.", "Blocked retrieval attempts not logged or monitored.", "Sources classified as conditionally authorized retrievable without access condition verification." ] }, "data_scientist": { "summary": "Domain boundaries shape retrieval quality: out-of-scope content that leaks into the index degrades answer precision and contaminates domain-specific evaluations.", "actions": [ "Include boundary-adherence checks in retrieval evaluation \u2014 verify returned chunks belong to the queried domain scope.", "Measure cross-domain leakage rates and treat increases as index-quality regressions.", "Validate that fine-tuning or embedding corpora respect the same domain boundaries as the serving index." ], "failure_signals": [ "Retrieval evaluations return chunks from domains outside the system's declared scope.", "Cross-domain leakage rate rises after an index rebuild." ] }, "it_operations": { "summary": "Domain boundaries must be enforced at both the application and network infrastructure layers, ensuring retrieval pipelines cannot access prohibited domains through infrastructure-level bypasses.", "actions": [ "Implement network egress controls that restrict retrieval pipeline network access to authorized source endpoint ranges.", "Monitor network logs for retrieval pipeline connections to endpoints outside the authorized domain allowlist.", "Integrate boundary violation alerts into the security operations monitoring stack with defined escalation paths." ], "failure_signals": [ "Retrieval pipeline with network access to prohibited domain endpoint ranges.", "No network-level logging for retrieval pipeline egress connections.", "Boundary violation alerts not integrated into security operations monitoring." ] }, "grc_auditor": { "summary": "Domain boundary definition provides evidence that the AI system has explicit authorization scope, preventing scope creep and unauthorized access to sensitive or legally restricted knowledge domains.", "actions": [ "Confirm that the domain boundary policy is documented, approved, and includes complete classification of authorized, conditionally authorized, and prohibited domains.", "Request blocked retrieval attempt logs for the review period and confirm all violations were investigated within SLA.", "Verify that conditionally authorized domains have documented access conditions that are enforced at runtime." ], "metrics": [ "Domain boundary policy coverage: target 100% of active knowledge domains classified.", "Blocked retrieval attempt investigation rate: target 100% within 30 days.", "Policy review cadence: at least annual or after any significant AI system scope change." ], "failure_signals": [ "Active knowledge domains not classified in the boundary policy.", "Blocked retrieval attempts not investigated within the defined SLA.", "Domain boundary policy not reviewed following AI system scope changes." ] }, "legal_counsel": { "summary": "Domain boundaries establish the legal authorization perimeter for AI knowledge access. Prohibited domain classifications must be reviewed by legal to ensure they capture all legally restricted knowledge categories.", "actions": [ "Review prohibited domain classifications to confirm they include all legally restricted categories: PII stores, privileged communications, insider-information domains, and jurisdictionally restricted content.", "Confirm that conditionally authorized domains with regulatory access requirements have documented authorization bases before any activation.", "Review blocked retrieval attempt logs for access attempts to legally privileged domains and escalate incidents per the defined process." ], "failure_signals": [ "Prohibited domain list does not include all legally restricted knowledge categories.", "Conditionally authorized regulatory domains activated without documented authorization basis.", "Legal escalation process not defined for blocked access attempts to privileged domains." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Domain boundary definition is typically absent or informal in enterprise AI deployments; systems frequently retrieve from domains that were never intended to be in scope." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "Knowledge Engineering Team", "Platform Engineering", "Legal / Compliance", "IT Security" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a74.3", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a74.3 requires organizations to determine the scope and boundaries of the AI management system. Knowledge domain boundary definition operationalizes scope limitation at the retrieval layer, giving the management-system scope an enforceable technical expression.", "normative_force": "certification-standard", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_27002", "requirement_id": "\u00a75.10", "fit": "direct", "rationale": "ISO/IEC 27002:2022 \u00a75.10 requires defining and enforcing acceptable use policies for information and other associated assets. Domain boundary definition applies this principle to AI retrieval systems, establishing the authorized scope for knowledge asset access and the prohibited categories that must never be queried.", "normative_force": "voluntary-standard", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2)", "fit": "direct", "rationale": "EU AI Act Art. 9(2) requires high-risk AI systems to have risk management systems that identify and analyze known and foreseeable risks associated with the AI system. Domain boundary definition directly addresses the risk of unauthorized knowledge access and scope creep, and the boundary enforcement controls constitute risk treatment measures required by this provision.", "normative_force": "binding-law", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_azure_ai", "requirement_id": "Azure AI Search index scope configuration", "fit": "adjacent", "rationale": "Microsoft Azure AI Search provides index-level scope configuration and content filtering that maps to domain boundary enforcement at the platform layer. Organizations using Azure AI Search should configure index scope and content filtering policies to enforce the domain boundary definitions established in this control.", "normative_force": "best-practice", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KS-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The AI retrieval system must enforce a formally documented domain boundary policy that classifies all candidate knowledge domains as authorized, conditionally authorized, or prohibited. The retrieval pipeline must block and log all attempts to query sources outside authorized domains at the connector resolution layer, and no conditionally authorized source may be queried without verified satisfaction of its documented access conditions.", "evidence_required": [ "domain_boundary_policy_document listing all candidate knowledge domains with their classification (authorized/conditionally-authorized/prohibited), governance approval date, and next review date", "retrieval_pipeline_allowlist_configuration_evidence confirming domain boundary enforcement at the connector resolution layer, with no prohibited or unclassified domain URIs accessible", "blocked_retrieval_attempt_log for the review period showing blocked domain, source URI, requesting context, timestamp, and investigation_status for each blocked event", "conditionally_authorized_access_log confirming access condition verification was recorded as a prerequisite for each query to a conditionally authorized source during the review period" ], "machine_tests": [ "Attempt to configure a retrieval connector pointing to a source URI classified as 'prohibited' in the domain boundary policy \u2192 assert connector activation is blocked with error code 'domain_prohibited'", "Submit a retrieval query containing a crafted prompt attempting to force resolution of a prohibited domain URI through prompt injection \u2192 assert retrieval pipeline blocks the URI and emits a boundary_violation event in the audit log", "Query the blocked_retrieval_attempt_log for entries where investigation_status is null and detected_at is older than the defined investigation SLA \u2192 assert zero results" ], "human_review": [ "Review the prohibited domain list with legal counsel to confirm all legally restricted categories are enumerated, including PII data stores, privileged communications, insider-information domains, and jurisdictionally restricted content", "Analyze the blocked retrieval attempt log for the review period to identify patterns indicating prompt injection attempts, misconfigured connectors, or scope expectation misalignment warranting policy updates", "Verify that conditionally authorized domains have documented authorization bases reviewed by legal prior to activation and that access conditions are enforced by technical controls, not user discretion" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Defining domain boundaries only in a policy document without wiring them into technical allowlist enforcement at the retrieval pipeline layer, leaving boundaries as advisory guidance rather than blocking controls", "Using broad domain classifications such as 'all internal documents as authorized' rather than explicit source URI ranges, making boundary enforcement ambiguous and creating unauditable scope boundaries", "Treating the prohibited domain list as a static document that is never updated as the AI system's scope evolves, new sensitive content categories are identified, or regulatory requirements change", "Allowing conditionally authorized domain access to proceed based on user-facing configuration inputs without a technical control verifying the access condition is satisfied at query execution time", "Logging blocked retrieval attempts without systematically investigating them, discarding the governance signal that boundary violation events provide about prompt injection activity or connector misconfiguration" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KS" }, { "id": "KS-07", "layer": "KS", "plane": "control", "name": "Source Attribution and Citation Disclosure Requirements", "plain": "AI systems must cite the knowledge sources used when making factual claims in their outputs, including source register ID, authority tier, and retrieval timestamp, and must emit a disclosure flag when a claim is made without a supporting source from the authorized knowledge base.", "threat": { "tags": [ "hallucination-opacity", "unsourced-claim-presentation", "attribution-laundering" ], "desc": "AI systems that make factual claims without source attribution create an epistemic illusion that the claim is grounded in authoritative knowledge. When the claim is a model hallucination or drawn from a low-authority tertiary source, users have no signal to calibrate confidence appropriately. Attribution laundering \u2014 presenting a low-authority source as the basis for a high-confidence claim \u2014 is indistinguishable from legitimate citation without mandatory tier disclosure. Regulatory frameworks increasingly require AI systems to be transparent about the basis for factual outputs." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 13(1)", "title": "Transparency and provision of information to deployers" }, { "id": "iso_42001", "section": "A.7.5", "title": "Data provenance" }, { "id": "w3c_prov", "section": "PROV-DM \u00a75.3.2", "title": "Attribution \u2014 ascribing entities to agents" }, { "id": "anthropic_transparency", "section": "Model card \u2014 knowledge cutoff disclosure", "title": "Training data cutoff disclosure" } ], "sources": [ { "id": "anthropic_model_cards_2024", "title": "Anthropic Model Cards & Knowledge Disclosure", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/transparency", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_transparency", "relationship": "informative_reference", "rationale": "Establishes Anthropic Model Cards & Knowledge Disclosure requirements informing the apeiris://knowledge/controls/KS-07 Source Attribution and Citation Disclosure Requirements control.", "reviewed_on": "2026-07-01" }, { "id": "google_vertex_ai_rag_2024", "title": "Google Vertex AI RAG & Grounding", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/vertex-ai/docs/generative-ai/grounding/overview", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_vertex_ai_rag_2024", "relationship": "informative_reference", "rationale": "Establishes Google Vertex AI RAG & Grounding requirements informing the apeiris://knowledge/controls/KS-07 Source Attribution and Citation Disclosure Requirements control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "System-level citation mandate with structured attribution metadata in AI outputs: source register ID, source name, authority tier, and retrieval timestamp. Outputs without source grounding must include an explicit disclosure flag distinguishing model-internal knowledge from retrieved knowledge.", "steps": [ "Define citation format standards: each factual claim in AI output must reference at least one source from the authorization register using the source ID, name, authority tier, and retrieval timestamp.", "Implement citation metadata injection in the retrieval-augmented generation pipeline, binding each generated passage to its retrieval source register entry before the response is returned.", "Configure the AI system to emit a disclosure flag when a response includes claims without corresponding source citations from the authorized knowledge base, clearly distinguishing model-internal knowledge from retrieved knowledge.", "Document citation standards in system documentation accessible to deployers and end users, including explanations of tier labels and how to interpret disclosure flags." ], "knowledge_engineer": { "summary": "Citation requirements must be enforced in the output pipeline by binding each generated claim to its retrieval source ID and metadata before the response is finalized. Disclosure flags require logic that detects claim scope exceeding the retrieved context.", "actions": [ "Implement citation metadata injection in the RAG pipeline, mapping each generated passage to its source register entry ID, tier, and retrieval timestamp.", "Build disclosure flag logic that detects unsourced claims and annotates them with an explicit disclosure marker in the response metadata.", "Expose source tier and retrieval timestamp in the citation metadata schema returned with every response." ], "failure_signals": [ "AI output responses with factual claims but no citation metadata.", "Disclosure flags not emitted for responses where claims exceed the knowledge base scope.", "Citation metadata not linked to source register IDs." ] }, "data_scientist": { "summary": "Attribution accuracy requires evaluating whether generated output is genuinely grounded in the cited sources, not merely citing them post-hoc. Use entailment-based metrics to measure attribution faithfulness.", "actions": [ "Evaluate attribution faithfulness using entailment-based metrics that compare generated claims against the cited source text.", "Monitor the rate of unsourced claims per output session as a grounding quality metric in the evaluation dashboard.", "Include attribution accuracy as a named dimension in the AI system evaluation scorecard and report it per model version." ], "failure_signals": [ "Attribution faithfulness score below 0.80 on the evaluation benchmark set.", "Unsourced claim rate above 15% of factual claims in representative evaluation queries.", "Attribution accuracy not included as a named metric in the system evaluation scorecard." ] }, "it_operations": { "summary": "Citation metadata is serving-path plumbing: source IDs and disclosure flags must survive every hop from retrieval through generation to the user-facing response payload.", "actions": [ "Propagate source register IDs through the retrieval and generation pipeline into the response payload schema.", "Monitor the fraction of responses emitted with complete citation metadata and alert on drops.", "Version the citation schema and test that downstream consumers render disclosure flags correctly." ], "failure_signals": [ "Responses reach users with citation fields stripped by an intermediate service.", "Citation completeness metrics drop after a pipeline deployment." ] }, "grc_auditor": { "summary": "Citation disclosure requirements provide evidence that the AI system is transparent about the basis for its outputs, directly satisfying transparency obligations under several regulatory frameworks for high-risk AI systems.", "actions": [ "Review a sample of AI system outputs and verify that factual claims include citation metadata with source ID, tier, and retrieval timestamp.", "Confirm that disclosure flags are emitted and visible to users for claims not grounded in the authorized knowledge base.", "Verify that citation standards are documented in system documentation accessible to deployers and end users." ], "metrics": [ "Citation metadata coverage rate for factual claims: target \u226595% in sampled outputs.", "Disclosure flag emission rate for unsourced claims: target 100%.", "User-facing citation documentation coverage: target 100% of deployment contexts." ], "failure_signals": [ "Factual claims in outputs without citation metadata.", "Unsourced claims without disclosure flags in sampled output review.", "Citation standards not documented or not accessible to deployers." ] }, "legal_counsel": { "summary": "Citation disclosure creates legal accountability trails for AI factual claims and is increasingly required by transparency regulations. It also limits liability by making the evidentiary basis for AI outputs auditable and reproducible.", "actions": [ "Review citation format standards to confirm they satisfy transparency requirements under applicable regulations including the EU AI Act Art. 13.", "Confirm that citation records are retained in audit logs at a granularity sufficient to support legal and regulatory inquiries.", "Assess whether citation disclosures meet sector-specific AI output transparency requirements applicable to the deployment context." ], "failure_signals": [ "Citation format does not satisfy transparency requirements under applicable regulations.", "Citation records not retained in auditable logs for the required retention period.", "Sector-specific transparency requirements not assessed for the current deployment context." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Structured citation with source register linkage and disclosure flags is uncommon in enterprise AI deployments; most systems provide informal references or no attribution at all." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Knowledge Engineering Team", "AI Product Team", "Legal / Compliance" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 13(1)", "fit": "direct", "rationale": "EU AI Act Art. 13(1) requires high-risk AI systems to be designed with sufficient transparency to enable deployers to interpret and use outputs appropriately. Source attribution in AI outputs is a direct transparency mechanism that enables deployers to understand the evidentiary basis for generated claims and assess their reliability.", "normative_force": "binding-law", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "A.7.5", "fit": "direct", "rationale": "ISO/IEC 42001:2023 Annex A control A.7.5 requires the provenance of data used in AI systems to be recorded and available. Source citation requirements surface that provenance at the individual output level, providing per-claim traceability to the underlying knowledge sources.", "normative_force": "certification-standard", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "w3c_prov", "requirement_id": "PROV-DM \u00a75.3.2", "fit": "direct", "rationale": "W3C PROV-DM \u00a75.3.2 defines Attribution (wasAttributedTo), linking a generated entity to the agent responsible for it. Applying this to AI outputs means attributing generated factual claims to the knowledge sources from which they derive, following the PROV attribution model.", "normative_force": "voluntary-standard", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_transparency", "requirement_id": "Model card \u2014 knowledge cutoff disclosure", "fit": "adjacent", "rationale": "Anthropic's model cards disclose the training data cutoff for deployed models \u2014 a source-transparency disclosure at the model level. This control extends the same transparency principle to individual outputs by mandating structured citation metadata and disclosure flags; the model card itself does not define a citation or grounding policy.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_vertex_rag", "requirement_id": "Grounding citations and source attribution", "fit": "adjacent", "rationale": "Google Vertex AI RAG provides built-in citation and grounding features that return structured source references alongside generated content. Organizations using Vertex AI RAG should configure these features and map their citation output to the source register ID schema required by this control.", "normative_force": "best-practice", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KS-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "AI system outputs containing factual claims must include structured citation metadata that binds each claim to a source register entry with source_id, authority_tier, and retrieval_timestamp fields. Outputs containing claims not grounded in the authorized knowledge base must emit an explicit disclosure_flag distinguishing model-internal knowledge from retrieved knowledge. Citation metadata injection must occur in the pipeline before any response is returned.", "evidence_required": [ "rag_output_citation_sample of 50 representative AI responses showing citation_metadata with source_id, source_name, authority_tier, and retrieval_timestamp fields for each grounded factual claim", "disclosure_flag_emission_log confirming all AI responses containing unsourced claims received a disclosure_flag field in response metadata during the review period", "citation_faithfulness_evaluation_report showing entailment-based attribution faithfulness scores per model version, stratified by authority tier and reporting unsourced claim rate", "citation_standards_user_documentation confirming that authority tier label meanings and disclosure flag interpretation guidance are accessible to deployers and end users in the deployment context" ], "machine_tests": [ "Submit 10 retrieval queries known to be outside the authorized knowledge base scope \u2192 assert each response includes a disclosure_flag='unsourced_claim' field in metadata and contains no fabricated source register citations", "Parse 50 sampled AI responses for factual claim spans \u2192 assert each claim span has a corresponding citation_metadata entry with non-null source_id, authority_tier, and retrieval_timestamp fields", "Verify that citation source_ids present in sampled AI output metadata resolve to active entries in the source authorization register \u2192 assert 100% of cited source_ids match a current active register entry" ], "human_review": [ "Review attribution faithfulness evaluation results and verify that generated claims are genuinely entailed by cited source passages, not merely co-located with cited text in the retrieval context window", "Confirm that disclosure flags are surfaced in user-facing interfaces or API response structures in an interpretable position, not buried in nested metadata fields invisible to typical deployers", "Assess whether citation format and disclosure flag standards satisfy transparency obligations under applicable regulations including EU AI Act Art. 13(1) for the deployment contexts in which the system operates" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Appending source citations as post-hoc lists at the end of AI responses without binding specific citations to specific claims, making it impossible to determine which source supports which factual assertion", "Citing sources that were retrieved by the RAG pipeline and included in the context window but were not actually used in generating the specific claim, creating false attribution grounding", "Suppressing disclosure flags for unsourced claims in high-confidence generation scenarios, assuming model confidence correlates with factual accuracy and removing the governance signal distinguishing retrieved from hallucinated content", "Using platform-generated citation references that map to internal chunk IDs or vector index positions rather than source register IDs, making citations unverifiable by auditors outside the system", "Treating source citation requirements as a user-experience feature subject to disabling for 'cleaner' output formatting, rather than as a compliance control that must be enforced regardless of presentation preferences" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KS" }, { "id": "KS-08", "layer": "KS", "plane": "lifecycle", "name": "Knowledge Sources Evidence Package", "plain": "The organization must compile and maintain a structured evidence package demonstrating that all KS-layer controls are implemented, including artifacts from the source authorization register, authority classifications, currency policy enforcement, provenance records, conflict resolution logs, domain boundary enforcement, and citation compliance reporting, compiled under a signed KG-08 attestation record.", "threat": { "tags": [ "unauditable-knowledge-governance", "evidence-gap", "compliance-assertion-without-proof" ], "desc": "Organizations that implement individual KS-layer controls in isolation without a consolidated evidence package cannot demonstrate to auditors, regulators, or relying parties that knowledge governance is operating cohesively. Evidence gaps \u2014 artifacts that exist locally but are not compiled, version-controlled, and accessible \u2014 are functionally equivalent to missing controls during a compliance review. An AI system's knowledge governance posture must be provable from a single evidence package, not reconstructed ad hoc from distributed sources under audit pressure." }, "standard": [ { "id": "iso_42001", "section": "\u00a79.2", "title": "AI management system internal audit and evidence requirements" }, { "id": "eu_ai_act", "section": "Art. 11", "title": "Technical documentation requirements for high-risk AI" }, { "id": "iso_30401", "section": "\u00a79.1", "title": "Knowledge management performance evaluation" }, { "id": "dama_dmbok", "section": "Ch. 15", "title": "Data Management Maturity Assessment" } ], "sources": [ { "id": "aws_bedrock_knowledge_bases_2024", "title": "Amazon Bedrock Knowledge Bases", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_knowledge_bases_2024", "relationship": "informative_reference", "rationale": "Establishes Amazon Bedrock Knowledge Bases requirements informing the apeiris://knowledge/controls/KS-08 Knowledge Sources Evidence Package control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Structured evidence package compiled per assessment cycle, containing required artifacts from each of KS-01 through KS-07, stored in an immutable evidence repository with version control, completeness attestation, and a signed summary attestation record conforming to the KG-08 attestation schema.", "steps": [ "Define the KS evidence package manifest: a versioned document specifying the required artifact from each KS control \u2014 register export from KS-01, classification rubric and coverage report from KS-02, currency policy and staleness status report from KS-03, provenance records sample from KS-04, conflict register export from KS-05, domain boundary policy and blocked attempt log from KS-06, citation compliance metrics report from KS-07.", "Establish a compilation cadence aligned with audit cycles: at minimum quarterly for continuous assurance programs and annually for certification-period assessments.", "Automate artifact collection where possible: generate register exports, staleness reports, conflict register exports, and citation compliance metrics programmatically at the close of each assessment period and push them to the immutable evidence repository.", "Produce a signed summary attestation record using the KG-08 attestation schema referencing all compiled artifacts by SHA-256 hash, confirming the assessment period, reviewer identity, completeness verdict, and overall knowledge governance assessment result." ], "knowledge_engineer": { "summary": "Evidence package compilation should be largely automated, pulling versioned exports from each KS-layer system at the close of each assessment period and storing them in an immutable evidence repository.", "actions": [ "Build automated evidence collection jobs that export register data, staleness reports, conflict registers, and citation compliance metrics at the close of each assessment period.", "Store all evidence artifacts in a versioned, immutable evidence repository with SHA-256 hash verification.", "Implement the evidence package manifest as a machine-readable document linking each artifact to its source control and hash." ], "failure_signals": [ "Evidence package missing required artifacts from any KS control layer.", "Artifacts not stored with integrity hashes in the evidence repository.", "Evidence package not compiled within the defined assessment cadence." ] }, "data_scientist": { "summary": "The evidence package aggregates source-quality metrics; those numbers must be reproducible from raw telemetry, or the package attests to figures nobody can regenerate.", "actions": [ "Make the queries and notebooks that produce source-quality metrics version-controlled and re-runnable.", "Reconcile packaged metrics against raw retrieval and ingestion telemetry each cycle before sign-off.", "Flag metric definitions that changed between packages so trend lines are not silently broken." ], "failure_signals": [ "Packaged metrics cannot be regenerated from the underlying telemetry.", "A metric definition changed mid-year and the package presents the series as continuous." ] }, "it_operations": { "summary": "Evidence package infrastructure requires an immutable artifact repository with access controls ensuring only authorized evidence collection jobs can write artifacts, and with retention policies meeting regulatory minimums.", "actions": [ "Provision an immutable evidence repository with write-once access controls for evidence collection jobs and read-only access for auditors.", "Configure retention policies to maintain evidence packages for a minimum of 5 years or applicable regulatory minimum, whichever is longer.", "Monitor evidence collection job execution and alert on failures that would result in incomplete evidence packages." ], "failure_signals": [ "Evidence repository without write-once or immutability controls.", "Evidence collection jobs failing silently without alerting the knowledge governance team.", "Retention policy below the required minimum duration." ] }, "grc_auditor": { "summary": "The KS evidence package is the primary artifact for assessing knowledge governance maturity and the only artifact that demonstrates all KS-layer controls are operating together as a system. It must be complete, current, and compilable without ad-hoc reconstruction.", "actions": [ "Request the current KS evidence package and verify completeness against the defined evidence package manifest.", "Verify artifact integrity hashes against underlying source systems for a random sample of artifacts.", "Confirm a signed KG-08 summary attestation record is present, complete, and references all required artifacts." ], "metrics": [ "Evidence package completeness rate: target 100% of required artifacts present per the manifest.", "Evidence compilation cycle adherence: target 100% of packages compiled within the defined cadence.", "Artifact integrity verification pass rate: target 100% on all sampled artifacts." ], "failure_signals": [ "Evidence package missing required artifacts from any KS control layer.", "Evidence packages not compiled within the defined cadence for two or more consecutive periods.", "Integrity hash verification failures on any sampled artifact.", "Signed KG-08 summary attestation record absent or unsigned." ] }, "legal_counsel": { "summary": "The KS evidence package is the legal defensibility record for AI knowledge governance. It must be complete, retained for required periods, and producible in response to regulatory inquiries or litigation.", "actions": [ "Review the evidence package manifest to confirm it captures all artifacts required for regulatory compliance under applicable frameworks including the EU AI Act.", "Confirm the retention policy for evidence packages meets applicable regulatory minimum requirements.", "Establish a process for evidence package production in response to regulatory inquiries, including defined access controls and chain-of-custody documentation." ], "failure_signals": [ "Evidence package manifest does not capture all regulatory-required artifacts.", "Retention period below the applicable regulatory minimum.", "No defined process for evidence package production in response to regulatory or legal inquiry." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Consolidated knowledge governance evidence packages are absent in most enterprises; audits require ad-hoc artifact reconstruction from distributed systems." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Knowledge Engineering Team", "GRC Team", "Platform Engineering" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a79.2", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a79.2 requires organizations to conduct internal audits of the AI management system at planned intervals and retain documented information as evidence of audit results. The KS evidence package is the compiled artifact set that satisfies this evidence retention and audit readiness requirement for the knowledge sources layer.", "normative_force": "certification-standard", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 11", "fit": "direct", "rationale": "EU AI Act Art. 11 requires providers of high-risk AI systems to draw up and maintain technical documentation demonstrating conformity. The KS evidence package constitutes the technical documentation artifacts for the knowledge governance dimension of this requirement, providing the compilation needed to support conformity assessment.", "normative_force": "binding-law", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_30401", "requirement_id": "\u00a79.1", "fit": "direct", "rationale": "ISO 30401:2018 \u00a79.1 requires organizations to evaluate the performance and effectiveness of their knowledge management system and retain documented information as evidence of the results. The KS evidence package operationalizes this performance evaluation evidence requirement for AI knowledge source governance.", "normative_force": "certification-standard", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 15", "fit": "partial", "rationale": "DAMA-DMBOK 2nd edition Chapter 15 (Data Management Maturity Assessment) addresses measuring and evidencing the effectiveness of data management programs. The KS evidence package applies this assessment discipline to AI knowledge source governance, aggregating the metrics and artifacts needed to assess whether the governance program is operating as intended.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_bedrock_kb", "requirement_id": "Knowledge Bases audit logging and compliance", "fit": "adjacent", "rationale": "Amazon Bedrock Knowledge Bases provides audit logging and compliance features including data source access logs and ingestion activity records that serve as artifact sources for the KS evidence package. Organizations using Bedrock should configure audit logging exports to feed into the automated evidence collection pipeline defined in this control.", "normative_force": "best-practice", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KS-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The KS evidence package must exist, be complete against the defined artifact manifest (one artifact per KS-01 through KS-07), contain SHA-256 integrity hashes for every artifact, have been compiled within the required assessment cadence, and be signed under a valid KG-08 attestation record referencing all artifacts by hash.", "evidence_required": [ "KS evidence package manifest listing all required artifacts per KS control with SHA-256 hashes and compilation timestamp within the assessment period", "Automated evidence collection job execution logs confirming artifact export timestamps and success status for the current assessment cycle", "Signed KG-08 attestation record containing reviewer_id, assessment_period, completeness_verdict, and a valid digital signature over the artifact set", "Immutable evidence repository access control configuration confirming write-once access for authorized collection jobs and read-only access for auditors", "Artifact integrity verification report showing SHA-256 hash comparison results against underlying source systems for a sampled artifact set" ], "machine_tests": [ "Parse evidence package manifest and verify artifact count \u2192 assert all 7 required KS control artifacts are listed with non-null SHA-256 hashes", "Recompute SHA-256 hash of each compiled evidence artifact and compare against the manifest-recorded hash \u2192 assert zero mismatches across all artifacts", "Retrieve the KG-08 attestation record and inspect fields \u2192 assert reviewer_id, assessment_period, completeness_verdict, and digital signature are all present and non-null", "Query evidence collection job execution history \u2192 assert at least one successful run exists within the configured assessment cadence window (quarterly or annual)" ], "human_review": [ "Review the KG-08 attestation record for completeness and verify the completeness_verdict accurately reflects the full artifact set rather than being pre-populated without verification", "Assess whether the evidence package manifest requirements and assessment cadence remain appropriate for the organization's audit cycle and regulatory commitments", "Verify that the evidence repository immutability controls and retention policy align with applicable regulatory minimum retention periods and cannot be overridden by collection jobs" ], "blocking_effect": "blocks-deployment", "normative_status": "certification-standard", "anti_patterns": [ "Reconstructing evidence ad hoc from distributed systems at audit time rather than compiling artifacts at the close of each defined assessment period", "Storing evidence artifacts without SHA-256 integrity hashes, making post-compilation tampering undetectable during audits", "Signing the KG-08 attestation record before verifying that all required artifacts are present and their stored hashes match the underlying source systems", "Treating evidence package compilation as a manual GRC exercise rather than an automated collection pipeline, creating dependency on individual effort at audit time", "Including artifact references in the manifest that point to mutable storage locations where content can be overwritten after the attestation record is signed" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KS" }, { "id": "KI-01", "layer": "KI", "plane": "control", "name": "Ingestion Pipeline Authorization", "plain": "Every content source feeding the knowledge base must be explicitly authorized through a governed approval gate before ingestion is permitted, with authorization records linked to source type, data classification, and responsible owner.", "threat": { "tags": [ "unauthorized-ingestion", "supply-chain-compromise", "ungoverned-source", "privilege-escalation" ], "desc": "Without explicit source authorization, attackers or misconfigured processes can inject arbitrary content into the knowledge base by connecting new unreviewed sources. Supply chain compromises targeting upstream data providers bypass perimeter controls entirely. Unauthorized sources accumulate over time as organizational changes orphan ownership records, leaving ungoverned pipelines that persist indefinitely." }, "standard": [ { "id": "iso_42001", "section": "\u00a76.1.2", "title": "AI risk assessment" }, { "id": "eu_ai_act", "section": "Art. 10(2)(f)\u2013(g)", "title": "Data governance \u2014 examination and mitigation of biases" }, { "id": "iso_30401", "section": "\u00a74.4.2", "title": "Knowledge development \u2014 acquiring new knowledge" }, { "id": "dama_dmbok", "section": "Ch. 8", "title": "Data integration and interoperability governance" } ], "sources": [ { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a76.1.2 requirements informing the apeiris://knowledge/controls/KI-01 Ingestion Pipeline Authorization control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 10(2)(f)\u2013(g) requirements informing the apeiris://knowledge/controls/KI-01 Ingestion Pipeline Authorization control.", "reviewed_on": "2026-07-02" }, { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements \u00a74.4.2 requirements informing the apeiris://knowledge/controls/KI-01 Ingestion Pipeline Authorization control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 8 requirements informing the apeiris://knowledge/controls/KI-01 Ingestion Pipeline Authorization control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Maintain a source authorization registry with approval workflow; each source entry records content type, data classification ceiling, owning team, approval expiry, and integration credentials. Ingestion pipelines perform a registry lookup before accepting any content batch; unapproved sources are rejected with an alert.", "steps": [ "Deploy a source authorization registry with structured entries: source_id, content_type, classification_ceiling, owner, approved_by, approved_at, expiry_date, and status.", "Integrate a pre-ingestion authorization check into all pipeline connectors so that content from any unregistered or expired source is blocked at the boundary and an alert is raised.", "Establish an annual re-authorization workflow requiring owners to confirm the source remains appropriate; auto-suspend sources whose authorization lapses.", "Define approval roles: source owners propose, data stewards validate classification, a knowledge governance board approves high-risk or external sources." ], "knowledge_engineer": { "summary": "The authorization registry is the ingestion boundary. No source enters the pipeline without a valid registry entry. Enforce this at the connector layer, not application logic.", "actions": [ "Build or configure pipeline connectors to call the registry API before accepting any batch.", "Implement hard-block logic on unapproved source IDs with structured error logging.", "Expose a self-service registration form for new source proposals that routes to the governance workflow." ], "failure_signals": [ "Any content successfully ingested from an unregistered source.", "Authorization registry entries with no owner assignment for more than 30 days.", "Expired authorizations not suspended within 24 hours of expiry." ] }, "data_scientist": { "summary": "Ingestion authorization protects your training and retrieval corpora: content that bypasses the gate enters embeddings and evaluations unvetted, and its effects are hard to unwind.", "actions": [ "Verify that every corpus used for embedding, fine-tuning, or evaluation entered through an authorized ingestion pipeline.", "Trace unexplained distribution shifts in the index back through ingestion records to find unauthorized paths.", "Refuse to build models or baselines on corpora lacking ingestion authorization records." ], "failure_signals": [ "An embedding corpus contains documents with no ingestion authorization record.", "A distribution shift in the index traces to an ad-hoc bulk load that bypassed the gate." ] }, "it_operations": { "summary": "Operationally enforce the registry lookup as a hard dependency; pipeline connectors must fail-closed when the registry is unreachable.", "actions": [ "Configure connectors to fail-closed on registry API timeout, with alerting to on-call.", "Monitor registry API availability and set SLO at 99.9% uptime.", "Automate suspension of expired entries via a scheduled job that writes back to the registry." ], "failure_signals": [ "Pipeline connectors configured to bypass the registry check when it is unavailable.", "Registry API downtime exceeding SLO without an incident ticket.", "Expired entries remaining in active status beyond the defined grace period." ] }, "grc_auditor": { "summary": "The source authorization registry is the primary artifact demonstrating that knowledge ingestion is governed. Sample entries against deployment records and verify approval evidence exists.", "actions": [ "Export the full source registry and cross-reference against active pipeline connectors to identify ungoverned sources.", "Sample 20% of approved sources and verify each has a documented approver, approval date, and classification ceiling.", "Review alert logs for blocked ingestion attempts to confirm the control is operationally effective." ], "metrics": [ "Source registry completeness rate: target 100% of active connectors have a registry entry.", "Authorization currency rate: target 100% of entries within expiry window.", "Mean time to suspend expired sources: target under 24 hours." ], "failure_signals": [ "Active pipeline connectors with no corresponding registry entry.", "Registry entries approved without a named approver in the audit log.", "No blocked ingestion alerts over a 90-day period despite active ingestion from new sources." ] }, "legal_counsel": { "summary": "The authorization gate is where content liability is controllable: once unvetted third-party content is ingested and served, copyright, confidentiality, and privacy exposure has already attached.", "actions": [ "Require legal review as an authorization criterion for source categories with elevated IP or privacy risk.", "Confirm ingestion agreements and licenses are recorded at authorization time, not reconstructed later.", "Treat discovered unauthorized ingestion as a potential legal incident, not only an engineering defect." ], "failure_signals": [ "Content from an unlicensed source is discovered in the serving index.", "No record exists of who authorized a legally sensitive source's ingestion." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises lack a formal source authorization registry; ingestion sources accumulate informally as teams add connectors without governance review." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Knowledge Engineering", "Data Governance", "Platform Engineering", "Security Operations" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a76.1.2", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a76.1.2 requires organizations to establish an AI risk assessment process that identifies risks associated with AI systems and their inputs, including knowledge sources. An ingestion authorization gate ensures every knowledge input has been assessed against organizational risk tolerance before it can enter the pipeline.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10(2)(f)\u2013(g)", "fit": "direct", "rationale": "EU AI Act Article 10(2)(f) and (g) require data governance practices covering examination for possible biases and measures to detect, prevent and mitigate them. Source authorization is the foundational governance mechanism ensuring only vetted data enters the knowledge pipeline where such examination can be applied. Non-compliance exposes providers to Article 99 penalties.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_30401", "requirement_id": "\u00a74.4.2", "fit": "direct", "rationale": "ISO 30401:2018 \u00a74.4.2 requires the knowledge management system to address acquiring new knowledge, which entails defined processes for evaluating and taking on knowledge from sources. The ingestion authorization registry operationalizes governed acquisition with a documented, auditable record of source approval decisions.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 8", "fit": "partial", "rationale": "DAMA DMBOK2 Chapter 8 on Data Integration and Interoperability establishes principles for governing how data flows between systems, including authorization and ownership requirements for data feeds. The source authorization control applies these principles specifically to AI knowledge base ingestion pipelines. The fit is partial because DAMA DMBOK2 addresses general data integration rather than AI-specific knowledge base management.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KI-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every active ingestion pipeline connector must successfully resolve the source it is connecting to against a current, non-expired entry in the source authorization registry before any content batch is accepted; content from any unregistered, expired, or suspended source must be blocked at the connector layer and logged as an alert; the registry API must be configured fail-closed so that connector downtime prevents ingestion rather than bypasses the check.", "evidence_required": [ "Source authorization registry export listing all entries with source_id, status, content_type, owner, approved_by, approved_at, and expiry_date for the assessment period", "Ingestion pipeline connector configuration showing the pre-ingestion registry API lookup call with fail-closed error handling code path and structured rejection logging", "Blocked ingestion alert log for the assessment period confirming the gate fired on at least one rejection event with source_id and failure_reason", "Registry API availability monitoring record confirming SLO compliance for the assessment period with no unmitigated outage events", "Annual re-authorization workflow records showing owner confirmation events for all active sources renewed within their expiry window" ], "machine_tests": [ "Submit a content batch from a source_id not present in the authorization registry \u2192 assert the pipeline returns a structured rejection error and raises an alert log entry", "Submit a content batch from a source with expiry_date set to yesterday \u2192 assert the pipeline blocks it, suspends the source entry, and does not write any content to the knowledge base", "Simulate registry API timeout during an active ingestion attempt \u2192 assert the pipeline connector fails-closed and no content is ingested from the pending batch", "Submit a valid authorized content batch from a current active registry entry \u2192 assert ingestion succeeds and the audit log records source_id, owner, and approved_at" ], "human_review": [ "Review the source authorization registry for entries with no owner assignment or approval records lacking a named approver, and confirm each has a remediation plan", "Assess whether the annual re-authorization workflow is functioning end-to-end and whether expired sources are being automatically suspended within the defined grace period", "Verify that approval role definitions maintain appropriate segregation between source proposers, data stewards who validate classification, and the governance board approving high-risk sources" ], "blocking_effect": "blocks-runtime-action", "normative_status": "certification-standard", "anti_patterns": [ "Configuring pipeline connectors to proceed with ingestion when the authorization registry API is unreachable rather than failing-closed, creating a registry availability bypass", "Performing authorization checks only at source onboarding time rather than at each ingestion batch boundary, allowing authorization to lapse silently between batches", "Maintaining authorization registry entries with lapsed expiry dates that remain in active status beyond the defined grace period due to absent automated suspension", "Using the same identity for both source proposal and source approval, undermining role segregation and governance integrity", "Allowing registry entries to accumulate with no owner assignment, making re-authorization impossible and creating ungoverned sources that persist indefinitely" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KI" }, { "id": "KI-02", "layer": "KI", "plane": "control", "name": "Knowledge Poisoning Detection and Prevention", "plain": "All content submitted for ingestion must pass automated adversarial content screening to detect manipulation, injection payloads, and coordinated poisoning attempts before being written to the knowledge base.", "threat": { "tags": [ "knowledge-poisoning", "adversarial-injection", "retrieval-manipulation", "data-tampering" ], "desc": "Adversaries who can influence upstream data sources can inject carefully crafted content that biases retrieval outcomes, causes the AI system to produce harmful or misleading outputs, or establishes persistent backdoor triggers. Poisoning attacks are particularly dangerous in RAG systems because a single injected document can contaminate many downstream responses before detection. Coordinated poisoning campaigns across multiple sources can systematically shift the knowledge base toward attacker-desired outcomes." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 10(2)(f)", "title": "Data governance \u2014 examination for biases and adversarial manipulation" }, { "id": "iso_42001", "section": "\u00a76.1.3", "title": "AI-specific threat assessment including data poisoning" }, { "id": "iso_27002", "section": "\u00a78.8", "title": "Management of technical vulnerabilities" } ], "sources": [ { "id": "aws_bedrock_knowledge_bases_2024", "title": "Amazon Bedrock Knowledge Bases", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_knowledge_bases_2024", "relationship": "informative_reference", "rationale": "Establishes Amazon Bedrock Knowledge Bases requirements informing the apeiris://knowledge/controls/KI-02 Knowledge Poisoning Detection and Prevention control.", "reviewed_on": "2026-07-01" }, { "id": "openlineage_spec_1_0", "title": "OpenLineage \u2014 Open Standard for Data Lineage", "authority": "OpenLineage / Linux Foundation", "source_type": "standard", "normative_force": "best-practice", "version": "1.0.0", "published_on": "2023-08-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openlineage.io/", "license": "open-access", "status": "current", "flagship": false, "source_id": "openlineage_spec_1_0", "relationship": "informative_reference", "rationale": "Establishes OpenLineage \u2014 Open Standard for Data Lineage requirements informing the apeiris://knowledge/controls/KI-02 Knowledge Poisoning Detection and Prevention control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Deploy a multi-stage poisoning detection pipeline that applies: (1) statistical anomaly detection against the existing corpus, (2) semantic similarity analysis to identify suspiciously redundant or contradictory content, (3) injection payload scanning for prompt injection patterns, (4) source reputation scoring. Content failing any stage is quarantined pending human review.", "steps": [ "Deploy statistical anomaly detection that flags content with unusual token distributions, unexpected topic drift relative to source history, or coordinated similarity clusters suggesting synthetic generation.", "Implement prompt injection pattern scanning that detects instruction-override syntax, role-play directives, and system-prompt escape sequences embedded in document content.", "Build a semantic contradiction checker that identifies content directly contradicting high-confidence existing knowledge entries, routing contradictions to editorial review rather than automatic rejection.", "Establish a quarantine queue for flagged content with SLA-bound human review; maintain a poisoning incident register to track patterns across attempts.", "Integrate source reputation scoring that escalates content from sources with prior poisoning incidents for enhanced screening." ], "knowledge_engineer": { "summary": "Poisoning detection must be layered \u2014 no single signal is sufficient. Build the pipeline to quarantine rather than silently drop suspicious content so patterns can be analyzed.", "actions": [ "Implement and tune anomaly detection thresholds per source type; external web sources require stricter thresholds than controlled internal sources.", "Build the quarantine queue with structured metadata capturing which detection stage flagged the content and with what confidence.", "Develop and maintain a prompt injection signature library updated from public adversarial research." ], "failure_signals": [ "Zero quarantine events over a 30-day period despite active ingestion from external sources.", "Human review queue backlog exceeding 72 hours without escalation.", "Known poisoning test vectors passing detection without quarantine." ] }, "data_scientist": { "summary": "Statistical and semantic anomaly models require calibration against legitimate corpus variation. Tune detection sensitivity to minimize false positives while maintaining recall on adversarial patterns.", "actions": [ "Train and periodically retrain anomaly detection models on historical clean ingestion data, updating baselines as the corpus evolves.", "Run red-team exercises quarterly using published adversarial prompt injection and poisoning datasets to measure detection recall.", "Monitor quarantine queue composition to identify systematic false-positive patterns and adjust model thresholds." ], "failure_signals": [ "False-positive rate above 5% causing legitimate content to be quarantined at scale.", "Detection model last retrained more than 90 days ago despite significant corpus growth.", "Red-team exercises revealing poisoning bypasses not captured by current detection." ] }, "it_operations": { "summary": "Poisoning defenses are operational controls: detection jobs, integrity baselines, and quarantine paths must be deployed, monitored, and exercised like any other security tooling.", "actions": [ "Run poisoning detection on every ingestion batch and keep integrity baselines for comparison scans.", "Wire quarantine so flagged content is isolated from the serving index automatically pending review.", "Exercise the poisoning response runbook periodically, including index rollback from clean snapshots." ], "failure_signals": [ "Detection jobs are green only because they stopped scanning new batches.", "Quarantined content re-enters the index without a documented release decision." ] }, "grc_auditor": { "summary": "Poisoning detection is a critical AI safety control. Verify the pipeline is operationally active, calibrated, and that quarantine items receive timely human review.", "actions": [ "Review quarantine logs and verify each item was reviewed within SLA and disposition was recorded.", "Request red-team exercise results and confirm detection recall meets organizational risk tolerance.", "Verify the poisoning incident register is maintained and patterns are reported to the knowledge governance board." ], "metrics": [ "Quarantine SLA compliance rate: target 95% of items reviewed within 72 hours.", "Detection recall against known adversarial vectors: target above 90%.", "Mean time to close quarantine items: target under 48 hours." ], "failure_signals": [ "Quarantine queue items older than SLA with no assigned reviewer.", "No red-team exercise conducted in the past 6 months.", "Poisoning incident register not updated in more than 30 days despite quarantine activity." ] }, "legal_counsel": { "summary": "A poisoning incident can make the organization an unwitting publisher of manipulated content. Response obligations may include customer notification, regulator reporting, and evidence preservation.", "actions": [ "Define with security when a poisoning event triggers notification or regulatory reporting duties.", "Ensure detection and response records are preserved in a litigation-ready form.", "Review contracts with content providers for warranties and remedies covering supplied-content integrity." ], "failure_signals": [ "Manipulated content influenced customer-facing outputs before detection.", "Response records for a suspected poisoning event were overwritten by routine log rotation." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Poisoning detection for AI knowledge bases is an emerging capability; most organizations rely on upstream source trust rather than active detection at the ingestion boundary." }, "capability_risk": { "capability_level": "low" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "cloud-native" ], "implementers": [ "Data Science", "Knowledge Engineering", "Security Operations", "AI/ML Platform" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 10(2)(f)", "fit": "direct", "rationale": "EU AI Act Article 10(2)(f) explicitly requires high-risk AI systems to examine training and knowledge data for possible biases and errors, which encompasses adversarial manipulation and poisoning. Active detection of poisoning attempts is a direct operationalization of this obligation. Failure to implement such controls exposes providers and deployers to enforcement action under Article 99.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "\u00a76.1.3", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a76.1.3 requires organizations to identify AI-specific threats including data poisoning as part of their AI risk treatment framework. Implementing automated poisoning detection directly operationalizes this risk treatment requirement. The standard's Annex B further identifies data integrity as a key AI management concern requiring active mitigations.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_27002", "requirement_id": "\u00a78.8", "fit": "adjacent", "rationale": "ISO/IEC 27002:2022 \u00a78.8 (Management of technical vulnerabilities) requires organizations to identify and remediate vulnerabilities in information systems. Data poisoning represents a class of exploitable weakness in AI knowledge pipelines, and detection tooling is a mitigating control. The fit is adjacent because \u00a78.8 does not specifically address AI poisoning, but the vulnerability management principle applies.", "normative_force": "voluntary-standard", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_bedrock_kb", "requirement_id": "Guardrails \u2014 content filters and contextual grounding check", "fit": "adjacent", "rationale": "Amazon Bedrock Guardrails provides content filters and a contextual grounding check that can flag responses not supported by, or anomalous relative to, knowledge base content. Aligning poisoning detection with Guardrails gives cloud-native deployments platform-level protection alongside application-layer detection. The fit is adjacent because Guardrails evaluates model inputs and outputs rather than ingestion-time content.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "openlineage", "requirement_id": "Run events (OpenLineage OpenAPI spec)", "fit": "direct", "rationale": "The OpenLineage specification defines run events \u2014 an OpenAPI-specified, vendor-neutral schema for capturing lineage as pipeline jobs execute. KI-02 ingestion pipelines should emit OpenLineage run events to establish traceable knowledge provenance.", "normative_force": "best-practice", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KI-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "All content submitted for ingestion from any source must pass a multi-stage poisoning detection pipeline before being written to the knowledge base; content failing any detection stage must be quarantined with structured metadata capturing the detection stage, confidence, and source; quarantine items must be reviewed within the defined SLA; the detection pipeline must demonstrate recall above 90% against known adversarial vectors in quarterly red-team exercises.", "evidence_required": [ "Quarantine queue log for the assessment period listing all flagged items with detection_stage, confidence, source_id, flagged_at timestamp, reviewer identity, and disposition_at within SLA", "Red-team exercise results report for the assessment period showing poisoning detection recall against published adversarial test vectors including prompt injection patterns and semantic contradiction cases", "Poisoning incident register export showing aggregate pattern analysis across quarantine events including source-level repeat patterns", "Anomaly detection model version record with last retraining date and calibration metrics measured against the current clean corpus baseline", "Prompt injection signature library version and last update date with source attribution confirming currency against published adversarial research" ], "machine_tests": [ "Submit a document containing a known prompt injection pattern (e.g., instruction-override directive embedded in body text) \u2192 assert the content is quarantined with detection_stage=injection_scan and is not written to the knowledge base", "Submit a document with statistical token distribution anomalies consistent with synthetic LLM-generated text \u2192 assert content is quarantined with detection_stage=anomaly_detection rather than auto-accepted", "Submit a document making direct factual contradictions to high-confidence existing knowledge entries \u2192 assert content is routed to editorial review rather than silently auto-accepted", "Submit a clean, structurally normal document from an authorized source with no anomalous patterns \u2192 assert ingestion proceeds without quarantine flag and the content reaches the knowledge store" ], "human_review": [ "Review the quarantine queue for items with human review pending beyond the defined SLA and confirm escalation procedures were followed, with reviewers identified and dispositions documented", "Evaluate red-team exercise findings and determine whether detection capability gaps indicate the anomaly model requires retraining or the signature library requires updates before the next assessment cycle", "Assess the poisoning incident register for patterns suggesting systematic or coordinated campaigns across multiple sources that require source-level suspension or upstream provider engagement" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Relying exclusively on upstream source trust and provider vetting without active detection at the ingestion boundary, assuming trusted sources cannot be compromised", "Silently dropping flagged content without creating a quarantine record, preventing pattern analysis and eliminating the ability to detect coordinated campaigns", "Setting anomaly detection thresholds broadly enough to avoid false positives at the cost of allowing coordinated low-density poisoning campaigns that stay below the statistical detection threshold", "Not updating the prompt injection signature library after new adversarial patterns are publicly disclosed, allowing known bypass techniques to succeed", "Systematically overriding quarantine decisions as false positives without documented review, progressively undermining detection effectiveness through reviewer fatigue patterns" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KI" }, { "id": "KI-03", "layer": "KI", "plane": "data", "name": "Ingestion Format Validation", "plain": "All content submitted for ingestion must pass strict schema validation, character encoding verification, and content-type enforcement at the ingestion boundary before any parsing or downstream processing occurs.", "threat": { "tags": [ "malformed-content", "encoding-exploit", "injection-via-format", "schema-violation" ], "desc": "Malformed or unexpected document formats can trigger parser vulnerabilities, cause embedding failures that silently corrupt knowledge entries, or smuggle executable payloads through encoding tricks. Content-type confusion attacks cause the pipeline to process a document as a different format than intended, potentially bypassing downstream validation logic. Schema violations that are silently tolerated accumulate into a corpus of structurally inconsistent knowledge that degrades retrieval quality over time." }, "standard": [ { "id": "dama_dmbok", "section": "Ch. 13", "title": "Data quality \u2014 completeness, validity, consistency" }, { "id": "iso_42001", "section": "A.7.4", "title": "Quality of data for AI systems" }, { "id": "w3c_prov", "section": "PROV-DM \u00a75", "title": "PROV-DM components \u2014 typed entities and activities" }, { "id": "itil_4", "section": "\u00a75.1.4", "title": "Knowledge management practice" } ], "sources": [ { "id": "microsoft_azure_ai_search_2024", "title": "Microsoft Azure AI Search & Grounding", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/azure/search/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_azure_ai_search_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Azure AI Search & Grounding requirements informing the apeiris://knowledge/controls/KI-03 Ingestion Format Validation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Implement a format validation layer as the first stage of the ingestion pipeline: (1) MIME type detection independent of the declared content-type header, (2) schema validation against registered content type schemas, (3) character encoding normalization with rejection of ambiguous or dangerous encodings, (4) size and structural bounds checking. Only content passing all stages proceeds to parsing.", "steps": [ "Deploy MIME type detection using content inspection independent of declared content-type, rejecting any content where detected and declared types conflict.", "Maintain a content type schema registry with JSON Schema or equivalent definitions for each permitted ingestion format; validate all structured content against the registered schema.", "Enforce character encoding normalization to UTF-8 with explicit rejection of known exploit encodings; validate that the claimed encoding matches the actual encoding before processing.", "Apply size bounds, nesting depth limits, and structural complexity limits per content type to prevent resource exhaustion and decompression bombs.", "Log all validation failures with structured metadata (source_id, content_type, failure_reason, timestamp) for pipeline health monitoring." ], "knowledge_engineer": { "summary": "Format validation must be the pipeline's first gate \u2014 before any parsing that could trigger vulnerabilities. Fail-closed on any validation ambiguity.", "actions": [ "Implement format validation as a separate, independently deployable pipeline stage with no shared state with downstream parsing.", "Maintain the content type schema registry and update schemas when new source formats are approved via KI-01.", "Instrument validation failure rates per source and content type to detect upstream format regressions." ], "failure_signals": [ "Validation stage bypassed or disabled for any content type.", "Schema registry containing content types with no associated schema definition.", "Validation failure rate for a source exceeding 1% without investigation." ] }, "data_scientist": { "summary": "Format validation failures are a signal about upstream data quality. Monitor failure distributions to identify sources degrading in quality before they impact the corpus.", "actions": [ "Build dashboards showing validation failure rates by source, content type, and failure reason.", "Investigate systematic failure patterns to determine if sources have changed format without re-authorization.", "Contribute to schema registry maintenance by identifying format variations observed in practice that require schema updates." ], "failure_signals": [ "Validation failure rate trend increasing without a corresponding authorized source change event.", "Schema registry not updated in more than 90 days despite active ingestion from evolving sources.", "No monitoring dashboard covering validation failure rates by source." ] }, "it_operations": { "summary": "Format validation is a pipeline infrastructure component requiring monitoring and capacity planning for validation throughput.", "actions": [ "Monitor validation stage latency and throughput; alert on degradation that would create ingestion backlogs.", "Ensure validation failures generate structured log events routed to the security monitoring system.", "Maintain format validation library dependencies with a security patch SLA of 30 days for critical vulnerabilities." ], "failure_signals": [ "Validation stage processing latency exceeding SLO thresholds.", "Unpatched critical vulnerabilities in MIME detection or schema validation libraries beyond SLA.", "Validation failure events not appearing in security monitoring dashboards." ] }, "grc_auditor": { "summary": "Format validation is an auditable gate: every ingested document should have a validation verdict, and rejects should be traceable to a rule and a disposition.", "actions": [ "Sample ingestion records quarterly and verify each has a validation verdict tied to a versioned rule set.", "Test that validation cannot be bypassed by re-submitting a rejected document through an alternate path.", "Review rejection dispositions for evidence that failures are remediated rather than force-approved." ], "metrics": [ "Share of ingested documents with recorded validation verdicts (target: 100%)", "Validation bypass attempts detected per quarter", "Median time from validation failure to disposition" ], "failure_signals": [ "Ingested documents lack validation verdicts for periods when the validator was down.", "Rejected documents reappear in the index with no re-validation record." ] }, "legal_counsel": { "summary": "Malformed or exploit-bearing files entering the knowledge pipeline are a security-liability vector; validation records are also the evidence that the organization exercised reasonable care in what it ingested.", "actions": [ "Confirm validation policies cover file types with known exploit history before they reach parsers.", "Preserve validation and rejection records to evidence diligence if ingested content causes harm.", "Review vendor contracts so suppliers warrant the technical integrity of delivered content." ], "failure_signals": [ "An exploit embedded in an ingested document reaches internal parsing infrastructure.", "No validation evidence exists for the period in which a harmful file was ingested." ] } }, "maturity": { "current": "managed", "target": "defined", "notes": "Basic format validation exists in most data pipelines; the gap is AI-specific schema validation for knowledge base ingestion formats and encoding exploit detection." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant" ], "implementers": [ "Platform Engineering", "Knowledge Engineering", "IT Operations" ], "frameworks": [ { "framework": "dama_dmbok", "requirement_id": "Ch. 13", "fit": "direct", "rationale": "DAMA DMBOK2 Chapter 13 on Data Quality establishes completeness, validity, and consistency as core quality dimensions. Format validation directly enforces validity by ensuring content conforms to expected schemas and encodings before entering the knowledge base. The standard's data quality measurement framework provides the basis for defining validation success metrics.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "iso_42001", "requirement_id": "A.7.4", "fit": "direct", "rationale": "ISO/IEC 42001:2023 Annex A control A.7.4 requires organizations to define and apply quality requirements for data used in AI systems. Format validation is a foundational data-quality control that ensures the structural integrity of knowledge base content before use.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "w3c_prov", "requirement_id": "PROV-DM \u00a75", "fit": "partial", "rationale": "W3C PROV-DM \u00a75 defines the typed components of the provenance data model \u2014 entities, activities and agents with well-defined representations. Format validation aligns with the requirement that entities entering provenance chains have well-defined structure. The fit is partial because PROV-DM addresses provenance modeling rather than ingestion validation.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "itil_4", "requirement_id": "\u00a75.1.4", "fit": "adjacent", "rationale": "The ITIL 4 knowledge management practice (5.1.4) emphasizes maintaining knowledge quality through structured processes. Format validation operationalizes that quality-gate concept at the ingestion boundary for AI knowledge services. The fit is adjacent because ITIL addresses service knowledge management broadly rather than AI ingestion pipelines.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_azure_ai", "requirement_id": "Azure AI Search \u2014 Index Schema", "fit": "adjacent", "rationale": "Microsoft Azure AI Search enforces document schema validation at indexing time, providing a platform-native mechanism for format validation in Azure-hosted knowledge bases. Aligning ingestion format validation with Azure's index schema requirements ensures compatibility and leverages platform enforcement. The fit is adjacent as Azure AI Search focuses on indexing rather than pre-ingestion boundary validation.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KI-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every content item submitted for ingestion must pass MIME type detection (independent of the declared content-type header), schema validation against the registered content type schema, character encoding verification confirming the actual encoding matches the declared encoding, and structural bounds checking before any parsing or downstream processing occurs; content with type conflicts, encoding anomalies, schema violations, or bound violations must be rejected and logged with structured failure metadata.", "evidence_required": [ "Format validation pipeline stage configuration showing independent MIME detection logic, content type schema registry linkage, encoding verification settings, and structural bounds limits per content type", "Validation failure log for the assessment period with structured per-failure metadata: source_id, content_type, failure_reason, detected_type, declared_type, and timestamp", "Content type schema registry export listing all permitted ingestion formats with associated schema definitions and last schema update date per format", "Security patch compliance record for MIME detection and schema validation library dependencies confirming no critical vulnerabilities outstanding beyond the 30-day SLA", "Validation stage latency and throughput monitoring records confirming the stage operates within SLO thresholds under production ingestion load" ], "machine_tests": [ "Submit a file with declared content-type application/json but containing binary PDF content \u2192 assert rejection with failure_reason=content_type_mismatch and no downstream processing", "Submit a document declaring UTF-8 encoding but containing byte sequences invalid in UTF-8 \u2192 assert rejection with failure_reason=encoding_validation_failed before any parsing occurs", "Submit a JSON document that violates the registered schema for its declared content type (missing required field or wrong type) \u2192 assert rejection with failure_reason=schema_violation", "Submit a valid document correctly conforming to its declared content type, encoding, and registered schema \u2192 assert acceptance and progression to the next pipeline stage without validation errors" ], "human_review": [ "Review validation failure rate trends per source to identify sources experiencing format regressions that may indicate unauthorized source configuration changes or upstream format drift without re-authorization", "Assess whether the content type schema registry is current and covers all formats actively being submitted from production sources, including any new format types onboarded since the last registry review", "Verify security patch compliance for validation library dependencies against the 30-day critical vulnerability SLA by reviewing patch records against published CVE timelines" ], "blocking_effect": "blocks-runtime-action", "normative_status": "certification-standard", "anti_patterns": [ "Trusting the declared content-type header without independent MIME detection, enabling content-type confusion attacks where a malicious file is processed as a different format", "Disabling schema validation for specific content types because all sources from those types have been vetted, eliminating the defense-in-depth protection layer at the format boundary", "Setting structural bounds limits so permissively high that decompression bomb or deeply nested JSON attacks can exhaust pipeline resources before they are rejected", "Transparently normalizing invalid character encodings to a valid representation rather than rejecting and logging the anomaly, masking potential encoding exploit attempts", "Maintaining the content type schema registry only at source onboarding time and never updating it, allowing format drift to proceed undetected as source content evolves" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KI" }, { "id": "KI-04", "layer": "KI", "plane": "control", "name": "Content Sensitivity Classification at Ingestion", "plain": "All content ingested into the knowledge base must receive an automated sensitivity classification at the ingestion boundary that governs which retrieval contexts and user roles may access it, with human review required for high-sensitivity determinations.", "threat": { "tags": [ "pii-leakage", "over-privileged-retrieval", "classification-bypass", "data-exposure" ], "desc": "Without sensitivity classification at ingestion, confidential or regulated content mixed into a general-purpose knowledge base becomes accessible to any user or agent that can query it, creating data exposure at retrieval time that is difficult to remediate retroactively. Classification applied only at query time is insufficient because the knowledge is already stored without access boundaries. Automated classification errors that under-classify sensitive content expose it to unauthorized retrievers at scale." }, "standard": [ { "id": "iso_27002", "section": "\u00a75.12", "title": "Classification of information" }, { "id": "eu_ai_act", "section": "Art. 10(5)", "title": "Data governance for special categories of personal data" }, { "id": "iso_42001", "section": "A.7.6", "title": "Data preparation \u2014 categorization and labelling" }, { "id": "dama_dmbok", "section": "Ch. 7", "title": "Data security \u2014 classification and access control" } ], "sources": [ { "id": "databricks_unity_catalog_2024", "title": "Databricks Unity Catalog (Knowledge Gov.)", "authority": "Databricks, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.databricks.com/en/data-governance/unity-catalog/index.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "databricks_unity_catalog_2024", "relationship": "informative_reference", "rationale": "Establishes Databricks Unity Catalog (Knowledge Gov.) requirements informing the apeiris://knowledge/controls/KI-04 Content Sensitivity Classification at Ingestion control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Deploy a multi-tier classification engine that runs on all content at ingestion: (1) automated PII/PHI/PCI pattern detection, (2) topic-based sensitivity classification using a trained classifier, (3) source-level classification ceiling inheritance where source authorization specifies an upper bound, (4) human-in-the-loop review for content classified at high or restricted tiers. Store classification labels as metadata on each knowledge entry and enforce at retrieval.", "steps": [ "Deploy pattern-based PII/PHI/PCI detection (regex and NER models) as the first classification stage, flagging any content containing regulated data categories with the appropriate label.", "Train or configure a topic-based sensitivity classifier calibrated to the organization's information classification policy; ensure classification labels map directly to the organization's access control tiers.", "Enforce source classification ceiling inheritance: content from a source authorized at Confidential ceiling cannot receive a lower classification, regardless of content scan results.", "Route all High or Restricted classifications to a human review queue with defined SLA; reviewers can confirm, downgrade with justification, or reject the content entirely.", "Attach classification metadata to every knowledge entry and enforce classification-based access control at all retrieval interfaces." ], "knowledge_engineer": { "summary": "Classification must happen at the ingestion boundary and be stored as immutable metadata. Retrofitting classification onto an existing corpus is operationally expensive \u2014 get it right at ingest.", "actions": [ "Integrate the classification engine into the ingestion pipeline so that no entry reaches the knowledge store without a classification label.", "Implement classification ceiling inheritance logic from the source authorization registry.", "Build classification metadata into the knowledge store schema so it cannot be omitted or null." ], "failure_signals": [ "Knowledge entries with null or missing classification metadata.", "Classification engine not running for any content type or source.", "Human review queue items older than SLA with no assigned reviewer." ] }, "data_scientist": { "summary": "Classification model accuracy directly determines both data exposure risk and knowledge utility. Calibrate for high recall on sensitive categories; accept higher false-positive rates for restricted tiers.", "actions": [ "Evaluate classifier performance against a labeled holdout set quarterly; track precision and recall separately for each classification tier.", "Analyze human review override decisions to identify systematic classifier errors and feed corrections back into model training.", "Monitor classification distribution across sources to detect shifts suggesting source content has changed character." ], "failure_signals": [ "Classifier recall for PII/PHI below 95% on quarterly evaluation.", "Human review override rate above 20%, indicating systematic classifier miscalibration.", "No model retraining for more than 6 months despite accumulated human review feedback." ] }, "it_operations": { "summary": "Sensitivity labels assigned at ingestion must be enforced downstream: index partitioning, retrieval filters, and export paths all read the classification metadata this control writes.", "actions": [ "Propagate sensitivity labels into index metadata and verify retrieval filters honor them.", "Block ingestion of content that arrives without a classification decision rather than defaulting to open.", "Audit export and backup paths to confirm classified content retains its labels outside the primary store." ], "failure_signals": [ "Retrieval filters ignore sensitivity labels after an index schema change.", "Unclassified content is served because ingestion defaulted it to the lowest sensitivity tier." ] }, "grc_auditor": { "summary": "Sensitivity classification is a foundational data governance control. Verify classification coverage, human review compliance, and that retrieval access controls honor classification labels.", "actions": [ "Sample 100 knowledge entries and verify each has a valid classification label with an audit record of how it was assigned.", "Test retrieval access controls by querying as a lower-privilege user for content classified above their tier and confirming it is not returned.", "Review human review queue compliance metrics against SLA." ], "metrics": [ "Classification coverage rate: target 100% of entries with a valid label.", "Human review SLA compliance: target 95% of high/restricted items reviewed within defined SLA.", "Retrieval access control effectiveness: zero unauthorized retrievals of classified content in quarterly test scenarios." ], "failure_signals": [ "Knowledge entries discoverable with no classification metadata.", "Retrieval test returning restricted content to an unauthorized query context.", "Human review queue compliance below SLA target for two consecutive months." ] }, "legal_counsel": { "summary": "Classification of personal data, attorney-client privileged content, and regulated categories requires legal input on the classification policy and review of edge cases routed through human review.", "actions": [ "Review and approve the classification policy mapping regulatory categories (GDPR special categories, HIPAA PHI, attorney-client privilege) to classification tiers.", "Provide guidance on human review queue items involving ambiguous legal privilege or regulatory applicability.", "Confirm that classification labels are sufficient to support data subject rights obligations such as right of erasure traceable to specific knowledge entries." ], "failure_signals": [ "Classification policy not reviewed by legal in the past 12 months.", "Human review queue routing ambiguous legal-privilege items without a legal escalation path.", "No mechanism to identify and delete all knowledge entries derived from a specific data subject's information." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations lack sensitivity classification at the knowledge base level; content is typically classified at the document store level but not propagated through the knowledge extraction and embedding pipeline." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "multi-tenant" ], "implementers": [ "Data Governance", "Knowledge Engineering", "Security", "Legal/Privacy" ], "frameworks": [ { "framework": "iso_27002", "requirement_id": "\u00a75.12", "fit": "direct", "rationale": "ISO/IEC 27002:2022 control 5.12 requires organizations to classify information according to legal requirements, value, criticality, and sensitivity. Applying automated classification at knowledge base ingestion directly operationalizes this control for AI systems. The standard specifies that classification should be applied when information is created or processed, making ingestion-time classification the correct implementation point.", "normative_force": "voluntary-standard", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10(5)", "fit": "direct", "rationale": "EU AI Act Article 10(5) requires that where processing involves special categories of personal data, appropriate data governance measures including access limitations must be in place. Sensitivity classification at ingestion enables enforcement of these access limitations by ensuring special categories are labeled before entering the knowledge base. This control is a prerequisite for GDPR-aligned data subject rights management over knowledge base content.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "A.7.6", "fit": "direct", "rationale": "ISO/IEC 42001:2023 Annex A control A.7.6 requires organizations to define and document data preparation methods and criteria, which include labelling and categorization of data used by AI systems. Sensitivity classification at ingestion is the preparation step that establishes access boundaries; without it, access control at retrieval cannot be reliably enforced.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 7", "fit": "partial", "rationale": "DAMA DMBOK2 Chapter 7 on Data Security covers information classification as a prerequisite for access control and establishes that classification should occur close to data creation or ingestion. The control aligns with DMBOK2's guidance on classifying data at the earliest practical point in its lifecycle. The fit is partial because DMBOK2 addresses classification for general enterprise data rather than specifically for AI knowledge base ingestion.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "databricks_unity", "requirement_id": "Unity Catalog \u2014 Tags and Column-Level Security", "fit": "adjacent", "rationale": "Databricks Unity Catalog provides tag-based classification and column-level security that can propagate sensitivity labels from source data through to knowledge extraction pipelines. Organizations using Databricks as a knowledge pipeline substrate can leverage Unity Catalog classification to fulfill this control's requirements. The fit is adjacent as Unity Catalog addresses data warehouse governance rather than AI knowledge base management specifically.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KI-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every content item ingested into the knowledge base must have a sensitivity classification label attached before being written to the knowledge store; zero knowledge entries may exist with a null or missing classification label; content classified at High or Restricted must have a documented human review record within the defined SLA; retrieval access controls must not return content to any requester whose access tier is below the content's classification label.", "evidence_required": [ "Knowledge entry classification coverage report confirming 100% of entries have a valid non-null classification label with the classification engine run_id and timestamp for each", "Classification engine configuration document showing PII/PHI/PCI pattern detection model versions, topic classifier version, source ceiling inheritance logic, and the tier-to-access-control mapping", "Human review queue disposition records for all High and Restricted classified items within the assessment period, showing reviewer identity, disposition, and time-to-review against SLA", "Quarterly classifier evaluation report showing precision and recall per classification tier against a labeled holdout set with the override rate from human reviewers", "Retrieval access control test results for the assessment period confirming lower-privilege user queries returned zero entries classified above their authorized tier" ], "machine_tests": [ "Submit a document containing a clearly identifiable PII pattern (e.g., full name adjacent to SSN-formatted number) \u2192 assert the resulting knowledge entry receives classification label at Confidential or higher and is routed to human review", "Submit a document from a source configured with a Confidential classification ceiling \u2192 assert the resulting entry is labeled at Confidential regardless of content scan result showing lower sensitivity", "Issue a retrieval query authenticated as a Standard-tier user targeting content that is classified at Restricted \u2192 assert the query returns zero Restricted-tier results with no classification bypass", "Submit a plaintext document with no sensitive content patterns from an open-access source \u2192 assert the entry receives a non-null classification label within the appropriate tier within the pipeline processing window" ], "human_review": [ "Review human review queue records for High and Restricted classifications to confirm all dispositions include documented rationale and reviewer identity, and that no items exceeded SLA without escalation", "Assess the quarterly classifier evaluation report for systematic miscalibration patterns, specifically where the human override rate exceeds 20%, indicating the classifier requires retraining", "Verify that the classification policy has been reviewed by legal counsel in the past 12 months and that GDPR special category data, HIPAA PHI, and attorney-client privileged content are correctly mapped to classification tiers" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Applying sensitivity classification only at query time rather than at ingestion, leaving content without access boundaries in the knowledge store until first retrieval", "Using a single classification label for entire source collections rather than per-entry classification, allowing mixed-sensitivity source content to be uniformly under-restricted", "Configuring source classification ceiling inheritance so source-level restrictions can be overridden downward by content-level detection, causing high-sensitivity content from sensitive sources to be under-classified", "Routing all High and Restricted items to a human review queue with no SLA enforcement, allowing sensitive content review to accumulate indefinitely without governance accountability", "Treating classifier PII recall below 95% as operationally acceptable without escalation, creating systematic sensitive content exposure at scale" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KI" }, { "id": "KI-05", "layer": "KI", "plane": "control", "name": "Copyright and License Compliance at Ingestion", "plain": "All content submitted for ingestion must have its copyright status and applicable license terms verified before being accepted into the knowledge base, with license metadata attached to each ingested entry and periodic compliance reviews as source terms evolve.", "threat": { "tags": [ "copyright-infringement", "license-violation", "ip-contamination", "unauthorized-reproduction" ], "desc": "Ingesting copyrighted content without a valid license exposes the organization to copyright infringement claims and significant financial liability. In the AI context, regulators and courts are increasingly scrutinizing whether knowledge base content was used with appropriate rights, and outputs derived from unlicensed knowledge may constitute unauthorized reproduction. License terms evolve over time \u2014 a source that was freely licensed when first ingested may have changed its terms, creating ongoing compliance exposure without proactive re-validation." }, "standard": [ { "id": "iso_30401", "section": "\u00a74.4.2", "title": "Knowledge development \u2014 acquiring new knowledge" }, { "id": "eu_ai_act", "section": "Art. 53(1)(c)\u2013(d)", "title": "GPAI obligations \u2014 copyright policy and training-content summary" }, { "id": "dama_dmbok", "section": "Ch. 3", "title": "Data Governance \u2014 legal and regulatory compliance" }, { "id": "anthropic_transparency", "section": "Model card \u2014 training data description", "title": "Training data description in model cards" } ], "sources": [ { "id": "anthropic_model_cards_2024", "title": "Anthropic Model Cards & Knowledge Disclosure", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/transparency", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_transparency", "relationship": "informative_reference", "rationale": "Establishes Anthropic Model Cards & Knowledge Disclosure requirements informing the apeiris://knowledge/controls/KI-05 Copyright and License Compliance at Ingestion control.", "reviewed_on": "2026-07-01" }, { "id": "google_vertex_ai_rag_2024", "title": "Google Vertex AI RAG & Grounding", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/vertex-ai/docs/generative-ai/grounding/overview", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_vertex_ai_rag_2024", "relationship": "informative_reference", "rationale": "Establishes Google Vertex AI RAG & Grounding requirements informing the apeiris://knowledge/controls/KI-05 Copyright and License Compliance at Ingestion control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Implement a license verification gate in the ingestion pipeline: (1) source-level license classification mapping authorized use cases to permitted license types, (2) automated license detection for common open licenses, (3) legal review queue for ambiguous or non-standard licenses, (4) license metadata storage on each knowledge entry, (5) quarterly license re-validation against live source terms. Content without verified license authorization is rejected.", "steps": [ "Build a source license registry mapping each authorized source to its governing license(s), permitted use cases (internal, commercial, redistribution), rights holder, and license review date.", "Implement automated license detection for common open licenses (Creative Commons, Apache, MIT, Open Database License) using license header scanning and source manifest inspection.", "Route content from sources with ambiguous, non-standard, or commercial licenses to legal review before ingestion is permitted; document the legal determination in the registry.", "Attach license metadata to every knowledge entry: license_type, license_url, source_url, rights_holder, permitted_uses, and expiry_date.", "Schedule quarterly license re-validation reviews against live source terms to detect term changes; suspend ingestion from sources whose terms have changed materially until re-reviewed by legal." ], "knowledge_engineer": { "summary": "License metadata must be attached at ingestion and stored as part of the knowledge entry. Retroactive license attribution is unreliable; build it in from the first ingest.", "actions": [ "Integrate the source license registry lookup into the ingestion pipeline before any content processing occurs.", "Ensure every knowledge entry schema includes mandatory license metadata fields that cannot be null.", "Build tooling to identify and quarantine entries from sources whose license status has changed since ingestion." ], "failure_signals": [ "Knowledge entries with null or missing license metadata.", "Active ingestion from sources not present in the license registry.", "License re-validation reviews overdue by more than 30 days." ] }, "data_scientist": { "summary": "License constraints bind corpora: content licensed for internal search may be prohibited in fine-tuning or evaluation exports. Corpus construction must respect the license metadata recorded at ingestion.", "actions": [ "Filter corpus builds on license metadata so restricted content never enters prohibited uses like fine-tuning.", "Record the license profile of every training and evaluation corpus alongside its manifest.", "Escalate before using scraped or unlabeled content in any model-facing corpus." ], "failure_signals": [ "A fine-tuning corpus includes content licensed for retrieval display only.", "Corpus manifests carry no license profile, making downstream use decisions guesswork." ] }, "it_operations": { "summary": "Maintain the license registry as a high-availability service; ingestion pipeline license checks must be synchronous and fail-closed.", "actions": [ "Ensure the license registry API meets the availability SLO required for synchronous ingestion pipeline checks.", "Automate alerts when license expiry dates are approaching (30-day and 7-day warnings).", "Build and maintain the scheduled quarterly re-validation job with alerting on completion status." ], "failure_signals": [ "License registry API downtime causing ingestion pipeline to bypass license checks.", "License expiry alerts not firing for sources within the 30-day warning window.", "Quarterly re-validation job failing silently without an alert." ] }, "grc_auditor": { "summary": "Copyright compliance is a legal risk control. Verify license registry completeness, review queue processing compliance, and that re-validation reviews are occurring on schedule.", "actions": [ "Sample 50 knowledge entries and verify each has complete license metadata with a traceable source.", "Review the license review queue for overdue items and confirm legal dispositions are documented.", "Verify quarterly re-validation reviews are occurring and that term-changed sources are suspended appropriately." ], "metrics": [ "License metadata coverage rate: target 100% of knowledge entries.", "Legal review queue SLA compliance: target 100% of items reviewed within 14 days.", "Re-validation review completion rate: target 100% of scheduled quarterly reviews completed on time." ], "failure_signals": [ "Knowledge entries with missing license metadata.", "Legal review queue items outstanding beyond the 14-day SLA.", "Quarterly re-validation review not completed in two consecutive quarters." ] }, "legal_counsel": { "summary": "Legal counsel must own the license review process for non-standard licenses and the policy framework for permissible use cases. Copyright risk in AI knowledge bases is an evolving area of law requiring active monitoring.", "actions": [ "Define the organizational policy for permissible license types per knowledge base use case (internal AI, customer-facing AI, redistributed outputs).", "Review and approve all ambiguous or commercial license determinations routed through the legal review queue.", "Monitor copyright litigation and regulatory developments relevant to AI knowledge base ingestion; update the license policy as the legal landscape evolves." ], "failure_signals": [ "License review queue items older than 14 days without a legal determination.", "License policy not reviewed in the past 12 months despite significant AI copyright law developments.", "No process to identify knowledge entries whose license has been retroactively disputed." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Formal license tracking for AI knowledge bases is rare; most organizations rely on informal source vetting rather than a structured license registry with per-entry metadata." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "eu-high-risk-ai", "high-risk-sector" ], "implementers": [ "Legal", "Knowledge Engineering", "Data Governance", "Compliance" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 53(1)(c)\u2013(d)", "fit": "direct", "rationale": "EU AI Act Article 53(1)(c) requires GPAI model providers to put in place a policy to comply with Union copyright law, and Article 53(1)(d) requires a sufficiently detailed public summary of the content used for training. License verification at ingestion and maintained license metadata create the evidentiary basis for these obligations where organizations assemble knowledge corpora for AI systems.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_30401", "requirement_id": "\u00a74.4.2", "fit": "partial", "rationale": "ISO 30401:2018 \u00a74.4.2 covers acquiring new knowledge as a knowledge development activity; acquisition must respect the legal boundaries attached to externally sourced content, including intellectual property rights. License verification at ingestion ensures those rights are evaluated before external content becomes a knowledge asset.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 3", "fit": "partial", "rationale": "DAMA-DMBOK 2nd edition Chapter 3 (Data Governance) includes legal and regulatory compliance obligations for data assets within governance scope. Copyright compliance for knowledge base content is such an obligation. The fit is partial because DMBOK addresses data governance broadly rather than AI-specific knowledge base copyright compliance.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_transparency", "requirement_id": "Model card \u2014 training data description", "fit": "adjacent", "rationale": "Anthropic's model cards describe training data at a general level (for example, a proprietary mix of public and licensed data); they do not publish detailed copyright compliance measures. Organizations assembling their own knowledge corpora should apply stronger, evidenced license verification than this disclosure norm alone provides. The fit is adjacent as the framework addresses model provider disclosure rather than enterprise knowledge base management.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_vertex_rag", "requirement_id": "Grounding \u2014 Data Source Configuration", "fit": "adjacent", "rationale": "Google Vertex AI RAG and Grounding documentation requires operators to ensure their grounding data sources comply with applicable terms of use and intellectual property rights. This platform requirement operationalizes license compliance for organizations using Vertex AI as their knowledge base substrate. The fit is adjacent as the requirement is a platform usage obligation rather than a standalone copyright compliance framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KI-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every content item ingested into the knowledge base must have its copyright status verified against the source license registry before being accepted; no knowledge entry may exist without complete license metadata including license_type, rights_holder, permitted_uses, and expiry_date; ingestion from sources with ambiguous or commercial licenses must not proceed without a documented legal determination on file; quarterly license re-validation reviews must be completed on schedule.", "evidence_required": [ "Source license registry export listing all active sources with license_type, rights_holder, permitted_uses, expiry_date, and last_review_date for each entry", "Legal review queue disposition records for ambiguous and commercial license determinations within the assessment period, showing legal determination, reviewer identity, and time-to-disposition against the 14-day SLA", "Knowledge entry license metadata coverage report confirming 100% of entries contain license_type, rights_holder, and permitted_uses fields with non-null values", "Quarterly license re-validation review completion records for the past four quarters confirming execution, scope, and any suspended sources due to material term changes", "License expiry alert log confirming 30-day and 7-day warning alerts fired for all sources with approaching expiry dates during the assessment period" ], "machine_tests": [ "Submit a content batch from a source_id not present in the license registry \u2192 assert the pipeline rejects it with license_status=unregistered and no content is written to the knowledge base", "Submit content from a source whose expiry_date is in the past \u2192 assert the pipeline blocks ingestion, suspends the registry entry, and raises an expiry alert", "Submit content from a source with a license_review_status of pending-legal-review \u2192 assert the pipeline quarantines the content and does not write it to the knowledge base until a legal determination is recorded", "Retrieve metadata for an existing knowledge entry \u2192 assert license_type, rights_holder, and permitted_uses fields are all present and non-null in the entry metadata" ], "human_review": [ "Review the legal review queue for items outstanding beyond the 14-day SLA and assess whether escalation to outside counsel is required for any pending ambiguous license determinations", "Assess the quarterly re-validation review process to confirm that sources with material license term changes are triggering appropriate ingestion suspension and legal re-review before re-activation", "Verify the license policy framework covers all applicable deployment use cases (internal-only AI, customer-facing AI, redistributed outputs) and has been reviewed and approved within the past 12 months" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Assuming that publicly accessible or open-access content is freely licensable for AI knowledge base ingestion without explicit per-source license verification", "Attaching license metadata only at the source level in the registry rather than per knowledge entry, allowing entry-level traceability to lapse when source records change", "Treating quarterly re-validation reviews as optional or repeatedly deferring them, allowing license term changes to go undetected until a compliance incident surfaces", "Implementing a soft-block where content from unlicensed sources is flagged as a warning but still ingested, creating de facto license violations at scale", "Failing to propagate usage restrictions captured in license metadata to runtime retrieval controls, allowing content to be returned in contexts beyond its permitted scope (e.g., commercial use of internal-only licensed content)" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KI" }, { "id": "KI-06", "layer": "KI", "plane": "data", "name": "Pre-Ingestion Content Quality Gates", "plain": "All content must satisfy defined quality standards covering accuracy indicators, completeness, recency, factual consistency, and source credibility before it is accepted into the knowledge base.", "threat": { "tags": [ "low-quality-contamination", "factual-drift", "stale-knowledge", "corpus-degradation" ], "desc": "Accepting low-quality content degrades the reliability of AI outputs by contaminating the knowledge base with inaccurate, outdated, or incomplete information. Factual drift occurs when content that was accurate at ingestion becomes misleading as underlying facts change, but the knowledge base is not updated. High volumes of low-quality content dilute high-quality signal, reducing retrieval precision. Without systematic quality gates, the knowledge base degrades progressively as new content accumulates without governance scrutiny." }, "standard": [ { "id": "dama_dmbok", "section": "Ch. 13", "title": "Data quality dimensions \u2014 accuracy, completeness, timeliness" }, { "id": "iso_30401", "section": "\u00a74.4.2", "title": "Knowledge development \u2014 handling invalid or outdated knowledge" }, { "id": "iso_42001", "section": "A.7.4", "title": "Quality of data for AI systems" }, { "id": "itil_4", "section": "\u00a75.1.4", "title": "Knowledge management practice" } ], "sources": [ { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 13 requirements informing the apeiris://knowledge/controls/KI-06 Pre-Ingestion Content Quality Gates control.", "reviewed_on": "2026-07-02" }, { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements \u00a74.4.2 requirements informing the apeiris://knowledge/controls/KI-06 Pre-Ingestion Content Quality Gates control.", "reviewed_on": "2026-07-02" }, { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 A.7.4 requirements informing the apeiris://knowledge/controls/KI-06 Pre-Ingestion Content Quality Gates control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 10(3) requirements informing the apeiris://knowledge/controls/KI-06 Pre-Ingestion Content Quality Gates control.", "reviewed_on": "2026-07-02" }, { "id": "itil_4", "title": "ITIL 4", "authority": "PeopleCert / Axelos", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "4", "published_on": "2019-02-28", "retrieved_on": "2026-07-02", "canonical_url": "https://www.axelos.com/certifications/itil-service-management/itil-4-foundation", "license": "proprietary", "status": "current", "flagship": false, "source_id": "itil_4", "relationship": "informative_reference", "rationale": "Establishes ITIL 4 \u00a75.1.4 requirements informing the apeiris://knowledge/controls/KI-06 Pre-Ingestion Content Quality Gates control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define a multi-dimensional quality scorecard for each content type with minimum thresholds per dimension. Run automated quality scoring at ingestion and route failing content to a quality review queue. Dimensions include: recency (publication or last-verified date within threshold), completeness (required fields and minimum content length), source credibility score from the authorization registry, internal consistency (no self-contradictory claims), and factual cross-check against high-confidence existing entries.", "steps": [ "Define quality dimensions and minimum thresholds per content type in a quality policy document approved by the knowledge governance board.", "Implement automated quality scoring: recency check against configurable staleness thresholds, completeness validation against content type schemas, and source credibility score lookup from the source authorization registry.", "Build a factual cross-check stage that identifies new content making claims that directly contradict high-confidence existing entries, routing contradictions to editorial review rather than auto-rejection.", "Route content below minimum quality thresholds to a quality review queue with the quality scorecard attached; reviewers can override with documented justification or reject.", "Publish quality metrics per source on a knowledge health dashboard to identify sources in persistent quality decline before they cause material corpus degradation." ], "knowledge_engineer": { "summary": "Quality gates protect the corpus from progressive degradation. Define thresholds per content type \u2014 a news article and a technical specification have different quality criteria.", "actions": [ "Implement the quality scoring pipeline with configurable per-content-type thresholds.", "Build the quality review queue with structured scorecard metadata to help reviewers make efficient decisions.", "Create the knowledge health dashboard showing quality metrics by source and over time." ], "failure_signals": [ "Quality gate disabled or threshold set to zero for any content type.", "Quality review queue backlog older than SLA without escalation.", "Knowledge health dashboard not updated in more than 7 days." ] }, "data_scientist": { "summary": "Quality threshold calibration requires empirical analysis of the relationship between content quality scores and downstream retrieval and generation quality. Measure the impact of quality gates on both corpus health and knowledge coverage.", "actions": [ "Analyze the correlation between quality scores at ingestion and downstream retrieval relevance ratings to validate threshold calibration.", "Run periodic corpus quality assessments to measure aggregate quality dimension scores and identify drift trends.", "Recommend threshold adjustments based on observed relationships between ingestion quality scores and AI output quality metrics." ], "failure_signals": [ "No empirical validation of quality threshold calibration against downstream AI output quality.", "Corpus quality assessment not run in more than 90 days.", "Quality thresholds set by policy without any data-driven validation." ] }, "it_operations": { "summary": "Quality gates are pipeline stages: scoring services must be deployed in the ingestion path, their thresholds configuration-managed, and their rejects routed to a reviewable queue.", "actions": [ "Run quality scoring as a blocking ingestion stage with thresholds under version control.", "Route rejected content to a review queue with retention, rather than deleting it silently.", "Monitor gate pass rates and alert on sudden shifts that suggest scorer drift or bypass." ], "failure_signals": [ "Gate pass rate jumps to 100% because the scorer was bypassed during an incident.", "Threshold changes ship without review because they live outside configuration management." ] }, "grc_auditor": { "summary": "Quality gates protect the organization from liability arising from AI outputs based on demonstrably low-quality knowledge. Verify gates are active, calibrated, and that review queues are processed within SLA.", "actions": [ "Sample 20 quality review queue decisions and verify each has a documented justification for acceptance or rejection.", "Review the knowledge health dashboard for sources showing persistent quality decline without governance action.", "Verify quality policy thresholds have been approved by the knowledge governance board and are reviewed annually." ], "metrics": [ "Quality gate pass rate by source: flag any source declining below 80% pass rate.", "Quality review queue SLA compliance: target 90% of items reviewed within 72 hours.", "Corpus average quality score trend: track over rolling 90-day window and alert on sustained decline." ], "failure_signals": [ "Quality policy thresholds not reviewed in the past 12 months.", "Sources with persistent quality decline below 80% pass rate still active without governance review.", "Quality review queue SLA compliance below target for two consecutive months." ] }, "legal_counsel": { "summary": "Quality gates are part of the duty-of-care story: if low-quality content produces harmful advice, the documented gate criteria and their enforcement records are the defense evidence.", "actions": [ "Confirm gate criteria for regulated content classes reflect the accuracy standards those domains require.", "Preserve gate decision records so the organization can evidence systematic quality screening.", "Review recurring quality waivers \u2014 repeated overrides undermine the defensibility of the control." ], "failure_signals": [ "Harmful advice traces to content that failed the gate but was force-approved without documented justification.", "Gate records for the period at issue were not retained." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Systematic pre-ingestion quality gates for AI knowledge bases are uncommon; most organizations rely on source selection as the primary quality control without automated per-document quality scoring." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector" ], "implementers": [ "Knowledge Engineering", "Data Science", "Data Governance" ], "frameworks": [ { "framework": "dama_dmbok", "requirement_id": "Ch. 13", "fit": "direct", "rationale": "DAMA DMBOK2 Chapter 13 defines data quality dimensions including accuracy, completeness, timeliness, and consistency as the foundational framework for data quality management. Pre-ingestion quality gates directly implement these dimensions as enforceable thresholds at the knowledge base entry point. The chapter's measurement and monitoring guidance provides the basis for the knowledge health dashboard metrics.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "iso_30401", "requirement_id": "\u00a74.4.2", "fit": "direct", "rationale": "ISO 30401:2018 \u00a74.4.2 includes handling invalid or outdated knowledge among required knowledge development activities, which presupposes assessing whether knowledge is fit to enter the system. Pre-ingestion quality gates operationalize that assessment as an automated enforcement mechanism.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.7.4", "fit": "direct", "rationale": "ISO/IEC 42001:2023 Annex A control A.7.4 requires organizations to define quality criteria for data used in AI systems and verify that data meets those criteria. Pre-ingestion quality gates are the direct operationalization of this control for knowledge base management.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10(3)", "fit": "partial", "rationale": "EU AI Act Article 10(3) requires training, validation and testing data sets to be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose. Pre-ingestion quality gates are a direct mechanism for meeting these requirements by filtering out low-quality, inaccurate, or incomplete content. The fit is partial because Article 10 applies specifically to high-risk AI systems rather than all enterprise AI knowledge bases.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "itil_4", "requirement_id": "\u00a75.1.4", "fit": "adjacent", "rationale": "The ITIL 4 knowledge management practice (5.1.4) requires knowledge quality to be actively managed rather than assumed. Pre-ingestion quality gates align with this principle. The fit is adjacent because ITIL targets IT service knowledge rather than AI knowledge bases specifically.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KI-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "All content submitted for ingestion must receive a multi-dimensional quality scorecard and meet or exceed the defined minimum threshold on each active dimension (recency, completeness, source credibility, internal consistency) before being written to the knowledge base; content falling below any threshold must be routed to the quality review queue and must not be ingested until reviewed with a documented disposition; no quality gate may be disabled or set to a zero threshold for any active content type.", "evidence_required": [ "Quality policy document defining minimum threshold values per quality dimension per content type, with knowledge governance board approval signature and last review date", "Quality scoring pipeline configuration showing active dimensions, threshold values per content type, and the routing logic for below-threshold content to the quality review queue", "Quality review queue records for the assessment period showing reviewed items, time-to-review against SLA, and documented acceptance or rejection justifications per item", "Knowledge health dashboard data export showing per-source quality pass rate trends over the rolling 90-day window with governance action records for sources below 80% pass rate", "Data scientist quality threshold calibration report showing correlation between ingestion quality scores and downstream retrieval relevance ratings used to validate threshold settings" ], "machine_tests": [ "Submit content with a publication date exceeding the configured staleness threshold for its content type \u2192 assert the recency dimension fails and the content is routed to the quality review queue rather than ingested", "Submit content below the minimum required character length for its declared content type \u2192 assert the completeness dimension fails and the pipeline does not write the content to the knowledge base", "Submit content from a source with a source credibility score below the registry-defined minimum for its tier \u2192 assert the credibility gate fails and the content is queued for review", "Submit content containing two directly contradictory factual claims within the same document \u2192 assert the internal consistency dimension flags the content for editorial review rather than auto-accepting" ], "human_review": [ "Review quality review queue records for systematic failure patterns by source to identify sources in persistent quality decline that should be suspended pending governance board review", "Assess the data scientist quality threshold calibration report to verify that defined thresholds are empirically grounded in observed relationships between ingestion quality scores and downstream AI output quality", "Verify the knowledge health dashboard reflects current data and that sources sustaining quality pass rates below 80% for more than 30 days have documented governance response actions in progress" ], "blocking_effect": "blocks-runtime-action", "normative_status": "certification-standard", "anti_patterns": [ "Setting quality thresholds to zero or bypassing the quality gate entirely for designated trusted sources, eliminating corpus protection for sources assumed to be self-governing", "Defining quality dimensions by policy without calibrating minimum thresholds against observed downstream impacts on AI output quality, resulting in thresholds that are arbitrary rather than evidence-based", "Routing below-threshold content to the quality review queue but failing to enforce a review SLA, allowing sub-threshold content to accumulate in review indefinitely without disposition", "Treating the knowledge health dashboard as a reporting artifact without defining governance response triggers for sustained source quality decline, removing the operational feedback loop", "Applying identical quality thresholds across all content types without accounting for inherent structural differences between document formats (e.g., applying news article thresholds to technical specifications)" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KI" }, { "id": "KI-07", "layer": "KI", "plane": "lifecycle", "name": "Ingestion Audit Trail", "plain": "A complete, tamper-evident log of all knowledge base additions, updates, and deletions must be maintained, recording the actor identity, source, timestamp, content hash, and triggering event for every change to the knowledge base.", "threat": { "tags": [ "audit-evasion", "untracked-modification", "accountability-gap", "tampered-log" ], "desc": "Without a complete audit trail, unauthorized or accidental knowledge base modifications cannot be detected, attributed, or reversed. An attacker who compromises an ingestion pipeline can introduce malicious content and erase evidence of the modification. Audit evasion undermines the ability to investigate AI system misbehavior by breaking the chain of evidence from knowledge base content back to its origin. Compliance frameworks increasingly require demonstrable provenance of AI knowledge data, which cannot be satisfied without an immutable audit record." }, "standard": [ { "id": "iso_27002", "section": "\u00a78.15", "title": "Logging" }, { "id": "w3c_prov", "section": "PROV-DM \u00a75", "title": "Provenance \u2014 activity records and agent attribution" }, { "id": "dama_dmbok", "section": "Ch. 9", "title": "Document and content management \u2014 audit and lineage" }, { "id": "eu_ai_act", "section": "Art. 12", "title": "Record-keeping and logging for high-risk AI systems" } ], "sources": [ { "id": "iso_27002", "title": "ISO/IEC 27002:2022 \u2014 Information Security Controls", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "voluntary-standard", "version": "2022", "published_on": "2022-02-15", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/75652.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_27002", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 27002:2022 \u2014 Information Security Controls \u00a78.15 requirements informing the apeiris://knowledge/controls/KI-07 Ingestion Audit Trail control.", "reviewed_on": "2026-07-02" }, { "id": "w3c_prov", "title": "W3C PROV Data Model", "authority": "World Wide Web Consortium", "source_type": "standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2013-04-30", "retrieved_on": "2026-07-02", "canonical_url": "https://www.w3.org/TR/prov-dm/", "license": "open-access", "status": "current", "flagship": false, "source_id": "w3c_prov", "relationship": "implementation_pattern", "rationale": "Establishes W3C PROV Data Model PROV-DM \u00a75 requirements informing the apeiris://knowledge/controls/KI-07 Ingestion Audit Trail control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 12 requirements informing the apeiris://knowledge/controls/KI-07 Ingestion Audit Trail control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 9 requirements informing the apeiris://knowledge/controls/KI-07 Ingestion Audit Trail control.", "reviewed_on": "2026-07-02" }, { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a79.1 requirements informing the apeiris://knowledge/controls/KI-07 Ingestion Audit Trail control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Implement an append-only, cryptographically chained audit log capturing every knowledge base mutation event. Each log record contains: event_id, event_type (add/update/delete), actor_id, source_id, content_hash (SHA-256), timestamp (UTC), triggering_event_id, and a chain_hash linking to the previous record. Log records are written before the mutation is committed; failed mutations are logged with outcome=failed.", "steps": [ "Deploy an append-only audit log store with cryptographic chaining: each record includes the SHA-256 hash of the previous record, creating a tamper-evident chain.", "Instrument all knowledge base write operations (add, update, delete, bulk import) to write an audit record before committing; use database transaction semantics to ensure log record and mutation are atomic.", "Capture actor identity for all operations: human operators via authenticated session identity, automated pipelines via service account identity with source pipeline identifier.", "Implement log integrity verification: a scheduled job that walks the chain and verifies hash continuity, alerting on any gap or hash mismatch.", "Define log retention policy meeting regulatory requirements (minimum 3 years for regulated sectors); archive logs to immutable storage with access controls preventing modification." ], "knowledge_engineer": { "summary": "The audit log is the forensic record of the knowledge base. Instrument all write paths \u2014 including bulk import scripts and automated pipeline operations \u2014 without exception.", "actions": [ "Instrument all knowledge base write operations to emit structured audit events before committing the mutation.", "Ensure bulk import tooling generates per-record audit events, not just batch-level summaries.", "Test the tamper-evidence chain by verifying the hash chain on a staging corpus after controlled test mutations." ], "failure_signals": [ "Any write operation path that does not generate an audit log event.", "Audit log missing entries for known mutations (hash chain gap detected).", "Actor identity recorded as null or unknown for any audit event." ] }, "data_scientist": { "summary": "The ingestion audit trail is your corpus lineage: reconstructing what a model or index could have known at a point in time depends on complete, timestamped ingestion records.", "actions": [ "Use the audit trail to reconstruct corpus state for reproducing historical evaluation results.", "Verify ingestion records capture the transformation parameters (chunking, embedding versions) needed to rebuild an index.", "Cross-check corpus snapshots against the trail before attributing model behavior changes to data changes." ], "failure_signals": [ "A historical evaluation cannot be reproduced because ingestion records omit transformation parameters.", "Corpus state at a past date cannot be reconstructed from the trail." ] }, "it_operations": { "summary": "Audit log availability and integrity are operational responsibilities. The log must be as reliable as the knowledge base itself and protected from unauthorized access.", "actions": [ "Deploy audit log storage on immutable infrastructure (WORM storage or append-only object storage) with access controls preventing modification.", "Configure log integrity verification job and alert routing to security monitoring.", "Test log retention and archival processes; verify archived logs remain readable after the archival process." ], "failure_signals": [ "Audit log storage with write access granted to any account other than the append pipeline service account.", "Log integrity verification job not run in more than 7 days.", "Log archival process not tested for readability in the past 90 days." ] }, "grc_auditor": { "summary": "The audit trail is the foundational evidence artifact for knowledge base governance. Verify it is complete, tamper-evident, and retained per policy.", "actions": [ "Verify the hash chain integrity by running the chain verification tool and confirming zero gaps in the audit period.", "Sample 50 audit events and verify each has a valid actor identity and content hash; spot-check hashes against the actual stored content.", "Confirm log retention policy meets the most stringent applicable regulatory requirement and that archives are tested for readability." ], "metrics": [ "Audit log completeness rate: target 100% of mutations have a corresponding audit event.", "Hash chain integrity: target zero chain gaps in any 90-day period.", "Actor attribution rate: target 100% of events with a named actor identity." ], "failure_signals": [ "Hash chain verification revealing any gap or mismatch.", "Audit events with null actor identity.", "Log retention shorter than the applicable regulatory minimum." ] }, "legal_counsel": { "summary": "The ingestion trail is discoverable evidence: it establishes what the organization ingested, when, and under whose authority \u2014 central facts in IP, privacy, and liability disputes.", "actions": [ "Set retention for ingestion audit records to match litigation and regulatory horizons.", "Verify the trail's integrity controls support its use as reliable evidence.", "Ensure legal hold procedures cover ingestion records and their backing storage." ], "failure_signals": [ "Ingestion records relevant to a dispute were purged under a default retention setting.", "Trail entries can be altered after the fact, undermining their evidentiary value." ] } }, "maturity": { "current": "managed", "target": "defined", "notes": "Generic audit logging exists in most data platforms but AI knowledge base-specific audit trails with tamper-evidence and per-entry content hashing are uncommon." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise", "multi-tenant" ], "implementers": [ "IT Operations", "Knowledge Engineering", "GRC/Audit", "Security Operations" ], "frameworks": [ { "framework": "iso_27002", "requirement_id": "\u00a78.15", "fit": "direct", "rationale": "ISO/IEC 27002:2022 control 8.15 requires comprehensive logging of activities, exceptions, and information security events to support monitoring and forensic investigation. The knowledge base audit trail directly implements this control by capturing all mutation events with actor identity and timestamps. The control specifies that log records should be protected against tampering, aligning with the tamper-evident chain implementation.", "normative_force": "voluntary-standard", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "w3c_prov", "requirement_id": "PROV-DM \u00a75", "fit": "direct", "rationale": "W3C PROV-DM \u00a75 defines activity records as the mechanism for capturing how entities were derived and transformed, including agent attribution and time bounds. The ingestion audit trail implements PROV-DM activity records for all knowledge base mutations, creating a W3C-compatible provenance graph for the knowledge base. This alignment enables interoperability with external provenance-consuming systems.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 12", "fit": "direct", "rationale": "EU AI Act Article 12 requires high-risk AI systems to maintain records including logging capabilities that enable reconstruction of the system's behavior and data inputs. The knowledge base audit trail directly satisfies this requirement by providing a complete record of all knowledge mutations that can be used to reconstruct what knowledge was available at any point in time. This is particularly critical for post-incident investigation and regulatory inquiry.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 9", "fit": "partial", "rationale": "DAMA DMBOK2 Chapter 9 on Document and Content Management covers audit trails and lineage as essential components of content governance, including requirements for tracking content creation, modification, and deletion. The ingestion audit trail implements these lineage requirements for AI knowledge base content. The fit is partial because DMBOK2 addresses document management rather than AI knowledge base management specifically.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "iso_42001", "requirement_id": "\u00a79.1", "fit": "partial", "rationale": "ISO/IEC 42001:2023 \u00a79.1 requires organizations to monitor, measure, analyze, and evaluate their AI management system, which requires the audit data that the ingestion trail provides. The audit trail is a foundational data source for AI management system performance monitoring and evaluation. The fit is partial because \u00a79.1 addresses monitoring broadly rather than specifically requiring a tamper-evident knowledge base audit log.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KI-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The knowledge base audit log must contain a tamper-evident, cryptographically chained record for every mutation event (add, update, delete), with each record including actor_id, source_id, content_hash (SHA-256), event_type, and timestamp, and the chain integrity verification must return zero gaps or hash mismatches for any 90-day audit window.", "evidence_required": [ "ingestion_audit_log export for the audit period showing event_id, event_type, actor_id, source_id, content_hash, timestamp, and chain_hash fields populated for every record", "chain_integrity_verification_report confirming zero hash mismatches or chain gaps across the most recent 90-day window", "actor_attribution_report showing 100% of audit events contain a non-null, named actor identity", "audit_log_storage_configuration_record confirming WORM or append-only storage with write access restricted to the ingestion pipeline service account", "log_retention_policy_document specifying retention period and confirming it meets or exceeds the applicable regulatory minimum" ], "machine_tests": [ "Inject a test add mutation into the knowledge base \u2192 assert audit log contains a matching record with correct content_hash and actor_id within 5 seconds", "Mutate a single audit log record directly in the store then run chain integrity verification \u2192 assert verification reports a hash mismatch at the modified record position", "Submit a bulk import of 100 test documents \u2192 assert audit log contains exactly 100 individual add-event records, not a single batch-level summary entry", "Simulate audit log storage unavailability during a write operation \u2192 assert the write is rejected and the failure is recorded to the error monitoring channel" ], "human_review": [ "Inspect a sample of 50 audit events from the prior quarter and verify each contains a valid actor identity, non-null content_hash, and a chain_hash linking to the previous record", "Assess whether all knowledge base write paths \u2014 including bulk import scripts and automated pipeline operations \u2014 are fully instrumented to emit audit events without exception", "Review the log retention and archival procedures to confirm they satisfy the most stringent applicable regulatory requirement and that archived logs are tested for readability" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Using application-level access logs as a substitute for a purpose-built append-only audit log with cryptographic chaining, allowing log records to be modified or deleted without detection", "Recording bulk import operations as a single batch-level event rather than per-document audit events, eliminating individual content hash accountability for ingested items", "Storing the audit log in a mutable database with write access granted to the same service accounts that execute mutations, creating a tamper opportunity that eliminates forensic value", "Recording actor identity as the pipeline service account for all automated operations without capturing the human operator or triggering job context that initiated the run", "Treating log retention as an operational preference rather than a compliance obligation, resulting in retention periods shorter than applicable regulatory minimums" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KI" }, { "id": "KI-08", "layer": "KI", "plane": "both", "name": "Knowledge Ingestion Evidence Package", "plain": "A structured evidence package must be compiled on a defined cadence demonstrating that ingestion pipeline controls (KI-01 through KI-07) are operating effectively, providing auditors and compliance reviewers with a single artifact summarizing the governance state of the knowledge ingestion layer.", "threat": { "tags": [ "compliance-gap", "evidence-incompleteness", "audit-failure", "ungoverned-pipeline" ], "desc": "Without a compiled evidence package, the governance state of the knowledge ingestion layer is distributed across multiple systems and logs, making compliance verification expensive and error-prone. Auditors who cannot efficiently verify ingestion controls may issue findings based on incomplete review, or governance failures may persist undetected because no single artifact surfaces the aggregate control state. Fragmented evidence increases the risk that control gaps exist in the space between individual metrics that are each within tolerance but collectively indicate systemic governance failure." }, "standard": [ { "id": "iso_42001", "section": "\u00a79.3", "title": "Management review \u2014 AI management system performance evidence" }, { "id": "eu_ai_act", "section": "Art. 18", "title": "Documentation keeping" }, { "id": "iso_27002", "section": "\u00a75.36", "title": "Compliance with policies, rules and standards for information security" }, { "id": "dama_dmbok", "section": "Ch. 3", "title": "Data governance \u2014 compliance reporting and evidence" } ], "sources": [ { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a79.3 requirements informing the apeiris://knowledge/controls/KI-08 Knowledge Ingestion Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 18 requirements informing the apeiris://knowledge/controls/KI-08 Knowledge Ingestion Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "iso_27002", "title": "ISO/IEC 27002:2022 \u2014 Information Security Controls", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "voluntary-standard", "version": "2022", "published_on": "2022-02-15", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/75652.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_27002", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 27002:2022 \u2014 Information Security Controls \u00a75.36 requirements informing the apeiris://knowledge/controls/KI-08 Knowledge Ingestion Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 3 requirements informing the apeiris://knowledge/controls/KI-08 Knowledge Ingestion Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "itil_4", "title": "ITIL 4", "authority": "PeopleCert / Axelos", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "4", "published_on": "2019-02-28", "retrieved_on": "2026-07-02", "canonical_url": "https://www.axelos.com/certifications/itil-service-management/itil-4-foundation", "license": "proprietary", "status": "current", "flagship": false, "source_id": "itil_4", "relationship": "informative_reference", "rationale": "Establishes ITIL 4 \u00a75.1.2 requirements informing the apeiris://knowledge/controls/KI-08 Knowledge Ingestion Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "w3c_prov", "title": "W3C PROV Data Model", "authority": "World Wide Web Consortium", "source_type": "standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2013-04-30", "retrieved_on": "2026-07-02", "canonical_url": "https://www.w3.org/TR/prov-dm/", "license": "open-access", "status": "current", "flagship": false, "source_id": "w3c_prov", "relationship": "implementation_pattern", "rationale": "Establishes W3C PROV Data Model PROV-DM \u00a75.4 requirements informing the apeiris://knowledge/controls/KI-08 Knowledge Ingestion Evidence Package control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Automate the compilation of a KI evidence package on a quarterly cadence (or on-demand for audits): aggregate control status, key metrics, exception summaries, and sample artifacts from KI-01 through KI-07 into a structured report. The package is signed by the knowledge governance owner and retained in the compliance evidence repository. For high-risk AI systems operating under EU AI Act, compile monthly.", "steps": [ "Define the KI evidence package template specifying required sections: source authorization registry status (KI-01), poisoning detection metrics and quarantine summary (KI-02), format validation failure rates (KI-03), classification coverage and review queue metrics (KI-04), license registry completeness and re-validation status (KI-05), quality gate pass rates and corpus health (KI-06), and audit trail integrity verification results (KI-07).", "Automate data collection from each control's metrics systems into the evidence package via a scheduled pipeline; flag any control with metrics outside defined thresholds in the package executive summary.", "Include in each package: a list of exceptions approved during the period, any material control failures and their remediation status, and a governance owner attestation confirming accuracy of the compiled evidence.", "Store compiled packages in an immutable evidence repository with retention matching the applicable regulatory minimum; index packages by period and knowledge base instance.", "Distribute the package summary to the AI governance board on the regular cadence and to audit teams on request; escalate immediately if any KI control is in a failed state." ], "knowledge_engineer": { "summary": "The evidence package is the authoritative summary of KI control health. Build the automated collection pipeline to pull from each control's metrics APIs without manual data gathering.", "actions": [ "Build the automated evidence collection pipeline, pulling metrics from KI-01 through KI-07 control systems.", "Implement threshold-based flagging logic that highlights any metric outside its defined acceptable range in the package summary.", "Ensure the package is machine-readable (structured JSON alongside human-readable PDF) for automated compliance system ingestion." ], "failure_signals": [ "Evidence package compiled with manual data gathering rather than automated collection.", "Package missing data from one or more KI controls.", "Last compiled package older than the defined cadence without a documented reason." ] }, "data_scientist": { "summary": "The ingestion evidence package cites pipeline quality metrics; those figures must be regenerable from ingestion telemetry, with stable definitions across reporting periods.", "actions": [ "Version-control the queries that compute ingestion metrics feeding the evidence package.", "Reconcile packaged figures against raw ingestion telemetry each cycle before sign-off.", "Annotate any metric definition changes so period-over-period comparisons remain honest." ], "failure_signals": [ "Evidence package metrics cannot be reproduced from ingestion telemetry.", "A silent metric redefinition makes ingestion quality look improved when it is not." ] }, "it_operations": { "summary": "Operate the evidence compilation pipeline and evidence repository as compliance-critical infrastructure with appropriate availability, backup, and access control.", "actions": [ "Deploy the evidence repository on immutable storage with restricted write access (compilation pipeline service account only) and read access to authorized reviewers.", "Monitor the scheduled compilation pipeline and alert on failure; implement retry with escalation to the knowledge governance owner.", "Maintain backup and restore procedures for the evidence repository tested annually." ], "failure_signals": [ "Evidence repository with write access granted to human accounts other than emergency break-glass.", "Compilation pipeline failure not generating an alert within 1 hour.", "Evidence repository backup not tested in the past 12 months." ] }, "grc_auditor": { "summary": "The KI evidence package is the primary artifact for auditing knowledge ingestion governance. Use it to identify control gaps, exception trends, and material failures requiring management attention.", "actions": [ "Review each KI evidence package against the prior period to identify deteriorating control metrics or accumulating exceptions.", "Trace material exceptions in the package back to the source control systems for corroboration.", "Use the package as the basis for the annual AI risk assessment update, identifying KI layer risks that have materialized or escalated." ], "metrics": [ "Package compilation cadence compliance: target 100% of packages compiled within 5 business days of period end.", "Control coverage rate: target 100% of KI-01 through KI-07 represented in each package.", "Exception closure rate: target 90% of exceptions from prior package closed or in active remediation." ], "failure_signals": [ "Package compiled more than 10 business days after period end.", "Any KI control missing from the package without a documented reason.", "Material exceptions from the prior package with no remediation record." ] }, "legal_counsel": { "summary": "The evidence package is the documentary basis for demonstrating regulatory compliance with EU AI Act and other knowledge governance obligations. Ensure the package format and retention policy satisfy applicable legal evidentiary requirements.", "actions": [ "Review the evidence package template to confirm it captures the records that must be kept at the disposal of competent authorities under EU AI Act Article 18 (documentation keeping), noting that the technical documentation itself is drawn up under Article 11.", "Confirm the retention period and storage format meet evidentiary admissibility requirements in applicable jurisdictions.", "Review the governance owner attestation language to ensure it accurately represents the scope of the assurance being provided without overstating coverage." ], "failure_signals": [ "Evidence package format not reviewed by legal in the past 12 months.", "Retention period shorter than the applicable regulatory minimum.", "Attestation language overstating assurance (e.g., claiming perfect control coverage when the package reflects sampled evidence)." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Compiled AI knowledge governance evidence packages are rare; most organizations rely on point-in-time audit preparation rather than automated, cadence-based evidence compilation." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Knowledge Engineering", "GRC/Audit", "Legal", "Compliance" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a79.3", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a79.3 requires management review of the AI management system to evaluate its continuing suitability, adequacy, and effectiveness. The KI evidence package is the primary input to this management review, providing a structured summary of ingestion control performance. The standard specifies that management review inputs must include results of monitoring, measurement, analysis, and evaluation \u2014 precisely what the evidence package compiles.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 18", "fit": "direct", "rationale": "EU AI Act Article 18 requires providers of high-risk AI systems to keep documentation, including quality management system records, at the disposal of competent authorities for ten years after the system is placed on the market. The KI evidence package creates the retained documentary record for the ingestion controls governing data quality, integrity and rights management \u2014 the artifact that would be produced in a regulatory inspection under Article 74.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27002", "requirement_id": "\u00a75.36", "fit": "partial", "rationale": "ISO/IEC 27002:2022 control 5.36 requires regular reviews to verify compliance with policies, rules, and standards for information security. The evidence package operationalizes this review requirement for knowledge ingestion controls, providing the structured evidence needed to verify compliance. The fit is partial because 5.36 addresses information security compliance broadly rather than AI knowledge governance specifically.", "normative_force": "voluntary-standard", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 3", "fit": "partial", "rationale": "DAMA DMBOK2 Chapter 3 on Data Governance covers compliance reporting and evidence as components of a mature data governance program. The evidence package implements DMBOK2's compliance reporting practices for AI knowledge base management. The fit is partial because DMBOK2 addresses data governance reporting broadly rather than the specific requirements of AI knowledge ingestion compliance evidence.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "itil_4", "requirement_id": "\u00a75.1.2", "fit": "adjacent", "rationale": "The ITIL 4 continual improvement practice (5.1.2) emphasizes evidence-based assessment of service performance to drive improvement decisions. The evidence package provides the structured performance record needed for continual improvement of the knowledge ingestion layer. The fit is adjacent because ITIL focuses on service improvement cycles rather than AI governance evidence compilation.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "w3c_prov", "requirement_id": "PROV-DM \u00a75.4", "fit": "adjacent", "rationale": "W3C PROV-DM \u00a75.4 defines bundles for grouping and attributing collections of provenance descriptions. The evidence package is conceptually such a bundle over the KI control layer, grouping each control's evidence records into an attributed, timestamped collection. The fit is adjacent because PROV-DM addresses provenance modeling rather than compliance evidence packaging.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KI-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A structured evidence package covering all seven KI-layer controls (KI-01 through KI-07) must be compiled and signed by the knowledge governance owner within 5 business days of the end of each defined reporting period, with all KI controls represented, metrics compared against documented thresholds, and the package stored in an immutable evidence repository with restricted write access.", "evidence_required": [ "ki_evidence_package artifact for the current period containing sections for all seven KI controls with control status, metrics, threshold comparison, and exception summaries", "governance_owner_attestation signed record confirming the accuracy and completeness of the compiled evidence package", "evidence_package_compilation_timestamp confirming the package was completed within 5 business days of period end", "exception_register extract listing all approved exceptions from the period with remediation status and target closure dates", "evidence_repository_access_log confirming write access is restricted to the compilation pipeline service account" ], "machine_tests": [ "Trigger the evidence compilation pipeline \u2192 assert it completes within the defined SLA window and produces a structured package containing all 7 KI control sections", "Set a KI control metric outside its defined threshold in a test environment and run compilation \u2192 assert the package executive summary flags that control as out-of-threshold", "Attempt to modify a previously compiled evidence package in the repository \u2192 assert the operation is rejected with a permission denied error" ], "human_review": [ "Review the current evidence package against the prior period to identify deteriorating control metrics, accumulating exception volumes, or controls approaching threshold limits", "Verify that the governance owner attestation accurately represents the scope and basis of the assurance provided and does not overstate coverage beyond the sampled evidence compiled", "Assess exception closure rates from the prior package and confirm that material open exceptions have active remediation plans with documented target dates" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Manually compiling evidence package data through spreadsheet aggregation rather than automated collection from control metrics APIs, introducing accuracy risk and unsustainable audit preparation burden", "Producing the evidence package only in response to an external audit request rather than on a proactive defined cadence, preventing trend detection between audits", "Omitting controls from the package that show no failures on the assumption that absence of reported issues confirms compliance, preventing auditors from independently verifying control operation", "Using attestation language that claims complete coverage of all KI controls when the package reflects sampled or estimated metrics rather than full population data" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KI" }, { "id": "KR-01", "layer": "KR", "plane": "control", "name": "Retrieval Relevance Quality Standards", "plain": "Every retrieval-augmented AI system must enforce minimum relevance thresholds for retrieved chunks, rejecting or downweighting content below defined similarity or ranking scores, and must include mechanisms to iteratively improve retrieval precision over time.", "threat": { "tags": [ "low-relevance-retrieval", "precision-degradation", "noise-injection", "answer-quality-failure" ], "desc": "When retrieval systems return chunks with low semantic relevance, the AI model incorporates irrelevant or misleading context that degrades response quality. Noise injected through poor retrieval propagates into downstream outputs, creating a systematic quality failure that is invisible to end users who cannot inspect the retrieved context. Without defined thresholds, relevance standards drift informally and are never enforced at runtime." }, "standard": [ { "id": "iso_30401", "section": "Clause 8", "title": "Operation" }, { "id": "iso_42001", "section": "A.6.2.6", "title": "AI system operation and monitoring" }, { "id": "aws_bedrock_kb", "section": "Knowledge Bases Retrieve API", "title": "Relevance scores and result filtering" }, { "id": "google_vertex_rag", "section": "Grounded generation", "title": "Grounding support scores" } ], "sources": [ { "id": "google_vertex_ai_rag_2024", "title": "Google Vertex AI RAG & Grounding", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/vertex-ai/docs/generative-ai/grounding/overview", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_vertex_ai_rag_2024", "relationship": "informative_reference", "rationale": "Establishes Google Vertex AI RAG & Grounding requirements informing the apeiris://knowledge/controls/KR-01 Retrieval Relevance Quality Standards control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_knowledge_bases_2024", "title": "Amazon Bedrock Knowledge Bases", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_knowledge_bases_2024", "relationship": "informative_reference", "rationale": "Establishes Amazon Bedrock Knowledge Bases requirements informing the apeiris://knowledge/controls/KR-01 Retrieval Relevance Quality Standards control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define a per-deployment minimum relevance score threshold (cosine similarity, BM25, or hybrid ranking) below which chunks are filtered from the retrieval context window. Implement threshold tuning pipelines using human-labeled evaluation sets, and expose real-time relevance metrics to monitoring dashboards.", "steps": [ "Establish a baseline relevance evaluation dataset of at least 200 query-chunk pairs labeled by domain experts for relevance.", "Configure the retrieval system with a hard-filter threshold (e.g., cosine similarity >= 0.72) and a soft-warning band for chunks between threshold and threshold+0.05.", "Implement a weekly relevance regression test that re-evaluates the threshold against the labeled dataset and alerts when precision drops by more than 5 percentage points.", "Document the threshold rationale, tuning methodology, and acceptable precision floor in the knowledge system's operational runbook." ], "knowledge_engineer": { "summary": "You own the relevance evaluation dataset and tuning pipeline. The threshold must be defensible against the labeled set.", "actions": [ "Build and maintain a query-chunk relevance evaluation dataset with domain expert labels.", "Configure vector store and hybrid retrieval thresholds based on evaluation results.", "Publish threshold values and tuning history to the knowledge governance log." ], "failure_signals": [ "Retrieval precision below defined floor for two consecutive weekly evaluations.", "Threshold changed without corresponding evaluation dataset update.", "Labeled evaluation set not refreshed within 90 days." ] }, "data_scientist": { "summary": "Maintain the scoring models and ensure the relevance metric correctly reflects downstream response quality.", "actions": [ "Validate that the chosen relevance metric (cosine, BM25, hybrid) correlates with human-rated response quality.", "Run A/B evaluations when threshold changes are proposed.", "Monitor for distribution shift in query embeddings that would invalidate the existing threshold." ], "failure_signals": [ "Correlation between retrieval score and response quality drops below 0.6.", "Embedding distribution shift detected without threshold re-evaluation.", "A/B test results not reviewed before threshold change is applied to production." ] }, "it_operations": { "summary": "Relevance thresholds are runtime configuration: they must be config-managed, consistent across serving replicas, and observable \u2014 a silently lowered threshold is a quality incident.", "actions": [ "Keep relevance thresholds in version-controlled configuration with change review.", "Emit threshold values and rejection rates as serving telemetry with alerts on drift.", "Test threshold behavior in staging with golden query sets before rollout." ], "failure_signals": [ "Serving replicas run with inconsistent threshold configurations.", "A threshold change ships without review and rejection rates collapse." ] }, "grc_auditor": { "summary": "The retrieval threshold and evaluation dataset are auditable evidence that relevance standards are enforced operationally.", "actions": [ "Request the current threshold configuration and confirm it matches the value in the operational runbook.", "Review the evaluation dataset creation date and verify it is within the 90-day refresh SLA.", "Confirm that threshold breach alerts have been actioned within defined SLA." ], "metrics": [ "Retrieval precision at defined threshold: target >= 85%.", "Evaluation dataset freshness: <= 90 days since last refresh.", "Threshold breach alert response rate: 100% actioned within SLA." ], "failure_signals": [ "Threshold not documented in operational runbook.", "Evaluation dataset older than 90 days.", "Threshold breach alerts unresolved beyond SLA." ] }, "legal_counsel": { "summary": "Relevance standards limit the risk of the AI answering from marginally related content \u2014 a key control when answers carry advice-like weight in regulated interactions.", "actions": [ "Confirm relevance standards are stricter for regulated query categories where wrong-context answers create liability.", "Review the fallback behavior when nothing meets threshold \u2014 declining to answer is often the defensible outcome.", "Preserve threshold configuration history as evidence of the standard in force at any given time." ], "failure_signals": [ "The AI answers a compliance question from a marginally relevant document because thresholds were relaxed.", "No record exists of the relevance standard in force when a disputed answer was produced." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises deploy RAG systems without formal relevance thresholds, relying on subjective quality assessments." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise" ], "implementers": [ "Knowledge Engineer", "Data Scientist", "Platform Engineering" ], "frameworks": [ { "framework": "iso_30401", "requirement_id": "Clause 8", "fit": "direct", "rationale": "ISO 30401:2018 Clause 8 (Operation) requires the processes needed for knowledge management to be planned, implemented and controlled so knowledge remains findable and fit for purpose. Retrieval relevance thresholds are a direct operational control for ensuring retrieved knowledge meets fitness standards.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "A.6.2.6", "fit": "direct", "rationale": "ISO/IEC 42001:2023 Annex A control A.6.2.6 requires organizations to define and operate controls for the operation and monitoring of AI systems. Retrieval relevance thresholds are an operation-stage control ensuring inference inputs meet defined quality standards before inclusion in the context window.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_bedrock_kb", "requirement_id": "Knowledge Bases \u2014 Retrieve API relevance scores", "fit": "direct", "rationale": "Amazon Bedrock Knowledge Bases returns relevance scores with retrieved results and supports result filtering, enabling minimum-threshold enforcement before chunks reach the model context window. This control implements that platform pattern in a platform-agnostic governance framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_vertex_rag", "requirement_id": "Grounded generation \u2014 grounding support scores", "fit": "direct", "rationale": "Google Vertex AI grounded generation returns grounding support scores for generated content, and Vertex AI Search returns relevance-ranked results, enabling score thresholds tuned against task-specific evaluation sets. This control implements that configuration pattern in a platform-agnostic governance framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "itil_4", "requirement_id": "\u00a75.1.4", "fit": "partial", "rationale": "The ITIL 4 knowledge management practice (5.1.4) defines quality expectations for knowledge assets \u2014 current, accurate, and fit for use. Retrieval relevance standards extend those quality criteria to automated AI retrieval, and ITIL's continual improvement loop applies directly to threshold tuning cycles.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KR-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The retrieval system must enforce a documented minimum relevance score threshold (cosine similarity, BM25, or hybrid) below which candidate chunks are excluded from the AI context window at runtime, and the threshold must be validated against a human-labeled evaluation dataset of at least 200 query-chunk pairs demonstrating retrieval precision at or above the defined floor.", "evidence_required": [ "retrieval_threshold_configuration_record documenting the current minimum relevance score, scoring method, acceptable precision floor, and date of last calibration", "relevance_evaluation_dataset with at least 200 human-labeled query-chunk relevance pairs and the computed precision score at the configured threshold", "weekly_relevance_regression_report showing precision trend across the prior 13 weeks with any threshold breach alerts and their resolution status", "threshold_tuning_rationale_document in the operational runbook explaining the methodology, evaluation results, and justification for the configured value" ], "machine_tests": [ "Submit a query with deliberately mismatched vocabulary to the retrieval system \u2192 assert zero chunks above the configured threshold score are returned", "Run the weekly relevance regression test against the labeled evaluation dataset \u2192 assert computed precision meets or exceeds the defined floor (e.g., >= 85%)", "Reduce the threshold below the calibrated value and re-run the regression test \u2192 assert the system generates an alert requiring updated evaluation before the threshold change is applied to production" ], "human_review": [ "Review the relevance evaluation dataset to confirm it was refreshed within the past 90 days and contains queries representative of current production traffic distribution", "Assess whether the chosen relevance metric correlates with human-rated response quality for the target domain rather than surface-level keyword overlap", "Verify that threshold breach alert responses from the prior quarter have been actioned within SLA and that all threshold changes are accompanied by updated evaluation dataset results" ], "blocking_effect": "blocks-runtime-action", "normative_status": "certification-standard", "anti_patterns": [ "Setting a single global relevance threshold without calibrating it against domain-specific labeled data, resulting in a value that is simultaneously too permissive for high-quality domains and too restrictive for broader corpus queries", "Using retrieval count (top-k) as the sole chunk selection criterion without a minimum relevance score floor, which accepts low-quality chunks whenever fewer than k high-quality chunks are available", "Evaluating the threshold only at initial deployment and never re-evaluating when knowledge base content, query distribution, or embedding models change", "Treating the threshold as a code constant rather than a documented, auditable governance parameter stored separately from application logic and subject to change control" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KR" }, { "id": "KR-02", "layer": "KR", "plane": "control", "name": "Grounding Completeness Requirements", "plain": "AI systems using retrieval augmentation must verify that retrieved content substantively supports each factual claim in the generated response, not merely shares topical overlap with the query, and must flag or suppress responses where grounding coverage falls below defined completeness thresholds.", "threat": { "tags": [ "ungrounded-response", "partial-grounding", "source-gap", "hallucination-enablement" ], "desc": "Topical retrieval match is insufficient to ground a response \u2014 retrieved documents may share keywords with a query while failing to support the specific claims the AI asserts. Partial grounding creates a false confidence that the response is sourced when critical claims are actually fabricated. This gap between retrieved context and response claims is a primary enabler of confident hallucination that evades naive relevance checks." }, "standard": [ { "id": "iso_42001", "section": "\u00a76.1.2", "title": "AI risk assessment \u2014 grounding integrity" }, { "id": "eu_ai_act", "section": "Art. 13", "title": "Transparency and provision of information \u2014 grounding completeness" }, { "id": "google_vertex_rag", "section": "RAG \u00a73.2", "title": "Grounding completeness and attribution" }, { "id": "anthropic_transparency", "section": "Model card", "title": "Factual-accuracy evaluations and limitations" } ], "sources": [ { "id": "anthropic_model_cards_2024", "title": "Anthropic Model Cards & Knowledge Disclosure", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/transparency", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_transparency", "relationship": "informative_reference", "rationale": "Establishes Anthropic Model Cards & Knowledge Disclosure requirements informing the apeiris://knowledge/controls/KR-02 Grounding Completeness Requirements control.", "reviewed_on": "2026-07-01" }, { "id": "google_vertex_ai_rag_2024", "title": "Google Vertex AI RAG & Grounding", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/vertex-ai/docs/generative-ai/grounding/overview", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_vertex_ai_rag_2024", "relationship": "informative_reference", "rationale": "Establishes Google Vertex AI RAG & Grounding requirements informing the apeiris://knowledge/controls/KR-02 Grounding Completeness Requirements control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_knowledge_bases_2024", "title": "Amazon Bedrock Knowledge Bases", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_knowledge_bases_2024", "relationship": "informative_reference", "rationale": "Establishes Amazon Bedrock Knowledge Bases requirements informing the apeiris://knowledge/controls/KR-02 Grounding Completeness Requirements control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Implement claim-level grounding verification that maps each factual assertion in AI output back to a specific retrieved chunk, computing grounding coverage as the ratio of supported claims to total claims. Responses below a defined coverage threshold are either blocked, downgraded to advisory status, or returned with explicit uncertainty markers.", "steps": [ "Deploy a grounding verification component that segments AI responses into discrete factual claims and attempts to locate supporting text in the retrieved context.", "Define a grounding coverage threshold (e.g., >= 80% of claims must be traceable to retrieved content) below which the response is flagged.", "Implement three disposition paths for under-grounded responses: block (high-risk contexts), advisory label (general contexts), and uncertainty marker injection (low-stakes contexts).", "Log grounding coverage scores per response to the retrieval audit trail (KR-07) for trend analysis." ], "knowledge_engineer": { "summary": "Design the claim segmentation and grounding mapping pipeline so it correctly identifies factual assertions versus hedges and qualifications.", "actions": [ "Build or integrate a claim extraction module that separates factual assertions from hedging language.", "Map extracted claims to retrieved chunk spans and compute per-response coverage scores.", "Define the coverage threshold in collaboration with the data science team based on task-specific evaluation." ], "failure_signals": [ "Claim extraction module misclassifying hedges as factual assertions at rate above 15%.", "Coverage computation not accounting for multi-chunk claim support.", "Grounding threshold not documented or not enforced in production pipeline." ] }, "data_scientist": { "summary": "Evaluate the grounding verification pipeline against human-labeled datasets to ensure coverage scores correlate with actual factual accuracy.", "actions": [ "Label a test set of 200+ responses with human grounding assessments and validate the automated coverage scores against them.", "Tune the claim segmentation model to minimize both false positives (claiming support that does not exist) and false negatives (missing real support).", "Monitor coverage score distributions across query types to detect systematic grounding gaps." ], "failure_signals": [ "Automated coverage score agreement with human labels below 75%.", "Coverage distribution shift across query categories without explanation.", "Test set not updated in more than 90 days." ] }, "it_operations": { "summary": "Grounding enforcement is a serving-path control: coverage scoring must run inline, blocking dispositions must actually block, and grounding telemetry must reach the observability stack.", "actions": [ "Deploy grounding coverage checks inline in the response path with fail-closed behavior on scorer errors.", "Alert on grounding score distribution shifts, which often signal retrieval or prompt regressions.", "Load-test the grounding checker so enforcement does not get disabled under latency pressure." ], "failure_signals": [ "Grounding checks were switched off during a latency incident and never re-enabled.", "Blocking dispositions log but do not actually suppress ungrounded responses." ] }, "grc_auditor": { "summary": "Grounding completeness metrics are primary evidence that AI outputs are substantiated by retrieved sources in high-risk use cases.", "actions": [ "Confirm grounding threshold is documented and matches production configuration.", "Review the grounding score distribution report for the prior quarter and flag any sustained below-threshold patterns.", "Verify that high-risk deployment contexts are configured with the blocking disposition rather than advisory." ], "metrics": [ "Mean grounding coverage across all production responses: target >= 80%.", "Rate of blocked responses due to grounding failure in high-risk contexts: tracked monthly.", "Human-label agreement on grounding pipeline: >= 75%." ], "failure_signals": [ "Mean grounding coverage below threshold for two consecutive reporting periods.", "High-risk contexts configured with advisory rather than blocking disposition.", "No quarterly grounding distribution review on record." ] }, "legal_counsel": { "summary": "Grounding completeness is a liability control \u2014 under-grounded AI outputs used in legal, medical, or financial contexts create foreseeable harm from unsupported factual claims.", "actions": [ "Review grounding policy to confirm it aligns with applicable sector regulations on AI-generated factual statements.", "Confirm that ungrounded responses in regulated use cases are suppressed or clearly labeled as unverified.", "Ensure grounding coverage metrics are included in any AI system regulatory disclosure or audit package." ], "failure_signals": [ "AI system used in regulated context without grounding verification enabled.", "Grounding failures in regulated contexts not reported to legal within defined SLA.", "Regulatory disclosure package omits grounding coverage metrics." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most RAG deployments rely on relevance scores as a proxy for grounding without verifying that retrieved content actually supports individual output claims." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Knowledge Engineer", "Data Scientist", "GRC Team" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a76.1.2", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a76.1.2 requires organizations to assess risks to AI system outputs including incomplete or inaccurate information generation. Grounding completeness directly addresses the risk of AI systems generating unsubstantiated factual claims despite operating in a retrieval-augmented context. The standard requires documented controls proportional to the identified output risks.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 13", "fit": "direct", "rationale": "EU AI Act Article 13 requires that high-risk AI systems provide output that allows users to interpret results appropriately, including understanding when outputs are not fully supported by available data. Grounding completeness verification operationalizes this interpretability requirement at the response level. The blocking and labeling dispositions implement the transparency obligations for under-grounded responses.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_vertex_rag", "requirement_id": "Grounded generation \u2014 grounding supports and citations", "fit": "direct", "rationale": "Google Vertex AI grounded generation provides grounding supports that link response segments to the supporting retrieved passages, with support scores measuring how well retrieved content backs the response. This control generalizes that completeness measurement methodology across platforms.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_transparency", "requirement_id": "Model card \u2014 factual-accuracy evaluations and limitations", "fit": "adjacent", "rationale": "Anthropic's model cards and system cards report factual-accuracy evaluation results and known limitations of deployed models; they do not define a grounding-versus-parametric answer policy for deployers. Grounding completeness requirements build on those disclosed limitations by making retrieval support an enforced property of enterprise deployments.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_bedrock_kb", "requirement_id": "Guardrails \u2014 contextual grounding check", "fit": "partial", "rationale": "Amazon Bedrock Guardrails' contextual grounding check evaluates whether model responses are grounded in the retrieved source content and can block responses below a configured grounding threshold. It is a platform-native implementation of the coverage metric this control standardizes across platforms.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KR-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The AI response pipeline must include a grounding verification component that segments generated responses into factual claims, maps each claim to retrieved chunk spans, computes a per-response grounding coverage score, and enforces a documented threshold-based disposition (block, advisory label, or uncertainty marker injection) before delivering any response whose coverage falls below the defined minimum.", "evidence_required": [ "grounding_coverage_threshold_configuration_record documenting the defined minimum threshold, the disposition path for each coverage level, and the date of last calibration against labeled data", "grounding_coverage_distribution_report for the prior quarter showing mean coverage score, under-threshold rate, and count of blocking events in high-risk contexts", "claim_grounding_evaluation_dataset with at least 200 human-labeled response-context pairs and the automated pipeline's agreement rate against human assessments", "grounding_audit_log_sample showing per-response claim_count, supported_claim_count, coverage_score, and disposition_applied for a representative set of production responses" ], "machine_tests": [ "Submit a query whose complete answer requires information absent from the retrieved context \u2192 assert the response grounding coverage score falls below threshold and the configured disposition is applied before delivery", "Submit a query fully answerable from the retrieved chunks \u2192 assert the grounding coverage score meets or exceeds the configured threshold with no advisory label or blocking disposition applied", "Disable the grounding verification component in a test environment \u2192 assert the pipeline rejects the configuration and refuses to serve responses without grounding verification active" ], "human_review": [ "Review the grounding distribution report for the prior quarter to identify sustained patterns of below-threshold coverage concentrated in specific query categories or knowledge base domains", "Verify that all high-risk deployment contexts are configured with blocking disposition rather than advisory label or uncertainty marker injection", "Assess the claim segmentation module by sampling 20 response-context pairs and evaluating whether it correctly distinguishes factual assertions from hedging language and qualifications" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Relying on retrieval relevance scores as a proxy for grounding completeness without verifying that retrieved documents actually support each individual claim in the generated response", "Configuring advisory labeling as the sole disposition for under-grounded responses in high-risk deployment contexts where unsubstantiated factual claims cause direct harm", "Computing grounding coverage as topical overlap between query terms and retrieved text rather than as claim-to-supporting-text alignment, which fails to detect confident hallucination within a topically relevant but claim-deficient context window", "Excluding hedging language from claim segmentation without validation, resulting in overcounting of claims from uncertainty markers that artificially deflates the coverage score" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KR" }, { "id": "KR-03", "layer": "KR", "plane": "control", "name": "Citation Fidelity and Accuracy Enforcement", "plain": "When AI systems produce responses that cite specific sources, those citations must accurately identify the source document, the relevant passage, and the claim it supports \u2014 and automated verification must confirm citations are not fabricated, misattributed, or materially misrepresented.", "threat": { "tags": [ "citation-fabrication", "misattribution", "source-distortion", "attribution-integrity-failure" ], "desc": "AI systems frequently generate plausible-looking citations that do not exist or that misrepresent the content of real sources. Citation fabrication creates liability when users act on invented references in legal, medical, or financial contexts. Even accurate source references that misrepresent a document's actual claims \u2014 through selective quotation or reversed conclusions \u2014 constitute a material integrity failure that citation fidelity enforcement must detect." }, "standard": [ { "id": "w3c_prov", "section": "PROV-DM \u00a75.3.2", "title": "Attribution \u2014 ascribing entities to agents" }, { "id": "iso_30401", "section": "\u00a77.5", "title": "Documented information \u2014 accuracy and traceability" }, { "id": "eu_ai_act", "section": "Art. 13(3)", "title": "Transparency \u2014 citation and sourcing obligations" }, { "id": "iso_42001", "section": "\u00a79.1", "title": "Performance evaluation \u2014 output fidelity monitoring" } ], "sources": [ { "id": "anthropic_model_cards_2024", "title": "Anthropic Model Cards & Knowledge Disclosure", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/transparency", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_transparency", "relationship": "informative_reference", "rationale": "Establishes Anthropic Model Cards & Knowledge Disclosure requirements informing the apeiris://knowledge/controls/KR-03 Citation Fidelity and Accuracy Enforcement control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "For each citation produced in an AI response, verify: (1) the source document exists in the knowledge base, (2) the cited passage is present verbatim or substantially in that document, and (3) the claim the citation supports is directionally consistent with the source text. Implement automated citation verification at generation time and log verification results per citation.", "steps": [ "Implement a citation extraction module that identifies source references, document IDs, passage quotes, and attributed claims in AI responses.", "Cross-reference each extracted citation against the knowledge base to verify document existence and passage presence using exact and fuzzy matching.", "Run a semantic consistency check comparing the AI's stated claim against the cited passage to detect directional misrepresentation.", "Block or redact citations that fail existence or consistency checks, and append a citation verification status field to the audit log entry." ], "knowledge_engineer": { "summary": "Maintain the citation verification pipeline and ensure the knowledge base indexes are consistent enough to support exact and fuzzy passage lookup.", "actions": [ "Build a citation extraction and verification module integrated into the response post-processing pipeline.", "Maintain document and passage lookup indexes that support both exact and approximate citation matching.", "Define pass/fail criteria for citation consistency checks and calibrate against human-labeled examples." ], "failure_signals": [ "Citation verification pipeline not running on all citations in production.", "Passage lookup index not synchronized with knowledge base within 24 hours of ingestion.", "Consistency check threshold not calibrated against labeled examples." ] }, "data_scientist": { "summary": "Validate that the semantic consistency model accurately identifies claim-to-source directional agreement and disagreement.", "actions": [ "Build a labeled evaluation set of citation-claim pairs with human directional consistency labels.", "Evaluate the consistency check model against the labeled set, targeting F1 >= 0.85.", "Monitor for performance drift as knowledge base content evolves and retrain when F1 drops below 0.80." ], "failure_signals": [ "F1 score on labeled evaluation set below 0.85.", "Evaluation set not updated within 90 days.", "Model not re-evaluated after major knowledge base update." ] }, "it_operations": { "summary": "Citation verification is pipeline infrastructure: the verifier must resolve cited IDs against the actual retrieval set on every response and record verdicts for audit.", "actions": [ "Run citation verification on every cited response, comparing citations against the actual retrieved chunk set.", "Persist verification verdicts with response IDs so fabricated-citation reports are investigable.", "Alert when the citation failure rate rises after model or prompt changes." ], "failure_signals": [ "Cited sources do not resolve to anything in the retrieval log for the same response.", "Verification verdicts are sampled rather than complete, leaving gaps in the audit record." ] }, "grc_auditor": { "summary": "Citation fidelity verification results are primary evidence for regulatory and legal defensibility of AI-generated content containing source references.", "actions": [ "Review citation verification failure rate reports for the prior quarter.", "Confirm that fabricated or failed citations are blocked in high-risk deployment contexts.", "Sample 20 citation verification log entries per audit cycle and manually spot-check accuracy." ], "metrics": [ "Citation existence verification pass rate: target >= 99%.", "Citation consistency check pass rate: target >= 90%.", "Mean time to block failed citations in production: target < 100ms." ], "failure_signals": [ "Citation existence pass rate below 99% without documented explanation.", "Manual spot-check finding discrepancies not matching automated results.", "High-risk contexts not configured to block failed citations." ] }, "legal_counsel": { "summary": "Fabricated citations create direct legal liability. Citation fidelity controls are a prerequisite for deploying AI in any context where source claims have legal, medical, or financial consequences.", "actions": [ "Confirm that citation verification is enabled for all AI deployments in regulated or high-stakes use cases.", "Review the scope of citation consistency checks to confirm they detect directional claim reversal, not just exact text match.", "Ensure citation verification failures are documented and retained as part of the AI system's legal defensibility record." ], "failure_signals": [ "AI citation verification disabled in regulated deployment context.", "Consistency check limited to keyword overlap without semantic directional check.", "Citation verification failure records not retained per applicable retention policy." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Citation verification is rare in production RAG deployments; most systems rely on retrieval to prevent hallucination without verifying what citations are actually produced in responses." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Knowledge Engineer", "GRC Team", "Legal Counsel", "Data Scientist" ], "frameworks": [ { "framework": "w3c_prov", "requirement_id": "PROV-DM \u00a75.3.2", "fit": "direct", "rationale": "W3C PROV-DM \u00a75.3.2 defines the Attribution relation (wasAttributedTo), ascribing an entity to an agent. Citation fidelity enforcement verifies that stated attributions in AI outputs correspond to actual provenance relations, making wasAttributedTo the normative basis for citation accuracy requirements.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 13(3)", "fit": "direct", "rationale": "EU AI Act Article 13(3) requires high-risk AI systems to provide information enabling users to interpret outputs correctly, including source attribution information. Citation fabrication directly violates the interpretability requirement by presenting invented references as real. The Act's transparency obligations require that citations in AI outputs be verifiably accurate when used in high-risk contexts.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_30401", "requirement_id": "\u00a77.5", "fit": "partial", "rationale": "ISO 30401:2018 \u00a77.5 requires that documented knowledge information be accurate, traceable to its origin, and suitable for its intended use. Citation fidelity controls extend this requirement to AI-generated knowledge artifacts by ensuring that source references embedded in AI outputs are traceable to actual knowledge base content. The standard's accuracy and traceability principles apply directly to AI citation integrity.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "\u00a79.1", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a79.1 requires organizations to monitor and measure AI system performance including output quality and accuracy. Citation fidelity verification is a measurable output quality control that operationalizes the \u00a79.1 performance evaluation requirement for RAG systems. The citation existence and consistency pass rates are directly reportable as \u00a79.1 performance metrics.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_transparency", "requirement_id": "Model card \u2014 known limitations and citation-accuracy risks", "fit": "adjacent", "rationale": "Anthropic's model and system cards disclose known failure modes of deployed models, including the risk that generated references may not correspond to real sources. Citation fidelity enforcement addresses that disclosed risk at the deployment layer by verifying stated citations against actual retrieval provenance.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KR-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every citation produced in an AI response must be verified before delivery against the knowledge base for document existence, passage presence, and directional claim consistency, achieving a citation existence pass rate of >= 99% and a semantic consistency model F1 of >= 0.85 on the labeled evaluation set, with citations failing either check blocked or redacted in all high-risk deployment contexts.", "evidence_required": [ "citation_verification_log for the prior quarter showing per-citation existence_check_result, passage_match_result, consistency_check_score, and final disposition for each citation produced", "citation_existence_pass_rate_report showing percentage of produced citations that resolved to real documents and passages in the knowledge base over the reporting period", "citation_consistency_evaluation_dataset with human-labeled citation-claim pairs and the computed F1 score for the semantic directional consistency model", "citation_blocking_configuration_record confirming that failed citations are blocked or redacted in all configured high-risk deployment contexts" ], "machine_tests": [ "Prompt the AI system with a query that elicits citation of a document not present in the knowledge base \u2192 assert the citation verification module returns existence_check=failed and the citation is blocked or redacted before response delivery", "Produce a response citing an existing document but attributing a claim that contradicts that document's actual content \u2192 assert the semantic consistency check returns consistency_check=failed for that citation", "Submit 100 production-representative queries and run citation verification on all produced citations \u2192 assert citation existence pass rate >= 99% and confirm no unverified citations appear in responses served in high-risk contexts" ], "human_review": [ "Sample 20 citation verification log entries and manually verify passage match and consistency check results against the actual source documents in the knowledge base to detect systematic false-pass patterns", "Review the consistency check model F1 evaluation report to confirm it was updated within 90 days of the most recent major knowledge base update and meets the >= 0.85 target", "Assess whether the citation extraction module correctly identifies all citation formats present in production responses, including document IDs, URLs, passage quotes, and inline footnote references" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Assuming that retrieving a source document confirms the accuracy of any specific claim attributed to it, without checking whether the cited passage is present or the attributed claim is directionally supported", "Limiting citation verification to URL format validation or title matching without performing passage-level presence checks against indexed knowledge base content", "Configuring citation failure disposition as a logged warning rather than response blocking in legal, medical, or financial contexts where fabricated citations create direct liability exposure", "Running citation verification in sampling mode covering only a fraction of produced citations rather than enforcing 100% coverage, which allows fabricated citations to pass undetected at a predictable rate", "Conflating topical relevance of a source document with directional claim support, which passes citations where the source discusses the topic but contradicts the specific claim being attributed to it" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KR" }, { "id": "KR-04", "layer": "KR", "plane": "control", "name": "Retrieval Hallucination Detection", "plain": "AI systems operating with retrieval augmentation must detect and flag responses where the AI's output contradicts, misrepresents, or generates claims beyond the scope of the retrieved context, distinguishing retrieval-grounded statements from model-generated fabrications.", "threat": { "tags": [ "hallucination", "retrieval-contradiction", "parametric-leakage", "grounding-bypass" ], "desc": "Retrieval-augmented AI systems can still hallucinate when the model's parametric knowledge overrides or supplements retrieved context with fabricated information. Retrieval contradiction \u2014 where AI output directly conflicts with retrieved sources \u2014 is a severe hallucination mode that is harder to detect than pure fabrication because it co-occurs with legitimately retrieved content. Without active detection, hallucinations in RAG systems appear grounded to downstream consumers who see citation markers but cannot inspect the actual claim-to-source alignment." }, "standard": [ { "id": "iso_42001", "section": "\u00a76.1.2", "title": "AI risk assessment \u2014 hallucination and output accuracy" }, { "id": "eu_ai_act", "section": "Art. 9", "title": "Risk management system \u2014 mitigation of output-accuracy risks" }, { "id": "anthropic_transparency", "section": "Model card", "title": "Hallucination and factuality evaluation results" }, { "id": "google_vertex_rag", "section": "Check Grounding API", "title": "Grounding support scoring for hallucination detection" } ], "sources": [ { "id": "anthropic_model_cards_2024", "title": "Anthropic Model Cards & Knowledge Disclosure", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/transparency", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_transparency", "relationship": "informative_reference", "rationale": "Establishes Anthropic Model Cards & Knowledge Disclosure requirements informing the apeiris://knowledge/controls/KR-04 Retrieval Hallucination Detection control.", "reviewed_on": "2026-07-01" }, { "id": "google_vertex_ai_rag_2024", "title": "Google Vertex AI RAG & Grounding", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/vertex-ai/docs/generative-ai/grounding/overview", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_vertex_ai_rag_2024", "relationship": "informative_reference", "rationale": "Establishes Google Vertex AI RAG & Grounding requirements informing the apeiris://knowledge/controls/KR-04 Retrieval Hallucination Detection control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_knowledge_bases_2024", "title": "Amazon Bedrock Knowledge Bases", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_knowledge_bases_2024", "relationship": "informative_reference", "rationale": "Establishes Amazon Bedrock Knowledge Bases requirements informing the apeiris://knowledge/controls/KR-04 Retrieval Hallucination Detection control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Deploy a hallucination detection layer that evaluates AI responses against retrieved context using natural language inference (NLI) or entailment models to classify each response segment as entailed, neutral, or contradicted by the retrieved passages. Responses with contradiction segments above a threshold are flagged, quarantined, or returned with explicit hallucination risk markers.", "steps": [ "Integrate an NLI-based hallucination detection model fine-tuned for the target domain into the response post-processing pipeline.", "Segment each AI response into claim units and run entailment scoring against each retrieved chunk to produce per-claim entailment labels (entailed/neutral/contradicted).", "Define disposition thresholds: responses with any contradiction-labeled segment in high-risk contexts are blocked; general contexts receive hallucination risk markers.", "Log per-claim entailment labels, contradiction counts, and overall hallucination risk score to the retrieval audit trail (KR-07)." ], "knowledge_engineer": { "summary": "Integrate the hallucination detection model into the retrieval pipeline and ensure it receives the same context window passed to the generative model.", "actions": [ "Instrument the retrieval pipeline to pass both the retrieved context and the generated response to the NLI hallucination detector.", "Maintain the claim segmentation module shared with the grounding completeness pipeline (KR-02) to avoid duplication.", "Define the hallucination risk score calculation and document threshold values in the operational runbook." ], "failure_signals": [ "Hallucination detector not receiving full retrieved context window.", "NLI model not calibrated against domain-specific vocabulary.", "Hallucination risk scores not included in audit log entries." ] }, "data_scientist": { "summary": "Select, fine-tune, and evaluate the NLI model for hallucination detection accuracy on the target domain's content.", "actions": [ "Build a labeled evaluation set of response-context pairs with human hallucination labels (entailed, neutral, contradicted).", "Fine-tune or configure the NLI model to achieve F1 >= 0.80 on the domain evaluation set.", "Monitor NLI model performance drift quarterly and retrain when F1 drops below 0.75." ], "failure_signals": [ "NLI model F1 on domain evaluation set below 0.80 without accepted risk exception.", "Evaluation set not updated within 90 days of knowledge base major update.", "Model performance not monitored between quarterly reviews." ] }, "it_operations": { "summary": "Ensure the hallucination detection layer has sufficient compute capacity to operate within response latency SLAs.", "actions": [ "Provision dedicated inference capacity for the NLI hallucination detection model to avoid latency spikes.", "Monitor NLI inference latency and alert when p99 latency exceeds 500ms.", "Maintain fail-closed fallback behavior (conservative blocking) when the NLI service is unavailable." ], "failure_signals": [ "NLI inference p99 latency exceeding 500ms in production.", "Hallucination detection service unavailable without fallback blocking active.", "Capacity not provisioned for peak load scenarios." ] }, "grc_auditor": { "summary": "Hallucination detection rates and blocking events are core evidence for AI system accuracy governance in high-risk deployments.", "actions": [ "Review the quarterly hallucination detection rate report and compare against accepted risk thresholds.", "Confirm that blocking dispositions are active for high-risk deployment contexts.", "Verify that the NLI model evaluation report is current and meets the F1 target." ], "metrics": [ "Rate of responses flagged for hallucination risk: tracked monthly.", "Rate of hallucination-flagged responses blocked in high-risk contexts: target 100%.", "NLI model F1 on evaluation set: target >= 0.80." ], "failure_signals": [ "Hallucination flagging rate not reported for prior quarter.", "High-risk contexts not blocking flagged responses.", "NLI evaluation report not current (older than 90 days)." ] }, "legal_counsel": { "summary": "Hallucinated output presented as sourced fact is the highest-liability failure of a knowledge system: it can constitute misrepresentation, and in regulated contexts, reportable harm.", "actions": [ "Set the blocking policy for detected hallucinations in high-stakes categories with counsel input \u2014 block, don't caveat.", "Define when hallucination incidents trigger customer notification or regulator reporting.", "Preserve detection and disposition records for defense of claims arising from AI-provided misinformation." ], "failure_signals": [ "A hallucinated answer in a regulated interaction reached a customer with a fabricated citation.", "No disposition record exists for a detected hallucination that later caused a complaint." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Hallucination detection in RAG systems is an active research area; most production deployments lack automated contradiction detection at the response level." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Data Scientist", "Knowledge Engineer", "Platform Engineering" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a76.1.2", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a76.1.2 requires identification and assessment of risks specific to AI systems including the risk of inaccurate or misleading outputs. Hallucination in retrieval-augmented systems is an identified AI-specific risk requiring operational controls proportional to the deployment context's risk level. The standard's risk treatment requirements map directly to the detection and blocking dispositions defined in this control.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9", "fit": "direct", "rationale": "EU AI Act Article 9 requires high-risk AI systems to operate under a risk management system that identifies foreseeable risks to health, safety and fundamental rights and adopts targeted mitigation measures. Ungrounded or fabricated output is such a risk in high-risk contexts, making hallucination detection with a blocking disposition an appropriate risk management measure for those deployments.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_vertex_rag", "requirement_id": "Check Grounding API", "fit": "direct", "rationale": "Google Vertex AI's Check Grounding API returns a support score for a candidate answer against provided facts, detecting when generated responses diverge from retrieved context \u2014 a direct platform implementation of the hallucination detection this control standardizes. Per-claim citation metadata in the response enables the entailment labels this control requires.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_transparency", "requirement_id": "Model card \u2014 hallucination and factuality evaluations", "fit": "adjacent", "rationale": "Anthropic's model cards report hallucination-related evaluation results and known failure modes for deployed models, giving operators a disclosed baseline for factual reliability. A retrieval hallucination detection layer operationalizes monitoring of those failure modes in production deployments.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_bedrock_kb", "requirement_id": "Guardrails \u2014 contextual grounding check", "fit": "partial", "rationale": "Amazon Bedrock Guardrails' contextual grounding check detects when model outputs are not supported by retrieved content and supports threshold-based blocking \u2014 a platform-native implementation of the hallucination risk scoring this control defines across platforms.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KR-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The AI response pipeline must include a hallucination detection layer using natural language inference or equivalent entailment modeling that classifies each response claim as entailed, neutral, or contradicted by retrieved context, with the NLI model achieving F1 >= 0.80 on the domain-specific evaluation set, and all contradiction-flagged responses blocked before delivery in high-risk deployment contexts.", "evidence_required": [ "nli_model_evaluation_report showing F1 score on the domain-specific evaluation set with human entailment labels, produced within the past 90 days", "hallucination_detection_rate_report for the prior quarter showing per-month rates of entailed/neutral/contradicted classifications and count of blocking events in high-risk contexts", "per_response_entailment_audit_log sample showing claim_count, contradiction_count, hallucination_risk_score, and disposition_applied for a representative set of production responses", "hallucination_evaluation_dataset with at least 200 human-labeled response-context pairs covering entailed, neutral, and contradicted examples representative of the target domain" ], "machine_tests": [ "Submit a query and inject a fabricated claim directly contradicting a retrieved chunk into the generated response \u2192 assert the NLI detector classifies at least one claim as contradicted and applies the configured blocking or flagging disposition", "Submit a query whose answer is fully supported by retrieved context \u2192 assert all claims are classified as entailed or neutral with zero contradiction flags and no blocking disposition applied", "Simulate NLI service unavailability during response generation \u2192 assert the pipeline fails closed and blocks response delivery rather than passing the response through without hallucination detection" ], "human_review": [ "Review the NLI model F1 evaluation report and verify the domain evaluation set contains queries and contexts representative of current production knowledge base content, not just the initial deployment corpus", "Assess blocking configuration for all high-risk deployment contexts and confirm that any response with at least one contradicted-claim segment is blocked rather than labeled", "Sample 10 hallucination-flagged responses from the prior quarter and manually assess whether flagged contradictions are genuine versus NLI false positives requiring threshold recalibration" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Using retrieval relevance scores as a substitute for contradiction detection, which cannot identify cases where the AI model's parametric knowledge overrides retrieved context with a factually divergent claim", "Deploying a general-purpose NLI model without fine-tuning on the target domain's vocabulary and reasoning patterns, producing high false-positive rates that erode operational trust in the detection system", "Configuring the hallucination detection layer to fail open (pass-through) when the NLI service is unavailable, converting a critical output quality control into an exploitable availability bypass", "Running NLI entailment scoring only at the full-response level rather than the claim unit level, which allows individual contradicted statements to be masked by a majority of entailed claims in the aggregate score" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KR" }, { "id": "KR-05", "layer": "KR", "plane": "control", "name": "Retrieval Permission Verification", "plain": "Every retrieval operation must verify that the requesting user or agent has authorization to access each candidate document or chunk before it is included in the retrieval context, enforcing the same access control rules that govern direct document access.", "threat": { "tags": [ "unauthorized-retrieval", "access-control-bypass", "permission-escalation", "cross-tenant-data-leakage" ], "desc": "RAG systems that embed access control enforcement in the ingestion layer but not the retrieval layer create a persistent bypass: a user without direct access to a document can obtain its contents via AI-generated responses that incorporate retrieved chunks. In multi-tenant deployments, insufficient retrieval authorization checks create cross-tenant data leakage where one tenant's knowledge base is surfaced to another. Permission escalation through retrieval is systematically harder to detect than direct access violations because the retrieved content appears embedded in a legitimate AI response." }, "standard": [ { "id": "iso_27002", "section": "\u00a75.15", "title": "Access control" }, { "id": "databricks_unity", "section": "Unity Catalog fine-grained access control", "title": "Row- and column-level authorization on knowledge assets" }, { "id": "eu_ai_act", "section": "Art. 15", "title": "Accuracy, robustness and cybersecurity" } ], "sources": [ { "id": "databricks_unity_catalog_2024", "title": "Databricks Unity Catalog (Knowledge Gov.)", "authority": "Databricks, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.databricks.com/en/data-governance/unity-catalog/index.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "databricks_unity_catalog_2024", "relationship": "informative_reference", "rationale": "Establishes Databricks Unity Catalog (Knowledge Gov.) requirements informing the apeiris://knowledge/controls/KR-05 Retrieval Permission Verification control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Integrate identity-aware retrieval that passes the requesting principal's access token or identity context to the vector store or search layer, where per-document authorization checks are enforced before results are returned. Never perform authorization checks only at ingestion time \u2014 enforce them per retrieval operation against the requesting principal's current permissions.", "steps": [ "Implement an identity-aware retrieval wrapper that receives the authenticated principal's identity context with every retrieval request.", "Configure the vector store or search index to support per-document or per-chunk access control metadata (ACL tags, security labels, tenant IDs).", "Enforce authorization checks as a retrieval-time filter that excludes unauthorized chunks before they are scored or ranked.", "Log each retrieval request with the requesting principal identity, the authorization check result, and any excluded chunk count (without content) to the audit trail." ], "knowledge_engineer": { "summary": "Design the retrieval authorization model so access control metadata is embedded at ingestion time and enforced at every retrieval operation.", "actions": [ "Define the access control metadata schema (ACL tags, classification labels, tenant IDs) and enforce its population during ingestion.", "Implement the retrieval-time authorization filter and integrate it with the enterprise identity provider.", "Test authorization enforcement by verifying that retrievals by principals without document access return empty or filtered result sets." ], "failure_signals": [ "Retrieval operation not receiving requesting principal's identity context.", "Authorization filter not applied before relevance scoring.", "Access control metadata absent from more than 1% of indexed chunks." ] }, "data_scientist": { "summary": "Permission-aware retrieval changes evaluation design: quality must be measured within each principal's authorized scope, and permission filters must not silently distort relevance metrics.", "actions": [ "Evaluate retrieval quality per permission scope rather than against the unfiltered corpus.", "Test that permission filtering happens before ranking metrics are computed, not after reporting.", "Verify embedding or index changes do not leak out-of-scope chunks into authorized result sets." ], "failure_signals": [ "Quality metrics are computed against content the requesting principals cannot actually retrieve.", "An index change causes out-of-scope documents to appear in scoped evaluation runs." ] }, "it_operations": { "summary": "Maintain the identity provider integration and monitor for authorization service availability so retrieval never fails open.", "actions": [ "Configure fail-closed behavior so retrieval returns an empty result set when the authorization service is unavailable, rather than returning all results.", "Monitor identity provider integration health and alert on latency spikes that could cause authorization timeouts.", "Conduct quarterly access control configuration reviews comparing indexed chunk ACLs to source document permissions." ], "failure_signals": [ "Retrieval configured to fail open when authorization service is unavailable.", "Identity provider integration not monitored for availability.", "ACL configuration review not completed within quarterly SLA." ] }, "grc_auditor": { "summary": "Retrieval permission verification is a prerequisite for any AI deployment where the knowledge base contains classified, confidential, or tenant-segregated content.", "actions": [ "Request retrieval authorization configuration documentation and verify fail-closed behavior is enabled.", "Sample 20 retrieval audit log entries and confirm each includes principal identity and authorization result.", "Review any authorization denial events from the prior quarter and confirm none represent unexpected access patterns." ], "metrics": [ "Percentage of retrieval operations with authorization enforcement active: target 100%.", "Unauthorized retrieval attempts blocked per month: tracked.", "ACL metadata coverage across indexed chunks: target >= 99%." ], "failure_signals": [ "Any retrieval operation without authorization enforcement in regulated deployment.", "ACL metadata coverage below 99% without accepted exception.", "Authorization denial events not reviewed in prior quarter." ] }, "legal_counsel": { "summary": "Retrieval permission violations may constitute unauthorized disclosure of confidential information regardless of whether the AI mediated the access.", "actions": [ "Confirm that retrieval authorization aligns with contractual data access obligations including NDA scope and data processing agreements.", "Review multi-tenant isolation architecture to confirm retrieval authorization prevents cross-tenant disclosure.", "Ensure unauthorized retrieval events are treated as potential data breach events under applicable regulations." ], "failure_signals": [ "Retrieval authorization not reviewed against data processing agreement scope.", "Multi-tenant isolation not verified via penetration test within 12 months.", "Unauthorized retrieval events not classified under breach notification policies." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most RAG deployments implement access control at the data ingestion layer but not as a per-retrieval authorization check, creating systematic bypass potential." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "IT Operations", "Knowledge Engineer", "Security Team" ], "frameworks": [ { "framework": "iso_27002", "requirement_id": "\u00a75.15", "fit": "direct", "rationale": "ISO/IEC 27002:2022 \u00a75.15 requires organizations to define and implement access control for information based on business and security requirements, ensuring that access rules are enforced for all access channels. Retrieval permission verification extends \u00a75.15 access control to the AI retrieval pathway, which is an information access channel equivalent to direct document access. The standard explicitly requires that access controls apply to all methods by which information can be accessed.", "normative_force": "voluntary-standard", "source_version": "2022", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "databricks_unity", "requirement_id": "Unity Catalog \u2014 fine-grained access control", "fit": "direct", "rationale": "Databricks Unity Catalog provides fine-grained access control on knowledge assets including vector store indices, enabling per-principal authorization checks at retrieval time. The Unity Catalog governance model is a direct implementation pattern for the identity-aware retrieval architecture this control requires.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 15", "fit": "partial", "rationale": "EU AI Act Article 15 requires high-risk AI systems to achieve appropriate cybersecurity and to be resilient against unauthorised attempts to alter their use or outputs. Retrieval permission verification limits the knowledge an AI system can incorporate to what the requesting principal is authorized to access, supporting this resilience requirement. The fit is partial because Article 15 addresses system-level cybersecurity broadly.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "A.6.2.6", "fit": "partial", "rationale": "ISO/IEC 42001:2023 Annex A control A.6.2.6 requires defined controls over AI system operation and monitoring. Retrieval permission verification is an operation-stage control ensuring the data feeding inference has been accessed through authorized channels. The fit is partial because A.6.2.6 addresses operation broadly rather than retrieval authorization specifically.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KR-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every retrieval operation must pass the authenticated requesting principal's identity context to the retrieval layer, which must enforce per-chunk access control checks before scoring or returning results, such that zero chunks accessible only to higher-privileged principals are returned to unprivileged requesters, and the system must fail closed returning an empty result set when the authorization service is unavailable.", "evidence_required": [ "retrieval_authorization_configuration_record confirming identity-aware retrieval is enabled, fail-closed behavior is active, and per-chunk ACL metadata is enforced as a pre-scoring filter at retrieval time", "retrieval_audit_log_sample showing requesting_principal_id, authorization_check_result, excluded_chunk_count, and timestamp for each retrieval operation across a representative week", "acl_metadata_coverage_report showing percentage of indexed chunks with access control metadata populated, targeting >= 99% coverage", "authorization_denial_event_log for the prior quarter listing blocked retrieval attempts with principal identity and denied resource identifier", "multi_tenant_isolation_penetration_test_report confirming zero cross-tenant chunk leakage (required for multi-tenant deployments)" ], "machine_tests": [ "Perform a retrieval query as a principal without access to a classified document \u2192 assert the result set contains zero chunks from that document and the exclusion is recorded in the retrieval audit log", "Simulate authorization service unavailability during a retrieval operation \u2192 assert the system returns an empty result set or structured error rather than returning unfiltered chunks", "In a multi-tenant configuration, perform a retrieval query using Tenant A credentials against Tenant B's knowledge base \u2192 assert zero Tenant B chunks are present in the result set", "Index a new chunk without access control metadata and perform a retrieval query \u2192 assert the chunk is excluded from all result sets pending ACL assignment and a warning is emitted to the audit log" ], "human_review": [ "Review the retrieval authorization configuration against the source document permission model to verify that ACL tags embedded at ingestion time accurately reflect current document-level access rights", "Assess the fail-closed implementation to confirm that authorization service timeouts and transient unavailability consistently result in blocked retrieval rather than unfiltered result pass-through", "Review authorization denial events from the prior quarter to identify unexpected access patterns that may indicate authorization misconfiguration or reconnaissance activity" ], "blocking_effect": "blocks-runtime-action", "normative_status": "certification-standard", "anti_patterns": [ "Enforcing access control only at ingestion time and trusting that only authorized content enters the knowledge base, which fails to prevent escalation when ACLs change after ingestion or when the same retrieval endpoint serves multiple principals with different access levels", "Passing the requesting principal's identity as a request header field without cryptographic verification, allowing the caller to claim a higher-privileged identity and retrieve restricted content", "Configuring the retrieval authorization filter as a post-ranking step rather than a pre-scoring exclusion, which exposes unauthorized chunk content to the ranking model even if the chunk is ultimately excluded from the result set", "Designing the authorization service as a non-critical dependency so the retrieval pipeline defaults to returning unfiltered results when the authorization service is degraded or unavailable" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KR" }, { "id": "KR-06", "layer": "KR", "plane": "control", "name": "Retrieval Performance Monitoring", "plain": "Retrieval-augmented AI systems must continuously monitor and report on retrieval quality metrics including relevance scores, retrieval latency, knowledge base coverage, and quality trends over time, with defined alert thresholds triggering remediation workflows when performance degrades.", "threat": { "tags": [ "quality-degradation", "retrieval-drift", "coverage-gap", "silent-performance-failure" ], "desc": "Retrieval quality degrades silently over time as knowledge bases grow stale, embedding models drift from the query distribution, or index fragmentation reduces precision. Without systematic monitoring, quality degradation accumulates across thousands of queries before becoming visible through user complaints or downstream error rates. Coverage gaps \u2014 knowledge base areas not adequately indexed for query types submitted by users \u2014 produce systematically poor responses that masquerade as valid outputs because the system appears to have returned retrieved content." }, "standard": [ { "id": "itil_4", "section": "\u00a75.2.7", "title": "Monitoring and event management practice" }, { "id": "iso_42001", "section": "\u00a79.1", "title": "Performance evaluation \u2014 AI system quality monitoring" }, { "id": "dama_dmbok", "section": "Ch. 13", "title": "Data quality measurement and monitoring" }, { "id": "microsoft_azure_ai", "section": "Azure AI Search monitoring", "title": "Search traffic analytics and metrics" } ], "sources": [ { "id": "google_vertex_ai_rag_2024", "title": "Google Vertex AI RAG & Grounding", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/vertex-ai/docs/generative-ai/grounding/overview", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_vertex_ai_rag_2024", "relationship": "informative_reference", "rationale": "Establishes Google Vertex AI RAG & Grounding requirements informing the apeiris://knowledge/controls/KR-06 Retrieval Performance Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_azure_ai_search_2024", "title": "Microsoft Azure AI Search & Grounding", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/azure/search/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_azure_ai_search_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Azure AI Search & Grounding requirements informing the apeiris://knowledge/controls/KR-06 Retrieval Performance Monitoring control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Instrument the retrieval pipeline with metric collectors capturing per-query relevance scores, latency percentiles, coverage rate, and chunk utilization rates. Feed metrics to a monitoring dashboard with defined alert thresholds and integrate with the enterprise observability stack. Run weekly synthetic evaluation queries to detect silent quality degradation independent of production traffic.", "steps": [ "Instrument the retrieval pipeline to emit per-query metrics: top-k scores, mean relevance score, retrieval latency (p50/p95/p99), and number of chunks returned at threshold.", "Define alert thresholds: mean relevance score drop of 10% sustained over 24 hours, p99 latency exceeding 2 seconds, coverage rate below 70% for query types in the synthetic evaluation set.", "Deploy a weekly synthetic evaluation suite of representative queries with labeled expected results to measure retrieval quality independent of production traffic.", "Produce a monthly retrieval quality trend report documenting mean relevance, coverage, and latency trends and presenting it to the knowledge governance review board." ], "knowledge_engineer": { "summary": "Own the synthetic evaluation suite and the knowledge base coverage analysis. Alert on coverage gaps before they affect production users.", "actions": [ "Build and maintain the synthetic evaluation query set with labeled expected results.", "Run weekly synthetic evaluations and compare results against baseline to detect drift.", "Conduct quarterly knowledge base coverage analysis identifying query types with below-threshold retrieval performance." ], "failure_signals": [ "Synthetic evaluation suite not run in more than 14 days.", "Coverage analysis not completed within quarterly SLA.", "Alert thresholds not defined or not connected to remediation workflows." ] }, "data_scientist": { "summary": "Analyze retrieval quality trends to distinguish noise from signal and identify root causes of systematic degradation.", "actions": [ "Analyze weekly synthetic evaluation results for statistical significance before triggering remediation workflows.", "Identify embedding model drift as a potential root cause when relevance scores degrade without knowledge base changes.", "Propose threshold updates when the query distribution shifts enough to invalidate baseline thresholds." ], "failure_signals": [ "Relevance score degradation not analyzed for root cause within 7 days of alert.", "Embedding drift not checked when sustained relevance degradation is detected.", "Threshold values not reviewed after significant query distribution shift." ] }, "it_operations": { "summary": "Operate the retrieval monitoring infrastructure and ensure metrics are reliably collected, stored, and accessible to the governance board.", "actions": [ "Deploy metric collection agents on the retrieval pipeline and integrate with the enterprise observability stack.", "Configure alert routing for threshold breaches to the knowledge engineering on-call team.", "Maintain 90-day metric retention for trend analysis and audit purposes." ], "failure_signals": [ "Metric collection gaps exceeding 1% of production queries.", "Alert routing not configured or not tested within 30 days.", "Metric retention below 90-day requirement." ] }, "grc_auditor": { "summary": "Retrieval performance monitoring data is evidence that the AI system's knowledge quality is actively governed and that degradation is detected and remediated.", "actions": [ "Request the most recent monthly retrieval quality trend report and review for sustained threshold breaches.", "Confirm that alert threshold definitions are documented and current.", "Verify that remediation actions were completed within SLA for any alerts triggered in the prior quarter." ], "metrics": [ "Mean retrieval relevance score: target within 10% of baseline.", "Retrieval p99 latency: target <= 2 seconds.", "Knowledge base coverage rate on synthetic evaluation set: target >= 85%.", "Alert-to-remediation SLA compliance: target >= 95%." ], "failure_signals": [ "Monthly trend report not produced for prior quarter.", "Alert-to-remediation SLA breached without documented exception.", "Synthetic evaluation suite not updated within 90 days of knowledge base major update." ] }, "legal_counsel": { "summary": "Retrieval performance monitoring produces the record showing the organization knew how well its knowledge system worked \u2014 silence in that record is itself a risk in post-incident scrutiny.", "actions": [ "Confirm monitoring covers the query categories with regulatory exposure, not just aggregate traffic.", "Set escalation duties for sustained quality degradation in regulated interaction paths.", "Retain monitoring reports long enough to answer regulator and litigation questions about past performance." ], "failure_signals": [ "A sustained quality degradation in a regulated category was visible in dashboards but never escalated.", "Monitoring data for the period of a disputed answer was not retained." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most RAG deployments lack structured retrieval quality monitoring; performance is assessed reactively through user feedback rather than proactive metric collection." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "federated-enterprise", "multi-tenant" ], "implementers": [ "IT Operations", "Data Scientist", "Platform Engineering" ], "frameworks": [ { "framework": "itil_4", "requirement_id": "\u00a75.2.7", "fit": "direct", "rationale": "The ITIL 4 monitoring and event management practice (5.2.7) requires systematic observation of services and components with defined metrics, thresholds and responses. Retrieval performance monitoring implements this practice for AI knowledge retrieval as a service, with defined SLIs (relevance score, latency, coverage) and alert thresholds.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "\u00a79.1", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a79.1 requires organizations to monitor, measure, analyze, and evaluate AI system performance against defined criteria at planned intervals. Retrieval performance monitoring directly implements the \u00a79.1 requirements with defined metrics (relevance, latency, coverage), measurement intervals (continuous, weekly synthetic, monthly reporting), and documented criteria for acceptable performance. The standard requires that performance monitoring results be retained and used as inputs to management review.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 13", "fit": "direct", "rationale": "DAMA DMBOK2 Chapter 13 defines data quality measurement practices including establishing data quality metrics, measurement methods, and reporting cycles. Retrieval quality is a data quality dimension applying to the knowledge base as a managed data asset, and monitoring retrieval performance implements the DMBOK2 quality measurement practices. The synthetic evaluation suite implements the DMBOK2 data quality assessment methodology applied to AI retrieval systems.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_azure_ai", "requirement_id": "Azure AI Search \u2014 monitoring and search traffic analytics", "fit": "direct", "rationale": "Microsoft Azure AI Search exposes monitoring metrics and search traffic analytics \u2014 query volumes, latency, and relevance instrumentation \u2014 that implement the monitoring infrastructure this control requires, and Azure Monitor provides the observability stack integration this control specifies. Microsoft's production guidance for Azure AI Search includes the evaluation and threshold-based alerting patterns this control standardizes.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_vertex_rag", "requirement_id": "Vertex AI RAG Engine \u2014 retrieval telemetry and evaluation", "fit": "partial", "rationale": "Google Vertex AI RAG Engine exposes retrieval telemetry including attribution scores, latency metrics, and chunk utilization that feed the monitoring dashboard this control requires, and Vertex AI monitoring integrates RAG metrics into broader AI system observability. Google's operational guidance recommends setting quality thresholds and monitoring them continuously for production RAG deployments.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KR-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Retrieval quality metrics including mean relevance score, p99 latency, and knowledge base coverage rate must be continuously collected per query, with alert thresholds defined and connected to remediation workflows, and a weekly synthetic evaluation suite executed to detect silent degradation independent of production traffic. The control passes when current metrics are within 10% of baseline and no unresolved threshold breaches older than 7 days exist.", "evidence_required": [ "retrieval_performance_dashboard showing per-query relevance scores, latency percentiles (p50/p95/p99), and coverage rate with timestamp and data source reference", "alert_threshold_configuration document specifying threshold values for mean relevance score, p99 latency, and coverage rate with last-reviewed date", "synthetic_evaluation_report from the prior 7 days showing query set, per-query relevance scores, and comparison against baseline with any degradation flags", "remediation_record for each threshold breach in the prior 90 days documenting root cause, remediation action, and resolution timestamp" ], "machine_tests": [ "Query retrieval pipeline with a labeled synthetic evaluation set of 50 representative queries \u2192 assert mean relevance score >= baseline minus 10%", "Submit a retrieval query with a known high-relevance document in the index \u2192 assert relevance score >= 0.7 is present in the returned metrics log entry", "Compare production retrieval request count against metric store entry count for a 1-hour window \u2192 assert metric collection coverage >= 99%", "Check alert_threshold_configuration last_reviewed date \u2192 assert reviewed within prior 90 days" ], "human_review": [ "Review the monthly retrieval quality trend report for sustained threshold breaches and assess whether remediation timelines met the defined SLA", "Evaluate the synthetic evaluation query set for representativeness against current production query distribution and request update if distribution has shifted significantly", "Assess whether defined alert thresholds remain appropriate given current knowledge base size, embedding model version, and production query volume" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Relying exclusively on user complaints or downstream error rates to detect retrieval quality degradation instead of proactive per-query metric collection", "Defining alert thresholds at system launch and never reviewing them as query distribution or knowledge base composition shifts over time", "Running synthetic evaluation queries against a separate test index rather than the production knowledge base, masking production-specific degradation", "Collecting per-query metrics but not aggregating them into trend reports, leaving the governance board without visibility into quality trajectories", "Setting alert thresholds so conservatively that they never fire, creating false confidence in retrieval quality while real degradation accumulates" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KR" }, { "id": "KR-07", "layer": "KR", "plane": "data", "name": "Retrieval Audit Trail", "plain": "Every retrieval operation must be logged with sufficient detail to reconstruct what was queried, which chunks were returned, what relevance scores they received, and what authorization checks were applied \u2014 creating an immutable audit trail that supports post-incident investigation, compliance reporting, and quality governance.", "threat": { "tags": [ "audit-gap", "retrieval-tampering", "non-repudiation-failure", "governance-blind-spot" ], "desc": "Without a complete retrieval audit trail, it is impossible to reconstruct what knowledge an AI system used when producing a specific output \u2014 eliminating the ability to investigate harmful responses, demonstrate compliance with access control requirements, or identify patterns of retrieval quality failure. Audit gaps also prevent non-repudiation of retrieval-based AI decisions in regulated contexts where the knowledge basis of an AI determination must be demonstrable. Tampering with or incomplete retention of retrieval logs creates permanent governance blind spots that cannot be retroactively closed." }, "standard": [ { "id": "w3c_prov", "section": "PROV-DM \u00a75.1.4", "title": "Usage \u2014 entities used by activities" }, { "id": "iso_27002", "section": "\u00a78.15", "title": "Logging" }, { "id": "dama_dmbok", "section": "Ch. 9", "title": "Document and Content Management \u2014 records management and audit trails" } ], "sources": [ { "id": "w3c_prov", "title": "W3C PROV Data Model", "authority": "World Wide Web Consortium", "source_type": "standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2013-04-30", "retrieved_on": "2026-07-02", "canonical_url": "https://www.w3.org/TR/prov-dm/", "license": "open-access", "status": "current", "flagship": false, "source_id": "w3c_prov", "relationship": "implementation_pattern", "rationale": "Establishes W3C PROV Data Model PROV-DM \u00a75.1.4 requirements informing the apeiris://knowledge/controls/KR-07 Retrieval Audit Trail control.", "reviewed_on": "2026-07-02" }, { "id": "iso_27002", "title": "ISO/IEC 27002:2022 \u2014 Information Security Controls", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "voluntary-standard", "version": "2022", "published_on": "2022-02-15", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/75652.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_27002", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 27002:2022 \u2014 Information Security Controls \u00a78.15 requirements informing the apeiris://knowledge/controls/KR-07 Retrieval Audit Trail control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 9 requirements informing the apeiris://knowledge/controls/KR-07 Retrieval Audit Trail control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 17 requirements informing the apeiris://knowledge/controls/KR-07 Retrieval Audit Trail control.", "reviewed_on": "2026-07-02" }, { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a79.1 requirements informing the apeiris://knowledge/controls/KR-07 Retrieval Audit Trail control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Implement append-only structured logging of every retrieval operation capturing: request ID, timestamp, requesting principal identity, query text or hash, retrieved chunk IDs with relevance scores, authorization check results, and any quality flags applied to the response. Retain logs for a minimum of 90 days in operational storage and 7 years in archival storage for regulated contexts.", "steps": [ "Define a structured retrieval log schema including all required fields: request_id, timestamp, principal_id, query_hash, retrieved_chunk_ids, relevance_scores, auth_check_result, excluded_chunks_count, grounding_coverage_score, hallucination_risk_score.", "Implement append-only log writes to an immutable log store (S3 with Object Lock, Azure Immutable Blob Storage, or equivalent) to prevent tampering.", "Configure log retention policies: 90-day operational retention for quality governance, 7-year archival retention for regulated contexts, with encrypted archival storage.", "Implement a log integrity verification mechanism (hash chain or Merkle tree) that enables verification that the audit trail has not been modified since initial write." ], "knowledge_engineer": { "summary": "Define the retrieval log schema and ensure all retrieval pipeline components emit conformant log events for every operation.", "actions": [ "Define and document the retrieval audit log schema version and required fields.", "Instrument all retrieval pipeline components (vector store query, reranker, authorization filter) to emit structured log events.", "Validate log completeness by running coverage checks verifying that 100% of production retrievals produce a corresponding log entry." ], "failure_signals": [ "Log schema not versioned or documented.", "Any retrieval pipeline component not emitting structured log events.", "Log completeness check showing coverage below 100%." ] }, "data_scientist": { "summary": "Retrieval audit trails are the raw material for quality analysis: per-query records of what was retrieved, scored, and used are what make relevance debugging and drift detection possible.", "actions": [ "Use the audit trail to reconstruct retrieval sets when investigating answer-quality regressions.", "Build drift analyses on trail data \u2014 score distributions, chunk usage, and coverage over time.", "Validate that the trail captures ranking scores and filter decisions, not just final chunk IDs." ], "failure_signals": [ "A quality regression cannot be diagnosed because trails omit ranking scores.", "Trail sampling was enabled to save storage, blinding drift analysis." ] }, "it_operations": { "summary": "Operate the immutable log infrastructure and enforce retention policies across operational and archival tiers.", "actions": [ "Deploy and maintain append-only immutable log storage with access controls preventing modification or deletion.", "Configure automated retention policy enforcement for 90-day operational and 7-year archival tiers.", "Run quarterly log integrity verification checks and report results to the governance board." ], "failure_signals": [ "Log storage not configured with immutability controls.", "Retention policy automation not verified in prior quarter.", "Log integrity verification not completed within quarterly SLA." ] }, "grc_auditor": { "summary": "The retrieval audit trail is the primary evidence source for demonstrating that AI retrieval operations were authorized, quality-controlled, and non-repudiable.", "actions": [ "Sample 30 retrieval audit log entries per audit cycle and verify all required fields are present and correctly populated.", "Confirm log immutability controls are active and integrity verification has been completed in the prior quarter.", "Verify log retention policy matches the regulatory requirement for the deployment context." ], "metrics": [ "Retrieval log completeness: target 100% of operations logged.", "Required field completeness per log entry: target >= 99%.", "Log integrity verification pass rate: target 100%.", "Retention policy compliance: 100% of entries within defined retention windows." ], "failure_signals": [ "Log completeness below 100% without accepted exception.", "Any required field absent from more than 1% of sampled entries.", "Integrity verification failure on any log segment.", "Log retention not meeting regulatory minimum." ] }, "legal_counsel": { "summary": "Retrieval audit trails are potential litigation evidence and must be retained and protected consistent with legal hold obligations and regulatory requirements.", "actions": [ "Define the applicable regulatory retention minimum for each deployment context and confirm log retention policy meets or exceeds it.", "Ensure legal hold procedures include retrieval audit logs when AI-generated content is subject to e-discovery.", "Confirm that query text retention versus hash-only is evaluated against privacy obligations including GDPR Article 30 records requirements." ], "failure_signals": [ "Log retention policy shorter than applicable regulatory minimum.", "Legal hold procedures not updated to include retrieval audit logs.", "Query text retained in logs for EU users without GDPR Article 30 evaluation." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Structured immutable retrieval audit logging is absent from most RAG deployments; operational logs typically capture only query text and response without chunk-level provenance." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "IT Operations", "GRC Team", "Knowledge Engineer" ], "frameworks": [ { "framework": "w3c_prov", "requirement_id": "PROV-DM \u00a75.1.4", "fit": "direct", "rationale": "W3C PROV-DM \u00a75.1.4 defines the Usage relation (used), capturing an activity's utilization of an entity. Modeling each AI response generation as a PROV Activity that used the retrieved chunk entities implements the chunk-level provenance this control requires; PROV-O serialization enables machine-readable retrieval audit trails that integrate with enterprise provenance systems.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_27002", "requirement_id": "\u00a78.15", "fit": "direct", "rationale": "ISO/IEC 27002:2022 \u00a78.15 requires organizations to implement audit logging for information system activities including access events and system administrator actions. Retrieval operations against knowledge bases are information access events subject to \u00a78.15 logging requirements. The standard's requirements for log integrity, retention, and protection against tampering directly map to the immutable log infrastructure this control specifies.", "normative_force": "voluntary-standard", "source_version": "2022", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 9", "fit": "direct", "rationale": "DAMA-DMBOK 2nd edition Chapter 9 (Document and Content Management) addresses records management for managed content, including retention of trustworthy records of how content is accessed and used. Retrieval audit trails apply this records discipline to knowledge assets by recording the path from knowledge base content through retrieval to AI response generation; the immutable log requirement aligns with DMBOK records-integrity principles.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 17", "fit": "direct", "rationale": "EU AI Act Article 17 requires high-risk AI system providers to establish record-keeping systems that enable competent authorities to assess compliance. Retrieval audit trails are the primary record-keeping mechanism for demonstrating that AI systems used compliant data sources and applied appropriate access controls during retrieval operations. The immutable retention requirement satisfies the Article 17 obligation to preserve records for the defined post-deployment oversight period.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "\u00a79.1", "fit": "partial", "rationale": "ISO/IEC 42001:2023 \u00a79.1 requires retention of documented information as evidence of AI system performance monitoring. Retrieval audit logs provide the operational evidence base required by \u00a79.1 performance evaluation, capturing the per-query data needed to compute aggregated quality metrics. The standard requires that monitoring evidence be retained in a form that supports management review and external audit, which the immutable log infrastructure delivers.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KR-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every retrieval operation must produce an append-only structured log entry capturing request_id, timestamp, principal_id, query_hash, retrieved_chunk_ids with relevance scores, and authorization check results, stored in immutable storage with verified log integrity. The control passes when 100% of production retrievals are logged with all required fields, no required fields are absent from more than 1% of sampled entries, and log integrity verification has been completed in the prior quarter with no failures.", "evidence_required": [ "retrieval_audit_log sample of 30 entries from the prior audit period each containing request_id, timestamp, principal_id, query_hash, retrieved_chunk_ids, relevance_scores, and auth_check_result fields", "immutable_storage_configuration_record showing Object Lock or equivalent immutability control on the log store with access control list preventing modification", "log_integrity_verification_report from the prior quarter confirming hash chain or Merkle tree verification passed for all log segments", "retention_policy_document specifying 90-day operational and minimum 7-year archival retention windows with evidence of automated enforcement", "log_completeness_check_report comparing production retrieval request count against log entry count for the prior 30-day period" ], "machine_tests": [ "Issue 10 retrieval queries via the standard API \u2192 assert each produces a corresponding audit log entry within 5 seconds with all required fields (request_id, timestamp, principal_id, query_hash, retrieved_chunk_ids, relevance_scores, auth_check_result) populated", "Attempt to delete or modify an existing audit log entry in the immutable store \u2192 assert the operation is rejected with permission_denied or immutability_violation", "Query log completeness check for the prior 24 hours \u2192 assert log entry count >= 99% of production retrieval request count", "Verify log schema version on 10 sampled entries \u2192 assert all entries conform to the current structured log schema with no missing or extra required fields" ], "human_review": [ "Review a sample of 30 audit log entries and verify all required fields are correctly populated and reflect actual retrieval operations rather than synthetic test entries", "Confirm that the log retention policy meets the applicable regulatory minimum for the deployment context and that legal hold procedures have been updated to include retrieval audit logs", "Assess query text retention decisions against applicable privacy obligations including GDPR Article 30 records requirements and confirm hash-only retention is used where full query text poses privacy risk" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Logging only query text and response text without chunk-level provenance, making it impossible to reconstruct exactly which knowledge the AI system retrieved for a given output", "Storing retrieval logs in mutable storage where entries can be modified or deleted after the fact, eliminating non-repudiation for compliance and litigation contexts", "Retaining operational logs for 30 days without an archival tier, creating compliance gaps for regulated deployment contexts with multi-year retention requirements", "Omitting authorization check results from log entries, preventing post-incident verification that access controls were correctly applied at query time", "Logging principal_id as a display name or email address rather than a stable resolvable identity reference, breaking attribution chains across identity system changes" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KR" }, { "id": "KR-08", "layer": "KR", "plane": "both", "name": "Knowledge Retrieval Evidence Package", "plain": "The Knowledge Retrieval Evidence Package compiles attestation-ready evidence from all KR-layer controls into a structured, time-bounded package demonstrating that retrieval quality meets defined standards \u2014 covering relevance thresholds (KR-01), grounding completeness (KR-02), citation fidelity (KR-03), hallucination detection (KR-04), permission verification (KR-05), performance monitoring (KR-06), and audit trail integrity (KR-07).", "threat": { "tags": [ "evidence-gap", "compliance-fragmentation", "audit-unpreparedness", "attestation-failure" ], "desc": "Without a structured evidence package, retrieval quality compliance exists only as dispersed operational data spread across multiple systems. Evidence gaps emerge when individual KR controls are implemented but their outputs are never compiled into a coherent attestation artifact, making compliance impossible to demonstrate to auditors, regulators, or downstream consumers. Fragmented evidence creates audit unpreparedness where the organization cannot rapidly produce a defensible record of retrieval quality governance for a specific time period or deployment context." }, "standard": [ { "id": "iso_42001", "section": "\u00a79.1", "title": "Performance evaluation \u2014 documented evidence of AI quality controls" }, { "id": "eu_ai_act", "section": "Art. 17", "title": "Quality management \u2014 record-keeping and evidence requirements" }, { "id": "iso_30401", "section": "\u00a79.1", "title": "Performance evaluation \u2014 knowledge management system effectiveness" }, { "id": "w3c_prov", "section": "PROV-DM \u00a75.4", "title": "Bundles \u2014 named sets of provenance descriptions" } ], "sources": [ { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a79.1 requirements informing the apeiris://knowledge/controls/KR-08 Knowledge Retrieval Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 17 requirements informing the apeiris://knowledge/controls/KR-08 Knowledge Retrieval Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "w3c_prov", "title": "W3C PROV Data Model", "authority": "World Wide Web Consortium", "source_type": "standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2013-04-30", "retrieved_on": "2026-07-02", "canonical_url": "https://www.w3.org/TR/prov-dm/", "license": "open-access", "status": "current", "flagship": false, "source_id": "w3c_prov", "relationship": "implementation_pattern", "rationale": "Establishes W3C PROV Data Model PROV-DM \u00a75.4 requirements informing the apeiris://knowledge/controls/KR-08 Knowledge Retrieval Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements \u00a79.1 requirements informing the apeiris://knowledge/controls/KR-08 Knowledge Retrieval Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 13 requirements informing the apeiris://knowledge/controls/KR-08 Knowledge Retrieval Evidence Package control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "On a defined cadence (monthly for operational governance, per-deployment for certification), automatically compile a structured evidence package from KR-01 through KR-07 outputs. The package includes current threshold configurations, evaluation dataset freshness dates, relevance and grounding coverage metrics, citation verification rates, hallucination detection rates, permission enforcement coverage, performance trend reports, and audit trail integrity verification results. The package is signed, timestamped, and stored in the evidence repository.", "steps": [ "Define the KnowledgeRetrievalAttestation (KR-08) evidence package schema specifying required fields from each contributing KR control.", "Implement an evidence compilation workflow that queries each KR control's data sources and assembles the package on the defined cadence.", "Apply an Ed25519 signature and SHA-256 integrity hash to each compiled evidence package before storing it in the evidence repository.", "Define acceptance criteria for a complete KR-08 package: all 7 control evidence sections present, all required metrics populated, no outstanding unresolved threshold breaches older than 30 days.", "Publish the KR-08 evidence package to the Apeiris evidence graph as a KnowledgeRetrievalAttestation artifact with blocking_effect set to blocks-deployment for new deployments in high-risk contexts without a valid current package." ], "knowledge_engineer": { "summary": "Own the evidence compilation workflow and ensure all KR control data sources are accessible and correctly queried for each package compilation.", "actions": [ "Build and maintain the KR-08 evidence compilation workflow with connections to all KR-01 through KR-07 data sources.", "Define the KnowledgeRetrievalAttestation schema and validate package completeness before signing.", "Coordinate with data scientists and IT operations to resolve any evidence gaps before package finalization." ], "failure_signals": [ "Evidence compilation workflow fails to collect from any KR control data source.", "Package produced with missing required sections.", "Evidence package not produced within defined cadence." ] }, "data_scientist": { "summary": "The retrieval evidence package quantifies retrieval quality for auditors; its metrics must be reproducible from the retrieval audit trail and stable in definition across periods.", "actions": [ "Version-control the analyses that turn retrieval telemetry into evidence package metrics.", "Reconcile packaged quality figures against the retrieval audit trail before each sign-off.", "Document metric definitions in the package so external reviewers can re-derive them." ], "failure_signals": [ "Packaged retrieval quality figures cannot be re-derived from the audit trail.", "Metric definitions drift between packages, breaking trend comparability." ] }, "it_operations": { "summary": "Maintain the evidence repository infrastructure and ensure evidence packages are stored with integrity controls and correct access permissions.", "actions": [ "Provision immutable storage for KR-08 evidence packages with access controls limiting modification to the evidence compilation workflow.", "Monitor evidence package compilation workflow execution and alert on failures within 1 hour.", "Ensure evidence repository capacity planning accounts for package retention requirements." ], "failure_signals": [ "Evidence package stored in mutable storage without access controls.", "Package compilation workflow failures not alerted within 1 hour.", "Evidence repository approaching capacity without remediation plan." ] }, "grc_auditor": { "summary": "The KR-08 evidence package is the primary artifact for retrieval quality compliance attestation. Review it quarterly and before any high-risk deployment authorization.", "actions": [ "Review the most recent KR-08 evidence package and verify all 7 control evidence sections are present and complete.", "Confirm that all metrics in the package meet or exceed defined thresholds, and that any exceptions are documented with accepted risk decisions.", "Verify that the package integrity signature is valid and that the package was produced within the defined cadence.", "Include the KR-08 package reference in any AI system compliance audit reports." ], "metrics": [ "KR-08 package completeness rate: target 100% of required sections populated.", "KR-08 package production cadence compliance: 100% produced on schedule.", "Metrics-within-threshold rate across all KR controls: target >= 90%.", "Mean time to produce KR-08 package: target <= 4 hours for automated compilation." ], "failure_signals": [ "Any required section missing from the KR-08 package.", "Package integrity signature validation failure.", "More than 10% of KR control metrics outside threshold without accepted exceptions.", "Package not produced within defined cadence for more than one consecutive period." ] }, "legal_counsel": { "summary": "The KR-08 evidence package is the legal defensibility record for AI retrieval quality. Ensure it covers the scope required by applicable regulations and contractual obligations.", "actions": [ "Review the KR-08 package schema to confirm it captures the evidence required by applicable sector regulations for AI knowledge governance.", "Confirm the package retention policy meets regulatory minimum retention requirements for AI system records.", "Ensure the KR-08 package is included in the AI system's technical documentation under EU AI Act Article 11 or equivalent requirements." ], "failure_signals": [ "KR-08 package scope does not cover applicable regulatory evidence requirements.", "Package retention period shorter than applicable regulatory minimum.", "KR-08 not included in Article 11 technical documentation for EU high-risk AI deployments." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Structured retrieval evidence packages are not a standard practice; most organizations lack the compilation infrastructure to produce on-demand attestation of retrieval quality governance." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "GRC Team", "Knowledge Engineer", "Legal Counsel" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a79.1", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a79.1 requires organizations to retain documented information as evidence of AI system performance evaluation results and to make this evidence available to management review and external audit. The KR-08 evidence package directly implements the \u00a79.1 documented evidence requirement for the retrieval quality domain, compiling all retrieval performance measurements into a structured, auditable artifact. The signed package with integrity hash satisfies the standard's requirements for evidence authenticity and tamper-evidence.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 17", "fit": "direct", "rationale": "EU AI Act Article 17 requires providers of high-risk AI systems to establish a quality management system that includes procedures for record-keeping and the ability to demonstrate compliance to competent authorities. The KR-08 evidence package is a structured record-keeping artifact that directly satisfies the Article 17 obligation to maintain compliance records. The package's blocking effect on new high-risk deployments without a valid current package operationalizes the Article 17 quality management gate.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "satisfies" }, { "framework": "w3c_prov", "requirement_id": "PROV-DM \u00a75.4", "fit": "direct", "rationale": "W3C PROV-DM \u00a75.4 defines bundles \u2014 named sets of provenance descriptions that can themselves have provenance. The KR-08 evidence package is such a bundle over the KR-layer provenance records, enabling a machine-readable, standards-aligned evidence format; signing the bundle aligns with the Ed25519 attestation requirement.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_30401", "requirement_id": "\u00a79.1", "fit": "direct", "rationale": "ISO 30401:2018 \u00a79.1 requires organizations to monitor, measure, analyze, and evaluate the performance of their knowledge management system and retain documented evidence of these results. The KR-08 evidence package is the structured performance evaluation record required by \u00a79.1 for the knowledge retrieval subsystem, compiled at defined intervals and retained per policy. The standard requires that these records be available for management review and external assessment, which the evidence package's structured storage enables.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 13", "fit": "partial", "rationale": "DAMA DMBOK2 Chapter 13 defines data quality reporting practices including the production of quality scorecards and compliance reports that aggregate quality measurements across multiple dimensions. The KR-08 evidence package is a knowledge retrieval quality scorecard implementing the DMBOK2 reporting practice, aggregating metrics from all seven KR quality controls into a single compliance artifact. The DMBOK2 emphasis on structured, time-bounded quality records aligns with the KR-08 package cadence and retention requirements.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-28", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KR-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A complete KnowledgeRetrievalAttestation evidence package must be compiled on the defined cadence covering all seven KR-layer controls, signed with Ed25519 and hashed with SHA-256, with all required metric sections populated and no outstanding unresolved threshold breaches older than 30 days. The control passes when the most recent package was produced within the defined cadence, passes signature verification, and has no missing required sections from KR-01 through KR-07.", "evidence_required": [ "knowledge_retrieval_attestation_package containing all seven KR control evidence sections, compilation timestamp, schema version, and Ed25519 signature with verification key reference", "package_integrity_verification_record showing SHA-256 hash of the evidence package matching the hash embedded in the package metadata", "evidence_compilation_workflow_execution_log showing automated compilation run with data source connection results and any exceptions for the most recent package", "kr_control_metrics_summary showing all KR-01 through KR-07 metrics in the package meet defined thresholds or have accepted exception records with approval metadata" ], "machine_tests": [ "Retrieve the most recent KnowledgeRetrievalAttestation package and verify Ed25519 signature against the published verification key \u2192 assert signature_valid=true", "Parse the evidence package schema and assert all 7 required control evidence sections (KR-01 through KR-07) are present with non-null content", "Check the package compilation timestamp against the defined cadence \u2192 assert the package is not older than the maximum cadence interval (monthly for operational, per-deployment for certification contexts)", "Query for unresolved threshold breaches in the KR control metric store older than 30 days \u2192 assert count=0 or assert each breach has a corresponding accepted_exception_record" ], "human_review": [ "Review the evidence package completeness: verify all 7 KR control sections contain substantive evidence rather than empty or placeholder entries", "Confirm that the package scope and retention policy cover the evidence requirements of applicable sector regulations and that the package is included in Article 11 technical documentation for EU high-risk AI deployments", "Assess whether evidence compilation workflow failure alerting is adequate and that any package compilation failures were investigated and resolved within the defined SLA" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Producing KR-08 evidence packages manually by copying metrics from dashboards into a document, creating untraceable provenance and introducing transcription errors that undermine the attestation integrity", "Omitting any of the 7 KR control sections because the control is not yet implemented, producing incomplete packages that misrepresent the organization's compliance state", "Storing evidence packages in mutable storage where contents can be modified after signing, undermining the integrity of the attestation as a non-repudiable artifact", "Treating the KR-08 package as an internal operational document rather than a litigation-defensible compliance artifact, resulting in insufficient retention and missing legal hold integration", "Compiling KR-08 packages on an annual basis rather than monthly for operational governance, leaving extended audit periods with no evidence coverage" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KR" }, { "id": "KC-01", "layer": "KC", "plane": "control", "name": "Knowledge Staleness Classification Policy", "plain": "Every knowledge asset must be assigned a staleness class that defines its maximum permissible age, review cadence, and action upon expiry, calibrated to content type, regulatory sensitivity, and operational domain.", "threat": { "tags": [ "stale-knowledge-propagation", "regulatory-non-compliance", "outdated-guidance-reliance", "unclassified-content-drift" ], "desc": "Without a formal staleness classification policy, AI systems operate on knowledge assets of indeterminate age. Regulatory guidance, product specifications, and legal interpretations change materially over months; unclassified content silently drifts past validity thresholds. Systems that cannot distinguish highly perishable content from archivally stable content apply uniform \u2014 and therefore incorrect \u2014 refresh cadences, exposing the enterprise to liability and users to materially wrong outputs." }, "standard": [ { "id": "iso_30401", "section": "\u00a74.4.2", "title": "Knowledge development \u2014 retaining current and handling outdated knowledge" }, { "id": "dama_dmbok", "section": "Ch. 13", "title": "Data Quality \u2014 timeliness dimension" }, { "id": "eu_ai_act", "section": "Art. 10(3)", "title": "Training, validation, and testing data \u2014 relevance and representativeness" }, { "id": "iso_42001", "section": "\u00a76.1.2", "title": "AI risk assessment \u2014 knowledge data relevance" } ], "sources": [ { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements \u00a74.4.2 requirements informing the apeiris://knowledge/controls/KC-01 Knowledge Staleness Classification Policy control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 13 requirements informing the apeiris://knowledge/controls/KC-01 Knowledge Staleness Classification Policy control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 10(3) requirements informing the apeiris://knowledge/controls/KC-01 Knowledge Staleness Classification Policy control.", "reviewed_on": "2026-07-02" }, { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a76.1.2 requirements informing the apeiris://knowledge/controls/KC-01 Knowledge Staleness Classification Policy control.", "reviewed_on": "2026-07-02" }, { "id": "itil_4", "title": "ITIL 4", "authority": "PeopleCert / Axelos", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "4", "published_on": "2019-02-28", "retrieved_on": "2026-07-02", "canonical_url": "https://www.axelos.com/certifications/itil-service-management/itil-4-foundation", "license": "proprietary", "status": "current", "flagship": false, "source_id": "itil_4", "relationship": "informative_reference", "rationale": "Establishes ITIL 4 \u00a75.1.4 \u2014 Knowledge management requirements informing the apeiris://knowledge/controls/KC-01 Knowledge Staleness Classification Policy control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "A policy document assigns every knowledge asset class a staleness tier (T1 critical \u226430 days, T2 operational \u226490 days, T3 reference \u2264365 days, T4 archival >365 days with review flag). Classification is encoded in asset metadata at ingest time and re-evaluated at each versioning event.", "steps": [ "Define staleness tiers with maximum age thresholds, review triggers, and expiry actions (flag, quarantine, or retire) for each content class.", "Enumerate at least five content classes: regulatory guidance, product documentation, internal policy, historical records, and training corpora, assigning each a default tier.", "Encode tier classification as a mandatory metadata field in the knowledge asset schema and enforce at ingest via pipeline validation.", "Establish a governance board responsible for annual review of tier assignments and exception approval for assets requiring non-standard retention.", "Publish the classification policy in the knowledge governance registry so downstream consumers can query an asset's staleness tier programmatically." ], "knowledge_engineer": { "summary": "The staleness policy is the foundational contract that governs every refresh and retirement decision in the knowledge pipeline. Encode it at ingest, not retrospectively.", "actions": [ "Add a required `staleness_tier` field to the knowledge asset metadata schema.", "Build ingest-time validation that rejects assets lacking a staleness_tier assignment.", "Maintain a lookup table mapping content_class to default staleness_tier for auto-assignment on bulk loads." ], "failure_signals": [ "More than 5% of knowledge assets lack a staleness_tier field.", "Classification policy document has not been reviewed in over 12 months.", "New content classes added without corresponding tier assignment in the lookup table." ] }, "data_scientist": { "summary": "Staleness classes are model inputs for quality work: freshness-sensitive evaluation, decay analysis, and refresh prioritization all key off the per-class thresholds this policy defines.", "actions": [ "Incorporate staleness class labels into retrieval evaluation so freshness failures are measurable per class.", "Analyze answer-quality decay against content age to validate or challenge the class thresholds.", "Flag corpora whose class assignments look wrong based on observed update frequency." ], "failure_signals": [ "Evaluation treats all content as equally fresh despite defined staleness classes.", "Observed decay contradicts a class threshold and nobody feeds that back into the policy." ] }, "it_operations": { "summary": "Staleness classes drive scheduler behavior: every asset must carry a class label, and the scanning and refresh machinery must read it \u2014 an unclassified asset is an unmanaged one.", "actions": [ "Enforce class labeling at ingestion so no asset enters the index unclassified.", "Wire scan and refresh schedules to class thresholds rather than a single global cadence.", "Report class coverage (share of assets with labels) and alert when it drops." ], "failure_signals": [ "A meaningful share of index assets carry no staleness class label.", "Refresh jobs ignore class thresholds and run on a flat schedule." ] }, "grc_auditor": { "summary": "The policy document and its asset-level enforcement are the primary artifacts demonstrating that knowledge currency is governed intentionally rather than by default.", "actions": [ "Request the current policy document and verify it has a dated approval signature and a defined review cadence.", "Sample 20 knowledge assets across at least three content classes and verify their staleness_tier metadata matches the policy lookup table.", "Confirm exception records exist for any assets whose assigned tier deviates from the default." ], "metrics": [ "Policy coverage rate: proportion of assets with staleness_tier metadata \u2014 target 100%.", "Policy review currency: policy document reviewed within the last 12 months \u2014 target 100%.", "Exception documentation rate: approved exception record present for all non-default tier assignments \u2014 target 100%." ], "failure_signals": [ "Assets with no staleness_tier assigned exceed 5% of total inventory.", "Policy document is older than 12 months without renewal.", "No governance board meeting minutes reference tier assignment reviews." ] }, "legal_counsel": { "summary": "The staleness policy creates a defensible record that the organization proactively calibrates knowledge age to regulatory and liability risk, a key element in AI governance due-diligence defenses.", "actions": [ "Review tier assignments for content classes covering regulated domains (financial advice, medical information, legal guidance) and confirm maximum age thresholds align with applicable regulatory update cycles.", "Verify that the policy includes a triggered re-classification pathway activated when a governing regulation is materially amended." ], "failure_signals": [ "Regulatory-class content assigned a tier with a maximum age exceeding the governing regulation's update cycle.", "No legal review sign-off on tier assignments for high-sensitivity content classes." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises have implicit staleness assumptions embedded in ad-hoc refresh scripts rather than a formal classification policy. Formalizing tiers is the necessary first step before automated detection can operate correctly." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Knowledge Management Office", "GRC Team", "Legal Counsel" ], "frameworks": [ { "framework": "iso_30401", "requirement_id": "\u00a74.4.2", "fit": "direct", "rationale": "ISO 30401:2018 \u00a74.4.2 requires the knowledge management system to address retaining current knowledge and handling outdated or invalid knowledge. A staleness classification policy encodes age thresholds per asset class, giving those lifecycle activities a measurable standard.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 13", "fit": "direct", "rationale": "DAMA-DMBOK 2nd edition Chapter 13 (Data Quality) defines timeliness as a core data quality dimension: data must be current enough for its intended use. The staleness classification policy is the governance instrument through which timeliness standards are set and enforced at the asset-class level. Absent this policy, timeliness cannot be measured or assured systematically.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10(3)", "fit": "direct", "rationale": "EU AI Act Article 10(3) requires that training and knowledge data used by high-risk AI systems be relevant, representative, and sufficiently error-free \u2014 properties that degrade as data ages. A staleness classification policy creates the documented governance mechanism for ensuring knowledge relevance, directly satisfying the regulatory requirement for data management practices in high-risk AI.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "\u00a76.1.2", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a76.1.2 requires AI management systems to assess risks arising from AI data, including data that may no longer reflect current conditions. Staleness classification is the risk-calibration mechanism that assigns and documents the temporal validity of each knowledge asset class in a form auditors can verify.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "itil_4", "requirement_id": "\u00a75.1.4 \u2014 Knowledge management", "fit": "partial", "rationale": "The ITIL 4 knowledge management practice (5.1.4) calls for maintaining knowledge that is accurate and up to date. The staleness classification policy is the formal mechanism that defines what 'up to date' means for each knowledge class, bridging ITIL's principle to a measurable standard. The fit is partial because ITIL addresses operational IT knowledge rather than AI knowledge bases specifically.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KC-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every knowledge asset within the AI retrieval corpus must have an assigned staleness class with a documented maximum permissible age, review cadence, and defined expiry action (quarantine, flag, or replace) calibrated to content type and regulatory sensitivity, with the staleness classification taxonomy reviewed within the prior 12 months. The control passes when 100% of registered knowledge assets have a staleness_class assignment traceable to the current taxonomy and no content types ingested into the corpus lack a classification mapping.", "evidence_required": [ "knowledge_staleness_classification_policy document defining the staleness tier taxonomy with tier names, maximum permissible age, review cadence, and expiry action for each tier", "knowledge_asset_register excerpt showing staleness_class field populated for all registered assets with class assignments traceable to the tier taxonomy", "staleness_policy_review_record showing the last annual review of tier definitions with any adjustments and approval signatures", "content_type_to_tier_mapping document specifying which staleness class applies to each recognized content type including regulatory guidance, product specifications, legal interpretations, and reference standards" ], "machine_tests": [ "Query the knowledge asset register for all assets with null or missing staleness_class field \u2192 assert count=0", "For each staleness class defined in the taxonomy, query the asset register for assets assigned that class \u2192 assert at least one asset is assigned to each defined class confirming the taxonomy is operationalized", "Retrieve the staleness_policy_review_record and check the review_date field \u2192 assert the review was completed within the prior 12 months", "Select 10 random knowledge assets and retrieve their staleness_class assignment \u2192 assert each class value matches a valid entry in the current staleness classification taxonomy" ], "human_review": [ "Review the staleness tier taxonomy and assess whether maximum permissible age definitions remain appropriate for each content type given current regulatory change velocity and operational domain risk profile", "Verify that the content-type-to-tier mapping covers all content types currently ingested into the knowledge base with no content types left unclassified", "Confirm that the expiry action for each tier (quarantine vs. flag vs. replace) aligns with the organization's risk tolerance and operational capacity to remediate stale content on the defined cadence" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Assigning all knowledge assets to a single staleness tier regardless of content type or regulatory sensitivity, eliminating the risk calibration the classification taxonomy is designed to provide", "Defining staleness classes without specifying the expiry action, resulting in expired assets remaining in the retrieval corpus with no governance consequence after threshold breach", "Setting maximum permissible age for rapidly-changing regulatory content at values appropriate for stable foundational reference content, allowing outdated regulatory interpretations to persist in the corpus", "Creating the staleness classification policy as a one-time exercise without an annual review cadence, allowing tier definitions to drift out of alignment with regulatory change velocity", "Storing staleness class assignments in a separate system from the knowledge asset register, making it impossible to enforce staleness policy at query time without cross-system joins" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KC" }, { "id": "KC-02", "layer": "KC", "plane": "control", "name": "Automated Staleness Detection", "plain": "The knowledge pipeline must continuously monitor all knowledge assets against their assigned staleness-tier thresholds and automatically flag, quarantine, or alert when content exceeds its maximum permissible age.", "threat": { "tags": [ "silent-knowledge-decay", "undetected-expiry", "stale-retrieval-in-rag", "governance-gap" ], "desc": "Knowledge bases grow to scales that make manual staleness review impractical. Without automated detection, assets silently breach their maximum-age thresholds and continue to be retrieved and surfaced to users or downstream agents. In RAG architectures, stale chunks are retrieved with high cosine similarity to current queries, providing no warning signal at inference time. Regulatory deadlines, product recalls, and policy reversals embedded in stale content are served as authoritative \u2014 creating liability at scale." }, "standard": [ { "id": "iso_42001", "section": "\u00a79.1", "title": "Monitoring, measurement, analysis, and evaluation" }, { "id": "dama_dmbok", "section": "Ch. 13", "title": "Data Quality monitoring and reporting" }, { "id": "aws_bedrock_kb", "section": "Knowledge Bases data source sync", "title": "Ingestion job status and sync timestamps" }, { "id": "iso_30401", "section": "\u00a79.1", "title": "Performance evaluation \u2014 knowledge effectiveness monitoring" } ], "sources": [ { "id": "google_vertex_ai_rag_2024", "title": "Google Vertex AI RAG & Grounding", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/vertex-ai/docs/generative-ai/grounding/overview", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_vertex_ai_rag_2024", "relationship": "informative_reference", "rationale": "Establishes Google Vertex AI RAG & Grounding requirements informing the apeiris://knowledge/controls/KC-02 Automated Staleness Detection control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_knowledge_bases_2024", "title": "Amazon Bedrock Knowledge Bases", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_knowledge_bases_2024", "relationship": "informative_reference", "rationale": "Establishes Amazon Bedrock Knowledge Bases requirements informing the apeiris://knowledge/controls/KC-02 Automated Staleness Detection control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "A scheduled staleness scanner reads asset metadata, computes age against staleness_tier thresholds, and writes detection events to a governance event stream. Assets that breach warning thresholds generate advisory alerts; assets that breach hard thresholds are automatically quarantined from retrieval until reviewed or refreshed.", "steps": [ "Deploy a staleness scanner that runs on a configurable schedule (minimum daily for T1 critical assets) and computes `asset_age = now() - last_verified_on` for every asset in the knowledge store.", "Define two threshold levels per tier: a warning threshold at 80% of the maximum age that generates advisory alerts, and a hard threshold at 100% that triggers automatic quarantine.", "Publish staleness detection events to a governance event stream (e.g., Kafka topic or cloud audit log) with fields: asset_id, staleness_tier, asset_age_days, threshold_type, triggered_action, detected_at.", "Integrate quarantine status with the retrieval layer so quarantined assets are excluded from vector search and API responses until their status is resolved.", "Generate a daily staleness dashboard showing total assets by tier, assets in warning state, assets in quarantine, and mean time to refresh by tier." ], "knowledge_engineer": { "summary": "Automated detection transforms staleness from a periodic manual audit into a continuous operational signal. The scanner must be tightly coupled to the retrieval layer so quarantine is enforced \u2014 detection without enforcement has no operational value.", "actions": [ "Implement the staleness scanner as a scheduled job that reads asset metadata from the knowledge catalog and writes detection events.", "Wire quarantine status to the retrieval API so quarantined assets are filtered before ranking.", "Add a staleness_status field (current, warning, quarantined) to asset metadata, updated by the scanner on each run." ], "failure_signals": [ "Scanner has not run in over 24 hours for T1 assets.", "Quarantined assets are still appearing in retrieval results.", "Detection event stream has gaps exceeding the scheduled interval." ] }, "data_scientist": { "summary": "Staleness detection must account for semantic staleness \u2014 content that is technically within its age threshold but references superseded facts. Complement rule-based age detection with embedding-drift signals where feasible.", "actions": [ "Instrument the retrieval pipeline to log retrieval frequency by asset; use retrieval decay as a secondary staleness signal (assets no longer matching queries may be semantically stale even within their age threshold).", "Periodically re-embed a sample of aging assets against the current embedding model and flag those with high cosine distance from recent canonical sources as staleness candidates." ], "failure_signals": [ "No semantic staleness signal beyond pure age thresholds deployed for T1 or T2 assets.", "Embedding model version used for staleness comparison differs from production retrieval model without documented justification." ] }, "it_operations": { "summary": "The staleness scanner is a critical pipeline component whose availability must be monitored with the same rigor as the retrieval service itself. Scanner downtime is a silent governance failure.", "actions": [ "Add the staleness scanner job to the production monitoring dashboard with alerting on missed runs.", "Configure the governance event stream with at-least-once delivery guarantees and a retention policy of at least 90 days.", "Implement a dead-letter queue for assets that fail staleness computation due to missing metadata fields." ], "failure_signals": [ "Scanner job failure rate exceeds 1% over a 7-day rolling window.", "Event stream consumer lag exceeds defined SLA.", "Dead-letter queue accumulates assets without investigation within 48 hours." ] }, "grc_auditor": { "summary": "Automated detection evidence demonstrates that staleness is monitored continuously, not only during periodic audits. The scanner run log and quarantine metrics are primary compliance artifacts.", "actions": [ "Review scanner run logs for the past 90 days and verify no missed scheduled runs exceed one cycle for any tier.", "Sample 10 assets in quarantined state and confirm they are excluded from active retrieval.", "Verify that the daily staleness dashboard is reviewed by a named knowledge governance owner and that review is documented." ], "metrics": [ "Scanner availability: scheduled runs completed as expected \u2014 target 99.5%.", "Quarantine enforcement rate: quarantined assets absent from retrieval results \u2014 target 100%.", "Warning-to-action rate: proportion of warning-state assets actioned within tier SLA \u2014 target \u226590%." ], "failure_signals": [ "Scanner missed more than one scheduled run in a 30-day window.", "Any quarantined asset found in active retrieval results.", "No evidence that dashboard is reviewed by a governance owner." ] }, "legal_counsel": { "summary": "Automated staleness detection creates a knowledge record: once the system flags content as stale, continuing to serve it is a knowing act \u2014 detection must therefore be coupled to enforceable disposition.", "actions": [ "Confirm flagged-stale content in regulated categories is suppressed or reviewed within a defined SLA.", "Treat detection logs as retention-worthy records; they establish what the organization knew and when.", "Review the disposition policy so 'flagged but still served' states are time-bounded and justified." ], "failure_signals": [ "Content flagged stale months ago is still served in a regulated category.", "Detection logs showing prior knowledge of staleness were not retained." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations detect staleness only at query time (via user feedback) or during periodic manual audits. Automated continuous detection is the target state and is achievable with standard metadata-driven pipeline tooling." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Knowledge Engineering Team", "Platform Engineering", "GRC Team" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a79.1", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a79.1 requires organizations to determine what needs to be monitored and measured regarding AI system performance, including data quality attributes. Automated staleness detection directly implements continuous monitoring of the timeliness dimension for knowledge assets, producing quantitative metrics against defined thresholds that satisfy the measurement and analysis requirements.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 13", "fit": "direct", "rationale": "DAMA-DMBOK 2nd edition Chapter 13 (Data Quality) prescribes automated, continuous data quality monitoring that produces measurable metrics against defined thresholds. The staleness scanner operationalizes this principle for the timeliness dimension, producing event-stream records that feed the data quality reporting infrastructure DMBOK prescribes.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "aws_bedrock_kb", "requirement_id": "Knowledge Bases \u2014 data source sync and ingestion job status", "fit": "partial", "rationale": "Amazon Bedrock Knowledge Bases synchronizes data sources through ingestion jobs whose status and timestamps are observable, letting operators compare indexed content against source document change times. The platform does not provide a native staleness detector; this control adds the detection and quarantine layer on top of those sync primitives.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10(3)", "fit": "direct", "rationale": "EU AI Act Article 10(3) requires high-risk AI systems to use data that is relevant and up-to-date. Automated detection is the operational mechanism that ensures this requirement is met continuously rather than only at initial deployment. Without automated detection, an organization cannot demonstrate ongoing compliance with the relevance requirement after initial model or knowledge base certification.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_vertex_rag", "requirement_id": "Vertex AI RAG \u2014 metadata filters at query time", "fit": "partial", "rationale": "Google Vertex AI RAG supports metadata filters at query time, which can exclude documents by date or other attributes when that metadata is populated. Filtering complements but does not replace automated staleness detection; this control adds proactive scanning and quarantine ahead of retrieval rather than relying on query-time filters alone.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KC-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The knowledge management system must continuously compare all knowledge asset timestamps against their assigned staleness-tier thresholds from KC-01 and automatically apply the configured expiry action (flag, quarantine, or alert) within 24 hours of any asset exceeding its maximum permissible age. The control passes when no asset has remained in an expired state for more than 24 hours without the configured expiry action being applied, and automated staleness detection covers 100% of registered knowledge assets.", "evidence_required": [ "staleness_detection_execution_log for the prior 30 days showing all assets scanned, staleness threshold comparisons, expiry actions triggered, and detection timestamps", "staleness_alert_record listing all assets flagged or quarantined in the prior 90 days with initial detection timestamp, expiry action applied, and resolution status", "detection_coverage_report showing the percentage of registered knowledge assets covered by automated staleness scanning with any coverage gaps identified and justified", "staleness_detection_system_configuration showing threshold values used in automated checks confirming they match the staleness classification taxonomy defined in KC-01" ], "machine_tests": [ "Insert a test knowledge asset with last_updated timestamp set to 1 day past the most restrictive staleness tier's maximum age \u2192 assert the detection system flags or quarantines the asset within 24 hours", "Query the staleness detection execution log for the prior 7 days \u2192 assert at least one complete scan cycle completed per day with coverage >= 100% of registered assets", "Check the staleness alert queue for assets that have exceeded their maximum age but have no expiry action applied for more than 24 hours \u2192 assert count=0", "Compare detection threshold values in system configuration against staleness tier taxonomy definitions from KC-01 \u2192 assert zero threshold mismatches" ], "human_review": [ "Review the staleness alert backlog and assess whether the volume and type of expired assets indicates systemic gaps in the knowledge refresh process defined in KC-03 requiring escalation", "Evaluate detection coverage gaps identified in the coverage report and determine whether uncovered assets pose material risk given their content type and assigned staleness class", "Assess whether configured expiry actions are appropriately calibrated to content risk \u2014 confirming that high-risk regulatory content triggers quarantine rather than an advisory flag only" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Running staleness detection as a weekly batch job rather than a continuous or daily process, allowing high-velocity regulatory content to remain in the corpus for days past expiry without detection", "Configuring the detection system with hardcoded age thresholds instead of reading thresholds from the staleness classification taxonomy, causing thresholds to drift out of sync when KC-01 taxonomy is updated", "Flagging expired assets in a monitoring dashboard without triggering any automated expiry action, leaving expired content available for retrieval despite detection", "Excluding recently-ingested assets from staleness scanning on the assumption that new content is always current, missing cases where content was stale at the time of ingestion", "Treating staleness detection as fully automated and removing human review of alert queues, missing cases where the automated threshold is inappropriate for specific high-sensitivity content subtypes" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KC" }, { "id": "KC-03", "layer": "KC", "plane": "lifecycle", "name": "Knowledge Refresh Scheduling and Execution", "plain": "Knowledge assets must be refreshed against authoritative upstream sources on schedules derived from their staleness-tier assignments, with triggered refresh pathways for event-driven updates and full execution audit trails.", "threat": { "tags": [ "refresh-schedule-gap", "source-drift-accumulation", "untracked-refresh-failure", "stale-policy-reliance" ], "desc": "Defining a staleness policy without a corresponding refresh execution mechanism creates a governance theater: assets are classified as stale but never actually updated. Scheduled refresh processes without audit trails cannot demonstrate that refresh occurred or that the refreshed content was sourced from the intended authoritative upstream. Refresh failures that go undetected leave the knowledge base in a state the policy declares invalid while systems continue to serve it." }, "standard": [ { "id": "iso_30401", "section": "\u00a74.4.2", "title": "Knowledge development \u2014 retaining current knowledge" }, { "id": "itil_4", "section": "\u00a75.1.4", "title": "Knowledge management practice" }, { "id": "dama_dmbok", "section": "Ch. 8", "title": "Data integration \u2014 ETL scheduling and lineage" }, { "id": "iso_42001", "section": "A.6.2.6", "title": "AI system operation and monitoring" } ], "sources": [ { "id": "databricks_unity_catalog_2024", "title": "Databricks Unity Catalog (Knowledge Gov.)", "authority": "Databricks, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.databricks.com/en/data-governance/unity-catalog/index.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "databricks_unity_catalog_2024", "relationship": "informative_reference", "rationale": "Establishes Databricks Unity Catalog (Knowledge Gov.) requirements informing the apeiris://knowledge/controls/KC-03 Knowledge Refresh Scheduling and Execution control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "A refresh orchestrator maintains a schedule registry keyed on staleness_tier and content_class, executes refresh jobs against declared upstream sources, validates output against quality gates, and writes an immutable execution record to the knowledge governance event stream. Trigger-based refresh pathways complement scheduled execution for event-driven updates.", "steps": [ "Build a refresh schedule registry that maps (staleness_tier, content_class) to refresh interval, upstream source identifier, and quality gate specification.", "Implement a refresh orchestrator that executes scheduled and triggered refresh jobs, pulling content from declared upstream sources and running validation checks before committing to the knowledge store.", "Write an immutable execution record for every refresh run including: job_id, asset_ids_refreshed, upstream_source_ref, quality_gate_results, start_time, end_time, status (success/partial/failed), and operator.", "Implement a trigger-based refresh pathway that accepts external events (e.g., regulatory publication webhooks, source system change notifications) and initiates out-of-schedule refresh jobs with elevated priority.", "Alert the knowledge governance owner within one hour when a scheduled refresh job fails or when quality gates reject more than 10% of refreshed assets." ], "knowledge_engineer": { "summary": "The refresh orchestrator is the operational heart of knowledge currency. Treat refresh jobs as first-class pipeline stages with the same observability, retry logic, and alerting as production data pipelines.", "actions": [ "Declare upstream source references for every knowledge asset class in the schedule registry; reject assets with no declared source from scheduled refresh.", "Implement idempotent refresh jobs so that duplicate triggers produce a single committed update with a deduplicated execution record.", "Build quality gates that validate refreshed content against the asset class schema and a minimum coverage threshold before committing." ], "failure_signals": [ "Any scheduled refresh job missed without a documented exception.", "Execution records missing for any refresh run in the past 90 days.", "Quality gate rejection rate exceeding 10% on any single refresh run without incident follow-up." ] }, "data_scientist": { "summary": "Refresh execution must include semantic drift validation \u2014 verifying that the refreshed content is meaningfully updated relative to the prior version, not simply re-ingesting identical content from a re-dated source.", "actions": [ "Add a semantic similarity gate to the refresh pipeline that computes embedding distance between the prior version and the refreshed version; flag assets with near-zero delta for manual review as potential source-unchanged artifacts.", "Track refresh delta metrics (proportion of assets substantively changed per refresh run) to detect upstream source staleness independent of the knowledge base." ], "failure_signals": [ "Refresh runs show near-zero semantic delta across multiple consecutive cycles without investigation.", "No semantic drift metric collected in refresh execution records." ] }, "it_operations": { "summary": "Refresh jobs are critical infrastructure whose availability directly affects knowledge currency compliance. Treat job scheduling infrastructure with production-grade SLAs.", "actions": [ "Monitor refresh job scheduler availability and alert on missed cron executions within one scheduling cycle.", "Implement retry logic with exponential backoff for transient upstream source failures, with a maximum retry window that does not exceed the staleness-tier threshold.", "Maintain a refresh job runbook covering manual execution, rollback procedures for failed batch updates, and escalation paths." ], "failure_signals": [ "Scheduler downtime causes more than one missed refresh cycle for any T1 or T2 asset class.", "No runbook exists or runbook has not been tested in the past 6 months.", "Upstream source connectivity failures go undetected for more than one scheduling cycle." ] }, "grc_auditor": { "summary": "Execution records and quality gate logs are the primary evidence that refresh scheduling is operationally enforced, not merely documented in policy. Audit the records, not the schedule.", "actions": [ "Pull execution records for the past 90 days and verify scheduled jobs ran at the expected intervals for each staleness tier.", "Sample 5 refresh execution records and trace the upstream source reference to verify the content was sourced from the declared authoritative source.", "Review quality gate rejection records and verify that rejected assets were not committed to the active knowledge store." ], "metrics": [ "Scheduled refresh completion rate: jobs completing as scheduled \u2014 target \u226599% for T1, \u226597% for T2.", "Quality gate pass rate: refreshed assets passing validation \u2014 target \u226590% per run.", "Refresh failure response time: alerts acknowledged and incidents opened within 1 hour \u2014 target 100%." ], "failure_signals": [ "Execution records absent for any scheduled refresh window.", "Upstream source reference in execution records does not match the declared authoritative source in the schedule registry.", "Rejected assets found in active retrieval results post-rejection." ] }, "legal_counsel": { "summary": "Refresh schedules encode compliance commitments: where law or contract requires current information, the refresh cadence and its execution records are the proof of meeting that duty.", "actions": [ "Map refresh cadences for regulated content to the update rhythms of the underlying legal sources.", "Require execution records for refreshes of compliance-critical corpora, not just schedule definitions.", "Review refresh failure reports for content classes where staleness creates legal exposure." ], "failure_signals": [ "A regulatory corpus missed scheduled refreshes for a quarter with no escalation.", "No execution evidence exists to show a contractual currency commitment was honored." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Organizations typically have ad-hoc refresh scripts without formal scheduling registries or execution audit trails. Formalizing the schedule registry and execution record pattern is the target state for this control." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Knowledge Engineering Team", "Platform Engineering", "IT Operations" ], "frameworks": [ { "framework": "iso_30401", "requirement_id": "\u00a74.4.2", "fit": "direct", "rationale": "ISO 30401:2018 \u00a74.4.2 requires retaining current knowledge and handling outdated knowledge as ongoing knowledge development activities. Refresh scheduling and execution is the operational mechanism through which knowledge is kept current systematically, with audit trails demonstrating it occurred as intended.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "itil_4", "requirement_id": "\u00a75.1.4 \u2014 Knowledge management", "fit": "direct", "rationale": "The ITIL 4 knowledge management practice (5.1.4) expects knowledge articles to be reviewed and kept current through defined processes. The refresh orchestrator pattern operationalizes this with the automation and audit trail appropriate for managing knowledge at enterprise scale.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2)", "fit": "direct", "rationale": "EU AI Act Article 9(2) requires the risk management system for high-risk AI to be a continuous, iterative process that is planned and run throughout the system's lifecycle and regularly reviewed and updated. Scheduled knowledge refresh operationalizes this regular review-and-update requirement for the knowledge data used by high-risk AI systems.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 8", "fit": "direct", "rationale": "DAMA-DMBOK 2nd edition Chapter 8 (Data Integration and Interoperability) treats ETL scheduling and lineage as core data integration disciplines, requiring that data refresh processes be documented, scheduled, and traceable to authoritative upstream sources. The refresh schedule registry and execution record pattern directly implements these disciplines for knowledge asset management.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "databricks_unity", "requirement_id": "Unity Catalog \u2014 data lineage for ingestion jobs", "fit": "partial", "rationale": "Databricks Unity Catalog captures lineage for scheduled ingestion jobs, enabling organizations to trace a knowledge asset's current version to its upstream source and execution run. Integrating refresh orchestration with Unity Catalog lineage satisfies the audit trail requirement for knowledge pipelines on Databricks, though the control applies equally to non-Databricks implementations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KC-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "All knowledge assets must be refreshed from their authoritative upstream sources on schedules derived from their staleness-tier assignments from KC-01, with triggered refresh pathways operating for event-driven updates such as regulatory amendments and source retractions, and a complete execution audit trail capturing job identity, source queried, content delta, and completion status for every refresh run. The control passes when no knowledge assets are overdue for scheduled refresh, triggered refresh events are executed within 4 hours of receipt, and every refresh job has a corresponding execution audit record.", "evidence_required": [ "refresh_schedule_configuration showing each knowledge asset group's scheduled refresh cadence mapped to its staleness tier assignment from KC-01", "refresh_execution_audit_log for the prior 90 days showing job_id, target_asset_group, source_queried, refresh_type (scheduled or triggered), execution_start, execution_end, content_delta_summary, and completion_status for each run", "overdue_refresh_report showing any assets currently past their scheduled refresh date with days_overdue, reason, and remediation status", "triggered_refresh_event_log showing event source, receipt_timestamp, trigger_type, and refresh_execution_start for all event-driven refreshes in the prior 90 days" ], "machine_tests": [ "Query the refresh schedule configuration and assert every knowledge asset group has a mapped refresh cadence that is less than or equal to its staleness tier's maximum permissible age from KC-01", "Check the overdue refresh report for assets with days_overdue > 0 \u2192 assert count=0 or assert each has a documented exception with approved deferral and expiry date", "Simulate a triggered refresh event via the event webhook and assert a refresh job executes within 4 hours with a corresponding execution audit log entry", "Retrieve 10 recent refresh execution audit log entries and assert each contains all required fields: job_id, target_asset_group, source_queried, refresh_type, execution_start, completion_status" ], "human_review": [ "Review the overdue refresh report and assess whether missed refresh schedules are due to source unavailability, system failure, or resource constraints \u2014 and whether the remediation plan is adequate to prevent repeat overdue cycles", "Evaluate the triggered refresh pathway configuration to confirm that known event sources including regulatory agency feeds and vendor changelogs are actively subscribed and have been tested within the prior quarter", "Assess refresh execution failure rates in the prior quarter and determine whether failure patterns indicate systemic upstream source instability requiring alternative or fallback refresh sources" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Defining refresh schedules without connecting them to the staleness tier classification from KC-01, resulting in refresh cadences that bear no relationship to content risk or regulatory change velocity", "Relying exclusively on scheduled refresh without implementing event-driven triggered pathways, causing regulatory amendments and source retractions to remain unprocessed until the next scheduled refresh cycle", "Running refresh jobs without producing execution audit records, making it impossible to demonstrate to auditors that scheduled refreshes were completed on time and from the correct authoritative source", "Refreshing knowledge asset content by overwriting prior content in place rather than creating a versioned update, destroying the change history required by KC-04", "Treating refresh execution failure as a non-critical alert, allowing failed refresh jobs to remain unresolved across multiple scheduled cycles without escalation or governance visibility" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KC" }, { "id": "KC-04", "layer": "KC", "plane": "data", "name": "Knowledge Version Control and Change History", "plain": "Every change to a knowledge asset must be recorded in an immutable version history that preserves the prior content, captures the change rationale and operator identity, and maintains stable references so that consumers of a prior version are not silently redirected to the updated content.", "threat": { "tags": [ "version-aliasing", "silent-content-replacement", "audit-trail-loss", "reference-ambiguity" ], "desc": "Knowledge systems that update assets in-place without versioning create an irreconcilable gap between what an AI system claimed at time T and what the knowledge base currently says. When regulators, auditors, or affected parties investigate an AI output, the organization cannot reconstruct the knowledge state that produced it. Silent in-place updates also create reference aliasing \u2014 a consumer holding a reference to a knowledge asset receives different content after refresh without any signal that the content changed." }, "standard": [ { "id": "w3c_prov", "section": "PROV-DM \u00a75.2.2", "title": "Revision \u2014 entity version derivations" }, { "id": "iso_42001", "section": "\u00a77.5", "title": "Documented information \u2014 version control and change management" }, { "id": "dama_dmbok", "section": "Ch. 9", "title": "Document and content management \u2014 version control" }, { "id": "eu_ai_act", "section": "Art. 12(1)", "title": "Record-keeping for high-risk AI systems" } ], "sources": [ { "id": "databricks_unity_catalog_2024", "title": "Databricks Unity Catalog (Knowledge Gov.)", "authority": "Databricks, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.databricks.com/en/data-governance/unity-catalog/index.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "databricks_unity_catalog_2024", "relationship": "informative_reference", "rationale": "Establishes Databricks Unity Catalog (Knowledge Gov.) requirements informing the apeiris://knowledge/controls/KC-04 Knowledge Version Control and Change History control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Knowledge assets are stored in an append-only content-addressed store. Each update creates a new version record with an immutable version_id, a parent_version reference chain, a content hash, operator identity, change rationale, and timestamp. Stable external references resolve to the current version by default but can be pinned to any version by specifying the version_id.", "steps": [ "Implement an append-only knowledge store where updates create new version records rather than overwriting existing content; prohibit in-place mutation of committed versions.", "Assign each version a globally unique version_id (e.g., content-addressed hash or UUID) and maintain a parent_version chain to enable full history traversal.", "Require change records to include: operator identity (authenticated), change_type (refresh, correction, retirement, emergency-update), change_rationale (free text), and source_reference.", "Implement stable asset references that resolve to the latest version by default and support version-pinned references using version_id for consumers requiring reproducibility.", "Provide a version history API endpoint that returns the full version chain for any asset_id, including content hashes, timestamps, and change rationale, accessible to governance tooling and audit processes." ], "knowledge_engineer": { "summary": "The content-addressed append-only store is the foundational data structure for version control. Once this pattern is established, every other knowledge currency control benefits from the resulting audit trail.", "actions": [ "Choose a storage backend that supports append-only writes with immutable version records (e.g., object storage with versioning enabled, or a document store with immutable audit log).", "Implement the version history API with pagination and filtering by date range, operator, and change_type.", "Add a content hash verification step to the ingest pipeline that detects duplicate content being submitted as a new version and rejects it without creating a spurious version record." ], "failure_signals": [ "Any in-place mutation of a committed knowledge asset version detected in storage audit logs.", "Version history chain broken (missing parent_version reference) for any asset.", "Change records with no operator identity or change rationale present in version history." ] }, "data_scientist": { "summary": "Version control enables reproducible AI experiments by allowing model evaluation to be conducted against a pinned historical knowledge state, critical for debugging regressions tied to knowledge base updates.", "actions": [ "Use version-pinned references in model evaluation pipelines to ensure evaluation is conducted against a fixed knowledge state, not the rolling current version.", "Instrument the retrieval pipeline to log the version_id of every chunk retrieved at inference time, enabling post-hoc attribution of outputs to specific knowledge versions." ], "failure_signals": [ "Model evaluation pipelines using floating current-version references that change between evaluation runs.", "Retrieved chunk version_ids not logged at inference time, preventing post-hoc knowledge attribution." ] }, "it_operations": { "summary": "Version control of knowledge assets is storage architecture: the append-only store, version chain integrity, and point-in-time reconstruction are operational capabilities that must be provisioned and tested.", "actions": [ "Operate the knowledge store in append-only mode with immutability controls verified by test.", "Exercise point-in-time reconstruction regularly so historical state recovery works when needed.", "Monitor version chain integrity and alert on gaps or hash mismatches." ], "failure_signals": [ "Point-in-time reconstruction fails when first attempted during a real investigation.", "Version chain gaps appear after a storage migration." ] }, "grc_auditor": { "summary": "Version history is the evidentiary record that enables post-incident reconstruction of knowledge state. Verify immutability, completeness, and the ability to replay any historical version.", "actions": [ "Verify storage backend configuration enforces append-only writes and that administrative override procedures require dual authorization.", "Select 5 assets with known recent updates and trace their full version history chains; verify each link includes operator identity, change rationale, and source reference.", "Attempt to reconstruct the knowledge state for a specified historical date using version history and verify the reconstruction matches expected content." ], "metrics": [ "Version history completeness: proportion of assets with complete, unbroken version chains \u2014 target 100%.", "Change record completeness: proportion of version records with operator identity and change rationale \u2014 target 100%.", "Historical reconstruction capability: ability to reconstruct knowledge state for any date within retention window \u2014 target 100%." ], "failure_signals": [ "Any asset with a broken version chain or missing parent_version reference.", "Version records lacking operator identity (indicating unauthorized or automated mutation without attribution).", "Storage backend permits in-place overwrites without creating version records." ] }, "legal_counsel": { "summary": "Immutable version history is the technical foundation for defensible AI governance. Without it, the organization cannot reconstruct the knowledge basis for any AI output that becomes subject to regulatory review or litigation.", "actions": [ "Confirm that version history retention policy satisfies the longest applicable regulatory record-keeping requirement across all content classes (minimum 7 years for financial content, confirm jurisdiction-specific requirements for other classes).", "Verify that the version history API is accessible to legal and compliance teams without dependency on knowledge engineering staff availability." ], "failure_signals": [ "Version history retention period shorter than the longest applicable regulatory record-keeping requirement.", "No documented procedure for extracting version history in a format admissible as evidence." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most knowledge bases use in-place update patterns inherited from CMS or database tooling without content-addressed versioning. Migrating to an append-only store with stable versioned references requires a storage layer change that must be planned carefully." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Knowledge Engineering Team", "Platform Engineering", "Legal Counsel" ], "frameworks": [ { "framework": "w3c_prov", "requirement_id": "PROV-DM \u00a75.2.2", "fit": "direct", "rationale": "W3C PROV-DM \u00a75.2.2 defines Revision as a derivation subtype: each revision is a new entity linked to its predecessor via wasRevisionOf, preserving the complete derivation chain. The append-only version store directly implements this revision model, enabling provenance graphs that trace any knowledge asset through its entire change history.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 12(1)", "fit": "direct", "rationale": "EU AI Act Article 12(1) requires high-risk AI systems to enable logging of events that are relevant for identifying risks and assessing compliance. Knowledge version history is a direct implementation of this logging requirement for the knowledge data dimension \u2014 it creates the record that enables regulators to determine what knowledge state produced any given AI output during the system's operational lifetime.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "\u00a77.5", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a77.5 requires documented information to be controlled, including version management, change history, and protection against unintended alteration. The immutable append-only version store with operator-attributed change records directly satisfies these documented information control requirements for knowledge assets used by AI systems.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 9", "fit": "direct", "rationale": "DAMA-DMBOK 2nd edition Chapter 9 (Document and Content Management) requires document and content systems to implement version control with change history to support provenance and regulatory record-keeping. The control's append-only store with version chain traversal directly implements these version-control practices.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "databricks_unity", "requirement_id": "Delta Lake \u2014 time travel and version history", "fit": "partial", "rationale": "Delta Lake time travel \u2014 the transaction-log-based versioning of the Delta Lake storage layer used on Databricks \u2014 provides append-only versioned storage with full history traversal, directly implementing the storage pattern this control requires. Organizations using Databricks for knowledge storage can use it to satisfy the historical reconstruction requirement. The fit is partial because the control applies equally to non-Databricks storage implementations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KC-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every change to a knowledge asset must produce an immutable version record preserving the prior content hash, capturing change_rationale, operator_identity, and change_timestamp, with stable version references ensuring consumers of a prior version are not silently redirected to updated content. The control passes when 100% of knowledge asset modifications produce a corresponding version record with all required fields, no version records can be deleted or modified after creation, and any prior version is retrievable by stable reference within 90 seconds.", "evidence_required": [ "knowledge_version_history sample for 5 knowledge assets showing at least 2 version records each with prior_content_hash, change_rationale, operator_id, change_timestamp, and version_ref fields populated", "version_store_immutability_configuration_record showing the version history store is configured with write-once controls preventing deletion or modification of prior versions", "version_reference_resolution_test_results confirming stable version references (asset_id + version_number) resolve to the correct prior content within defined latency", "change_coverage_report showing all knowledge asset modifications in the prior 30 days produced corresponding version records with no unversioned changes detected" ], "machine_tests": [ "Modify a knowledge asset via the standard update API \u2192 assert a version record is created within 5 seconds containing prior_content_hash, operator_id, change_timestamp, and version_ref", "Attempt to delete a prior version record from the version history store \u2192 assert the operation is rejected with immutability_violation or permission_denied", "Retrieve a prior version of a knowledge asset by stable version reference \u2192 assert the returned content matches the stored prior_content_hash and retrieval latency is <= 90 seconds", "Query the change coverage report for knowledge asset modifications in the prior 24 hours without corresponding version records \u2192 assert count=0" ], "human_review": [ "Review a sample of 10 version records and assess whether change_rationale entries are substantive descriptions of what changed and why rather than generic placeholders such as routine update", "Evaluate whether the version retention policy is adequate for the deployment context \u2014 confirming version history is retained for at least the regulatory minimum applicable to the organization's sector", "Assess whether stable version references are consistently used in downstream AI retrieval component configuration, ensuring components cannot silently receive updated content without explicit version advancement" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Updating knowledge asset content in-place without versioning, making it impossible to reconstruct what content was available to the AI system at a specific historical point in time for audit or litigation purposes", "Recording version history with operator_id as a team or shared service account name rather than a specific individual identity, eliminating personal accountability for knowledge content changes", "Allowing version records to be deleted during routine data management or storage reclamation operations, destroying the immutability that makes version history legally defensible", "Storing version history in the same mutable store as the current content without a separate immutability layer, exposing historical versions to the same modification risks as live content", "Treating version control as optional for minor content updates without a defined threshold for what constitutes a minor change, creating inconsistent versioning coverage across the knowledge corpus" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KC" }, { "id": "KC-05", "layer": "KC", "plane": "control", "name": "Knowledge Cutoff Date Disclosure to Users", "plain": "AI systems must transparently disclose the effective knowledge cutoff date to users when queries touch domains where knowledge currency could materially affect response accuracy, and must present this disclosure in a form the user can act on.", "threat": { "tags": [ "undisclosed-knowledge-cutoff", "user-reliance-on-stale-output", "confidence-miscalibration", "informed-consent-gap" ], "desc": "Users and downstream systems that do not know the knowledge cutoff date cannot calibrate their trust in AI outputs appropriately. A user querying an AI about current drug interactions, regulatory requirements, or market conditions has no basis for knowing whether the response reflects the world as of last week or two years ago. Uniform non-disclosure creates systematic confidence miscalibration \u2014 users treat outputs as current when they may be materially outdated, creating liability for the deploying organization and harm for the affected user." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 13(1)", "title": "Transparency obligations \u2014 information to users" }, { "id": "anthropic_transparency", "section": "Model Card \u2014 Training Data Cutoff", "title": "Knowledge cutoff disclosure in model cards" }, { "id": "iso_42001", "section": "A.6.2.7", "title": "AI system technical documentation" } ], "sources": [ { "id": "anthropic_model_cards_2024", "title": "Anthropic Model Cards & Knowledge Disclosure", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/transparency", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_transparency", "relationship": "informative_reference", "rationale": "Establishes Anthropic Model Cards & Knowledge Disclosure requirements informing the apeiris://knowledge/controls/KC-05 Knowledge Cutoff Date Disclosure to Users control.", "reviewed_on": "2026-07-01" }, { "id": "openai_system_cards_2024", "title": "OpenAI System Cards & Transparency", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2023-03-14", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/index/gpt-4-system-card/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_system_cards_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI System Cards & Transparency requirements informing the apeiris://knowledge/controls/KC-05 Knowledge Cutoff Date Disclosure to Users control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "The AI system maintains a per-domain knowledge_cutoff registry. At query time, the system identifies the relevant knowledge domain(s), retrieves the applicable cutoff dates, and appends a structured disclosure to the response when the query is classified as currency-sensitive. Disclosure format includes: cutoff date, affected domains, confidence impact classification, and a link to the knowledge currency status page.", "steps": [ "Build a knowledge_cutoff registry that stores the effective cutoff date for each knowledge domain, updated automatically by the staleness detection and refresh pipeline.", "Implement a query classifier that identifies queries touching currency-sensitive domains (regulatory, financial, medical, legal, product specifications) and marks them for cutoff disclosure.", "Generate a structured disclosure block appended to responses for currency-sensitive queries, including: knowledge_cutoff_date, affected_domains, confidence_impact (low/medium/high), and a user-actionable recommendation (e.g., 'Verify against current sources for decisions made after [date]').", "Expose a machine-readable knowledge currency status endpoint (e.g., `/.well-known/knowledge-currency.json`) that returns current cutoff dates by domain for API consumers and downstream systems.", "Log every disclosure event with the query_id, user_id (if applicable), disclosed_cutoff_dates, and confidence_impact for governance auditing." ], "knowledge_engineer": { "summary": "Cutoff disclosure depends on an accurate and automatically maintained cutoff registry. The registry must be updated synchronously with every successful refresh execution, not as a separate manual step.", "actions": [ "Update the knowledge_cutoff registry as a mandatory post-step in every refresh execution job.", "Implement the well-known knowledge currency endpoint with a defined schema and include it in the site's CORS policy to allow cross-origin reads by downstream consumers.", "Build the query classifier with explicit coverage targets for currency-sensitive domain categories; log unclassified queries for review and classifier improvement." ], "failure_signals": [ "Knowledge_cutoff registry date out of sync with the last successful refresh execution by more than 24 hours.", "Query classifier coverage below 95% for known currency-sensitive domain categories.", "Well-known endpoint returning stale or cached data older than 1 hour." ] }, "data_scientist": { "summary": "Confidence impact classification in the disclosure block should be calibrated empirically, not assigned arbitrarily. Measure the effect of knowledge age on response accuracy for each domain to generate evidence-based confidence impact ratings.", "actions": [ "Run controlled evaluations comparing response accuracy on time-sensitive queries against knowledge bases of varying ages to calibrate the confidence_impact classifications.", "Instrument retrieval to track what proportion of retrieved chunks are within 30, 90, and 365 days of the cutoff date, using chunk age distribution to refine confidence impact classification at query time." ], "failure_signals": [ "Confidence impact classifications assigned without empirical calibration.", "Confidence impact classification not updated after significant knowledge base refresh events." ] }, "it_operations": { "summary": "Cutoff disclosure is computed at serving time: the disclosure value must reflect the actual snapshot and index state of the responding system, which means it is plumbing, not copy.", "actions": [ "Derive the disclosed cutoff dynamically from index snapshot metadata rather than hardcoding it.", "Test that disclosure values update correctly after refresh and re-index events.", "Monitor for responses emitted without the disclosure field after payload schema changes." ], "failure_signals": [ "The disclosed cutoff date stays fixed while the index refreshes weekly.", "A schema change silently drops the disclosure field from responses." ] }, "grc_auditor": { "summary": "Disclosure logs are the evidence that transparency obligations were fulfilled for individual queries. Audit both the accuracy of disclosed cutoff dates and the completeness of disclosure coverage across currency-sensitive query types.", "actions": [ "Sample 20 responses to known currency-sensitive queries and verify each includes a disclosure block with an accurate cutoff date matching the knowledge_cutoff registry.", "Review disclosure event logs for the past 30 days and verify coverage rate for queries classified as currency-sensitive.", "Verify the well-known endpoint returns current data and matches the disclosure blocks appended to live responses." ], "metrics": [ "Disclosure accuracy rate: disclosed cutoff dates matching the knowledge_cutoff registry \u2014 target 100%.", "Coverage rate: proportion of currency-sensitive queries receiving disclosure \u2014 target \u226599%.", "Registry currency: knowledge_cutoff registry updated within 24 hours of every successful refresh \u2014 target 100%." ], "failure_signals": [ "Any disclosed cutoff date that does not match the knowledge_cutoff registry.", "Currency-sensitive query receiving no disclosure block.", "Disclosure event logs missing for any production session." ] }, "legal_counsel": { "summary": "Cutoff date disclosure is a consumer protection and regulatory transparency obligation. The disclosure format, placement, and content must be designed for informed reliance, not for burying caveats in fine print.", "actions": [ "Review the disclosure block format and confirm it is presented in plain language, positioned before any substantive response content for high-confidence-impact disclosures, and includes a clear user-actionable recommendation.", "Confirm that disclosure language satisfies EU AI Act Article 13 transparency requirements for the jurisdictions in which the system is deployed." ], "failure_signals": [ "Disclosure blocks positioned after substantive response content for high-confidence-impact queries.", "Disclosure language uses technical jargon that is not comprehensible to the intended user population.", "No legal review of disclosure text in past 12 months despite applicable regulatory changes." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most AI systems provide a static global knowledge cutoff date in documentation rather than dynamic per-query disclosure calibrated to domain and confidence impact. Per-domain dynamic disclosure is the target state." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "eu-high-risk-ai", "high-risk-sector", "multi-tenant" ], "implementers": [ "Knowledge Engineering Team", "Product Management", "Legal Counsel" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 13(1)", "fit": "direct", "rationale": "EU AI Act Article 13(1) requires high-risk AI systems to be designed with transparency sufficient to allow users to interpret and use the system's output appropriately. Dynamic knowledge cutoff disclosure directly implements this transparency requirement for the knowledge currency dimension \u2014 users cannot use AI outputs appropriately if they do not know whether those outputs are based on current or outdated knowledge.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "anthropic_transparency", "requirement_id": "Model Card \u2014 Training Data Cutoff", "fit": "direct", "rationale": "Anthropic's model card practice establishes knowledge cutoff disclosure as a standard transparency artifact for AI systems. This control extends that model-level disclosure practice to the runtime level, providing per-query dynamic disclosure that reflects the actual knowledge state at the time of the query rather than a static model card entry that may not reflect knowledge base updates deployed after model release.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "iso_42001", "requirement_id": "A.6.2.7", "fit": "direct", "rationale": "ISO/IEC 42001:2023 Annex A control A.6.2.7 requires organizations to provide technical documentation about the AI system, including its limitations, to relevant interested parties. Knowledge cutoff disclosure implements this documentation requirement for the temporal-validity dimension of AI knowledge.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_transparency", "requirement_id": "System Card \u2014 Knowledge Limitations", "fit": "partial", "rationale": "OpenAI's system card practice includes documentation of knowledge limitations including training cutoffs. This control operationalizes that transparency practice at the runtime level, converting static documentation into dynamic per-query disclosure. The fit is partial because OpenAI system cards focus on model-level documentation rather than runtime knowledge base management.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KC-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The AI system must append a structured disclosure block to every response touching a currency-sensitive domain, containing at minimum the knowledge_cutoff_date, affected_domains, and confidence_impact classification. The disclosed cutoff date must match the knowledge_cutoff registry, which itself must have been updated within 24 hours of the most recent successful refresh execution.", "evidence_required": [ "knowledge_cutoff_registry export showing per-domain cutoff_date and last_updated_at timestamps, confirming registry is within 24 hours of last successful refresh", "query_classification_log sample (minimum 500 queries) showing currency_sensitive_flag assignment with domain classification rationale for each entry", "disclosure_event_log with query_id, disclosed_cutoff_dates, confidence_impact rating, and user_id for each disclosure event in the audit period", "well-known knowledge-currency.json endpoint response captured at audit time, showing per-domain cutoff dates and endpoint generation timestamp", "classifier_coverage_report confirming the proportion of known currency-sensitive domain categories (regulatory, medical, financial, legal, product) receiving correct classification" ], "machine_tests": [ "Submit a query about current pharmaceutical drug interaction guidelines \u2192 assert response contains a structured disclosure block with fields knowledge_cutoff_date, affected_domains, and confidence_impact", "Submit a query about a historical event from 1905 \u2192 assert response does NOT contain a disclosure block (non-currency-sensitive domain correctly excluded)", "Request GET /.well-known/knowledge-currency.json \u2192 assert HTTP 200, valid JSON with per-domain cutoff_date values, and generated_at timestamp within 60 minutes of request time", "Advance the test clock 25 hours beyond last refresh, query the cutoff registry \u2192 assert staleness_flag=true and a staleness alert has been emitted to the monitoring channel" ], "human_review": [ "Sample 20 responses to known currency-sensitive queries and assess whether the disclosure block is positioned before substantive response content for high-confidence-impact classifications and is written in plain language comprehensible to the target user population", "Evaluate the query classifier domain coverage list against the organization's full taxonomy of currency-sensitive domains and confirm all high-risk categories (regulatory, medical, financial, legal, product specifications) are explicitly modeled", "Review the disclosure text content with legal counsel for sufficiency under EU AI Act Article 13(1) transparency requirements in each jurisdiction where the system is deployed" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Disclosing only the model training cutoff date from static documentation rather than the effective knowledge base refresh date, which may differ substantially and changes with each refresh cycle", "Triggering disclosure based on the model's own uncertainty signals (e.g., model confidence scores) rather than authoritative cutoff registry lookups, creating inconsistency between disclosed and actual knowledge currency", "Positioning the disclosure block after the substantive response content or in a collapsible footnote section where users are unlikely to encounter it before relying on the response", "Building the query classifier as a static keyword list covering only a narrow set of pre-approved topics, leaving entire categories of currency-sensitive queries unclassified and undisclosed", "Failing to expose a machine-readable knowledge currency endpoint, preventing downstream API consumers and multi-agent systems from programmatically checking currency before acting on AI outputs" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KC" }, { "id": "KC-06", "layer": "KC", "plane": "control", "name": "Domain-Specific Currency Requirements", "plain": "Knowledge currency standards must be calibrated to the specific refresh requirements of each content domain, applying stricter freshness thresholds to regulatory, medical, financial, and safety-critical content while permitting longer retention windows for archivally stable content.", "threat": { "tags": [ "uniform-staleness-policy-mismatch", "regulatory-content-lag", "over-refresh-resource-waste", "domain-risk-misclassification" ], "desc": "A single uniform staleness threshold applied across all content types will simultaneously under-protect high-risk domains and over-constrain archivally stable content. Regulatory guidance that changes quarterly treated with an annual refresh cycle leaves users exposed to superseded rules; historical records or mathematical reference material refreshed daily wastes resources and creates unnecessary version churn without improving accuracy. Domain-specific calibration is the mechanism that matches governance intensity to actual risk." }, "standard": [ { "id": "iso_30401", "section": "\u00a76.1", "title": "Actions to address risks and opportunities" }, { "id": "eu_ai_act", "section": "Art. 10(2)(b)", "title": "Data collection processes and the origin of data" }, { "id": "dama_dmbok", "section": "Ch. 13", "title": "Data quality dimensions \u2014 domain-specific standards" }, { "id": "iso_27002", "section": "\u00a75.12", "title": "Classification of information \u2014 sensitivity and handling" } ], "sources": [ { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements \u00a76.1 requirements informing the apeiris://knowledge/controls/KC-06 Domain-Specific Currency Requirements control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 10(2)(b) requirements informing the apeiris://knowledge/controls/KC-06 Domain-Specific Currency Requirements control.", "reviewed_on": "2026-07-02" }, { "id": "iso_27002", "title": "ISO/IEC 27002:2022 \u2014 Information Security Controls", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "voluntary-standard", "version": "2022", "published_on": "2022-02-15", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/75652.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_27002", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 27002:2022 \u2014 Information Security Controls \u00a75.12 requirements informing the apeiris://knowledge/controls/KC-06 Domain-Specific Currency Requirements control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 13 requirements informing the apeiris://knowledge/controls/KC-06 Domain-Specific Currency Requirements control.", "reviewed_on": "2026-07-02" }, { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a76.1.2 requirements informing the apeiris://knowledge/controls/KC-06 Domain-Specific Currency Requirements control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "A domain currency matrix defines freshness requirements for each content domain by combining the staleness tier assignment with domain-specific maximum age, review trigger events, and blocking thresholds. The matrix is owned by a domain governance council and reviewed quarterly. Refresh scheduling and staleness detection are parameterized from the matrix rather than from a global configuration.", "steps": [ "Define a domain currency matrix enumerating all knowledge domains with: content_class, regulatory_sensitivity (low/medium/high/critical), max_age_days, review_trigger_events (e.g., 'regulatory amendment published'), and hard_block_threshold (age beyond which retrieval is blocked without exception approval).", "Parameterize the refresh scheduler and staleness detection scanner to read thresholds from the domain currency matrix rather than from global configuration, enabling per-domain overrides without code changes.", "Establish a domain governance council with named owners for each high and critical sensitivity domain, responsible for approving matrix entries and reviewing triggered events.", "Implement a trigger event subscription mechanism that allows external event sources (regulatory publication feeds, product release notifications) to fire domain-specific refresh triggers against the matrix.", "Review the domain currency matrix quarterly and after any material regulatory change in a covered domain, with review minutes and matrix version history maintained in governance records." ], "knowledge_engineer": { "summary": "The domain currency matrix is the parameterization layer between policy and pipeline. Build the refresh scheduler and staleness scanner to read from it dynamically so that policy changes propagate to operational behavior without deployment events.", "actions": [ "Implement the domain currency matrix as a versioned configuration store (not hardcoded constants) with an API that the refresh scheduler and staleness scanner read at runtime.", "Build the trigger event subscription mechanism with a standard webhook interface so external event sources can be onboarded without code changes.", "Log every matrix read with the effective threshold values applied so that governance audits can verify the correct thresholds were in effect for any given refresh or detection event." ], "failure_signals": [ "Refresh scheduler or staleness scanner using hardcoded thresholds not sourced from the domain currency matrix.", "Domain currency matrix not versioned; no history of prior threshold values available.", "Trigger events received but not processed within one scheduling cycle." ] }, "data_scientist": { "summary": "Domain-calibrated currency thresholds should be empirically grounded: observed decay rates per content domain are the evidence for setting and defending different freshness requirements.", "actions": [ "Measure answer-quality decay per content domain to inform domain threshold calibration.", "Backtest proposed thresholds against historical incidents of stale-content harm.", "Re-evaluate domain thresholds when source update patterns change materially." ], "failure_signals": [ "Thresholds are uniform across domains despite measurably different decay rates.", "A domain threshold has no empirical basis when challenged." ] }, "it_operations": { "summary": "Per-domain currency requirements multiply scheduler complexity: the scanning and refresh machinery must apply different thresholds per domain, and configuration errors look exactly like policy.", "actions": [ "Encode per-domain thresholds in reviewed configuration consumed by the scanning and refresh jobs.", "Verify jobs resolve the correct domain threshold for mixed-domain corpora.", "Surface per-domain currency compliance on dashboards rather than a single global metric." ], "failure_signals": [ "All domains run on the default threshold because domain resolution silently fails.", "The dashboard's single global freshness number hides a failing regulated domain." ] }, "grc_auditor": { "summary": "The domain currency matrix is the governance instrument that makes domain-specific risk calibration auditable. Verify both the matrix content and its operational application.", "actions": [ "Review the domain currency matrix and confirm that all content domains with regulatory sensitivity of high or critical have max_age_days values that are shorter than the relevant regulatory publication cycle.", "Pull refresh execution logs for the past 90 days and verify that threshold values applied match the domain currency matrix entries effective at the time of execution.", "Confirm the governance council reviewed the matrix at least quarterly and that review minutes are on file." ], "metrics": [ "Domain coverage: proportion of active knowledge domains with a domain currency matrix entry \u2014 target 100%.", "Threshold compliance: proportion of refresh/detection events applying correct domain-specific thresholds \u2014 target 100%.", "Governance review cadence: quarterly review completed on schedule \u2014 target 100%." ], "failure_signals": [ "Knowledge domains active in production without a domain currency matrix entry.", "Refresh events applying global defaults rather than domain-specific thresholds.", "No governance council review for more than 4 months." ] }, "legal_counsel": { "summary": "Domain-specific currency requirements create the documented basis for asserting that regulatory and safety-critical content is governed to a higher standard than general knowledge \u2014 a key element in proportionality defenses under EU AI Act and sector-specific regulatory frameworks.", "actions": [ "Review the domain currency matrix entries for all content classes subject to sector-specific regulation (financial, medical, legal, environmental) and confirm max_age_days values are defensible relative to the governing regulatory update cycle.", "Verify that the matrix includes explicit entries for jurisdiction-specific content classes where different legal systems impose different update obligations." ], "failure_signals": [ "Regulated content class max_age_days exceeds the applicable regulatory update cycle.", "No jurisdiction-specific entries for content classes where legal requirements vary by geography." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Organizations typically apply a single global staleness threshold inherited from general IT data management practice. Building a domain-specific matrix requires cross-functional input from legal, compliance, and domain experts, but is achievable in a structured design sprint." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise", "multi-tenant" ], "implementers": [ "Knowledge Management Office", "GRC Team", "Legal Counsel", "Domain Subject Matter Experts" ], "frameworks": [ { "framework": "iso_30401", "requirement_id": "\u00a76.1", "fit": "direct", "rationale": "ISO 30401:2018 \u00a76.1 requires organizations to determine risks and opportunities for the knowledge management system and plan actions to address them. Evaluating how quickly knowledge in different domains becomes outdated is such a risk determination; domain-specific currency requirements encode its outcome as calibrated thresholds.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10(2)(b)", "fit": "partial", "rationale": "EU AI Act Article 10(2)(b) requires data governance practices covering data collection processes and the origin of data. Domain-specific currency requirements extend that origin-aware governance by calibrating freshness thresholds to the regulatory and operational risk profile of each content domain, so collection and refresh cadences match each domain's obligations.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27002", "requirement_id": "\u00a75.12", "fit": "partial", "rationale": "ISO/IEC 27002:2022 \u00a75.12 establishes that information classification must reflect the sensitivity and handling requirements of the information type. Domain-specific currency requirements extend this classification principle to the temporal dimension \u2014 different content classes require different freshness standards based on their sensitivity, regulatory status, and operational criticality. The fit is partial because ISO 27002 focuses on confidentiality classification rather than temporal validity.", "normative_force": "voluntary-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 13", "fit": "direct", "rationale": "DAMA-DMBOK 2nd edition Chapter 13 (Data Quality) recognizes that quality dimensions, including timeliness, must be defined in the context of specific data domains and their business uses rather than applied uniformly. Domain-specific currency requirements implement this domain-calibrated approach for the knowledge currency dimension.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "iso_42001", "requirement_id": "\u00a76.1.2", "fit": "adjacent", "rationale": "ISO/IEC 42001:2023 \u00a76.1.2 requires AI management systems to identify and assess risks arising from AI data, including domain-specific risks related to data relevance and currency. The domain currency matrix is the operational output of that risk assessment process, translating identified risks into calibrated governance thresholds.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KC-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every active knowledge domain in production must have a corresponding entry in the domain currency matrix specifying its regulatory_sensitivity tier, max_age_days threshold, and hard_block_threshold, and the refresh scheduler and staleness scanner must demonstrably read thresholds from the matrix rather than from global hardcoded configuration.", "evidence_required": [ "domain_currency_matrix export (versioned) listing every active knowledge domain with regulatory_sensitivity, max_age_days, hard_block_threshold, review_trigger_events, and domain_owner fields", "refresh_execution_log entries for the past 90 days annotated with the effective domain-specific threshold values applied, sourced from the matrix version active at execution time", "staleness_detection_log sample showing per-domain threshold reads with matrix version ID and timestamp, confirming runtime parameterization from the matrix", "governance_council_review_minutes for the most recent quarterly review of the domain currency matrix, signed by named participants", "trigger_event_processing_log showing external regulatory publication events received and the domain-specific refresh jobs fired in response" ], "machine_tests": [ "Query the refresh scheduler configuration endpoint \u2192 assert max_age_days and hard_block_threshold values for a selected domain match the current domain_currency_matrix entry exactly (no hardcoded overrides)", "Update a test domain's max_age_days in the matrix \u2192 assert the refresh scheduler applies the new threshold on its next execution cycle without a deployment event", "Fire a simulated trigger event for a regulatory domain via the webhook interface \u2192 assert a domain-specific refresh job is queued within one scheduling cycle", "Introduce a test knowledge asset aged beyond hard_block_threshold for a Restricted domain \u2192 assert retrieval returns a block response citing the threshold rather than returning the asset" ], "human_review": [ "Review the domain currency matrix entries for all content domains classified as high or critical regulatory_sensitivity and assess whether max_age_days values are shorter than the corresponding regulatory publication cycle for each domain", "Assess whether the domain governance council membership includes named subject matter experts for each high-sensitivity domain, and whether review minutes demonstrate substantive threshold review rather than rubber-stamp approval", "Evaluate whether the matrix includes jurisdiction-specific entries for content classes where legal update obligations differ across geographies in which the organization operates" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Hardcoding staleness thresholds as constants in the refresh scheduler or staleness scanner code rather than reading them from a versioned, externally configurable domain currency matrix", "Applying a single global max_age_days value across all knowledge domains, treating archivally stable historical content and rapidly-changing regulatory guidance identically", "Creating domain currency matrix entries only for domains that have already experienced a staleness incident, leaving newly onboarded high-risk domains ungoverned until a problem occurs", "Assigning governance ownership of the matrix to a single knowledge engineer rather than a cross-functional governance council, creating a single point of failure for threshold calibration decisions", "Omitting the hard_block_threshold field from matrix entries on the assumption that advisory alerts will be acted on promptly, removing the enforcement backstop for safety-critical and regulatory content" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KC" }, { "id": "KC-07", "layer": "KC", "plane": "lifecycle", "name": "Emergency Knowledge Update Procedures", "plain": "The organization must maintain tested procedures for rapidly updating, correcting, or quarantining knowledge assets when urgent circumstances require action outside of the scheduled refresh cycle, including regulatory changes, discovered factual errors, and safety-critical corrections.", "threat": { "tags": [ "emergency-correction-delay", "erroneous-knowledge-propagation", "regulatory-change-lag", "knowledge-incident-response-gap" ], "desc": "Scheduled refresh cycles are calibrated for normal operational cadence and are not designed to respond to material events occurring between cycles. A regulatory change issued Monday that contradicts knowledge refreshed the prior Friday will circulate in AI outputs until the next scheduled refresh \u2014 potentially days or weeks. Factual errors discovered in high-retrieval assets will continue to be served at scale until a correction path exists that bypasses the normal cycle. Without emergency procedures, the only response to urgent knowledge incidents is system-wide takedown, which creates operational disruption disproportionate to the correction needed." }, "standard": [ { "id": "iso_30401", "section": "\u00a710.1", "title": "Nonconformity and corrective action \u2014 knowledge errors" }, { "id": "itil_4", "section": "\u00a75.2.4", "title": "Change enablement \u2014 emergency changes" }, { "id": "eu_ai_act", "section": "Art. 72", "title": "Post-market monitoring by providers" }, { "id": "iso_42001", "section": "\u00a710.2", "title": "Nonconformity and corrective action for AI systems" } ], "sources": [ { "id": "itil_4", "title": "ITIL 4", "authority": "PeopleCert / Axelos", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "4", "published_on": "2019-02-28", "retrieved_on": "2026-07-02", "canonical_url": "https://www.axelos.com/certifications/itil-service-management/itil-4-foundation", "license": "proprietary", "status": "current", "flagship": false, "source_id": "itil_4", "relationship": "informative_reference", "rationale": "Establishes ITIL 4 \u00a75.2.4 \u2014 Change enablement (emergency changes) requirements informing the apeiris://knowledge/controls/KC-07 Emergency Knowledge Update Procedures control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 72 requirements informing the apeiris://knowledge/controls/KC-07 Emergency Knowledge Update Procedures control.", "reviewed_on": "2026-07-02" }, { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a710.2 requirements informing the apeiris://knowledge/controls/KC-07 Emergency Knowledge Update Procedures control.", "reviewed_on": "2026-07-02" }, { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements \u00a710.1 requirements informing the apeiris://knowledge/controls/KC-07 Emergency Knowledge Update Procedures control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "A documented Emergency Knowledge Update Procedure (EKUP) defines triggers, authorization levels, execution steps, and post-incident review requirements for out-of-cycle knowledge updates. The procedure includes three tracks: immediate quarantine (minutes), targeted correction (hours), and emergency full-refresh (hours to day). Each track has a named authorization level and a documented execution checklist.", "steps": [ "Document the Emergency Knowledge Update Procedure (EKUP) with three tracks: (1) Immediate Quarantine \u2014 removes identified assets from retrieval within 15 minutes; (2) Targeted Correction \u2014 replaces or annotates specific assets within 4 hours; (3) Emergency Full Refresh \u2014 triggers full domain refresh within 24 hours.", "Define trigger criteria for each track: regulatory amendment with immediate effect, discovered factual error in high-retrieval asset, product recall or safety notice, court order or regulatory directive.", "Assign named authorization levels for each track: IT on-call for immediate quarantine, Knowledge Governance Manager for targeted correction, Chief Knowledge Officer or designated deputy for emergency full refresh.", "Implement a break-glass quarantine mechanism accessible to on-call engineers that can quarantine assets by asset_id or content_class without going through the normal change approval pipeline.", "Require a post-incident review within 48 hours of every emergency update execution, documenting trigger event, track used, assets affected, time to quarantine/correction, and root-cause assessment with process improvement actions." ], "knowledge_engineer": { "summary": "The break-glass quarantine mechanism is the most critical implementation component. It must be tested quarterly, access-controlled via emergency authorization, and leave an immutable audit trail.", "actions": [ "Implement the break-glass quarantine API with dual-authorization (two on-call engineers required), returning a quarantine confirmation record with asset_ids, operator identities, and timestamp.", "Test the quarantine mechanism against a production-equivalent environment quarterly; document test results and update the EKUP if the 15-minute target is not met.", "Build a targeted correction pipeline that creates a new version record (per KC-04) with change_type set to 'emergency-correction' and requires approval from the Knowledge Governance Manager before committing." ], "failure_signals": [ "Break-glass quarantine mechanism not tested in past 90 days.", "Emergency quarantine exceeds 15-minute SLA in test or production execution.", "Emergency correction committed without dual authorization or version record." ] }, "data_scientist": { "summary": "Emergency knowledge updates change the corpus underneath running models: post-update verification must confirm the correction actually propagated to retrieval and did not degrade neighboring content.", "actions": [ "Define verification queries that prove an emergency correction is reflected in retrieval results.", "Check embedding and index side-effects after emergency changes to nearby content.", "Record before/after evaluation snapshots for post-incident review of emergency updates." ], "failure_signals": [ "An emergency correction was declared complete while retrieval still served the erroneous content.", "An emergency update silently degraded retrieval quality for adjacent topics." ] }, "it_operations": { "summary": "Emergency knowledge updates are an incident response category. Wire them into the organization's incident management framework with the same escalation, communication, and post-mortem processes used for security incidents.", "actions": [ "Add 'knowledge incident' as a recognized incident category in the IT service management platform with defined severity levels mapping to EKUP tracks.", "Include the break-glass quarantine procedure in the on-call runbook and verify on-call engineers can execute it without knowledge engineering staff assistance.", "Set up a dedicated notification channel (PagerDuty, Slack, SMS) for knowledge incident alerts that reaches the Knowledge Governance Manager within 5 minutes of trigger." ], "failure_signals": [ "Knowledge incidents not captured in the ITSM platform.", "On-call engineers unable to execute break-glass quarantine without assistance in runbook test.", "No dedicated notification path for knowledge governance manager." ] }, "grc_auditor": { "summary": "Emergency procedure effectiveness is demonstrated by test records and post-incident reviews, not by the existence of the documented procedure alone. Audit the tests and post-mortems.", "actions": [ "Request EKUP test records for the past 12 months and verify each track was tested at least once.", "Review post-incident records for all emergency updates executed in the past 12 months and verify they were completed within 48 hours with root-cause documentation.", "Verify break-glass quarantine audit logs are immutable and that authorization records match the defined dual-authorization requirement." ], "metrics": [ "EKUP test coverage: each track tested at least once in past 12 months \u2014 target 100%.", "Time to quarantine: immediate quarantine track executed within 15-minute SLA \u2014 target 100% in tests and production.", "Post-incident review completion: reviews completed within 48 hours \u2014 target 100%." ], "failure_signals": [ "Any EKUP track not tested in the past 12 months.", "Post-incident review not completed within 48 hours for any emergency update event.", "Break-glass quarantine used without dual authorization or without an immutable audit record." ] }, "legal_counsel": { "summary": "Emergency update procedures create the documented response capability that demonstrates the organization takes immediate corrective action when erroneous or harmful knowledge is identified \u2014 a key factor in regulatory enforcement decisions and litigation defense.", "actions": [ "Review trigger criteria to ensure they include legally required scenarios: regulatory directives, court orders, product liability notifications, and data subject correction rights (where applicable).", "Confirm the EKUP includes notification obligations \u2014 some regulatory changes require notifying users that previously provided information may have been incorrect." ], "failure_signals": [ "EKUP trigger criteria do not include regulatory directives or court orders.", "No user notification procedure for scenarios where erroneous knowledge was served at material scale before correction." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations have no formal emergency knowledge update procedure and respond to urgent corrections on an ad-hoc basis. Formalizing the three-track EKUP structure and testing it quarterly moves the organization from reactive to defined maturity." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Knowledge Management Office", "IT Operations", "GRC Team", "Legal Counsel" ], "frameworks": [ { "framework": "itil_4", "requirement_id": "\u00a75.2.4 \u2014 Change enablement (emergency changes)", "fit": "direct", "rationale": "The ITIL 4 change enablement practice (5.2.4) defines emergency changes as a distinct change type with expedited authorization, execution and post-implementation review. The EKUP applies this emergency-change governance model to knowledge asset corrections and regulatory updates.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 72", "fit": "direct", "rationale": "EU AI Act Article 72 requires providers of high-risk AI systems to establish a post-market monitoring system that actively collects and reviews operating experience so corrective action can be taken. Emergency knowledge update procedures are the corrective-action mechanism for the knowledge data dimension when monitoring identifies knowledge-related risks.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "\u00a710.2", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a710.2 requires AI management systems to react to nonconformities with immediate control and corrective action, and to retain documented information as evidence. The EKUP operationalizes this requirement for knowledge nonconformities (erroneous, outdated, or non-compliant knowledge assets) with defined tracks, authorization levels, and mandatory post-incident documentation.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_30401", "requirement_id": "\u00a710.1", "fit": "direct", "rationale": "ISO 30401:2018 \u00a710.1 requires organizations to react to nonconformities, determine root causes, and implement corrective actions to prevent recurrence. The EKUP's three-track structure and mandatory post-incident review with root-cause documentation directly satisfy this corrective action requirement for knowledge management nonconformities.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KC-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The organization must maintain a documented and tested Emergency Knowledge Update Procedure with three defined tracks (immediate quarantine, targeted correction, emergency full-refresh), each with verified execution times within defined SLAs, tested at least once in the prior 12 months, and supported by an operational break-glass quarantine mechanism with dual-authorization and immutable audit trail.", "evidence_required": [ "Emergency Knowledge Update Procedure (EKUP) document showing all three tracks with trigger criteria, authorization levels, execution checklists, and SLA targets for each track", "EKUP test execution records for all three tracks from the past 12 months, including test date, operators, assets quarantined or corrected, actual time-to-execution, and SLA pass/fail result", "break-glass quarantine audit log entries showing dual-authorization records (two operator identities) with asset_ids, quarantine_timestamp, and confirmation record for each real or test activation", "post-incident_review records for any emergency updates executed in the past 12 months, completed within 48 hours and containing trigger event description, root-cause assessment, and remediation actions", "ITSM platform screenshot or export showing 'knowledge incident' as a recognized incident category with defined severity mappings to EKUP tracks" ], "machine_tests": [ "Invoke the break-glass quarantine API with a single operator credential \u2192 assert the API rejects the request with error=dual_authorization_required (single-operator bypass not permitted)", "Invoke the break-glass quarantine API with two valid operator credentials and a test asset_id \u2192 assert quarantine_confirmation record is created with both operator identities, asset_id, and timestamp within 60 seconds", "Submit a retrieval query for a quarantined asset \u2192 assert retrieval returns HTTP 451 or equivalent block response citing quarantine status rather than the asset content", "Attempt to commit an emergency correction via the targeted correction pipeline without Knowledge Governance Manager approval \u2192 assert the pipeline halts and returns an authorization_required error" ], "human_review": [ "Review EKUP trigger criteria completeness against a checklist of legally required scenarios including regulatory directives with immediate effect, court orders, product recall notices, and data subject correction rights, confirming each category is explicitly addressed", "Assess post-incident review records for quality: each review should identify root cause, time-to-quarantine measured against SLA, and at least one process improvement action \u2014 reviews that merely confirm the incident occurred without analysis do not satisfy the corrective action requirement", "Verify that on-call engineers can execute the break-glass quarantine procedure end-to-end using only the runbook, without requiring knowledge engineering staff assistance, through a blind runbook test or tabletop exercise" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Responding to emergency knowledge incidents on an ad-hoc basis without documented tracks, authorization levels, or SLA targets, creating inconsistent response quality that depends entirely on which personnel happen to be available", "Implementing only a system-wide takedown as the emergency response mechanism, making the response disproportionately disruptive when only a subset of assets require quarantine or correction", "Testing the break-glass quarantine mechanism only once at initial deployment and never running it again, allowing authorization bindings, access credentials, and runbook steps to drift out of date", "Omitting user notification procedures from the EKUP for scenarios where materially incorrect knowledge was served at scale before correction, creating regulatory exposure under transparency and consumer protection obligations", "Allowing a single engineer to authorize emergency quarantine without dual-authorization controls, creating opportunity for unauthorized knowledge removal by a malicious insider or compromised account" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KC" }, { "id": "KC-08", "layer": "KC", "plane": "both", "name": "Knowledge Currency Evidence Package", "plain": "The organization must compile and maintain a Knowledge Currency Evidence Package that aggregates attestation artifacts from KC-01 through KC-07, enabling an auditor or regulator to assess the end-to-end currency governance posture of the knowledge base from a single evidence set.", "threat": { "tags": [ "fragmented-evidence-gap", "audit-readiness-failure", "attestation-inconsistency", "governance-posture-opacity" ], "desc": "Knowledge currency controls implemented across KC-01 through KC-07 generate evidence in disparate systems \u2014 policy documents, scanner logs, refresh execution records, version histories, disclosure logs, domain matrices, and incident records. Without a compiled evidence package, an audit requires weeks of manual evidence collection across multiple teams and systems, creating windows where inconsistencies go undetected, evidence is lost to retention policy gaps, and the organization cannot demonstrate its currency posture on demand. Regulators expecting on-demand evidence of AI data governance are increasingly treating evidence collection latency as itself indicative of governance immaturity." }, "standard": [ { "id": "iso_42001", "section": "\u00a79.3", "title": "Management review \u2014 AI system compliance evidence" }, { "id": "eu_ai_act", "section": "Art. 18", "title": "Documentation keeping" }, { "id": "iso_30401", "section": "\u00a79.3", "title": "Management review \u2014 knowledge system performance evidence" }, { "id": "dama_dmbok", "section": "Ch. 13", "title": "Data quality reporting and evidence compilation" } ], "sources": [ { "id": "microsoft_azure_ai_search_2024", "title": "Microsoft Azure AI Search & Grounding", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/azure/search/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_azure_ai_search_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Azure AI Search & Grounding requirements informing the apeiris://knowledge/controls/KC-08 Knowledge Currency Evidence Package control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "An automated evidence aggregator runs on a defined schedule (minimum monthly, triggered on demand) and compiles the KC Evidence Package from the outputs of KC-01 through KC-07. The package is a signed, versioned artifact containing: policy document references, scanner metrics summaries, refresh execution statistics, version history completeness metrics, disclosure coverage rates, domain currency matrix version, EKUP test records, and a composite currency posture score. The package is stored in a governance artifact repository with retention policies satisfying applicable regulatory requirements.", "steps": [ "Define the KC Evidence Package schema specifying required artifacts from each of KC-01 through KC-07, minimum metric thresholds, and the composite currency posture score calculation.", "Build an evidence aggregator that reads from each KC control's data sources \u2014 policy registry, scanner event stream, refresh execution records, version history API, disclosure event logs, domain currency matrix, and EKUP test records \u2014 and compiles them into a signed package artifact.", "Generate the KC Evidence Package on a monthly scheduled basis and on demand via API, storing each version in a governance artifact repository with an immutable package_id and generation timestamp.", "Sign the evidence package with the organization's governance key (Ed25519 or equivalent) so that package integrity can be verified by external auditors without requiring access to source systems.", "Compute a composite Knowledge Currency Posture Score (KCPS) from weighted control metrics and include it in the package summary, with a breakdown showing each control's contribution and any metrics below threshold." ], "knowledge_engineer": { "summary": "The evidence aggregator is a read-only compilation pipeline. Design it to pull from stable governance APIs (not direct database queries) so that the evidence package can be generated without knowledge engineering staff involvement during audits.", "actions": [ "Implement the evidence aggregator as a scheduled pipeline with on-demand trigger support, reading from the governance APIs of KC-01 through KC-07 control outputs.", "Ensure the package generation process is fully automated and does not require manual data collection steps from any team.", "Implement package signature generation using the organization's governance signing key and include signature verification instructions in the package metadata." ], "failure_signals": [ "Package generation requires manual data collection steps from any team.", "Evidence aggregator fails to access any KC control's governance API without human intervention.", "Package signature verification fails due to key management issues." ] }, "data_scientist": { "summary": "The KCPS composite score and per-control metric trends are valuable model governance signals \u2014 correlate them with model performance metrics to identify whether knowledge currency degradation precedes measurable output quality decline.", "actions": [ "Integrate KCPS trend data with model evaluation dashboards so that knowledge currency posture changes are visible alongside accuracy and helpfulness metrics.", "Run retrospective analyses after knowledge incidents to measure the impact of the currency gap on output quality metrics during the incident window." ], "failure_signals": [ "KCPS trends not correlated with model performance metrics.", "No retrospective analysis conducted after knowledge incidents to quantify output quality impact." ] }, "it_operations": { "summary": "The evidence aggregator pipeline requires the same operational oversight as production services \u2014 missed package generations are governance failures with potential regulatory consequences.", "actions": [ "Add the evidence aggregator scheduled job to the production monitoring dashboard with alerting on missed runs.", "Implement access controls on the governance artifact repository so that package retrieval by auditors is possible without requiring knowledge engineering team involvement.", "Test the on-demand package generation API quarterly and document response time against defined SLA." ], "failure_signals": [ "Evidence aggregator missed a scheduled run without alert.", "Auditor access to governance artifact repository requires knowledge engineering team involvement.", "On-demand API response time exceeds defined SLA in quarterly test." ] }, "grc_auditor": { "summary": "The KC Evidence Package is your primary audit artifact. Validate both the package content completeness and the package integrity \u2014 a signed, versioned package generated automatically from production systems is more defensible than manually assembled evidence.", "actions": [ "Request the most recent KC Evidence Package and verify the package signature against the governance signing key.", "Review each section of the package against the required KC-01 through KC-07 artifact list and flag any missing or below-threshold items.", "Verify the package was generated by the automated aggregator (not manually assembled) by checking generation metadata and comparing package content to source system spot-checks." ], "metrics": [ "Package completeness: all required KC-01 through KC-07 artifacts present \u2014 target 100%.", "Package generation currency: most recent package generated within 30 days \u2014 target 100%.", "KCPS composite score: all individual control metrics at or above threshold \u2014 target \u226590% aggregate score.", "Package integrity: signature verification passes for all packages in governance repository \u2014 target 100%." ], "failure_signals": [ "Any required KC artifact section missing from the evidence package.", "Package older than 30 days at the time of audit request.", "KCPS composite score below 80% with no documented remediation plan.", "Package signature verification failure." ] }, "legal_counsel": { "summary": "The signed, versioned evidence package is the instrument through which the organization demonstrates regulatory compliance with knowledge governance obligations. Ensure retention policy and access controls satisfy applicable regulatory evidence requirements.", "actions": [ "Confirm the governance artifact repository's retention policy satisfies the longest applicable regulatory record-keeping requirement (minimum 7 years for EU AI Act high-risk systems where applicable).", "Review the evidence package format and confirm it satisfies the documentation-keeping obligation of EU AI Act Article 18 \u2014 records retained at the disposal of competent authorities \u2014 alongside the technical documentation drawn up under Article 11.", "Establish a documented procedure for providing evidence packages to regulators on request, including authorization levels and response time commitments." ], "failure_signals": [ "Governance artifact repository retention period shorter than applicable regulatory requirement.", "No documented regulatory disclosure procedure for evidence packages.", "Package format does not satisfy the Art. 18 documentation-keeping obligation (or the Art. 11 technical documentation requirements) for applicable jurisdictions." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Compliance evidence for knowledge currency is typically assembled manually from disparate systems during audit preparation, creating significant lag and inconsistency risk. Automated compilation into a signed, versioned package with a composite posture score is the defined target state, achievable once KC-01 through KC-07 controls are instrumented." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise", "multi-tenant" ], "implementers": [ "Knowledge Management Office", "GRC Team", "Platform Engineering" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a79.3", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a79.3 requires management reviews of AI systems to be supported by compiled evidence of system performance, data quality, and compliance status. The KC Evidence Package is the purpose-built artifact for satisfying this management review input requirement for the knowledge currency dimension, providing a compiled, signed, and versioned evidence set that supports both internal reviews and external certification audits.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 18", "fit": "direct", "rationale": "EU AI Act Article 18 requires providers of high-risk AI systems to keep the technical documentation, quality-management documentation and other records at the disposal of national competent authorities for ten years. The KC Evidence Package provides the retained, signed record of knowledge currency governance that this documentation-keeping obligation demands (the documentation itself is drawn up under Article 11).", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_30401", "requirement_id": "\u00a79.3", "fit": "direct", "rationale": "ISO 30401:2018 \u00a79.3 requires management reviews to be supported by evidence of knowledge system performance, including the effectiveness of knowledge currency controls. The KC Evidence Package with its KCPS composite score and per-control metric breakdown directly provides the structured evidence input that ISO 30401 management reviews require.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 13", "fit": "direct", "rationale": "DAMA-DMBOK 2nd edition Chapter 13 (Data Quality) calls for regular reporting artifacts that summarize quality posture across dimensions so management and governance bodies can assess and direct improvement. The KC Evidence Package operationalizes this reporting practice for the knowledge currency dimension.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "w3c_prov", "requirement_id": "PROV-DM \u00a75.4 \u2014 Bundles", "fit": "partial", "rationale": "W3C PROV-DM \u00a75.4 defines a bundle as a named set of provenance descriptions whose provenance can itself be described and attributed. The KC Evidence Package is structurally a PROV bundle \u2014 a named, signed collection of assertions about knowledge currency governance, attributed to the organization's signing key \u2014 enabling inclusion in broader AI provenance graphs.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_azure_ai", "requirement_id": "Azure AI Compliance \u2014 Evidence Collection for Audits", "fit": "adjacent", "rationale": "Microsoft Azure AI's compliance framework supports automated evidence collection from Azure AI Search and grounding services for audit purposes. Organizations operating KC controls on Azure infrastructure can leverage Azure Policy compliance reports and Azure Monitor logs as source inputs to the evidence aggregator, reducing custom tooling burden for the compilation pipeline.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KC-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A signed, versioned Knowledge Currency Evidence Package must exist in the governance artifact repository generated within the past 30 days, containing required artifact sections from each of KC-01 through KC-07, a computable Knowledge Currency Posture Score (KCPS) at or above 90%, and a valid Ed25519 or equivalent signature verifiable against the organization's published governance signing key.", "evidence_required": [ "KC Evidence Package artifact from the governance repository with package_id, generation_timestamp, and package_signature, generated within the past 30 days", "signature verification result confirming the package signature matches the organization's current governance signing key and the package content has not been modified post-signature", "evidence_aggregator pipeline execution log confirming the package was generated automatically from governance APIs (not manually assembled) with source system API response codes for each KC control section", "KCPS composite score report with per-control metric breakdown showing individual control contributions and any metrics below threshold with remediation status", "governance_artifact_repository retention policy document confirming retention period meets the longest applicable regulatory record-keeping requirement for the organization's deployment jurisdictions" ], "machine_tests": [ "Trigger on-demand package generation via the evidence aggregator API \u2192 assert HTTP 200, package_id returned, package appears in governance repository within defined SLA, and package contains all required KC-01 through KC-07 artifact sections", "Verify the package signature using the organization's published governance signing key \u2192 assert signature is valid and package content hash matches the signed payload", "Modify a single byte of a retrieved evidence package and re-run signature verification \u2192 assert verification fails, confirming tamper-evidence of the package", "Query the evidence aggregator for its last 30 scheduled runs \u2192 assert all scheduled runs completed successfully and no runs were skipped without a recorded alert" ], "human_review": [ "Review the KCPS composite score methodology and confirm the weighting of individual control metrics reflects the relative governance importance of each KC control rather than an arbitrary equal-weight formula", "Assess whether the evidence package satisfies the documentation-keeping obligation under EU AI Act Article 18, complementing the technical documentation drawn up under Article 11, and identify any gaps a regulator would flag.", "Evaluate the governance artifact repository access control configuration to confirm auditors and regulators can retrieve packages on demand without requiring knowledge engineering team involvement, while write access is restricted to the automated evidence aggregator" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Manually assembling the evidence package from spreadsheets, email threads, and ad-hoc system exports at audit time rather than maintaining an automated, continuously updated compilation pipeline", "Generating the evidence package without a cryptographic signature, making it impossible for external auditors to verify the package has not been modified between generation and presentation", "Retaining evidence packages for a period shorter than the longest applicable regulatory record-keeping requirement, creating gaps in the organization's ability to respond to retrospective regulatory inquiries", "Computing the KCPS composite score without a documented weighting methodology, making the score non-reproducible and potentially manipulable by adjusting weights after seeing metric outcomes", "Requiring knowledge engineering staff to manually intervene in package generation or retrieval, creating operational friction that delays audit responses and signals governance immaturity to regulators" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KC" }, { "id": "KM-01", "layer": "KM", "plane": "lifecycle", "name": "Knowledge Asset Lifecycle Governance", "plain": "Every knowledge asset in the enterprise must have a documented lifecycle policy defining its creation, review, approval, publication, retirement, and deletion stages, with assigned ownership at each stage to ensure knowledge remains accurate and fit for AI consumption.", "threat": { "tags": [ "stale-knowledge", "orphaned-asset", "undocumented-ownership", "governance-gap" ], "desc": "Without formal lifecycle governance, knowledge assets accumulate without review, becoming stale or contradictory. AI systems consuming unreviewed knowledge produce outputs grounded in outdated or incorrect information. Orphaned assets with no assigned owner are never retired, and newly ingested assets may conflict with existing entries without any reconciliation process." }, "standard": [ { "id": "iso_30401", "section": "Clause 8", "title": "Operation" }, { "id": "dama_dmbok", "section": "Ch. 3", "title": "Data Governance lifecycle framework" }, { "id": "iso_42001", "section": "A.6.2.6", "title": "AI system operation and monitoring" }, { "id": "itil_4", "section": "\u00a75.1.4", "title": "Knowledge management practice" } ], "sources": [ { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements Clause 8 requirements informing the apeiris://knowledge/controls/KM-01 Knowledge Asset Lifecycle Governance control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 3 \u2014 Data Governance requirements informing the apeiris://knowledge/controls/KM-01 Knowledge Asset Lifecycle Governance control.", "reviewed_on": "2026-07-02" }, { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 A.6.2.6 requirements informing the apeiris://knowledge/controls/KM-01 Knowledge Asset Lifecycle Governance control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 10(3) requirements informing the apeiris://knowledge/controls/KM-01 Knowledge Asset Lifecycle Governance control.", "reviewed_on": "2026-07-02" }, { "id": "itil_4", "title": "ITIL 4", "authority": "PeopleCert / Axelos", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "4", "published_on": "2019-02-28", "retrieved_on": "2026-07-02", "canonical_url": "https://www.axelos.com/certifications/itil-service-management/itil-4-foundation", "license": "proprietary", "status": "current", "flagship": false, "source_id": "itil_4", "relationship": "informative_reference", "rationale": "Establishes ITIL 4 \u00a75.1.4 Knowledge Management Practice requirements informing the apeiris://knowledge/controls/KM-01 Knowledge Asset Lifecycle Governance control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define a five-stage lifecycle (Draft \u2192 Review \u2192 Active \u2192 Deprecated \u2192 Archived) for each knowledge asset class. Assign a named owner and review cadence at provisioning time. Gate transitions between stages with approval workflows. Publish lifecycle state as a metadata field consumed by retrieval systems to filter out non-Active assets by default.", "steps": [ "Define the canonical lifecycle states and transition rules in a knowledge governance policy document and publish it as an internal standard.", "Instrument the knowledge base platform to store and expose lifecycle_state, owner, review_due_date, and last_reviewed_by as indexed metadata fields on every asset.", "Configure retrieval pipelines to exclude assets not in Active state unless an explicit override flag is set by an authorized role.", "Implement automated reminders that notify asset owners when review_due_date is within 30 days and escalate to domain leads if unacknowledged for 7 days.", "Run a quarterly lifecycle audit report that lists all assets by state, flags overdue reviews, and identifies assets without an active owner." ], "knowledge_engineer": { "summary": "Lifecycle governance is the foundation of a trustworthy knowledge base. Every asset must have a state, an owner, and a review date before it enters the Active pool.", "actions": [ "Define asset classes (documents, chunks, structured records, embeddings) and map lifecycle states to each class.", "Build or configure lifecycle state transitions in the knowledge management platform with mandatory approval steps.", "Validate that retrieval queries filter by lifecycle_state=Active by default." ], "failure_signals": [ "Assets with no owner assigned found in Active state.", "Lifecycle state field missing on more than 2% of assets.", "Review overdue rate exceeds 10% of the Active corpus." ] }, "data_scientist": { "summary": "Lifecycle states are corpus filters: models and evaluations should consume only assets in active lifecycle states, and retired content must leave the embedding space, not just the catalog.", "actions": [ "Filter corpus builds on lifecycle state so deprecated or retired assets are excluded.", "Verify retirement propagates to indices and embeddings, not just the asset catalog.", "Use lifecycle metadata to explain corpus composition changes in model behavior analyses." ], "failure_signals": [ "Retired assets remain retrievable because embeddings were never rebuilt.", "Corpus builds ignore lifecycle state and include deprecated content." ] }, "it_operations": { "summary": "Operational teams are responsible for enforcing lifecycle transitions at the infrastructure level and ensuring the platform exposes metadata to downstream systems.", "actions": [ "Deploy platform-level hooks that prevent ingestion of assets without required lifecycle metadata fields.", "Schedule automated jobs to sweep for assets past review_due_date and update state to Flagged-for-Review.", "Provide a dashboard showing lifecycle distribution across all knowledge stores." ], "failure_signals": [ "Assets ingested without lifecycle metadata in the last 30 days.", "Automated sweep jobs failing silently.", "Dashboard staleness exceeding 24 hours." ] }, "grc_auditor": { "summary": "The lifecycle governance policy and its enforcement records are the primary evidence that knowledge consumed by AI systems is actively managed and not stale.", "actions": [ "Request the quarterly lifecycle audit report and verify it covers 100% of knowledge stores.", "Sample 15% of Active assets and verify each has a current owner and non-overdue review date.", "Confirm that retrieval pipeline configuration excludes non-Active assets and test with a known Deprecated asset." ], "metrics": [ "Asset ownership coverage: target 100% of Active assets.", "Review overdue rate: target <5%.", "Lifecycle audit report completion: target quarterly with no gaps." ], "failure_signals": [ "Ownership coverage below 95% in two consecutive quarters.", "Overdue review rate exceeding 10% at time of audit.", "Lifecycle audit report not produced in the last 90 days." ] }, "legal_counsel": { "summary": "Lifecycle governance establishes the documented basis for demonstrating that AI systems are not consuming outdated or unauthorized knowledge, which is relevant for regulatory obligations and liability management.", "actions": [ "Review the lifecycle policy to ensure it accounts for legal hold scenarios where normal deletion cycles must be suspended.", "Confirm that knowledge assets subject to regulatory update requirements have review cadences aligned with the regulatory update cycle.", "Verify that the approval workflow for lifecycle transitions creates an auditable record suitable for regulatory examination." ], "failure_signals": [ "Lifecycle policy does not address legal hold scenarios.", "Assets subject to regulatory updates lack mandatory review triggers.", "Approval workflow records not retained for the required period." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises manage knowledge assets informally; lifecycle states and owner assignments are typically absent from RAG knowledge bases." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Knowledge Engineering Team", "Data Governance Office", "IT Operations" ], "frameworks": [ { "framework": "iso_30401", "requirement_id": "Clause 8", "fit": "direct", "rationale": "ISO 30401:2018 Clause 8 (Operation) requires organizations to plan, implement and control the processes needed for knowledge management, and \u00a74.4.2 frames knowledge development from acquisition through handling of outdated knowledge. The lifecycle stage model operationalizes these requirements at the asset level.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 3 \u2014 Data Governance", "fit": "direct", "rationale": "DAMA DMBOK 2 Chapter 3 establishes data governance lifecycle frameworks that apply directly to knowledge assets as a subclass of data. The ownership, stewardship, and review cadence requirements mirror DAMA's data steward accountability model.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "iso_42001", "requirement_id": "A.6.2.6", "fit": "direct", "rationale": "ISO/IEC 42001:2023 Annex A control A.6.2.6 requires AI system operation to be managed under defined operational controls across the system life cycle. Lifecycle governance of the knowledge assets an AI system consumes operationalizes this requirement at the asset level.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10(3)", "fit": "partial", "rationale": "EU AI Act Article 10(3) requires that training, validation, and test data for high-risk AI systems be subject to data governance practices. Knowledge assets feeding retrieval-augmented generation systems are functionally analogous and should be held to equivalent governance standards.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "itil_4", "requirement_id": "\u00a75.1.4 Knowledge Management Practice", "fit": "direct", "rationale": "ITIL 4 Knowledge Management practice defines knowledge articles as managed service assets with explicit lifecycle stages. The governance pattern described here extends ITIL's approach to AI-consumed knowledge stores with ownership, review cadence, and automated state enforcement.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KM-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every knowledge asset in the Active retrieval pool must have a non-null lifecycle_state field set to 'Active', a named owner with a valid organizational identity, and a review_due_date that has not elapsed; and retrieval pipeline configuration must demonstrably exclude assets in any non-Active lifecycle state from query results without requiring an explicit override flag.", "evidence_required": [ "lifecycle_audit_report (quarterly) listing all knowledge assets by lifecycle_state with owner identities, review_due_dates, and overdue-review count, covering 100% of knowledge stores", "retrieval_pipeline_configuration export showing the lifecycle_state=Active filter applied as a mandatory retrieval predicate without override capability for standard consumer roles", "asset_metadata_sample (15% random sample of Active assets) showing lifecycle_state, owner, review_due_date, and last_reviewed_by fields populated for each sampled asset", "automated_review_reminder_log showing escalation events for overdue reviews including asset_id, owner_notified, days_overdue, and escalation_target for assets within 30 days of review_due_date", "governance_policy_document defining the five-stage lifecycle (Draft\u2192Review\u2192Active\u2192Deprecated\u2192Archived), transition rules, owner assignment requirements, and review cadence standards" ], "machine_tests": [ "Query the retrieval API with a known asset in Deprecated lifecycle_state \u2192 assert the asset is NOT returned in results without explicit override authorization from a privileged role", "Ingest a test asset without the owner field populated \u2192 assert the ingestion pipeline rejects the asset with error=missing_required_lifecycle_field before any data is committed", "Set a test asset's review_due_date to today-1day in the test environment \u2192 assert the automated sweep job transitions the asset to Flagged-for-Review state and sends a notification to the registered owner", "Run the lifecycle completeness API endpoint \u2192 assert fewer than 2% of Active assets have a missing or null lifecycle_state field" ], "human_review": [ "Review a 15% random sample of Active assets and verify each has a named owner with a current organizational identity (not a departed employee or decommissioned role), a non-overdue review_due_date, and a last_reviewed_by record showing the review was substantive rather than auto-acknowledged", "Assess the lifecycle approval workflow records to confirm that transitions from Review to Active are documented with approver identity and approval timestamp, constituting an auditable record suitable for regulatory examination", "Evaluate the lifecycle policy document for completeness on legal hold scenarios, confirming that normal deletion or archival cycles are explicitly suspended for assets under legal hold and that the hold mechanism is technically enforced" ], "blocking_effect": "blocks-deployment", "normative_status": "certification-standard", "anti_patterns": [ "Assigning ownership of knowledge assets to shared functional mailboxes or team accounts rather than named individuals, making it impossible to identify a responsible accountable party when review deadlines are missed or governance failures occur", "Implementing lifecycle state as a non-indexed metadata annotation rather than an enforced retrieval predicate, allowing non-Active assets to be returned by queries that do not explicitly filter on the field", "Setting review cadences uniformly across all asset types regardless of content volatility, applying the same annual review cycle to rapidly-changing regulatory content as to archivally stable reference material", "Treating lifecycle governance as a documentation exercise without technical enforcement, allowing assets to remain in Active state indefinitely past their review_due_date with no automated escalation or state transition", "Failing to account for asset owner offboarding in the lifecycle policy, leaving orphaned Active assets with no responsible owner who receives review reminders or escalation notices" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KM" }, { "id": "KM-02", "layer": "KM", "plane": "control", "name": "Knowledge Base Segmentation and Access Control", "plain": "Knowledge assets must be organized into named segments reflecting sensitivity, domain, and authorized consumer populations, with access control policies enforced at the retrieval layer to ensure AI agents and human users can only access segments for which they hold explicit authorization.", "threat": { "tags": [ "unauthorized-knowledge-access", "privilege-escalation", "cross-tenant-leakage", "data-exfiltration" ], "desc": "Monolithic, undifferentiated knowledge bases expose all content to any consumer. An AI agent authorized for customer service may inadvertently retrieve internal strategy documents or PII-laden records if segments are not isolated. In multi-tenant deployments, retrieval queries that lack tenant-scoped filters can surface one tenant's knowledge to another, creating confidentiality breaches and regulatory violations." }, "standard": [ { "id": "iso_27002", "section": "\u00a75.15", "title": "Access control policy for information assets" }, { "id": "iso_30401", "section": "\u00a74.4.3", "title": "Knowledge conveyance and transformation \u2014 knowledge sharing" }, { "id": "aws_bedrock_kb", "section": "Knowledge Base Data Source Permissions", "title": "IAM-based knowledge base access control" }, { "id": "eu_ai_act", "section": "Art. 15", "title": "Accuracy, robustness and cybersecurity" } ], "sources": [ { "id": "microsoft_azure_ai_search_2024", "title": "Microsoft Azure AI Search & Grounding", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/azure/search/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_azure_ai_search_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Azure AI Search & Grounding requirements informing the apeiris://knowledge/controls/KM-02 Knowledge Base Segmentation and Access Control control.", "reviewed_on": "2026-07-01" }, { "id": "aws_bedrock_knowledge_bases_2024", "title": "Amazon Bedrock Knowledge Bases", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_knowledge_bases_2024", "relationship": "informative_reference", "rationale": "Establishes Amazon Bedrock Knowledge Bases requirements informing the apeiris://knowledge/controls/KM-02 Knowledge Base Segmentation and Access Control control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define a segment taxonomy (e.g., Public, Internal, Confidential, Restricted) mapped to sensitivity labels. Assign every knowledge asset to exactly one segment at ingestion time. Enforce segment-level access control at the vector store and retrieval API layer using attribute-based access control (ABAC) policies. Bind AI agent identities to an authorized segment list via their capability manifest.", "steps": [ "Define the knowledge segment taxonomy and publish it as part of the information classification policy, aligning segment labels with existing data classification labels where possible.", "Instrument the ingestion pipeline to require a segment_label field on every asset and reject unlabeled content.", "Configure the vector store and retrieval API to enforce segment filters based on the authenticated caller's authorized segment list using ABAC policies.", "Bind each AI agent's capability manifest to its authorized knowledge segments and validate this binding at agent deployment time via the identity registry.", "Run weekly access review reports that list all agents and users by segment authorization and flag any with access to more than two sensitivity levels above their minimum required." ], "knowledge_engineer": { "summary": "Segmentation is enforced at ingestion and retrieval time. Every asset must carry a segment label, and every query context must carry a caller identity bound to an authorized segment list.", "actions": [ "Design the segment taxonomy in collaboration with data classification and legal teams.", "Implement segment filter injection at the retrieval layer so callers cannot override their own segment restrictions.", "Validate that embedding generation does not cross segment boundaries during batch embedding jobs." ], "failure_signals": [ "Assets ingested without segment_label in the last 30 days.", "Retrieval queries succeeding without a valid caller identity binding.", "Cross-segment retrieval results returned to a caller without elevated authorization." ] }, "data_scientist": { "summary": "Segmentation defines what each model context can see: evaluation and fine-tuning must respect segment boundaries, or quality work itself becomes an access-control violation.", "actions": [ "Run evaluations within segment boundaries using appropriately scoped service principals.", "Verify fine-tuning exports draw only from segments the training use is authorized for.", "Test that cross-segment leakage does not appear in retrieval results after index changes." ], "failure_signals": [ "An evaluation harness with over-broad credentials reads segments production cannot access, skewing results.", "A fine-tuning corpus includes content from a segment restricted to another tenant." ] }, "it_operations": { "summary": "Segment enforcement depends on correct IAM bindings at the vector store and retrieval API. Operations teams must maintain the ABAC policy rules and audit binding accuracy.", "actions": [ "Deploy ABAC policies on vector stores (e.g., Pinecone namespace isolation, OpenSearch document-level security, Azure AI Search security filters).", "Integrate segment enforcement with the organization's IAM system to inherit role changes automatically.", "Monitor retrieval API logs for cross-segment access attempts and alert on anomalies." ], "failure_signals": [ "ABAC policy misconfiguration discovered during quarterly review.", "IAM role changes not propagated to retrieval layer within SLA.", "Cross-segment access attempts not generating alerts." ] }, "grc_auditor": { "summary": "Access control over knowledge segments is a key control for demonstrating that AI systems do not process information beyond their authorized scope, supporting both information security and AI governance audit requirements.", "actions": [ "Request the segment taxonomy and verify it is aligned with the information classification policy.", "Test retrieval API access with credentials from each segment tier and verify that lower-tier callers cannot retrieve higher-tier assets.", "Review the quarterly access review report and confirm overprovisioned agents are remediated within SLA." ], "metrics": [ "Unlabeled asset rate: target 0%.", "Overprovisioned agent rate: target <2% of active agents.", "Cross-segment access test failure rate: target 0%." ], "failure_signals": [ "Unlabeled assets found in production knowledge base.", "Penetration test demonstrates cross-segment retrieval bypass.", "Access review overdue for more than one consecutive quarter." ] }, "legal_counsel": { "summary": "Knowledge segmentation provides the technical basis for demonstrating that AI systems handle regulated information categories (PII, privileged communications, trade secrets) only under appropriate access controls.", "actions": [ "Review segment definitions to ensure regulatory categories (PII, attorney-client privileged material, MNPI) are mapped to the Restricted segment at minimum.", "Confirm that AI agents processing Restricted segment knowledge have documented legal authority and data processing agreements in place.", "Verify that segment access logs are retained for the required period under applicable law." ], "failure_signals": [ "Regulated information categories not explicitly mapped to segment taxonomy.", "AI agents accessing Restricted segments without documented authority.", "Access logs not retained per applicable retention requirements." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most RAG deployments lack segment-level isolation; all knowledge is queryable by any consumer of the vector store." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "Knowledge Engineering Team", "IAM / Security Team", "IT Operations" ], "frameworks": [ { "framework": "iso_27002", "requirement_id": "\u00a75.15 \u2014 Access control", "fit": "direct", "rationale": "ISO/IEC 27002:2022 \u00a75.15 establishes requirements for access control policies over information assets. Knowledge segments are a class of information asset and must be governed by the same access control principles, including need-to-know and least privilege.", "normative_force": "voluntary-standard", "source_version": "2022", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 15", "fit": "partial", "rationale": "EU AI Act Article 15 requires high-risk AI systems to be resilient against attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities. Knowledge base segmentation and access control reduce that attack surface by ensuring AI agents can reach only the knowledge appropriate to their authorized function.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "aws_bedrock_kb", "requirement_id": "Knowledge Base Data Source Permissions", "fit": "direct", "rationale": "Amazon Bedrock Knowledge Bases enforces data source access through IAM policies and supports namespace-level isolation. This control maps to Bedrock's recommended pattern of binding knowledge base access to service role policies scoped to specific data sources.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_azure_ai", "requirement_id": "Azure AI Search Security Filters", "fit": "direct", "rationale": "Microsoft Azure AI Search supports document-level security trimming via security filters, enabling segment-based access control at the retrieval layer. This control aligns with Azure's recommended pattern for multi-tenant knowledge isolation.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "iso_30401", "requirement_id": "\u00a74.4.3", "fit": "direct", "rationale": "ISO 30401:2018 \u00a74.4.3 addresses knowledge conveyance and transformation, including knowledge sharing through defined channels. Governed sharing presupposes boundaries on who may access which knowledge; knowledge base segmentation is the technical implementation of those boundaries for AI-consumed stores.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KM-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every knowledge asset in production must carry a non-null segment_label field matching a defined entry in the segment taxonomy, and the retrieval API must enforce attribute-based access control such that a caller with authorization for segment tier N cannot retrieve assets assigned to any segment tier above N \u2014 confirmed by penetration testing and weekly access review.", "evidence_required": [ "segment_taxonomy definition document aligned with the organization's information classification policy, mapping segment labels (Public, Internal, Confidential, Restricted) to sensitivity classifications and authorized consumer populations", "ingestion_pipeline_audit_log for the past 30 days showing zero assets committed without a valid segment_label field, with any rejected ingestion attempts and their reasons recorded", "retrieval_access_control_test_report showing penetration test results for each segment boundary, with test credentials used, queries attempted, and results confirming no cross-segment retrieval bypass", "agent_capability_manifest_registry export listing all active AI agents with their authorized knowledge segments, confirming each agent's segment authorization is explicitly bound at deployment time", "weekly_access_review_report identifying all agents and users by segment authorization tier with any overprovisioned entities (access to more than two tiers above minimum required) flagged and remediation status" ], "machine_tests": [ "Submit a retrieval query with credentials bound only to the Internal segment authorization \u2192 assert zero assets from Confidential or Restricted segments are returned, even when the query text matches content in those segments", "Attempt to ingest a knowledge asset without providing a segment_label field \u2192 assert the ingestion pipeline returns HTTP 400 with error=missing_segment_label and the asset is not committed", "Submit a retrieval query without any authentication credentials \u2192 assert HTTP 401 response and no knowledge asset content is returned", "Promote an AI agent's segment authorization from Internal to Restricted in the capability manifest registry, then verify retrieval \u2192 assert the agent can now retrieve Restricted assets within one IAM propagation cycle SLA" ], "human_review": [ "Review the segment taxonomy and confirm that regulated information categories \u2014 including PII, attorney-client privileged communications, MNPI, and trade secrets \u2014 are explicitly mapped to the Restricted segment (or equivalent highest-sensitivity tier) with documented rationale", "Assess the weekly access review reports for the past quarter and evaluate whether overprovisioned entities are remediated within the defined SLA, and whether the remediation actions are logged with approver identity", "Examine AI agent capability manifests for all agents with Restricted segment access and verify each has documented legal authority (data processing agreement, authorized business purpose) and that the authorization was reviewed within the past review cycle" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Implementing segmentation as a naming convention or folder structure rather than as enforced ABAC policies at the retrieval API and vector store layers, allowing segment boundaries to be bypassed by a caller who knows the naming pattern", "Granting AI agents access to all knowledge segments by default on the assumption that the agent's prompt instructions will constrain what it retrieves, trusting prompt-level controls instead of retrieval-layer enforcement", "Using a single undifferentiated knowledge base for multi-tenant deployments where different tenants' knowledge must be isolated, relying on query filtering alone without namespace or index isolation between tenants", "Failing to propagate IAM role changes to the retrieval layer access control policies, creating windows where a deprovisioned user's identity retains effective knowledge access after offboarding", "Performing access reviews annually rather than weekly for segments containing Restricted or Confidential knowledge, allowing overprovisioned access to persist for months before detection" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KM" }, { "id": "KM-03", "layer": "KM", "plane": "data", "name": "Knowledge Versioning and Change History", "plain": "Every knowledge asset must be versioned such that prior states are immutably preserved and retrievable, enabling rollback to any prior version, attribution of changes to named actors, and forensic reconstruction of what knowledge was available at any point in time.", "threat": { "tags": [ "untracked-knowledge-mutation", "rollback-failure", "supply-chain-corruption", "audit-trail-gap" ], "desc": "Without versioning, changes to knowledge assets are irreversible and unattributed. A corrupted or adversarially modified knowledge asset cannot be detected or rolled back. When an AI system produces a harmful output, investigators cannot determine whether the output was caused by a knowledge change if no change history exists. Supply chain attacks that inject malicious content into a knowledge base leave no forensic trace." }, "standard": [ { "id": "iso_30401", "section": "\u00a74.4.2", "title": "Knowledge development \u2014 retaining current knowledge" }, { "id": "w3c_prov", "section": "PROV-DM \u00a72", "title": "Entity revision and derivation model" }, { "id": "dama_dmbok", "section": "Ch. 9", "title": "Document and content management versioning" }, { "id": "iso_42001", "section": "A.7.5", "title": "Data provenance" } ], "sources": [ { "id": "databricks_unity_catalog_2024", "title": "Databricks Unity Catalog (Knowledge Gov.)", "authority": "Databricks, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.databricks.com/en/data-governance/unity-catalog/index.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "databricks_unity_catalog_2024", "relationship": "informative_reference", "rationale": "Establishes Databricks Unity Catalog (Knowledge Gov.) requirements informing the apeiris://knowledge/controls/KM-03 Knowledge Versioning and Change History control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Implement append-only versioned storage for all knowledge assets. Assign a monotonically increasing version number and a content hash (SHA-256) to each version. Record the actor, timestamp, change_type (create/update/delete/rollback), and diff_summary for every transition. Expose a version history API that returns the full chain of versions for any asset. Configure retrieval pipelines to optionally pin to a specific version snapshot for reproducible evaluation.", "steps": [ "Select or build a versioned knowledge store (e.g., Delta Lake, DVC-tracked blob store, or a purpose-built knowledge platform with built-in versioning) that stores each version as an immutable record.", "Instrument the ingestion and update pipelines to compute a SHA-256 content hash at write time and store it alongside the version record.", "Record change metadata (actor, timestamp, change_type, diff_summary) as an immutable changelog entry for every version transition.", "Implement a rollback API that promotes a prior version to Active state and records the rollback as a new version entry rather than overwriting history.", "Configure automated integrity checks that recompute content hashes for Active assets on a scheduled basis and alert on hash mismatches." ], "knowledge_engineer": { "summary": "Versioning is an architectural property of the knowledge store, not a post-hoc feature. Immutable version chains with content hashes are the foundation of rollback and forensic capability.", "actions": [ "Design the versioned storage schema to be append-only and prohibit in-place mutation of any persisted version.", "Implement content hash computation as a mandatory step in the ingestion pipeline before any asset is committed.", "Expose version history and rollback endpoints in the knowledge management API." ], "failure_signals": [ "Version records missing content hash field.", "In-place mutation of versioned records detected in storage audit.", "Rollback operation overwrites prior version history rather than appending a rollback record." ] }, "data_scientist": { "summary": "Versioning enables reproducible experiments and evaluation runs. Pinning retrieval pipelines to a named knowledge snapshot ensures that evaluation results are comparable across runs.", "actions": [ "Use version snapshot IDs when running RAG evaluation harnesses to ensure retrieval is reproducible.", "Log the knowledge snapshot version alongside model evaluation metrics so that performance regressions can be attributed to knowledge changes versus model changes.", "Validate that rollback restores retrieval behavior to the expected baseline using a held-out evaluation set." ], "failure_signals": [ "Evaluation runs not logging knowledge snapshot version.", "Performance regression cannot be attributed to a specific knowledge change due to missing version history.", "Rollback does not restore retrieval behavior to expected baseline." ] }, "it_operations": { "summary": "Operations teams must ensure versioned storage is backed up, hash integrity checks run on schedule, and rollback tooling is tested regularly.", "actions": [ "Configure backup and recovery for the versioned knowledge store with RPO and RTO targets aligned to knowledge criticality tier.", "Schedule daily hash integrity sweeps across all Active assets and route alerts to the knowledge operations queue.", "Test rollback procedures quarterly and document results." ], "failure_signals": [ "Backup jobs failing silently for versioned knowledge store.", "Hash integrity sweep not run in the last 7 days.", "Rollback procedure last tested more than 90 days ago." ] }, "grc_auditor": { "summary": "Version history is the primary forensic artifact for demonstrating that knowledge changes are attributable, reversible, and auditable, and the basis for investigating AI output anomalies linked to knowledge mutations.", "actions": [ "Request version history for a sample of 10 assets and verify each has a complete, unbroken change chain with actor attribution.", "Test rollback capability by requesting a rollback of a test asset and verifying the rollback is recorded as a new version entry.", "Confirm that automated hash integrity checks run on schedule and review the last 30 days of results." ], "metrics": [ "Version history completeness: target 100% of Active assets have a version chain.", "Actor attribution rate: target 100% of version records have a named actor.", "Hash integrity check pass rate: target 100%." ], "failure_signals": [ "Assets found with no version history (no record of initial creation).", "Version records lacking actor attribution.", "Hash mismatch detected on any Active asset." ] }, "legal_counsel": { "summary": "Version history is the evidentiary backbone for knowledge disputes: proving what the system knew and served at a past moment depends on immutable, attributable change records.", "actions": [ "Confirm version records are immutable and attribute every change to an actor, supporting evidentiary use.", "Align version retention with litigation and regulatory look-back periods.", "Use version history to reconstruct served content when responding to complaints about past answers." ], "failure_signals": [ "The content served at the time of a disputed answer cannot be reconstructed.", "Change attribution is missing for a contested knowledge edit." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most vector stores and RAG platforms lack native versioning; this typically requires an overlay architecture using Delta Lake or similar append-only storage." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Knowledge Engineering Team", "Data Engineering Team", "IT Operations" ], "frameworks": [ { "framework": "w3c_prov", "requirement_id": "PROV-DM \u00a72 \u2014 Entity and Revision", "fit": "direct", "rationale": "W3C PROV-DM \u00a72 defines the entity-revision model that underpins traceable changes to data objects. Knowledge asset versions are PROV entities; each version transition is a PROV derivation. Implementing this control produces a PROV-conformant knowledge provenance graph.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 9 \u2014 Document and Content Management", "fit": "direct", "rationale": "DAMA DMBOK 2 Chapter 9 addresses document and content management including version control as a required capability for managing knowledge assets. The SHA-256 hash integrity pattern aligns with DAMA's content integrity requirements for managed records.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "iso_42001", "requirement_id": "A.7.5", "fit": "direct", "rationale": "ISO/IEC 42001:2023 Annex A control A.7.5 requires organizations to record the provenance of data used in AI systems over its life cycle. Immutable versioning with actor attribution implements provenance-preserving change control for knowledge assets consumed at inference time.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_30401", "requirement_id": "\u00a74.4.2", "fit": "direct", "rationale": "ISO 30401:2018 \u00a74.4.2 requires retaining current knowledge and handling outdated knowledge, which entails reviewing and updating knowledge assets in a controlled, traceable way. This control implements that requirement with cryptographic integrity verification and append-only change history.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "databricks_unity", "requirement_id": "Delta Lake time travel", "fit": "partial", "rationale": "Delta Lake time travel \u2014 the transaction-log-based versioning of the Delta Lake storage layer used on Databricks \u2014 provides immutable version history and rollback, directly enabling the version history and rollback requirements described in this control when the knowledge base is built on Databricks.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KM-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every knowledge asset must have an unbroken, immutable version chain from initial creation to current state, with each version record containing a SHA-256 content hash, named actor, timestamp, and change_type; and automated hash integrity checks must run at least daily on all Active assets with zero unresolved hash mismatches at any point in the audit period.", "evidence_required": [ "version_history_API response for a sample of 10 knowledge assets showing the complete unbroken chain from creation to current state, with version_number, content_hash (SHA-256), actor, timestamp, and change_type on every entry", "rollback_API test record showing a rollback operation appended as a new version entry rather than overwriting the prior version chain, with rollback actor identity and timestamp", "hash_integrity_check_log for the past 30 days showing daily sweep results for all Active assets, with any detected mismatches, their asset_ids, and resolution actions documented", "versioned_storage_audit confirming the storage backend enforces append-only writes (no in-place mutation of committed version records) and that backup and recovery procedures satisfy defined RPO/RTO targets", "knowledge_snapshot_version references in at least two RAG evaluation run logs, confirming evaluation pipeline pins to a specific knowledge version rather than querying the live corpus" ], "machine_tests": [ "Attempt to overwrite an existing version record in the versioned store by submitting a write to a committed version_id \u2192 assert the store rejects the operation with error=immutable_version_record", "Modify the byte content of an Active asset in the test environment, then trigger the hash integrity sweep \u2192 assert the sweep detects the mismatch, generates an alert, and marks the asset with integrity_status=compromised within one sweep cycle", "Submit a rollback request for a test asset to version N-2 \u2192 assert the rollback creates a new version record (not an overwrite), Active state moves to the restored content, and the version chain shows N, N-1, N-2, rollback-to-N-2 in sequence", "Query version history for a test asset with five known versions \u2192 assert all five versions are returned with complete metadata (content_hash, actor, timestamp, change_type) and the hashes are independently verifiable against the stored content" ], "human_review": [ "Review version history completeness for a random sample of 10 Active assets and confirm each has an unbroken chain back to an initial creation record \u2014 assets with no creation record (first version is an update) indicate the versioning system was not in place at ingestion time and the chain is incomplete", "Assess hash integrity check results for the past 30 days and evaluate the remediation process for any detected mismatches: each mismatch should trigger quarantine, root-cause investigation, and documentation of whether the mismatch was caused by infrastructure error, authorized update without version record, or unauthorized modification", "Evaluate whether the rollback procedure is included in the knowledge engineering team's regular testing cadence (at least quarterly) and whether test records document actual time-to-rollback against SLA" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Implementing versioning as a backup snapshot taken at fixed intervals (e.g., daily full backup) rather than as an append-only record of individual asset changes, creating version granularity gaps and preventing rollback to states between snapshot intervals", "Recording change metadata (actor, timestamp, change_type) in a mutable external log table rather than as immutable fields on each version record, allowing audit trail manipulation without affecting the version content itself", "Computing content hashes at the document level only, not at the chunk and embedding level, leaving granular knowledge mutations (adversarial injection into a single chunk) undetectable by integrity checks", "Running hash integrity checks only on a scheduled weekly or monthly basis rather than daily, creating windows of days or weeks during which a hash mismatch from supply chain corruption or unauthorized modification goes undetected", "Treating rollback as an in-place content restoration that overwrites the current version rather than appending a rollback event to the version chain, destroying the forensic record of the state that was rolled back from" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KM" }, { "id": "KM-04", "layer": "KM", "plane": "lifecycle", "name": "Knowledge Archival and Retention Policy", "plain": "Every knowledge asset class must have a defined retention period, archival trigger conditions, and deletion authorization workflow, with legal hold capabilities that can suspend normal retention schedules when required by litigation, investigation, or regulatory examination.", "threat": { "tags": [ "premature-deletion", "indefinite-retention", "legal-hold-failure", "regulatory-noncompliance" ], "desc": "Without a retention policy, knowledge assets accumulate indefinitely, increasing storage costs and expanding the attack surface. Conversely, premature deletion of assets subject to litigation holds can constitute spoliation, exposing the organization to legal sanctions. Regulatory bodies increasingly expect documented retention schedules for data used to train or inform AI systems." }, "standard": [ { "id": "dama_dmbok", "section": "Ch. 6", "title": "Data Storage and Operations \u2014 retention and archiving" }, { "id": "iso_27002", "section": "\u00a78.10", "title": "Information deletion and retention" }, { "id": "eu_ai_act", "section": "Art. 12(1)", "title": "Record-keeping for high-risk AI systems" } ], "sources": [ { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 6 \u2014 Data Storage and Operations requirements informing the apeiris://knowledge/controls/KM-04 Knowledge Archival and Retention Policy control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 12(1) \u2014 Record-keeping requirements informing the apeiris://knowledge/controls/KM-04 Knowledge Archival and Retention Policy control.", "reviewed_on": "2026-07-02" }, { "id": "iso_27002", "title": "ISO/IEC 27002:2022 \u2014 Information Security Controls", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "voluntary-standard", "version": "2022", "published_on": "2022-02-15", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/75652.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_27002", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 27002:2022 \u2014 Information Security Controls \u00a78.10 \u2014 Information Deletion requirements informing the apeiris://knowledge/controls/KM-04 Knowledge Archival and Retention Policy control.", "reviewed_on": "2026-07-02" }, { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a77.5 \u2014 Documented Information requirements informing the apeiris://knowledge/controls/KM-04 Knowledge Archival and Retention Policy control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define retention classes (e.g., Operational-90d, Regulatory-7yr, Permanent) for each knowledge asset class in consultation with legal and compliance. Automate retention schedule enforcement via the knowledge platform's lifecycle engine. Implement legal hold as an asset-level flag that overrides the retention schedule. Require a dual-authorization workflow for any deletion of assets in Regulatory or Permanent classes.", "steps": [ "Inventory all knowledge asset classes and classify each against the organization's records retention schedule, noting applicable regulatory requirements.", "Configure the knowledge management platform to enforce retention periods automatically, moving assets to Archived state at retention expiry and scheduling deletion review.", "Implement a legal hold flag on individual assets and at the segment level, ensuring hold flags propagate to all versions of an affected asset.", "Build a dual-authorization deletion workflow for Regulatory and Permanent class assets and log all deletion authorizations with approver identity and timestamp.", "Conduct an annual retention schedule review with legal and compliance to incorporate new regulatory requirements and adjust asset class mappings." ], "knowledge_engineer": { "summary": "Retention policy must be codified as machine-enforced rules, not manual processes. The knowledge platform must support retention class tagging, automated archival, and legal hold at the asset and segment level.", "actions": [ "Tag every asset with a retention_class field at ingestion time.", "Configure platform-level retention rules that trigger archival and deletion review based on retention_class and asset age.", "Implement legal hold propagation so that a hold on a parent document cascades to all derived chunks and embeddings." ], "failure_signals": [ "Assets missing retention_class field in production.", "Legal hold not propagating to derived chunks.", "Archival automation failing silently past retention expiry." ] }, "data_scientist": { "summary": "Archival policy determines what historical corpus states remain available: reproducing past model behavior and running longitudinal quality studies require archived snapshots to survive on schedule.", "actions": [ "Confirm archived corpus snapshots cover the periods needed for reproducing historical evaluations.", "Test restoring an archived snapshot into an analysis environment at least annually.", "Coordinate purge schedules with research needs so longitudinal baselines are not destroyed." ], "failure_signals": [ "A historical behavior investigation fails because the relevant corpus snapshot was purged.", "Archived snapshots cannot actually be restored when requested." ] }, "it_operations": { "summary": "Operations teams are responsible for executing retention schedules reliably and maintaining the legal hold registry.", "actions": [ "Deploy and monitor the automated archival jobs and alert on failures within 4 hours.", "Maintain a legal hold registry that maps hold identifiers to affected assets and segments.", "Perform quarterly reconciliation of the hold registry against active legal matters." ], "failure_signals": [ "Archival jobs not executing on schedule.", "Legal hold registry not reconciled in the last 90 days.", "Assets deleted while under active legal hold." ] }, "grc_auditor": { "summary": "The retention policy and its enforcement records are the primary artifacts for demonstrating that the organization manages knowledge assets in compliance with legal and regulatory obligations.", "actions": [ "Review the retention schedule and verify it covers all knowledge asset classes in scope.", "Sample 10 assets in each retention class and verify their retention_class tag matches the schedule.", "Confirm that at least one legal hold test has been conducted in the last 12 months and review the test results." ], "metrics": [ "Retention class coverage: target 100% of asset classes mapped.", "Legal hold test frequency: target annual at minimum.", "Deletion authorization completeness: target 100% of Regulatory/Permanent class deletions have dual authorization records." ], "failure_signals": [ "Asset class not mapped in the retention schedule.", "Legal hold not tested in the last 12 months.", "Deletion authorization records missing for Regulatory class assets." ] }, "legal_counsel": { "summary": "Knowledge retention policy is a direct legal obligation under multiple regulatory regimes. Legal counsel must define retention requirements and maintain oversight of legal hold lifecycle.", "actions": [ "Define retention periods for each knowledge asset class based on applicable law, regulation, and contract requirements.", "Establish a legal hold policy that defines triggers (litigation, investigation, regulatory inquiry) and the process for issuing and releasing holds.", "Review the retention policy annually and update it when new regulatory requirements take effect." ], "failure_signals": [ "Retention periods not reviewed in the last 12 months.", "Legal hold policy does not cover AI knowledge assets specifically.", "New regulatory requirements not reflected in the retention schedule within 90 days of effective date." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Knowledge base retention is rarely addressed in enterprise records retention schedules; most policies were written before RAG architectures became common." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Knowledge Engineering Team", "Legal / Compliance", "IT Operations" ], "frameworks": [ { "framework": "dama_dmbok", "requirement_id": "Ch. 6 \u2014 Data Storage and Operations", "fit": "direct", "rationale": "DAMA-DMBOK 2nd edition Chapter 6 (Data Storage and Operations) addresses data retention, archival and purge as core storage management capabilities. The retention class taxonomy and archival automation described in this control directly implement these recommended retention governance practices.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 12(1) \u2014 Record-keeping", "fit": "direct", "rationale": "EU AI Act Article 12(1) requires providers of high-risk AI systems to ensure logging and record-keeping sufficient to enable reconstruction of the system's functioning. Retaining versioned knowledge assets for the required period is necessary to satisfy this reconstruction requirement.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27002", "requirement_id": "\u00a78.10 \u2014 Information Deletion", "fit": "direct", "rationale": "ISO/IEC 27002:2022 \u00a78.10 requires organizations to delete information when it is no longer required while respecting legal retention obligations. This control operationalizes both the deletion and the legal hold exception requirements for knowledge assets.", "normative_force": "voluntary-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "\u00a77.5 \u2014 Documented Information", "fit": "partial", "rationale": "ISO/IEC 42001:2023 \u00a77.5 requires AI management systems to retain documented information as evidence of conformity. Knowledge assets that inform AI outputs are a form of documented information subject to this retention requirement, extending the standard's scope to runtime knowledge stores.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KM-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every knowledge asset class must be tagged with a valid retention_class at ingestion time, and the knowledge platform must enforce automated archival and deletion-review workflows that honor retention schedules and suspend deletion when a legal hold is active. The control passes when all asset classes appear in the retention schedule, no assets exceed their retention expiry without a recorded archival action, and legal hold flags propagate to all derived chunks and embeddings.", "evidence_required": [ "retention_schedule_document listing all knowledge asset classes with retention_class codes, retention periods, regulatory basis, and effective dates", "asset_retention_class_audit_report confirming 100% of production knowledge assets carry a valid retention_class tag with no assets missing classification", "archival_job_execution_log showing each automated archival action with asset_id, retention_class, retention_expiry_date, archived_at timestamp, and job_status", "legal_hold_registry mapping hold_id to affected asset_ids, segment_ids, and derived_chunk_ids with hold_issued_at, issuing_authority, and current hold_status", "dual_authorization_deletion_record for each Regulatory or Permanent class deletion showing authorizer_1_id, authorizer_2_id, authorized_at, and deletion_rationale" ], "machine_tests": [ "Submit an ingestion request for a knowledge asset without a retention_class field \u2192 assert the platform rejects the request with error_code=missing_retention_class and no asset is written", "Set a test asset's retention_class to Operational-90d and created_at to 91 days ago \u2192 assert the platform has moved the asset to Archived state or created a deletion_review_task within the retention enforcement window", "Place a legal hold on a parent document via the hold API \u2192 assert within 60 seconds the hold propagates to all derived chunk IDs and embedding records in the same segment", "Attempt to delete a Regulatory-class asset with a single authorization token \u2192 assert the platform rejects the request with error_code=dual_authorization_required and no deletion occurs" ], "human_review": [ "Review the retention schedule for completeness, verifying that all active knowledge asset classes are mapped and that each retention period is grounded in identified legal, regulatory, or contractual obligations", "Inspect the legal hold policy and confirm it explicitly covers AI knowledge assets including vector embeddings and derived chunks, not only source documents", "Sample 10 Regulatory or Permanent class asset deletion records and verify each shows two distinct authorizers with separate timestamps and a documented rationale" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Applying a single general retention class to all knowledge asset classes instead of a tiered schedule with class-specific periods grounded in regulatory requirements", "Implementing legal hold as a metadata flag only on source documents without propagating the hold to derived chunks and vector embeddings", "Relying on manual archival processes rather than platform-enforced lifecycle rules, allowing assets to exceed retention expiry without action", "Allowing single-approver deletion of Regulatory or Permanent class assets without enforcing a dual-authorization workflow in the platform", "Updating the retention schedule only during annual review cycles rather than incorporating new regulatory requirements within 90 days of their effective date" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KM" }, { "id": "KM-05", "layer": "KM", "plane": "data", "name": "Knowledge-to-Output Lineage Tracking", "plain": "Every AI-generated output that draws on retrieved knowledge must be traceable back to the specific knowledge chunks, asset versions, and retrieval queries that informed it, creating an auditable lineage graph from output to source that enables incident investigation, hallucination diagnosis, and regulatory evidence production.", "threat": { "tags": [ "unattributed-ai-output", "hallucination-opacity", "lineage-gap", "evidence-destruction" ], "desc": "Without output-to-knowledge lineage, it is impossible to determine whether an AI output was grounded in authoritative knowledge or hallucinated. When an AI system produces a harmful or incorrect output, the absence of retrieval lineage prevents investigators from determining whether the cause was a knowledge error, a retrieval failure, or a model-level hallucination. Regulators requiring AI system explainability cannot be satisfied without retrievable lineage records." }, "standard": [ { "id": "w3c_prov", "section": "PROV-DM \u00a75.2", "title": "Derivations \u2014 wasDerivedFrom relations" }, { "id": "eu_ai_act", "section": "Art. 13(1)", "title": "Transparency and provision of information to deployers" }, { "id": "iso_42001", "section": "A.7.5", "title": "Data provenance" }, { "id": "dama_dmbok", "section": "Ch. 12", "title": "Metadata Management \u2014 data lineage" } ], "sources": [ { "id": "google_vertex_ai_rag_2024", "title": "Google Vertex AI RAG & Grounding", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/vertex-ai/docs/generative-ai/grounding/overview", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_vertex_ai_rag_2024", "relationship": "informative_reference", "rationale": "Establishes Google Vertex AI RAG & Grounding requirements informing the apeiris://knowledge/controls/KM-05 Knowledge-to-Output Lineage Tracking control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "At inference time, capture the retrieval context for each output: the query embedding hash, retrieved chunk IDs, chunk version hashes, segment labels, and retrieval scores. Store this context as a lineage record linked to the output_id. Build a lineage API that accepts an output_id and returns the full retrieval context including chunk content at the retrieved version. Retain lineage records for at least the duration of the underlying knowledge asset's retention period.", "steps": [ "Instrument the RAG pipeline to capture and persist a lineage record for every inference call, including: output_id, timestamp, model_id, query_embedding hash, retrieved_chunk_ids with version hashes, retrieval_scores, and segment_labels.", "Store lineage records in an append-only lineage store with a retention policy aligned to the longest retention class of the referenced knowledge assets.", "Build a lineage query API that accepts an output_id and returns the full retrieval context, resolving chunk IDs to content via the versioned knowledge store.", "Integrate lineage record production into the inference gateway so it cannot be bypassed by individual application teams.", "Test lineage completeness monthly by sampling 100 recent outputs and verifying each has a resolvable lineage record with all required fields populated." ], "knowledge_engineer": { "summary": "Lineage tracking requires coordination between the retrieval pipeline, the inference gateway, and the knowledge store's version API. Every chunk retrieval must produce a traceable record that can later be resolved to versioned content.", "actions": [ "Design the lineage record schema to include chunk_id, version_hash, retrieval_score, and segment_label for each retrieved chunk.", "Instrument the retrieval pipeline to emit lineage events to the lineage store as a side-effect of every inference call.", "Validate that the lineage API correctly resolves chunk IDs to versioned content and handles the case where a referenced version has been archived." ], "failure_signals": [ "Inference calls without associated lineage records found in the last 30 days.", "Lineage records missing chunk version_hash field.", "Lineage API unable to resolve chunk IDs for archived versions." ] }, "data_scientist": { "summary": "Lineage records are the primary diagnostic tool for hallucination analysis. When a model produces an incorrect output, lineage tells you whether the error was in the retrieved knowledge or in the model's synthesis.", "actions": [ "Use lineage records to classify output errors as retrieval failures (wrong chunks retrieved), knowledge errors (correct chunks but stale content), or synthesis failures (correct chunks but incorrect reasoning).", "Incorporate lineage-based analysis into the standard incident review workflow for AI output quality issues.", "Use aggregated lineage data to identify knowledge chunks with high retrieval frequency but low downstream answer quality, flagging them for review." ], "failure_signals": [ "Output error investigation cannot be completed due to missing lineage record.", "Lineage data not used in incident review process.", "High-retrieval, low-quality chunks not flagged via lineage analysis." ] }, "it_operations": { "summary": "Lineage capture is a runtime service: recording chunk-to-output links on every inference adds latency and storage that must be engineered for, or teams will quietly disable it.", "actions": [ "Provision the lineage store and write path for production inference volume with defined retention.", "Monitor lineage capture coverage \u2014 the share of responses with complete chunk-level records.", "Include lineage capture in load tests so it survives peak traffic instead of being shed." ], "failure_signals": [ "Lineage capture is sampled or disabled at peak load, leaving gaps exactly when scrutiny is likely.", "The lineage store fills and rotates away records inside the required retention window." ] }, "grc_auditor": { "summary": "Output-to-knowledge lineage is the evidential backbone for demonstrating AI system explainability and accountability to regulators and auditors examining how AI outputs are grounded.", "actions": [ "Sample 20 AI outputs from the last 90 days and verify each has a complete, resolvable lineage record.", "Confirm that lineage records are retained for the required period and cannot be deleted outside of the formal retention workflow.", "Request the monthly lineage completeness test results and verify they meet the 100% target." ], "metrics": [ "Lineage record completeness: target 100% of production inference calls.", "Lineage resolution rate: target 100% of lineage records resolvable to versioned content.", "Monthly completeness test pass rate: target 100%." ], "failure_signals": [ "Inference calls without lineage records found in production.", "Lineage records not resolvable due to deleted or unversioned chunks.", "Monthly completeness test not run in the last 60 days." ] }, "legal_counsel": { "summary": "Knowledge-to-output lineage is the technical foundation for satisfying transparency and explainability obligations under AI regulation, and for defending or refuting claims of harm caused by AI-generated outputs.", "actions": [ "Confirm that lineage retention periods are aligned with applicable statutes of limitations for claims arising from AI-generated outputs.", "Review the lineage record schema to ensure it captures sufficient information to reconstruct what knowledge the AI system had access to at the time of inference.", "Establish a legal hold workflow that can place lineage records for specific output IDs under hold when litigation is anticipated." ], "failure_signals": [ "Lineage retention period shorter than the applicable statute of limitations.", "Lineage records insufficient to reconstruct the knowledge state at inference time.", "No legal hold mechanism available for lineage records." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most production RAG systems do not persist retrieval context; lineage is an emerging requirement driven by EU AI Act and enterprise explainability demands." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "cloud-native" ], "implementers": [ "Knowledge Engineering Team", "AI Platform Engineering", "Data Engineering Team" ], "frameworks": [ { "framework": "w3c_prov", "requirement_id": "PROV-DM \u00a75.2 \u2014 Derivations", "fit": "direct", "rationale": "W3C PROV-DM \u00a75.2 defines the derivation component (wasDerivedFrom), the natural formalism for knowledge-to-output lineage: each inference is a PROV Activity, retrieved chunks are Entities used by that activity, and the AI output is derived from those entities. Implementing this control produces a PROV-conformant lineage graph.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 13(1) \u2014 Transparency", "fit": "direct", "rationale": "EU AI Act Article 13(1) requires high-risk AI systems to be designed to be sufficiently transparent for deployers to interpret outputs. Retrieval lineage records are a technical means of satisfying this transparency requirement by enabling post-hoc attribution of outputs to source knowledge.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "A.7.5", "fit": "direct", "rationale": "ISO/IEC 42001:2023 Annex A control A.7.5 requires organizations to record the provenance of data used in AI systems. Knowledge-to-output lineage is the runtime expression of this provenance requirement, extending traceability into inference-time retrieval contexts.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 12 \u2014 Metadata Management (data lineage)", "fit": "direct", "rationale": "DAMA-DMBOK 2nd edition Chapter 12 (Metadata Management) establishes data lineage as a core metadata capability. This control applies that lineage discipline to the AI inference context, where the data transformation is the retrieval and synthesis of knowledge chunks into an AI output.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "google_vertex_rag", "requirement_id": "Grounding and Citation APIs", "fit": "partial", "rationale": "Google Vertex AI RAG's grounding and citation APIs provide native support for associating outputs with retrieved source documents. This control extends that capability with version-level attribution and an independent lineage store for audit purposes beyond what the platform natively retains.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KM-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every AI inference call that retrieves from the knowledge base must produce a persisted lineage record containing the output_id, retrieved chunk IDs with version hashes, retrieval scores, and segment labels, stored in an independent lineage store. The control passes when 100% of sampled production inference calls have a resolvable lineage record and the lineage API can reconstruct the exact knowledge state used at any past inference within the retention window.", "evidence_required": [ "lineage_record_completeness_report showing percentage of inference calls with associated lineage records over the last 30 days, with output_id, timestamp, and record_status for each sampled call", "lineage_record_schema_validation_result confirming all lineage records contain output_id, model_id, query_embedding_hash, retrieved_chunk_ids[] each with version_hash and retrieval_score, segment_labels[], and collected_at", "lineage_api_resolution_test_log showing that sampled chunk IDs referenced in lineage records resolve to versioned content via the lineage query API without error", "lineage_retention_policy_document showing that lineage record retention period is aligned to the longest retention class of referenced knowledge assets and is not shorter than the applicable statute of limitations" ], "machine_tests": [ "Submit a RAG inference call to the production inference gateway \u2192 assert a lineage record is created within 5 seconds containing the output_id and at least one retrieved_chunk_id with version_hash and retrieval_score", "Query the lineage API with a known output_id from 30 days ago \u2192 assert it returns the full retrieval context with chunk content resolved from the versioned knowledge store and no resolution errors", "Bypass the lineage emission step for a synthetic test inference call \u2192 assert the monitoring system raises a lineage_gap alert within 15 minutes and creates an incident record", "Attempt to delete a knowledge chunk whose chunk_id appears in a lineage record within the active retention window \u2192 assert the system blocks deletion with error_code=lineage_reference_active" ], "human_review": [ "Sample 20 AI outputs from the last 90 days and verify each has a complete, resolvable lineage record by querying the lineage API and confirming the returned chunk content matches the expected knowledge state at inference time", "Review the lineage retention policy and confirm the retention period is no shorter than the applicable statute of limitations and the longest retention class of referenced knowledge assets", "Assess whether the lineage record schema captures sufficient information to reconstruct the AI system's knowledge state at inference time to satisfy regulatory explainability requirements" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Capturing retrieval context only in application logs rather than in an independent, queryable lineage store with version-level attribution and formal retention enforcement", "Associating lineage records with document titles or URLs rather than immutable chunk IDs and version hashes, making historical reconstruction impossible after content updates", "Retaining lineage records for a shorter period than the retention class of the knowledge assets they reference, creating gaps in retrospective investigation capability", "Relying on the inference platform's built-in logging rather than an independent lineage store that enforces retention policies and supports legal hold", "Not testing lineage completeness monthly, allowing silent gaps to accumulate when pipeline changes inadvertently bypass the lineage emission step" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KM" }, { "id": "KM-06", "layer": "KM", "plane": "control", "name": "Knowledge Impact Assessment Before Major Changes", "plain": "Before making major changes to the knowledge base \u2014 including bulk ingestion, large-scale deletion, segment restructuring, or embedding model replacement \u2014 the organization must conduct a documented impact assessment estimating the effect on AI system output quality, coverage, and risk posture.", "threat": { "tags": [ "unassessed-knowledge-change", "output-quality-degradation", "embedding-drift", "change-induced-hallucination" ], "desc": "Major changes to a knowledge base can alter AI output behavior in unpredictable ways. Replacing an embedding model voids existing vector representations, changing retrieval relevance across the entire corpus. Bulk deletion of apparently obsolete assets may remove content that anchors correct answers in high-stakes queries. Without a pre-change impact assessment, these risks are discovered only after harmful outputs are produced in production." }, "standard": [ { "id": "iso_30401", "section": "Clause 8", "title": "Operation \u2014 control of planned changes" }, { "id": "iso_42001", "section": "\u00a76.1.2", "title": "AI risk assessment for knowledge changes" }, { "id": "itil_4", "section": "\u00a75.2.4", "title": "Change enablement and impact assessment" }, { "id": "eu_ai_act", "section": "Art. 9(2)", "title": "Risk management for high-risk AI system modifications" } ], "sources": [ { "id": "databricks_unity_catalog_2024", "title": "Databricks Unity Catalog (Knowledge Gov.)", "authority": "Databricks, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.databricks.com/en/data-governance/unity-catalog/index.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "databricks_unity_catalog_2024", "relationship": "informative_reference", "rationale": "Establishes Databricks Unity Catalog (Knowledge Gov.) requirements informing the apeiris://knowledge/controls/KM-06 Knowledge Impact Assessment Before Major Changes control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define a change classification scheme (Minor, Significant, Major) based on scope thresholds (e.g., >5% of active corpus, any embedding model change, any segment restructuring). Require a documented Impact Assessment for all Major changes. The assessment must include: affected asset count, estimated retrieval coverage change, regression test results against a held-out evaluation set, risk classification, and approval by the Knowledge Governance lead and at least one AI system owner. Gate deployment of Major changes on assessment approval.", "steps": [ "Define change classification thresholds in the knowledge governance policy and publish them in the change management runbook.", "Create and maintain a held-out knowledge evaluation set (golden queries with expected answers) covering each knowledge segment, refreshed quarterly.", "Before each Major change, run the evaluation set against the pre-change and post-change knowledge state and document coverage and quality metric deltas.", "Route the completed impact assessment to the Knowledge Governance lead and affected AI system owners for approval and block deployment if not approved.", "After deployment, run a 48-hour post-change monitoring window comparing live output quality metrics against the pre-change baseline." ], "knowledge_engineer": { "summary": "Impact assessment is a gate in the change management process. Every Major change must be accompanied by a completed assessment document before deployment is authorized.", "actions": [ "Maintain the held-out evaluation set and update it when new knowledge segments are added.", "Run pre/post evaluation comparisons for every Major change and document the results in the assessment template.", "Instrument the deployment pipeline to block Major changes without an approved impact assessment." ], "failure_signals": [ "Evaluation set not refreshed in the last 90 days.", "Major change deployed without a completed impact assessment.", "Post-change monitoring window not executed after a Major change." ] }, "data_scientist": { "summary": "Data scientists own the evaluation methodology and are responsible for interpreting pre/post assessment results and signing off on acceptable regression levels.", "actions": [ "Design the golden query evaluation set to cover representative queries across all knowledge segments and difficulty levels.", "Define acceptable regression thresholds for each quality metric (retrieval precision, answer correctness, coverage) and document them in the assessment template.", "Review evaluation results for each Major change and provide a written assessment of whether the change is safe to deploy." ], "failure_signals": [ "Acceptable regression thresholds not defined for all metrics.", "Data scientist sign-off missing from impact assessment.", "Post-change quality metrics exceed defined regression thresholds." ] }, "it_operations": { "summary": "Operations teams enforce the deployment gate and run the post-change monitoring window, providing the infrastructure layer of the impact assessment workflow.", "actions": [ "Implement the deployment gate that checks for an approved impact assessment ticket before authorizing Major changes to production knowledge stores.", "Configure the post-change monitoring dashboard to compare live quality metrics against the pre-change baseline for 48 hours after each Major change.", "Provide rollback tooling that can revert a Major change within 2 hours if the post-change monitoring window detects a significant regression." ], "failure_signals": [ "Deployment gate bypassed for a Major change.", "Post-change monitoring dashboard not active after a Major change.", "Rollback capability not tested in the last quarter." ] }, "grc_auditor": { "summary": "The impact assessment process is evidence that the organization manages changes to AI-informing knowledge bases with appropriate rigor and oversight, satisfying change management requirements under multiple frameworks.", "actions": [ "Review the change log for the last 12 months and identify all Major changes; verify each has a completed impact assessment on file.", "Sample three impact assessments and verify they include all required elements (evaluation results, risk classification, approval records).", "Confirm that the deployment gate is enforced and that no Major changes were deployed without approval." ], "metrics": [ "Impact assessment coverage: target 100% of Major changes.", "Approval completeness: target 100% of assessments have required approvals on file.", "Post-change monitoring coverage: target 100% of Major changes." ], "failure_signals": [ "Major change deployed without an impact assessment.", "Impact assessment missing required approval signatures.", "Post-change monitoring not executed within 48 hours of deployment." ] }, "legal_counsel": { "summary": "Major knowledge changes can alter what the AI tells customers overnight: impact assessment is the mechanism that surfaces legal review before, not after, a risky change ships.", "actions": [ "Define change categories that require legal sign-off \u2014 regulated content swaps, license changes, jurisdiction shifts.", "Review impact assessments for changes affecting advice-like outputs in regulated domains.", "Keep assessment records as evidence that foreseeable risks were evaluated before deployment." ], "failure_signals": [ "A bulk content replacement changed regulated-domain answers with no pre-change legal review.", "No impact assessment exists for a change that later caused customer harm." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Pre-change impact assessment for knowledge bases is rarely practiced; most organizations discover regressions through user complaints after deployment." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Knowledge Engineering Team", "AI Platform Engineering", "Change Advisory Board" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a76.1.2 \u2014 AI Risk Assessment", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a76.1.2 requires AI organizations to assess risks associated with changes to AI systems. Knowledge base changes are a material modification to the AI system's inputs, and this control operationalizes the required risk assessment process at the knowledge layer.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2) \u2014 Risk management system", "fit": "direct", "rationale": "EU AI Act Article 9(2) requires a continuous, iterative risk management process for high-risk AI systems, including identification and evaluation of risks that may emerge during operation. Changes to the knowledge base are a foreseeable source of new risk that must be assessed for impact on AI output quality and safety before deployment.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "itil_4", "requirement_id": "\u00a75.2.4 \u2014 Change Enablement", "fit": "direct", "rationale": "ITIL 4 Change Enablement practice defines impact assessment as a required step for significant changes to service-impacting systems. Knowledge bases are service-impacting systems and must be subject to the same change management rigor, including deployment gates and post-change review.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_30401", "requirement_id": "Clause 8", "fit": "direct", "rationale": "ISO 30401:2018 Clause 8 (Operation) requires organizations to control planned changes and review the consequences of unintended changes to the knowledge management system. Pre-change impact assessment is the structured implementation of that change-control requirement for major knowledge base modifications.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "databricks_unity", "requirement_id": "Unity Catalog Data Lineage and Impact Analysis", "fit": "adjacent", "rationale": "Databricks Unity Catalog's data lineage capabilities can be used to identify downstream AI pipelines that will be affected by upstream knowledge base changes, supporting the impact scoping step of the assessment process described in this control.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KM-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Before any major change to the knowledge base is executed, a documented impact assessment must be completed and approved that quantifies the expected effect on AI output quality, retrieval coverage, and risk posture. The control passes when no major knowledge changes are deployed to production without a completed, approver-signed impact assessment on record prior to the change execution.", "evidence_required": [ "knowledge_change_impact_assessment_record for each major change including change_type, scope_description, estimated_coverage_delta, estimated_quality_delta, risk_posture_assessment, proposed_mitigations, and approver_id with approved_at timestamp prior to deployment", "pre_post_change_quality_benchmark_report comparing retrieval accuracy, answer quality scores, and coverage metrics between pre-change and post-change states using the standard evaluation dataset", "change_management_log showing that all major knowledge changes were preceded by a completed impact assessment with approval timestamps recorded before deployment", "embedding_model_replacement_impact_report (where applicable) documenting re-indexing validation results and retrieval relevance regression test outcomes across all knowledge segments" ], "machine_tests": [ "Attempt to initiate a bulk ingestion of more than 500 documents via the knowledge management API without an associated impact_assessment_id \u2192 assert the API rejects the request with error_code=impact_assessment_required", "Trigger an embedding model replacement in the staging environment without a completed impact assessment \u2192 assert the system blocks promotion to production and returns error_code=change_assessment_not_approved", "Submit a change with an impact assessment record that has no approver_id field \u2192 assert the change management system flags the assessment as incomplete and blocks the change from proceeding", "Run the standard evaluation dataset against the knowledge base before and after a simulated major change \u2192 assert quality metric deltas are captured in a benchmark report and compared against defined acceptance thresholds" ], "human_review": [ "Review the change management log for the last 6 months and verify that all changes classified as major have a corresponding approved impact assessment on record with approval timestamps predating deployment", "Assess the quality of impact assessment methodology, verifying it includes quantitative coverage and quality delta estimates backed by evaluation data rather than qualitative risk narratives alone", "Evaluate whether the organization's definition of major change is precise enough to prevent teams from reclassifying large-scope changes as minor to circumvent the assessment requirement" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Performing impact assessment only for embedding model replacements while treating bulk ingestion or large-scale deletion as routine changes that do not require assessment", "Completing the impact assessment after the change has been deployed to production and treating it as a post-hoc documentation exercise rather than a pre-deployment gate", "Defining major change solely by document count without considering the semantic scope of the change relative to the knowledge base's coverage of critical topics", "Not comparing pre-change and post-change quality metrics against a stable evaluation dataset, leaving the impact assessment qualitative and unverifiable", "Using a single approver for high-risk changes such as bulk deletion of content in regulated knowledge domains without requiring additional sign-off from domain leadership" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KM" }, { "id": "KM-07", "layer": "KM", "plane": "both", "name": "Knowledge Base Performance and Quality Metrics", "plain": "The organization must define, instrument, and continuously monitor a set of knowledge base quality and performance metrics covering retrieval accuracy, coverage, freshness, and user-reported satisfaction, with defined thresholds that trigger review or remediation when breached.", "threat": { "tags": [ "undetected-retrieval-failure", "knowledge-coverage-gap", "quality-degradation", "unmonitored-knowledge-decay" ], "desc": "A knowledge base that is not continuously measured degrades silently. Retrieval precision can drop when the embedding model distribution shifts relative to the knowledge corpus. Coverage gaps emerge as the domain evolves but the knowledge base is not updated. Without quantitative metrics and thresholds, quality problems are discovered only through user complaints or high-profile AI output failures rather than through proactive monitoring." }, "standard": [ { "id": "iso_30401", "section": "\u00a79.1", "title": "Knowledge management performance evaluation" }, { "id": "iso_42001", "section": "\u00a79.1", "title": "AI system monitoring and measurement" }, { "id": "itil_4", "section": "\u00a75.1.2", "title": "Continual improvement and measurement" }, { "id": "dama_dmbok", "section": "Ch. 13", "title": "Data quality metrics and measurement" } ], "sources": [ { "id": "aws_bedrock_knowledge_bases_2024", "title": "Amazon Bedrock Knowledge Bases", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_knowledge_bases_2024", "relationship": "informative_reference", "rationale": "Establishes Amazon Bedrock Knowledge Bases requirements informing the apeiris://knowledge/controls/KM-07 Knowledge Base Performance and Quality Metrics control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define a knowledge quality metrics framework covering four dimensions: Retrieval Performance (precision@k, recall@k, MRR), Coverage (query answering rate against the golden evaluation set), Freshness (percentage of Active assets reviewed within their review cadence), and Satisfaction (user-reported thumbs-down rate on AI responses attributable to knowledge issues). Instrument all metrics via automated pipelines and publish them to a live knowledge health dashboard. Define breach thresholds for each metric that trigger a remediation workflow.", "steps": [ "Define the target metrics and breach thresholds for each dimension in the knowledge quality policy and publish them as the knowledge base SLA.", "Instrument the retrieval pipeline to log precision@k and recall@k against the golden evaluation set on a daily automated run.", "Implement a user feedback collection mechanism in AI-facing applications that captures thumbs-up/thumbs-down ratings attributable to knowledge quality issues.", "Build and publish a knowledge health dashboard that aggregates all four metric dimensions with trend lines and breach threshold indicators.", "Define and publish a remediation workflow that is triggered automatically when any metric breaches its threshold, including escalation paths and resolution SLAs." ], "knowledge_engineer": { "summary": "Metrics instrumentation is a core responsibility of the knowledge engineering team. Retrieval performance metrics must be automatically computed against the golden evaluation set on a scheduled basis.", "actions": [ "Implement daily automated retrieval evaluation against the golden query set and publish results to the metrics store.", "Instrument the freshness metric by querying the lifecycle metadata store for assets past their review cadence.", "Define breach thresholds in consultation with AI system owners and document them in the knowledge quality policy." ], "failure_signals": [ "Daily retrieval evaluation not running.", "Freshness metric not computable due to missing review cadence metadata.", "Breach thresholds not defined or not enforced." ] }, "data_scientist": { "summary": "Data scientists are responsible for the statistical validity of retrieval metrics and for interpreting trends to distinguish noise from genuine quality degradation.", "actions": [ "Design the golden evaluation set to be statistically representative across all knowledge segments and query difficulty levels.", "Implement statistical significance testing for metric changes to distinguish genuine degradation from measurement variance.", "Analyze knowledge quality trends quarterly and produce a written assessment for the Knowledge Governance review." ], "failure_signals": [ "Golden evaluation set not updated to reflect new knowledge segments.", "Metric changes interpreted without statistical significance testing.", "Quarterly trend analysis not produced." ] }, "it_operations": { "summary": "Operations teams maintain the metrics pipeline and knowledge health dashboard, ensuring they are reliable, current, and alerting correctly.", "actions": [ "Monitor the automated evaluation pipeline for failures and alert on job failures within 2 hours.", "Maintain the knowledge health dashboard and ensure it refreshes on the defined cadence.", "Configure breach threshold alerts to route to the knowledge engineering team's incident queue." ], "failure_signals": [ "Automated evaluation pipeline failing without alert.", "Dashboard not refreshing on schedule.", "Breach threshold alerts not routing to the correct queue." ] }, "grc_auditor": { "summary": "Knowledge quality metrics and their breach history are evidence that the organization actively monitors and manages the effectiveness of its knowledge management function.", "actions": [ "Review the knowledge health dashboard and verify all four metric dimensions are active and current.", "Request the last 90 days of breach events and verify each triggered a documented remediation workflow.", "Confirm that the knowledge quality policy defines breach thresholds and that they have been reviewed in the last 12 months." ], "metrics": [ "Metrics instrumentation coverage: target 100% of metric dimensions instrumented.", "Breach remediation rate: target 100% of breaches trigger a documented remediation workflow.", "Dashboard freshness: target metrics updated within 24 hours." ], "failure_signals": [ "One or more metric dimensions not instrumented.", "Breach events with no documented remediation action.", "Dashboard metrics stale for more than 48 hours." ] }, "legal_counsel": { "summary": "Quality metrics are representations: numbers reported to customers, auditors, or regulators about knowledge system performance must be accurate and consistently defined, or they become misrepresentation risk.", "actions": [ "Review externally shared quality claims against the actual measured metrics and their definitions.", "Confirm metric retention supports substantiating past performance claims.", "Flag contractual SLAs that reference knowledge quality metrics so measurement changes get legal review." ], "failure_signals": [ "A customer-facing quality claim cannot be substantiated by the underlying metrics.", "A metric definition change silently invalidates an SLA commitment." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Formal knowledge quality metrics with defined thresholds are uncommon in production RAG deployments; most organizations rely on anecdotal user feedback." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector" ], "implementers": [ "Knowledge Engineering Team", "AI Platform Engineering", "IT Operations" ], "frameworks": [ { "framework": "iso_30401", "requirement_id": "\u00a79.1 \u2014 Performance Evaluation", "fit": "direct", "rationale": "ISO 30401:2018 \u00a79.1 requires organizations to monitor, measure, analyze, and evaluate their knowledge management performance. This control operationalizes that requirement with quantitative metrics across four quality dimensions and breach-triggered remediation workflows.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "\u00a79.1 \u2014 Monitoring and Measurement", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a79.1 requires AI organizations to monitor and measure the performance of their AI management systems. Knowledge base quality metrics are a required input to the AI system performance monitoring process, directly supporting this clause.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "itil_4", "requirement_id": "\u00a75.1.2 \u2014 Continual Improvement", "fit": "direct", "rationale": "ITIL 4's continual improvement practice requires that services be measured against defined targets and that deviations trigger improvement actions. Knowledge base SLA breach thresholds and remediation workflows are the ITIL continual improvement pattern applied to knowledge management services.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 13 \u2014 Data Quality", "fit": "direct", "rationale": "DAMA DMBOK 2 Chapter 13 establishes data quality metrics as a core data management capability. The four-dimension metrics framework (retrieval performance, coverage, freshness, satisfaction) maps to DAMA's completeness, accuracy, timeliness, and usability quality dimensions.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_bedrock_kb", "requirement_id": "Knowledge Base Metrics and Evaluation", "fit": "partial", "rationale": "Amazon Bedrock Knowledge Bases provides built-in evaluation metrics and retrieval observability. This control extends Bedrock's native metrics with additional coverage and satisfaction dimensions and an independent thresholding and alerting layer that persists beyond the platform's native retention window.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KM-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The knowledge base must have formally defined quality and performance metrics with documented thresholds, continuous automated monitoring against those thresholds, and an alerting mechanism that generates remediation tasks when any metric breaches its threshold. The control passes when all defined metrics are instrumented and current, thresholds are documented and grounded in use-case requirements, and no unaddressed threshold breach is older than the defined response SLA.", "evidence_required": [ "knowledge_quality_metrics_definition_document listing each metric (retrieval accuracy, coverage, freshness, user satisfaction) with its measurement methodology, numeric threshold values, monitoring cadence, and breach response SLA", "automated_quality_monitoring_report from the most recent monitoring cycle showing current metric values against thresholds with pass or breach status for each metric and report timestamp", "threshold_breach_remediation_log for any metric breaches in the last 90 days, showing breach_detected_at, assigned_to, remediation_action_taken, and resolved_at timestamps", "user_satisfaction_feedback_aggregate showing user-reported satisfaction scores and qualitative feedback categorized by knowledge domain and collection period" ], "machine_tests": [ "Run the standard evaluation dataset through the RAG pipeline \u2192 assert retrieval_accuracy_score meets or exceeds the defined threshold and the result is written as a record in the quality_monitoring_report with a current timestamp", "Inject test queries spanning all defined knowledge segments \u2192 assert coverage_score (percentage of queries with at least one retrieved chunk above the relevance threshold) meets the defined coverage threshold", "Simulate a threshold breach by submitting queries against a degraded test knowledge base \u2192 assert the monitoring system raises an alert within the defined breach-detection SLA and creates a remediation task with an assigned owner", "Query the monitoring dashboard API \u2192 assert it returns current metric values for all defined metrics with timestamps no older than the defined monitoring cadence interval" ], "human_review": [ "Review the metrics definition document and verify that thresholds are grounded in actual quality requirements for the AI system's use cases rather than set at levels that historical performance trivially exceeds", "Sample 10 threshold breach remediation records and assess whether root cause analysis was performed and whether the remediation action addressed the underlying cause rather than merely restoring the metric value", "Evaluate whether user satisfaction feedback is systematically collected, categorized, and fed into knowledge improvement workflows rather than only logged without follow-up action" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Setting quality thresholds based on historical performance averages rather than minimum acceptable quality levels for the AI system's specific use cases and risk profile", "Monitoring retrieval quality using only precision metrics while ignoring recall, allowing the system to appear healthy while missing critical information on complex queries", "Collecting user satisfaction feedback through a form that is never reviewed or aggregated into quality improvement actions, treating it as a compliance checkbox rather than actionable signal", "Defining thresholds that are never breached because they are set below the current baseline performance level, removing the alerting function entirely", "Running quality evaluations only on a static test set that does not evolve with the knowledge base, allowing coverage gaps to develop silently in newly added knowledge domains" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KM" }, { "id": "KM-08", "layer": "KM", "plane": "control", "name": "Knowledge Management Evidence Package", "plain": "The organization must compile and maintain a KM-layer evidence package that aggregates attestation artifacts from KM-01 through KM-07, demonstrating that knowledge assets are governed through a documented lifecycle, segmented and access-controlled, versioned with complete change history, retained per policy, traceable from output to source, change-impact assessed, and continuously measured for quality and performance.", "threat": { "tags": [ "compliance-evidence-gap", "audit-unreadiness", "fragmented-governance-record", "attestation-failure" ], "desc": "Even when individual KM controls are implemented, the absence of a compiled evidence package means that compliance audits require ad hoc evidence gathering that is slow, incomplete, and error-prone. Regulators examining AI knowledge governance expect a coherent, cross-referenced package of artifacts, not disparate records across multiple systems. Fragmented governance records also prevent internal assurance teams from forming a reliable view of the organization's knowledge management posture." }, "standard": [ { "id": "iso_30401", "section": "\u00a79.3", "title": "Management review and evidence compilation" }, { "id": "iso_42001", "section": "\u00a79.3", "title": "AI management system review outputs" }, { "id": "eu_ai_act", "section": "Art. 17(1)", "title": "Quality management documentation for high-risk AI" }, { "id": "itil_4", "section": "\u00a75.1.4", "title": "Knowledge management practice" } ], "sources": [ { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements \u00a79.3 \u2014 Management Review requirements informing the apeiris://knowledge/controls/KM-08 Knowledge Management Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a79.3 \u2014 Management Review requirements informing the apeiris://knowledge/controls/KM-08 Knowledge Management Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 17(1) \u2014 Quality Management requirements informing the apeiris://knowledge/controls/KM-08 Knowledge Management Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 15 \u2014 Data Management Maturity Assessment requirements informing the apeiris://knowledge/controls/KM-08 Knowledge Management Evidence Package control.", "reviewed_on": "2026-07-02" }, { "id": "itil_4", "title": "ITIL 4", "authority": "PeopleCert / Axelos", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "4", "published_on": "2019-02-28", "retrieved_on": "2026-07-02", "canonical_url": "https://www.axelos.com/certifications/itil-service-management/itil-4-foundation", "license": "proprietary", "status": "current", "flagship": false, "source_id": "itil_4", "relationship": "informative_reference", "rationale": "Establishes ITIL 4 \u00a75.1.4 \u2014 Knowledge management requirements informing the apeiris://knowledge/controls/KM-08 Knowledge Management Evidence Package control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define the KM Evidence Package as a structured artifact collection that maps each sub-control (KM-01 through KM-07) to its required evidence artifacts. Compile the package on a quarterly basis and on-demand for audits or regulatory examinations. Store the package in a tamper-evident repository with access restricted to authorized governance roles. Include a signed attestation statement from the Knowledge Governance lead affirming the accuracy and completeness of the package.", "steps": [ "Define the KM Evidence Package template specifying the required artifacts for each sub-control: lifecycle audit report (KM-01), access control test results (KM-02), version history sample with hash verification (KM-03), retention schedule and hold registry (KM-04), lineage record sample (KM-05), impact assessment log (KM-06), and metrics dashboard export (KM-07).", "Automate the collection of available artifacts from the knowledge management platform, metrics store, and lineage store into the evidence package on a quarterly schedule.", "Route the compiled package to the Knowledge Governance lead for review and signature; the signed attestation becomes the KM-08 attestation artifact.", "Store the signed package in a tamper-evident, access-controlled evidence repository with retention aligned to the organization's audit evidence retention policy.", "During audits or regulatory examinations, provide the most recent signed package as the primary knowledge management compliance artifact and supplement with on-demand queries as needed." ], "knowledge_engineer": { "summary": "Knowledge engineers are responsible for ensuring that each sub-control generates the artifacts required by the evidence package template, and for automating artifact collection into the package.", "actions": [ "Instrument each KM sub-control to generate the artifacts specified in the evidence package template as a standard output of its operation.", "Build or configure the automated artifact collection pipeline that assembles the quarterly evidence package.", "Validate the completeness of each quarterly package before routing it for governance review." ], "failure_signals": [ "One or more sub-control artifacts missing from the quarterly package.", "Automated collection pipeline failing silently.", "Package assembled without validation of artifact completeness." ] }, "data_scientist": { "summary": "The KM evidence package rolls up lifecycle, access, and quality metrics; each figure must be traceable to reproducible analysis over the underlying management telemetry.", "actions": [ "Version-control the analysis code that produces the package's lifecycle and quality figures.", "Reconcile packaged numbers against source telemetry each cycle before certification.", "Document definition changes so cross-period comparisons in the package remain honest." ], "failure_signals": [ "Package figures diverge from source telemetry with no explanation.", "Trend claims in the package span an undisclosed metric redefinition." ] }, "it_operations": { "summary": "Operations teams are responsible for the tamper-evident evidence repository and the reliability of the automated collection pipeline.", "actions": [ "Deploy and maintain the tamper-evident evidence repository with access restricted to authorized governance roles.", "Monitor the quarterly evidence package collection pipeline and alert on failures.", "Test repository tamper-evidence controls annually and document results." ], "failure_signals": [ "Evidence repository access not restricted to authorized roles.", "Collection pipeline failures not alerting within SLA.", "Tamper-evidence controls not tested in the last 12 months." ] }, "grc_auditor": { "summary": "The KM Evidence Package is the primary artifact for assessing the organization's knowledge management compliance posture. Its completeness, accuracy, and timeliness are the central audit indicators for the KM layer.", "actions": [ "Review the most recent quarterly evidence package and verify it contains all required artifacts for KM-01 through KM-07.", "Verify that the package bears a signed attestation from the Knowledge Governance lead with a date within the last 90 days.", "Cross-reference a sample of package artifacts against source systems to verify accuracy and detect fabrication." ], "metrics": [ "Evidence package completeness: target 100% of required artifacts present.", "Package production frequency: target quarterly with no missed quarters.", "Cross-reference accuracy: target 100% of sampled artifacts match source systems." ], "failure_signals": [ "Evidence package missing required artifacts for any sub-control.", "Most recent package older than 90 days.", "Cross-reference discrepancies found between package artifacts and source systems." ] }, "legal_counsel": { "summary": "The signed evidence package is a formal assertion of the organization's knowledge management compliance posture and may be used in regulatory examinations, certification audits, or litigation discovery.", "actions": [ "Review the attestation statement template to ensure it accurately represents the scope and limitations of the assurance provided.", "Confirm that the signed package is stored with sufficient integrity protections to be admissible as evidence in regulatory proceedings.", "Advise on the retention period for signed evidence packages based on applicable statutes of limitations and regulatory requirements." ], "failure_signals": [ "Attestation statement overstates the assurance provided by the evidence package.", "Evidence repository lacks the integrity controls required for admissibility.", "Signed packages not retained for the required period." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Compiled knowledge governance evidence packages do not exist in most enterprises; evidence is gathered ad hoc during audits with no persistent package structure." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Knowledge Engineering Team", "GRC / Compliance Team", "Knowledge Governance Lead" ], "frameworks": [ { "framework": "iso_30401", "requirement_id": "\u00a79.3 \u2014 Management Review", "fit": "direct", "rationale": "ISO 30401:2018 \u00a79.3 requires top management to review the knowledge management system at planned intervals and retain documented information as evidence. The quarterly evidence package is the primary vehicle for satisfying this review and documentation requirement.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "\u00a79.3 \u2014 Management Review", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a79.3 requires AI management system reviews to produce outputs including decisions and actions, supported by documented evidence. The KM evidence package provides the structured evidence base for this review, covering all seven KM sub-controls.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 17(1) \u2014 Quality Management", "fit": "direct", "rationale": "EU AI Act Article 17(1) requires providers of high-risk AI systems to implement quality management systems that include documentation and record-keeping. The KM evidence package is the record-keeping artifact for knowledge management quality, directly satisfying this documentation requirement.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 15 \u2014 Data Management Maturity Assessment", "fit": "partial", "rationale": "DAMA-DMBOK 2nd edition Chapter 15 (Data Management Maturity Assessment) treats documented evidence of governance activities as the basis for assessing program maturity. The KM evidence package operationalizes this by creating a structured, signed record of knowledge governance activities across all seven sub-controls.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "itil_4", "requirement_id": "\u00a75.1.4 \u2014 Knowledge management", "fit": "adjacent", "rationale": "The ITIL 4 knowledge management practice (5.1.4) calls for information and knowledge to be maintained so it remains reliable evidence of how services are run. The KM evidence package extends this practice to AI knowledge management, providing a structured quarterly record of quality metrics and control effectiveness.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KM-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The organization must maintain a current KM-layer evidence package aggregating attestation artifacts from KM-01 through KM-07, with each artifact no older than its defined review cadence. The control passes when an authorized reviewer can retrieve a complete, current evidence package covering all seven KM controls and present it in response to an audit or regulatory inquiry without gaps or expired artifacts.", "evidence_required": [ "km_evidence_package_manifest listing all required attestation artifacts from KM-01 through KM-07, each with artifact_type, artifact_id, collected_at timestamp, review_cadence, and current_status (current or expired)", "km_evidence_completeness_assessment_report confirming all 7 KM control attestation artifacts are present, current within their review cadence, and free of identified deficiencies", "KnowledgeAttestation attestation record signed by the authorized knowledge steward with references to all underlying KM-layer artifact IDs and their SHA-256 integrity hashes", "evidence_package_access_log showing who accessed or reviewed the evidence package and when, supporting chain-of-custody documentation for regulatory evidence production" ], "machine_tests": [ "Query the evidence management system for the KM evidence package \u2192 assert it returns a manifest listing artifacts for all 7 KM controls (KM-01 through KM-07) with no missing control entries", "For each artifact in the manifest, check its collected_at timestamp \u2192 assert no artifact is older than its defined review cadence and none are flagged as expired", "Request the KnowledgeAttestation record \u2192 assert it carries a valid cryptographic signature and references artifact IDs and integrity hashes for all 7 KM control artifacts", "Attempt to generate the evidence package with one KM control artifact missing \u2192 assert the evidence management system returns error_code=evidence_package_incomplete and lists the missing control IDs" ], "human_review": [ "Review the KM evidence package for completeness, verifying each artifact references the correct control, covers the required scope, and contains sufficient detail for an external auditor to assess control effectiveness", "Assess whether the evidence package has been successfully exercised in a tabletop audit simulation or regulatory inquiry rehearsal within the last 12 months", "Verify that the evidence package update process is automated or calendared so that artifacts are refreshed on schedule without requiring manual initiation for each review cycle" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Maintaining KM evidence as disconnected documents in different systems without a manifest or cross-reference to the specific controls they attest to", "Including evidence artifacts in the package that are outdated beyond their review cadence without flagging the staleness, presenting a false picture of governance completeness", "Treating the evidence package as a static document produced once for certification rather than a living collection updated on the defined review cadence", "Signing the KnowledgeAttestation before all underlying KM-layer artifacts have been reviewed and confirmed current, creating an attestation that overstates the evidence it references", "Not rehearsing evidence package retrieval and presentation before an actual audit, discovering access failures or format gaps under regulatory time pressure" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KM" }, { "id": "KG-01", "layer": "KG", "plane": "control", "name": "Knowledge Governance Structure", "plain": "The enterprise must establish formal knowledge stewardship roles, ownership accountability structures, a cross-functional knowledge governance committee, and documented escalation procedures for knowledge quality disputes and policy exceptions.", "threat": { "tags": [ "governance-gap", "orphaned-knowledge", "accountability-void", "escalation-failure" ], "desc": "Without defined stewardship, knowledge assets accumulate without owners. Gaps in accountability allow stale or erroneous content to persist in AI-facing knowledge bases unchecked. When AI systems produce errors traceable to bad knowledge, the absence of a governance committee means no party has authority or obligation to remediate, resulting in systemic quality failures that spread across AI outputs enterprise-wide." }, "standard": [ { "id": "iso_30401", "section": "\u00a75.3", "title": "Organizational roles, responsibilities and authorities" }, { "id": "iso_42001", "section": "\u00a75.1", "title": "Leadership and commitment for AI management" }, { "id": "itil_4", "section": "\u00a75.1.4", "title": "Knowledge management practice" }, { "id": "dama_dmbok", "section": "Ch. 3", "title": "Data governance roles and organizational structures" } ], "sources": [ { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements \u00a75.3 requirements informing the apeiris://knowledge/controls/KG-01 Knowledge Governance Structure control.", "reviewed_on": "2026-07-02" }, { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a75.1\u20135.3 requirements informing the apeiris://knowledge/controls/KG-01 Knowledge Governance Structure control.", "reviewed_on": "2026-07-02" }, { "id": "itil_4", "title": "ITIL 4", "authority": "PeopleCert / Axelos", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "4", "published_on": "2019-02-28", "retrieved_on": "2026-07-02", "canonical_url": "https://www.axelos.com/certifications/itil-service-management/itil-4-foundation", "license": "proprietary", "status": "current", "flagship": false, "source_id": "itil_4", "relationship": "informative_reference", "rationale": "Establishes ITIL 4 \u00a75.1.4 \u2014 Knowledge management requirements informing the apeiris://knowledge/controls/KG-01 Knowledge Governance Structure control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 3 \u2014 Data Governance requirements informing the apeiris://knowledge/controls/KG-01 Knowledge Governance Structure control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 9 \u2014 Risk Management System requirements informing the apeiris://knowledge/controls/KG-01 Knowledge Governance Structure control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Establish a Knowledge Governance Committee with representatives from knowledge engineering, data science, legal, GRC, and domain business units. Define RACI for knowledge stewardship, quality assurance, and policy exception handling. Document escalation paths from operational issues to committee to executive sponsor.", "steps": [ "Charter a Knowledge Governance Committee with defined membership, meeting cadence, quorum rules, and decision authority over knowledge quality policy.", "Assign a named Knowledge Steward to each knowledge domain and register ownership in the enterprise knowledge registry with mandatory renewal every 12 months.", "Define and publish escalation procedures covering knowledge quality disputes, policy exception requests, external provider governance failures, and AI-output errors attributable to knowledge defects.", "Integrate governance committee review into the AI system deployment approval workflow so no AI system consuming enterprise knowledge proceeds to production without committee sign-off." ], "knowledge_engineer": { "summary": "The governance structure defines who owns each knowledge artifact and who resolves disputes. Engineers must register all knowledge assets and escalate quality issues through defined channels.", "actions": [ "Register all knowledge assets in the enterprise registry with assigned steward and ownership expiry.", "Route unresolved quality disputes to the Knowledge Governance Committee via the documented escalation path.", "Participate in quarterly committee reviews to surface systemic knowledge quality issues." ], "failure_signals": [ "Knowledge assets with no assigned steward exceed 5% of registry.", "Escalation queue shows issues older than 30 days without committee resolution.", "Committee quorum not reached in two consecutive scheduled meetings." ] }, "data_scientist": { "summary": "Governance structure decides whose call quality is: data science needs a named seat for threshold setting, evaluation standards, and escalation when quality and delivery pressure conflict.", "actions": [ "Secure explicit data science representation in the knowledge governance body for quality-standard decisions.", "Route evaluation-standard and threshold disputes through the documented escalation path.", "Bring corpus-quality risk findings to governance reviews with quantified evidence." ], "failure_signals": [ "Quality thresholds are changed by delivery teams without the governance body's knowledge.", "Data science findings about corpus risk have no formal path into governance decisions." ] }, "it_operations": { "summary": "Governance assigns operational ownership: every knowledge store, pipeline, and index needs a named operational owner with an escalation path \u2014 orphaned infrastructure is where governance fails first.", "actions": [ "Maintain an ownership map from every knowledge system component to a named operational owner.", "Exercise the escalation path in incident drills so it works under pressure.", "Report unowned or ownership-stale components to the governance body each quarter." ], "failure_signals": [ "An incident stalls because the affected pipeline has no current owner.", "The ownership map is a year stale and routes escalations to departed staff." ] }, "grc_auditor": { "summary": "The governance committee charter and RACI are primary audit artifacts for demonstrating that knowledge management is formally governed at the enterprise level.", "actions": [ "Request committee charter, membership roster, and meeting minutes for the prior 12 months.", "Verify that each knowledge domain has a named steward and that ownership renewals are current.", "Sample 10 AI system deployments and confirm knowledge governance committee sign-off is on record." ], "metrics": [ "Knowledge asset ownership coverage: target 100%.", "Committee meeting attendance rate: target \u226580% per member per quarter.", "Escalations resolved within SLA: target \u226595%." ], "failure_signals": [ "Ownership coverage below 95% for two consecutive quarters.", "Committee has not met in more than 60 days.", "No documented escalation resolution for any open item older than 45 days." ] }, "legal_counsel": { "summary": "The governance structure establishes the accountability chain required for regulatory inquiries and litigation holds involving AI knowledge failures.", "actions": [ "Review committee charter to confirm it assigns liability-relevant accountability for AI knowledge errors.", "Ensure escalation procedures include legal notification triggers for knowledge incidents with regulatory exposure.", "Confirm that ownership records are retained per the enterprise records retention schedule." ], "failure_signals": [ "Charter does not specify legal escalation trigger conditions.", "No legal representative on the Knowledge Governance Committee.", "Ownership records are not retained per the applicable retention policy." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises have informal knowledge owners but no formal committee or documented escalation. Formalizing the RACI is typically the highest-impact first step." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Knowledge Management Office", "GRC Team", "Executive Leadership", "IT Operations" ], "frameworks": [ { "framework": "iso_30401", "requirement_id": "\u00a75.3", "fit": "direct", "rationale": "ISO 30401:2018 \u00a75.3 requires top management to ensure that responsibilities and authorities for relevant roles in the knowledge management system are assigned and communicated. This is the primary normative anchor for a defined knowledge governance structure with named owners and escalation paths.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_42001", "requirement_id": "\u00a75.1\u20135.3", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a75.1\u20135.3 requires top management to demonstrate leadership and commitment to the AI management system, which includes knowledge governance as a foundational component. It requires documented roles and responsibilities for AI-affecting processes.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "itil_4", "requirement_id": "\u00a75.1.4 \u2014 Knowledge management", "fit": "direct", "rationale": "The ITIL 4 knowledge management practice (5.1.4) defines ownership, roles and workflows for organizational knowledge. Its accountability model informs the committee-and-owner structure required by this control.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 3 \u2014 Data Governance", "fit": "partial", "rationale": "DAMA DMBOK2 Chapter 3 provides a mature model for data governance organization, roles, and decision rights that maps directly to knowledge asset governance. While focused on data, its stewardship and committee patterns are directly applicable to knowledge management governance structures.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9 \u2014 Risk Management System", "fit": "partial", "rationale": "EU AI Act Article 9 requires providers of high-risk AI systems to establish a risk management system with defined roles and responsibilities. Knowledge governance structure is a prerequisite for fulfilling the risk management obligations where AI systems rely on enterprise knowledge bases.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" } ], "canonical_id": "apeiris://knowledge/controls/KG-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The enterprise must have defined and staffed formal knowledge stewardship roles with named owners for all active knowledge domains, a cross-functional knowledge governance committee with a documented charter and meeting cadence, and documented escalation procedures for knowledge quality disputes. The control passes when all active knowledge domains have an assigned steward, the governance committee has convened within the last quarter, and escalation procedures have been reviewed within the last 12 months.", "evidence_required": [ "knowledge_stewardship_role_registry listing all defined stewardship roles with role_id, responsible_domain_ids, incumbent_name, appointment_date, and reporting_line for each active knowledge domain", "knowledge_governance_committee_charter documenting membership criteria, decision-making authority, meeting cadence, quorum requirements, and the scope of matters requiring committee approval", "governance_committee_meeting_records for the last 4 meetings including attendance against quorum, agenda items, decisions made, and action items with assigned owners and due dates", "escalation_procedure_document defining trigger conditions, the escalation path with named roles at each level, decision authority, and maximum resolution time SLAs", "orphaned_domain_remediation_log showing any knowledge domains identified as lacking a steward and the action taken to assign ownership within the defined SLA" ], "machine_tests": [ "Query the stewardship registry API for all active knowledge segments \u2192 assert each segment has an assigned steward_id and the steward record has a valid appointment_date and active status", "Query the governance committee meeting log \u2192 assert at least one meeting record exists with a meeting_date within the last 90 days and an attendance count meeting the charter-defined quorum", "Submit a simulated knowledge quality dispute via the escalation workflow \u2192 assert it is routed to the correct escalation path and a first response is generated within the SLA window defined in the escalation procedure", "Query for knowledge domains where the assigned steward record is flagged as inactive for more than 30 days \u2192 assert the system generates a stewardship_continuity_alert for each such domain" ], "human_review": [ "Review the stewardship role registry and verify that no active knowledge domains are orphaned and that steward assignments reflect current organizational structure rather than historical role assignments that have not been updated", "Assess governance committee meeting records for the last 4 meetings to confirm that material governance decisions are made and followed through, not merely documented as agenda items without action", "Evaluate the escalation procedure for specificity, verifying that trigger conditions are precise enough to be applied consistently and that resolution time SLAs are actively monitored" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Assigning a single person as knowledge steward for all domains rather than distributing ownership to subject matter experts who have the knowledge and authority to make quality decisions in their domain", "Establishing a governance committee on paper but not convening it on the defined cadence, allowing governance decisions to be made informally outside the committee process", "Defining escalation procedures that route disputes to a generic compliance inbox rather than to named roles with specific authority to resolve the type of dispute being escalated", "Maintaining the stewardship registry as a document rather than a machine-readable data store, making it impossible to automatically detect orphaned domains when organizational changes occur", "Not reviewing escalation procedures annually, allowing them to become misaligned with changes in organizational authority and decision-making structures" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KG" }, { "id": "KG-02", "layer": "KG", "plane": "control", "name": "AI Knowledge Substrate Policy Framework", "plain": "The enterprise must maintain a formal policy framework governing what content may be ingested into AI-facing knowledge bases, including permissible sources, quality thresholds, restricted content categories, usage restrictions, and the review process for policy exceptions.", "threat": { "tags": [ "unauthorized-source", "policy-gap", "content-poisoning", "quality-threshold-bypass" ], "desc": "Without explicit ingestion policy, engineers ingest convenient but ungoverned sources \u2014 unofficial wikis, unvetted web scrapes, or personal document stores \u2014 into AI knowledge bases. This introduces factual errors, confidential disclosures, copyright-infringing content, and adversarially poisoned material. Policy gaps allow quality degradation to compound silently until AI-generated errors cause material harm or regulatory exposure." }, "standard": [ { "id": "iso_42001", "section": "\u00a76.1.3", "title": "AI risk treatment \u2014 knowledge substrate controls" }, { "id": "eu_ai_act", "section": "Art. 10", "title": "Data and data governance requirements" }, { "id": "dama_dmbok", "section": "Ch. 4", "title": "Data architecture and quality policy" }, { "id": "iso_30401", "section": "Clause 8", "title": "Operation" } ], "sources": [ { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a76.1.3 \u2014 AI risk treatment requirements informing the apeiris://knowledge/controls/KG-02 AI Knowledge Substrate Policy Framework control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 10 \u2014 Data and data governance requirements informing the apeiris://knowledge/controls/KG-02 AI Knowledge Substrate Policy Framework control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 4 \u2014 Data Architecture; Ch. 13 \u2014 Data Quality requirements informing the apeiris://knowledge/controls/KG-02 AI Knowledge Substrate Policy Framework control.", "reviewed_on": "2026-07-02" }, { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements Clause 8 \u2014 Operation requirements informing the apeiris://knowledge/controls/KG-02 AI Knowledge Substrate Policy Framework control.", "reviewed_on": "2026-07-02" }, { "id": "iso_27002", "title": "ISO/IEC 27002:2022 \u2014 Information Security Controls", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "voluntary-standard", "version": "2022", "published_on": "2022-02-15", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/75652.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_27002", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 27002:2022 \u2014 Information Security Controls \u00a75.12 \u2014 Classification of information requirements informing the apeiris://knowledge/controls/KG-02 AI Knowledge Substrate Policy Framework control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Publish and version-control a Knowledge Ingestion Policy that enumerates approved source categories, minimum quality scores, prohibited content types, PII handling rules, copyright and license constraints, and the exception review process. Enforce the policy via automated ingestion pipeline gates and quarterly manual audits.", "steps": [ "Draft a Knowledge Ingestion Policy covering approved sources, quality thresholds, prohibited categories (PII, confidential, legally sensitive, unverified), license requirements, and retention limits.", "Implement automated policy gates in every ingestion pipeline that check source classification, license metadata, and quality score before allowing content into AI-facing knowledge stores.", "Establish an exception review process with a defined SLA for requests to ingest content that does not meet policy defaults, requiring Knowledge Governance Committee approval.", "Conduct quarterly audits of active knowledge base content against current policy, flagging and quarantining non-compliant artifacts for steward remediation." ], "knowledge_engineer": { "summary": "Policy framework defines what you can and cannot ingest. Every pipeline must enforce it programmatically \u2014 manual exceptions require committee approval.", "actions": [ "Implement policy-gate middleware in all ingestion pipelines that validates source, license, and quality metadata before insert.", "Tag all knowledge artifacts with their source classification, ingestion policy version, and quality score at ingest time.", "Submit exception requests for non-compliant sources through the formal review process; do not bypass gates." ], "failure_signals": [ "Ingestion pipeline audit finds artifacts lacking policy compliance metadata.", "Exception queue contains unapproved sources that are already in production knowledge stores.", "Quality scores below threshold are present in active AI-facing indexes." ] }, "data_scientist": { "summary": "The substrate policy sets the rules corpus work must satisfy: quality thresholds, permitted source classes, and validation requirements should be implementable and measurable, not aspirational.", "actions": [ "Review policy quality thresholds for measurability and implement them as automated corpus checks.", "Feed evidence from evaluation work back into policy revisions when thresholds prove mis-set.", "Verify experimental corpora comply with the same policy rules as production before promotion." ], "failure_signals": [ "Policy thresholds exist that no pipeline actually measures.", "An experimental corpus violating policy is promoted to production unchanged." ] }, "it_operations": { "summary": "Policy is enforced in infrastructure: ingestion gates, retrieval filters, and monitoring must be configured to the policy's rules, and configuration drift from policy is a compliance gap.", "actions": [ "Trace each policy rule to the specific pipeline control that enforces it, and flag unenforced rules.", "Alert on configuration drift between deployed controls and the policy baseline.", "Implement policy changes through change management with rollout verification." ], "failure_signals": [ "A policy rule has existed for a year with no enforcing control in any pipeline.", "Deployed thresholds drift from policy values with no drift detection." ] }, "grc_auditor": { "summary": "The policy document, version history, and pipeline enforcement evidence are the primary artifacts for demonstrating controlled knowledge ingestion.", "actions": [ "Request the current Knowledge Ingestion Policy and verify it is version-controlled and approved by the Knowledge Governance Committee.", "Sample 20 knowledge artifacts from production stores and verify each has valid source classification, license, and quality metadata meeting policy requirements.", "Review exception logs for the prior quarter and confirm each exception has documented committee approval." ], "metrics": [ "Policy-compliant artifacts in production stores: target \u226598%.", "Exceptions with documented committee approval: target 100%.", "Policy version currency: policy reviewed within 12 months." ], "failure_signals": [ "Policy has not been reviewed or updated in more than 18 months.", "Non-compliant artifacts found in production without exception approval.", "No automated gate evidence; policy enforcement is manual only." ] }, "legal_counsel": { "summary": "The policy must address copyright licensing, PII/data privacy, and confidentiality obligations to limit legal exposure from AI knowledge base content.", "actions": [ "Review the Knowledge Ingestion Policy for adequate coverage of copyright license requirements, fair-use limitations, and PII handling obligations under applicable privacy law.", "Confirm that the policy prohibits ingestion of legally privileged, export-controlled, or confidential third-party materials.", "Ensure that the exception review process requires legal sign-off for any exception involving content with copyright or privacy risk." ], "failure_signals": [ "Policy contains no copyright or license requirements for ingested content.", "PII handling rules are absent or do not reference applicable privacy regulations.", "Legal counsel is not listed as a required approver for high-risk exception requests." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations have informal source approval practices. Formalizing the policy and implementing automated pipeline gates are the critical maturity steps." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "cloud-native" ], "implementers": [ "Knowledge Engineering", "Legal Counsel", "GRC Team", "Policy Office" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a76.1.3 \u2014 AI risk treatment", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a76.1.3 requires organizations to select and implement controls to treat AI risks, including risks arising from training and operational data used as AI knowledge. A formal ingestion policy is a required control artifact under this treatment requirement.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10 \u2014 Data and data governance", "fit": "direct", "rationale": "EU AI Act Article 10 requires providers of high-risk AI systems to implement data governance practices covering data collection, preparation, and quality assessment. A Knowledge Ingestion Policy is a direct implementation artifact for this requirement.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 4 \u2014 Data Architecture; Ch. 13 \u2014 Data Quality", "fit": "direct", "rationale": "DAMA DMBOK2 provides the foundational model for data quality policy, including source classification, quality threshold definition, and fitness-for-purpose assessment. These concepts map directly to knowledge substrate policy requirements for AI systems.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "iso_30401", "requirement_id": "Clause 8 \u2014 Operation", "fit": "direct", "rationale": "ISO 30401:2018 Clause 8 (Operation) requires organizations to plan, implement and control the processes needed for knowledge management. This includes defining what constitutes permissible knowledge assets and the processes for their ingestion and curation.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_27002", "requirement_id": "\u00a75.12 \u2014 Classification of information", "fit": "partial", "rationale": "ISO/IEC 27002:2022 \u00a75.12 provides the classification framework required to determine which content categories are permissible in AI-facing knowledge bases. Classification policy must be integrated into the knowledge ingestion policy to prevent confidential or restricted information from entering AI substrate.", "normative_force": "voluntary-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KG-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The enterprise must maintain a formal, versioned policy framework defining permissible sources, quality thresholds, restricted content categories, and usage restrictions for AI-facing knowledge bases, with an ingestion gate that enforces policy rules before any content is written to the knowledge base. The control passes when all production ingestion requests are validated against the policy framework, unauthorized source types are rejected at the gate, and the policy has been reviewed and approved within the last 12 months.", "evidence_required": [ "knowledge_substrate_policy_document (versioned) defining permissible source categories, numeric quality thresholds, restricted content categories, usage restrictions, and exception review procedures with effective_date and approver_id", "ingestion_gate_validation_log for the last 30 days showing each ingestion request with source_type, quality_check_result, policy_match_status, and accept or reject decision", "policy_exception_request_log recording ingestion requests requiring exception review, with exception_id, requester_id, source_type, rationale, reviewer_id, approval decision, and approved_at timestamp", "annual_policy_review_record confirming the policy was reviewed, updated as needed, and approved by designated authority within the last 12 months with reviewer_id and review_completed_at" ], "machine_tests": [ "Submit an ingestion request sourcing content from a URL not in the permissible source category list \u2192 assert the ingestion gate rejects the request with error_code=unauthorized_source and no content is written to the knowledge base", "Submit content containing a restricted category pattern (e.g., personally identifiable information matching the defined PII regex) to the ingestion endpoint \u2192 assert the gate flags it with policy_violation=restricted_content_category and routes it to the exception review workflow without writing content", "Submit content with a quality score below the defined numeric threshold \u2192 assert the ingestion gate rejects the request with error_code=quality_threshold_not_met and records the rejection in the ingestion_gate_validation_log", "Submit an ingestion request with a source that was previously authorized but whose authorization has expired \u2192 assert the gate rejects with error_code=source_authorization_expired and requires re-authorization before proceeding" ], "human_review": [ "Review the policy framework for completeness, verifying it defines explicit permissible source categories, numeric quality thresholds with documented measurement methodology, and a restricted content taxonomy relevant to the organization's AI use case risk profile", "Sample 10 policy exception requests from the last 6 months and assess whether each was granted based on documented rationale reviewed by appropriate authority, or approved without adequate justification", "Evaluate whether the policy's quality thresholds and restricted content categories have been updated since the last review to reflect changes in the organization's AI use case risk profile or new regulatory requirements" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Defining permissible sources as a static whitelist of domain names rather than source category rules with authorization criteria, making the policy brittle to new legitimate sources and easy to circumvent with a subdomain", "Implementing policy checks as advisory filters that log violations but allow content to proceed into the knowledge base without requiring exception approval", "Setting quality thresholds based on automated metadata checks alone such as file size or format validity without substantive content quality criteria such as source authority, currency, and topical relevance", "Maintaining the policy as a static document disconnected from the ingestion gate, requiring manual interpretation for each ingestion decision rather than machine-enforced rule evaluation", "Granting blanket policy exceptions for entire source categories rather than evaluating individual sources, allowing low-quality or high-risk content to enter under a category-level exception" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KG" }, { "id": "KG-03", "layer": "KG", "plane": "control", "name": "Senior Accountability for Knowledge Quality and Safety", "plain": "A named executive must hold documented accountability for the quality, safety, and governance of enterprise AI knowledge bases, with defined reporting obligations, authority to direct remediation, and visibility into knowledge risk metrics through a formal executive review cadence.", "threat": { "tags": [ "accountability-gap", "executive-blindness", "risk-escalation-failure", "ai-error-propagation" ], "desc": "Without executive-level accountability, knowledge quality failures are treated as operational nuisances rather than enterprise risks. When AI systems produce harmful or incorrect outputs rooted in bad knowledge, the absence of a named accountable executive means no one has the authority or incentive to mobilize resources for remediation. Regulators and courts increasingly expect identifiable human accountability for AI system failures, and its absence aggravates liability." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 9, Art. 17", "title": "Risk management and quality management system requirements" }, { "id": "iso_42001", "section": "\u00a75.1", "title": "Top management leadership and accountability for AI" }, { "id": "iso_30401", "section": "\u00a75.1", "title": "Leadership commitment to knowledge management" } ], "sources": [ { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 9 and Art. 17 requirements informing the apeiris://knowledge/controls/KG-03 Senior Accountability for Knowledge Quality and Safety control.", "reviewed_on": "2026-07-02" }, { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a75.1 \u2014 Leadership and commitment requirements informing the apeiris://knowledge/controls/KG-03 Senior Accountability for Knowledge Quality and Safety control.", "reviewed_on": "2026-07-02" }, { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements \u00a75.1 \u2014 Leadership and commitment requirements informing the apeiris://knowledge/controls/KG-03 Senior Accountability for Knowledge Quality and Safety control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 3 \u2014 Data Governance: Executive Stewardship requirements informing the apeiris://knowledge/controls/KG-03 Senior Accountability for Knowledge Quality and Safety control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Designate a named executive \u2014 typically the Chief Data Officer, Chief AI Officer, or equivalent \u2014 as accountable for AI knowledge quality and safety. Document the accountability in a board-approved or CEO-approved mandate. Establish a quarterly executive knowledge risk review with defined inputs from the Knowledge Governance Committee.", "steps": [ "Issue a board-approved or CEO-approved executive mandate naming a specific individual accountable for AI knowledge quality and safety, with explicit authority to direct remediation budgets and escalate to the board.", "Define the executive's reporting obligations: minimum quarterly knowledge risk report to the board or audit committee covering quality metrics, open incidents, and remediation status.", "Establish a quarterly Executive Knowledge Risk Review meeting with defined inputs from the Knowledge Governance Committee including current quality scores, incident summaries, and emerging risks.", "Create a formal escalation path from the Knowledge Governance Committee to the accountable executive for issues exceeding defined risk thresholds or SLA breaches." ], "knowledge_engineer": { "summary": "The executive accountability structure means knowledge quality failures can be escalated to someone with budget authority. Engineers should surface systemic issues through the governance committee rather than treating them as purely technical matters.", "actions": [ "Prepare quality metric dashboards that feed directly into the executive quarterly review.", "Escalate recurring or high-impact knowledge quality issues through the governance committee rather than resolving silently.", "Document systemic root causes of knowledge failures in formats suitable for executive reporting." ], "failure_signals": [ "Executive review has not been held in more than 90 days.", "Quality dashboard inputs are not being prepared or delivered to the review.", "No escalation has ever reached the executive from the governance committee despite open incidents." ] }, "data_scientist": { "summary": "Senior accountability needs honest signal: the accountable executive's picture of knowledge quality and safety is only as good as the metrics and incident reporting that reach them.", "actions": [ "Deliver the accountable executive a quarterly quality and risk readout with uncensored failure data.", "Escalate material quality risks directly through the accountability chain when normal channels stall.", "Quantify the potential impact of known corpus weaknesses so accountability decisions are informed." ], "failure_signals": [ "Executive reporting shows green while known quality incidents accumulate below.", "A material corpus risk known to the team never reaches the accountable executive." ] }, "it_operations": { "summary": "Accountability requires operational transparency upward: incident data, availability, and control-health metrics for knowledge systems must roll up to the accountable executive without filtering.", "actions": [ "Feed knowledge system incident and control-health metrics into the executive reporting pack.", "Notify the accountable executive's office of severity-1 knowledge incidents per the escalation SLA.", "Keep runbook and ownership records current so accountability reviews reflect operational reality." ], "failure_signals": [ "A severity-1 knowledge incident never appears in executive reporting.", "Control-health dashboards feeding accountability reviews are stale or hand-edited." ] }, "grc_auditor": { "summary": "The executive mandate and review records are the primary artifacts for demonstrating senior accountability at the level required by EU AI Act and ISO 42001.", "actions": [ "Obtain the executive mandate document and verify it names a specific individual, not a committee or role title.", "Review quarterly knowledge risk reports for the prior year and verify they were delivered to the board or audit committee.", "Confirm that the escalation path from governance committee to executive is defined and that at least one escalation has been tested or exercised." ], "metrics": [ "Executive review held per schedule: target 100% of scheduled quarters.", "Board/audit committee report delivery: target 100% on schedule.", "Open escalations awaiting executive action beyond SLA: target 0." ], "failure_signals": [ "Mandate does not name a specific individual.", "Quarterly reports have not been delivered to the board for more than one quarter.", "No escalation path exists from the governance committee to the executive." ] }, "legal_counsel": { "summary": "Named executive accountability is a direct regulatory expectation under EU AI Act and emerging global AI governance frameworks. The mandate document is a key liability management artifact.", "actions": [ "Review the executive mandate for adequacy of accountability language and coverage of both quality and safety obligations.", "Ensure the mandate includes obligation to notify legal counsel when knowledge incidents have potential regulatory or litigation consequences.", "Confirm the mandate aligns with the company's existing AI governance policy and any regulatory commitments made to supervisors." ], "failure_signals": [ "Mandate does not reference safety obligations or regulatory exposure.", "Legal notification trigger is absent from escalation procedures.", "Mandate has not been updated to reflect changes in applicable AI regulation." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises have not yet assigned executive accountability for AI knowledge quality as a distinct obligation. The Chief Data Officer role is often the natural home, but requires explicit mandate expansion." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Executive Leadership", "Board / Audit Committee", "GRC Team", "Knowledge Management Office" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 9 and Art. 17", "fit": "direct", "rationale": "EU AI Act Articles 9 and 17 together require providers to establish a risk management system and quality management system with defined senior accountability. The quality management system must explicitly cover data and knowledge governance, making named executive accountability a direct compliance requirement for high-risk AI systems.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_42001", "requirement_id": "\u00a75.1 \u2014 Leadership and commitment", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a75.1 requires top management to demonstrate commitment to the AI management system by taking accountability for its effectiveness. This directly requires a named accountable executive with defined reporting obligations for AI knowledge quality and safety.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_30401", "requirement_id": "\u00a75.1 \u2014 Leadership and commitment", "fit": "direct", "rationale": "ISO 30401:2018 \u00a75.1 mandates that top management demonstrate leadership and commitment to knowledge management, including by ensuring resources are available and that knowledge management objectives align with strategic direction.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 3 \u2014 Data Governance: Executive Stewardship", "fit": "adjacent", "rationale": "DAMA DMBOK2 Chapter 3 provides the organizational model for executive data stewardship that serves as the precedent for knowledge quality accountability. The Chief Data Officer accountability model described in DMBOK2 is the reference pattern for this control.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KG-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A named individual must be documented as accountable for AI knowledge quality and safety through a board- or CEO-approved mandate specifying their authority to direct remediation budgets, and evidence of at least one quarterly knowledge risk review delivered to the board or audit committee within the prior 90 days must exist.", "evidence_required": [ "executive_accountability_mandate signed by board or CEO naming a specific individual, their title, and explicit authority to direct remediation budgets with a dated approval signature", "quarterly_knowledge_risk_report delivered to the board or audit committee within the prior 90 days, containing quality_metrics, open_incidents, and remediation_status sections", "escalation_path_definition document mapping risk thresholds from the Knowledge Governance Committee to the named executive with defined response_sla_hours", "executive_review_meeting_records for the prior four quarters showing scheduled date, actual date, and attendees confirming delivery to the governance committee" ], "machine_tests": [ "Query governance system for executive_accountability records where scope='ai_knowledge_quality' \u2192 assert at least one record with named_individual (string, non-null), approved_by in ['board','ceo'], and authority_to_direct_remediation=true", "Retrieve latest knowledge_risk_executive_report from document store \u2192 assert report_date within 90 days of today and document contains sections: quality_metrics, open_incidents, remediation_status", "Query escalation_path_registry for entry domain='knowledge_governance' \u2192 assert escalation_owner matches named_individual from mandate and response_sla_hours is non-null" ], "human_review": [ "Review the executive mandate document to verify it names a specific individual rather than a committee or generic role title, and that authority language explicitly covers budget direction and board escalation", "Interview the named executive or their delegate to confirm awareness of accountability obligations and that the quarterly review process is actively functioning with prepared committee inputs", "Assess whether the escalation path has been exercised or tested and that the governance committee is actively using it to escalate material knowledge quality issues rather than resolving them silently at the operational level" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Assigning accountability to a committee or a generic role title such as 'the GRC Team' rather than a named individual, making accountability non-enforceable and unauditable by regulators", "Issuing the executive mandate without board or CEO approval, reducing its legal weight as a compliance artifact and preventing it from satisfying EU AI Act Article 17 quality management documentation requirements", "Conducting executive knowledge risk reviews ad-hoc with no defined quarterly cadence, allowing governance gaps to accumulate undetected across entire fiscal quarters", "Failing to define the escalation path from the Knowledge Governance Committee to the named executive, ensuring knowledge quality failures never reach the person with authority to mobilize remediation resources", "Treating the accountability mandate as a one-time document that is not updated when the named executive changes roles or leaves the organization, leaving a governance gap with no auditable transition record" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KG" }, { "id": "KG-04", "layer": "KG", "plane": "control", "name": "Knowledge Risk Assessment", "plain": "The enterprise must conduct systematic, documented risk assessments of AI-facing knowledge bases covering knowledge gaps, stale content, poisoned or adversarially manipulated content, unauthorized sources, and provenance failures \u2014 with findings tracked to remediation and integrated into enterprise risk registers.", "threat": { "tags": [ "knowledge-gap", "stale-content", "adversarial-poisoning", "provenance-failure" ], "desc": "Knowledge risk is invisible without active assessment. Gaps \u2014 topics the knowledge base does not cover \u2014 cause AI systems to hallucinate or refuse to answer. Stale content causes AI systems to provide outdated guidance that may be harmful or non-compliant. Poisoned content, introduced through compromised ingestion pipelines or malicious contributors, can cause AI systems to provide systematically wrong or harmful outputs at scale before detection." }, "standard": [ { "id": "iso_42001", "section": "\u00a76.1.2", "title": "AI risk assessment" }, { "id": "eu_ai_act", "section": "Art. 9", "title": "Risk management system requirements" }, { "id": "dama_dmbok", "section": "Ch. 13", "title": "Data quality risk assessment" }, { "id": "w3c_prov", "section": "PROV-DM \u00a72", "title": "Provenance model for knowledge asset traceability" } ], "sources": [ { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a76.1.2 \u2014 AI risk assessment requirements informing the apeiris://knowledge/controls/KG-04 Knowledge Risk Assessment control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 9 \u2014 Risk management system requirements informing the apeiris://knowledge/controls/KG-04 Knowledge Risk Assessment control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 13 \u2014 Data Quality Management requirements informing the apeiris://knowledge/controls/KG-04 Knowledge Risk Assessment control.", "reviewed_on": "2026-07-02" }, { "id": "w3c_prov", "title": "W3C PROV Data Model", "authority": "World Wide Web Consortium", "source_type": "standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2013-04-30", "retrieved_on": "2026-07-02", "canonical_url": "https://www.w3.org/TR/prov-dm/", "license": "open-access", "status": "current", "flagship": false, "source_id": "w3c_prov", "relationship": "implementation_pattern", "rationale": "Establishes W3C PROV Data Model PROV-DM \u00a72 \u2014 Data Model requirements informing the apeiris://knowledge/controls/KG-04 Knowledge Risk Assessment control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Conduct annual comprehensive knowledge risk assessments and trigger ad-hoc assessments on material changes (new AI system, major ingestion pipeline change, external provider change). Use a structured risk taxonomy covering gap risk, currency risk, integrity risk, provenance risk, and legal risk. Register all findings in the enterprise risk register with assigned owners and remediation SLAs.", "steps": [ "Define a knowledge risk taxonomy with categories for gap risk, currency/staleness risk, integrity and poisoning risk, provenance and traceability risk, and legal/compliance risk.", "Conduct annual full-scope knowledge risk assessments for each AI-facing knowledge base, using automated staleness scans, gap analysis against domain topic coverage targets, and provenance audit samples.", "Trigger ad-hoc risk assessments within 10 business days of any material change: new AI system deployment, major ingestion pipeline modification, external provider change, or knowledge-related security incident.", "Register all identified risks in the enterprise risk register with severity scores, assigned remediation owners, target remediation dates, and tracking through to closure." ], "knowledge_engineer": { "summary": "Risk assessments identify the specific gaps, stale artifacts, and provenance breaks that make AI systems unreliable. Engineers own the technical execution of assessments and the tooling that surfaces findings.", "actions": [ "Build and maintain automated staleness scanning that flags knowledge artifacts exceeding defined age thresholds by content category.", "Run gap analysis against domain topic coverage maps quarterly and surface results to the governance committee.", "Implement provenance traceability checks that verify source metadata integrity on a sample basis at each assessment cycle." ], "failure_signals": [ "No automated staleness scan tooling exists; assessments are entirely manual.", "Risk assessments have not been conducted for more than 14 months.", "Risk register contains open knowledge risk items with no assigned owner or remediation date." ] }, "data_scientist": { "summary": "Knowledge risk directly affects model output quality. Data scientists should use risk assessment findings to tune retrieval parameters, implement fallback strategies, and flag high-risk knowledge domains for extra validation in RAG pipelines.", "actions": [ "Consume knowledge risk assessment outputs to calibrate confidence thresholds in RAG retrieval pipelines.", "Implement retrieval-time staleness checks that surface artifact age to downstream generation steps.", "Flag AI outputs sourced from knowledge artifacts identified as high-risk in the most recent assessment for additional human review." ], "failure_signals": [ "RAG pipelines have no staleness or risk metadata flowing from knowledge stores.", "High-risk knowledge domains are not reflected in any model confidence or uncertainty signaling.", "Data scientists are not receiving knowledge risk assessment findings." ] }, "it_operations": { "summary": "Knowledge risk assessments must include operational failure modes: pipeline single points of failure, backup gaps, credential sprawl, and monitoring blind spots belong in the risk register with owners.", "actions": [ "Contribute operational failure modes and their likelihood to each knowledge risk assessment cycle.", "Track remediation of infrastructure risks accepted into the register through to closure.", "Re-trigger assessment when architecture changes materially alter the operational risk picture." ], "failure_signals": [ "The risk register omits a pipeline single point of failure that later causes an outage.", "Accepted infrastructure risks have no owner or remediation date." ] }, "grc_auditor": { "summary": "The risk assessment records and risk register entries are the primary evidence for demonstrating systematic knowledge risk management.", "actions": [ "Request the most recent knowledge risk assessment report and verify it covers all defined risk categories.", "Confirm that assessment findings are registered in the enterprise risk register with owners and remediation dates.", "Verify that ad-hoc assessments were triggered for all material changes in the prior 12 months." ], "metrics": [ "Annual assessment completion: target 100% on schedule.", "Risk register currency: all open items have valid owners and remediation dates.", "Ad-hoc assessment trigger compliance: target 100% of qualifying events." ], "failure_signals": [ "Assessment has not been conducted in more than 18 months.", "Risk register has open items with no assigned owner.", "Material changes occurred with no corresponding ad-hoc assessment." ] }, "legal_counsel": { "summary": "The knowledge risk register is where legal exposure gets named: IP contamination, privacy leakage, and regulatory staleness risks need legal assessment of severity and defensible treatment decisions.", "actions": [ "Assess legal-exposure risks (IP, privacy, regulatory currency) in each assessment cycle with counsel input.", "Document the legal basis for risk acceptance decisions on knowledge risks with legal dimensions.", "Re-review the register when new regulation changes the severity of existing knowledge risks." ], "failure_signals": [ "A known IP contamination risk is accepted with no legal review of the decision.", "New regulation invalidates the register's severity ratings and nobody updates them." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Knowledge risk assessment is typically informal or absent in enterprises that have not yet experienced a significant AI knowledge failure. Structured taxonomy and automated tooling are the primary maturity accelerators." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "cloud-native", "federated-enterprise" ], "implementers": [ "Risk Management", "Knowledge Engineering", "Data Science", "GRC Team" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a76.1.2 \u2014 AI risk assessment", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a76.1.2 requires organizations to conduct AI risk assessments that identify risks associated with AI system operation, including risks arising from the knowledge and data the AI system uses. Systematic knowledge risk assessment directly implements this clause.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9 \u2014 Risk management system", "fit": "direct", "rationale": "EU AI Act Article 9 requires a continuous risk management system for high-risk AI systems, including identification and analysis of known and foreseeable risks. Knowledge risks \u2014 gaps, staleness, poisoning \u2014 are foreseeable risks that must be assessed and mitigated under this requirement.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 13 \u2014 Data Quality Management", "fit": "direct", "rationale": "DAMA DMBOK2 Chapter 13 provides the methodological foundation for data quality risk assessment including completeness, currency, and integrity risk dimensions. These map directly to the knowledge gap, staleness, and poisoning risk categories required by this control.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "w3c_prov", "requirement_id": "PROV-DM \u00a72 \u2014 Data Model", "fit": "partial", "rationale": "W3C PROV-DM provides the formal model for provenance traceability that enables assessment of provenance risk in knowledge assets. Implementing PROV-compatible provenance metadata is a technical prerequisite for conducting provenance risk assessments at scale.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KG-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A documented knowledge risk assessment covering all five categories \u2014 gap, currency, integrity, provenance, and legal \u2014 must have been completed within the prior 14 months for each AI-facing knowledge base, with all findings registered in the enterprise risk register with assigned owners and target remediation dates, and ad-hoc assessments triggered within 10 business days of all qualifying material changes.", "evidence_required": [ "knowledge_risk_assessment_report dated within 14 months containing scored findings for each of the five risk categories: gap_risk, currency_risk, integrity_risk, provenance_risk, and legal_risk", "risk_register_extract with filter domain='knowledge' showing all open items with assigned_owner, remediation_date, and tracking_status fields populated for each", "ad_hoc_assessment_trigger_log documenting material change events in the prior 12 months with linked ad_hoc_assessment_id and completion_date proving assessment within 10 business days", "automated_staleness_scan_output showing age-threshold breach counts by content category and the timestamp of the most recent automated run" ], "machine_tests": [ "Query risk_register where domain='knowledge' and status != 'closed' \u2192 assert every record has assigned_owner (non-null string), remediation_date (future date), and status in ['open','in-progress']", "Retrieve latest knowledge_risk_assessment metadata \u2192 assert assessment_date within 420 days of today and risk_categories_covered is a superset of ['gap','currency','integrity','provenance','legal']", "Query change_event_log for past 365 days where event_type in ['new_ai_deployment','ingestion_pipeline_change','external_provider_change','knowledge_security_incident'] \u2192 for each event assert linked ad_hoc_assessment completed within 10 business days" ], "human_review": [ "Review the risk assessment methodology document to confirm the five risk categories are assessed with distinct evaluation criteria and scoring rubrics rather than collapsed into a single generic data quality score", "Assess whether provenance traceability checks are sampling sufficient artifact volume across content categories to provide statistically meaningful coverage rather than cherry-picking a token sample", "Verify that risk register items from prior assessments are progressing to remediation closure rather than accumulating as unactioned backlog with repeatedly deferred remediation dates" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Treating knowledge risk assessment as a single annual checkbox with no automated tooling, causing findings to become outdated within months and material changes to proceed without risk evaluation", "Conflating knowledge risk with general data quality metrics and omitting gap risk, poisoning risk, and provenance failure as distinct risk categories, leaving major threat vectors invisible", "Registering risk assessment findings in a standalone assessment report rather than the enterprise risk register, preventing executive visibility, SLA tracking, and integration with enterprise remediation workflows", "Failing to trigger ad-hoc assessments after material changes such as new AI system deployments or major ingestion pipeline modifications, allowing risk posture changes to go unassessed until the next annual cycle", "Conducting gap analysis only at initial knowledge base deployment and not repeating it as AI system usage patterns and required knowledge domains evolve over time" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KG" }, { "id": "KG-05", "layer": "KG", "plane": "control", "name": "External Knowledge Provider Governance", "plain": "The enterprise must govern all third-party knowledge providers and data enrichment services through formal contracts with quality and security obligations, periodic audits of provider compliance, and documented controls for provider failure, substitution, and exit.", "threat": { "tags": [ "supply-chain-contamination", "unaudited-source", "provider-failure", "third-party-drift" ], "desc": "Third-party knowledge providers are a primary vector for introducing unverified, stale, or adversarially manipulated content into enterprise AI knowledge bases. Provider quality degrades silently over time; without periodic audits, contamination propagates into AI outputs before detection. Provider failure or abrupt service discontinuation leaves AI systems operating on a frozen or incomplete knowledge substrate without fallback governance." }, "standard": [ { "id": "iso_42001", "section": "A.10.3", "title": "Suppliers" }, { "id": "eu_ai_act", "section": "Art. 10, Art. 25", "title": "Data governance and third-party obligations" }, { "id": "dama_dmbok", "section": "Ch. 10", "title": "Reference and master data \u2014 external source governance" }, { "id": "iso_27002", "section": "\u00a75.19", "title": "Information security in supplier relationships" } ], "sources": [ { "id": "aws_bedrock_knowledge_bases_2024", "title": "Amazon Bedrock Knowledge Bases", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_bedrock_knowledge_bases_2024", "relationship": "informative_reference", "rationale": "Establishes Amazon Bedrock Knowledge Bases requirements informing the apeiris://knowledge/controls/KG-05 External Knowledge Provider Governance control.", "reviewed_on": "2026-07-01" }, { "id": "databricks_unity_catalog_2024", "title": "Databricks Unity Catalog (Knowledge Gov.)", "authority": "Databricks, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024", "retrieved_on": "2026-06-29", "canonical_url": "https://docs.databricks.com/en/data-governance/unity-catalog/index.html", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "databricks_unity_catalog_2024", "relationship": "informative_reference", "rationale": "Establishes Databricks Unity Catalog (Knowledge Gov.) requirements informing the apeiris://knowledge/controls/KG-05 External Knowledge Provider Governance control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain a registry of all external knowledge providers. Require contractual quality SLAs, security obligations, audit rights, and breach notification clauses. Conduct annual provider audits or accept SOC 2 Type II / ISO 27001 equivalent. Implement provider dependency monitoring and documented fallback procedures for each critical provider.", "steps": [ "Maintain a registry of all external knowledge providers including data enrichment APIs, licensed content databases, and RAG grounding services, with risk classification and business criticality rating.", "Require all providers to sign contracts that include quality SLAs, data integrity obligations, security requirements, audit rights, breach notification clauses, and exit/data-return provisions.", "Conduct annual provider governance reviews covering SLA performance data, security certification currency, audit findings, and any material changes to the provider's data collection or processing practices.", "Implement provider dependency monitoring that detects provider API degradation, content quality drops, or service outages and triggers the documented fallback procedure within defined RTO thresholds." ], "knowledge_engineer": { "summary": "External providers are third-party dependencies with their own quality and security postures. Engineers must monitor provider health signals and implement fallback logic in ingestion pipelines.", "actions": [ "Implement health checks on all external provider API connections that surface quality and availability metrics to the provider registry dashboard.", "Build fallback logic in ingestion pipelines for each critical external provider covering both service outage and content quality degradation scenarios.", "Flag content from providers with open audit findings or expired certifications in the knowledge store with elevated risk metadata." ], "failure_signals": [ "External provider registry is incomplete or not maintained.", "No fallback procedure exists for any critical external provider.", "Provider content is entering production knowledge stores without quality validation checks." ] }, "data_scientist": { "summary": "External providers ship your input distribution: provider content quality must be measured on arrival and over time, because upstream drift becomes your model's quality problem.", "actions": [ "Baseline and monitor content quality per provider, alerting on distribution or quality drift.", "Include provider identity in corpus metadata so quality regressions are attributable.", "Evaluate candidate providers with sampled-content quality assessments before onboarding." ], "failure_signals": [ "A provider's silent format change degrades retrieval quality for weeks before detection.", "Quality issues cannot be attributed because provider identity is missing from corpus metadata." ] }, "it_operations": { "summary": "Provider integrations are attack and failure surface: credentials, delivery pipelines, and update feeds from external knowledge providers need the same operational rigor as any third-party integration.", "actions": [ "Manage provider credentials in the secrets store with rotation and least-privilege scopes.", "Monitor provider feed health and validate deliveries against expected schemas and volumes.", "Maintain suspension runbooks so a compromised or failing provider can be cut off cleanly." ], "failure_signals": [ "A provider credential with excessive scope persists long after the integration changed.", "A failed provider feed goes unnoticed until users report stale answers." ] }, "grc_auditor": { "summary": "Provider contracts, audit records, and registry completeness are the primary evidence artifacts for external knowledge provider governance.", "actions": [ "Request the external knowledge provider registry and verify completeness against production ingestion pipeline configurations.", "Sample provider contracts for five providers and verify they contain required quality SLA, audit rights, and breach notification clauses.", "Confirm that annual governance reviews have been conducted for all critical providers and that open findings are tracked to remediation." ], "metrics": [ "Provider registry completeness: target 100% of active providers registered.", "Contracts with required clauses: target 100% of critical providers.", "Annual governance reviews completed on schedule: target 100%." ], "failure_signals": [ "Registry is incomplete \u2014 active providers not registered.", "Provider contracts lack audit rights or quality SLA clauses.", "No annual governance reviews have been conducted in the prior 18 months." ] }, "legal_counsel": { "summary": "Provider contracts must create enforceable obligations for knowledge quality, data rights, and exit. Legal review of provider contracts is required before onboarding any critical knowledge provider.", "actions": [ "Review all external knowledge provider contracts before execution for adequacy of quality SLA, data rights, IP/copyright obligations, breach notification, audit rights, and exit provisions.", "Ensure contracts include provisions addressing AI-specific usage rights and prohibitions on provider use of the enterprise's query patterns for model training.", "Confirm that breach notification clauses align with enterprise obligations under applicable privacy and AI regulations." ], "failure_signals": [ "Provider contracts are executed without legal review.", "Contracts do not address AI-specific data usage rights.", "No breach notification clause or threshold is defined in provider contracts." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises treat external knowledge providers as commodity vendors rather than AI supply chain dependencies. Elevating them to supply chain risk management is the primary maturity shift required." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "cloud-native", "multi-tenant" ], "implementers": [ "Vendor Management", "Legal Counsel", "Knowledge Engineering", "GRC Team" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "A.10.3 \u2014 Suppliers", "fit": "direct", "rationale": "ISO/IEC 42001:2023 Annex A control A.10.3 requires organizations to ensure that their use of suppliers aligns with the organization's approach to responsible AI development and use. External knowledge providers are a direct supplier dependency governed under this control.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 10 and Art. 25", "fit": "direct", "rationale": "EU AI Act Article 10 requires data governance practices for high-risk AI systems that extend to third-party data sources. Article 25 establishes obligations for providers and deployers regarding third-party components. External knowledge provider governance is a direct implementation requirement for high-risk AI systems using third-party knowledge.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27002", "requirement_id": "\u00a75.19 \u2014 Information security in supplier relationships", "fit": "direct", "rationale": "ISO/IEC 27002:2022 \u00a75.19 requires organizations to define and implement processes to manage information security risks associated with the use of supplier products or services. External knowledge providers are suppliers under this requirement, and their content integrity is a direct information security concern.", "normative_force": "voluntary-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 10 \u2014 Reference and Master Data Management", "fit": "partial", "rationale": "DAMA DMBOK2 Chapter 10 addresses governance of external reference data sources, including vendor data quality requirements, contractual SLAs, and monitoring. These practices directly inform the external knowledge provider governance model.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_bedrock_kb", "requirement_id": "Knowledge Base Data Source Configuration", "fit": "adjacent", "rationale": "Amazon Bedrock Knowledge Bases provides reference architecture for governing external data sources connected to AI systems, including access controls, refresh policies, and source validation. Its data source governance model informs practical implementation of external provider controls in cloud-native deployments.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "databricks_unity", "requirement_id": "Unity Catalog \u2014 External Locations and Credentials", "fit": "adjacent", "rationale": "Databricks Unity Catalog's external location and credential governance model provides a reference implementation pattern for controlling access to external knowledge sources and auditing their usage within data and AI pipelines.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KG-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "All active external knowledge providers must appear in a complete provider registry with risk classification and business criticality ratings; all critical providers must be governed by contracts containing quality SLA, audit rights, breach notification, and exit provisions; annual governance reviews must be completed for all critical providers; and documented fallback procedures with defined RTOs must exist for each critical provider.", "evidence_required": [ "external_knowledge_provider_registry listing all active providers with risk_classification, business_criticality, contract_reference_id, certification_expiry, and last_governance_review_date for each", "provider_contract_sample for at least three critical providers containing signed quality_sla, audit_rights_clause, breach_notification_threshold, ai_usage_restrictions, and exit_and_data_return provisions", "annual_provider_governance_review_report for each critical provider showing sla_performance_data, certification_currency, open_audit_findings, and remediation_status", "provider_fallback_procedure_document per critical provider specifying activation_trigger_conditions, fallback_knowledge_source, rto_hours, and responsible_team", "provider_health_monitoring_log showing availability metrics and content quality indicators for all active providers over the prior 30 days" ], "machine_tests": [ "Query provider_registry for all records where status='active' \u2192 assert every record has risk_classification, business_criticality, contract_id, and last_governance_review_date within 365 days", "Query ingestion_pipeline_config for all external_source_connections \u2192 cross-reference against provider_registry \u2192 assert zero active connections to providers not present in the registry", "Query fallback_procedure_store for each provider where business_criticality='critical' \u2192 assert every critical provider has a fallback record with rto_hours (non-null) and fallback_source (non-null)" ], "human_review": [ "Review a sample of five provider contracts to verify they contain enforceable quality SLA language, audit rights, AI-specific data usage restrictions prohibiting provider use of enterprise query patterns for model training, and data-return exit provisions", "Assess whether provider dependency monitoring is sensitive enough to detect content quality degradation \u2014 not only service outages \u2014 and that quality degradation triggers the correct fallback procedure rather than silently serving degraded content", "Verify that legal counsel has reviewed all critical provider contracts before execution and that the AI-specific usage rights provisions meet current regulatory requirements under applicable data protection and AI governance regulations" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Onboarding external knowledge providers without formal contracts, treating them as commodity data feeds rather than AI supply chain dependencies with enforceable quality and security obligations", "Accepting provider SOC 2 Type II reports as a substitute for knowledge-specific quality SLA measurement, when SOC 2 scope covers security controls but not content accuracy, currency, or AI-specific integrity requirements", "Failing to document fallback procedures until after a provider outage occurs, causing improvised remediation under pressure with extended knowledge base degradation affecting AI output quality", "Allowing provider quality certifications to lapse without triggering a risk re-classification or re-audit, leaving the provider registry stale and risk assessments based on outdated compliance status", "Not including AI-specific data usage restrictions in provider contracts, creating an exposure where providers can use enterprise query logs and interaction patterns to train or improve their own AI models" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KG" }, { "id": "KG-06", "layer": "KG", "plane": "lifecycle", "name": "Knowledge Incident Response", "plain": "The enterprise must maintain documented procedures for detecting, containing, eradicating, and recovering from knowledge quality failures, poisoning incidents, systematic citation errors, and large-scale hallucination events attributable to knowledge base defects, including stakeholder notification and post-incident review.", "threat": { "tags": [ "knowledge-poisoning", "mass-propagation-error", "citation-failure", "contamination-spread" ], "desc": "Knowledge incidents differ from conventional security incidents in their propagation model: a single poisoned or erroneous knowledge artifact can be cited across thousands of AI-generated outputs before detection. The longer the contamination persists, the greater the downstream harm \u2014 including misinformed decisions, regulatory violations, reputational damage, and safety failures. Without prepared incident response procedures, organizations improvise under pressure and typically fail to contain contamination or assess full impact." }, "standard": [ { "id": "iso_42001", "section": "\u00a710.2", "title": "AI incident management and nonconformity" }, { "id": "eu_ai_act", "section": "Art. 73", "title": "Reporting of serious incidents" }, { "id": "itil_4", "section": "Incident Management Practice", "title": "Incident detection, classification, and resolution" }, { "id": "iso_30401", "section": "\u00a710.1", "title": "Nonconformity and corrective action" } ], "sources": [ { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a710.2 \u2014 Nonconformity and corrective action requirements informing the apeiris://knowledge/controls/KG-06 Knowledge Incident Response control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 73 \u2014 Reporting of serious incidents requirements informing the apeiris://knowledge/controls/KG-06 Knowledge Incident Response control.", "reviewed_on": "2026-07-02" }, { "id": "itil_4", "title": "ITIL 4", "authority": "PeopleCert / Axelos", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "4", "published_on": "2019-02-28", "retrieved_on": "2026-07-02", "canonical_url": "https://www.axelos.com/certifications/itil-service-management/itil-4-foundation", "license": "proprietary", "status": "current", "flagship": false, "source_id": "itil_4", "relationship": "informative_reference", "rationale": "Establishes ITIL 4 Incident Management Practice requirements informing the apeiris://knowledge/controls/KG-06 Knowledge Incident Response control.", "reviewed_on": "2026-07-02" }, { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements \u00a710.1 \u2014 Nonconformity and corrective action requirements informing the apeiris://knowledge/controls/KG-06 Knowledge Incident Response control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 13 \u2014 Data Quality Incident Management requirements informing the apeiris://knowledge/controls/KG-06 Knowledge Incident Response control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Maintain a Knowledge Incident Response Plan as a versioned document integrated into the enterprise incident response framework. Define knowledge-specific incident categories and severity levels. Test the plan annually via tabletop exercise. Implement automated contamination detection monitoring that triggers incident workflows.", "steps": [ "Develop and maintain a Knowledge Incident Response Plan with defined incident categories (poisoning, staleness-at-scale, citation error, provenance failure), severity levels, detection triggers, and role assignments for containment and eradication.", "Implement automated monitoring for knowledge quality degradation signals that can trigger incident response workflows: sudden quality score drops, anomalous citation patterns, provenance check failures, and unusual ingestion volumes from external sources.", "Define and implement containment procedures including quarantine of suspect knowledge artifacts, isolation of affected AI system knowledge partitions, and rollback to the last known-good knowledge snapshot.", "Establish post-incident review procedures requiring root cause analysis, impact assessment (scope of AI outputs affected), remediation validation, and lessons-learned integration into governance controls within 30 days of incident closure.", "Align knowledge incident reporting with regulatory notification obligations under EU AI Act Article 73 and applicable sector-specific regulations." ], "knowledge_engineer": { "summary": "Knowledge incidents require rapid technical response \u2014 quarantine, rollback, and root cause analysis. Engineers own the technical execution of containment and recovery procedures.", "actions": [ "Maintain tested rollback procedures for each knowledge base that can restore a known-good state within the defined RTO.", "Implement quarantine tagging in the knowledge store that immediately suppresses retrieval of flagged artifacts without requiring full deletion.", "Participate in annual tabletop exercises and update technical playbooks based on findings." ], "failure_signals": [ "No rollback capability exists for any knowledge base.", "Quarantine mechanism does not suppress retrieval in all consuming AI pipelines.", "Incident response plan has not been tested in more than 18 months." ] }, "data_scientist": { "summary": "Knowledge incidents need blast-radius analysis: when bad content is found, someone must determine which outputs, over what period, for which users were affected \u2014 that is an analytical task on lineage and logs.", "actions": [ "Build and test queries that enumerate outputs influenced by a given contaminated asset via lineage records.", "Quantify incident blast radius (affected responses, users, time window) for severity classification.", "Verify post-remediation that contaminated content no longer influences retrieval or cached results." ], "failure_signals": [ "Blast radius for a contamination incident cannot be determined from available records.", "Post-remediation checks miss cached or embedded traces of the contaminated content." ] }, "it_operations": { "summary": "IT Operations is responsible for operating the monitoring and alerting infrastructure that detects knowledge incidents and for executing the infrastructure-level containment procedures.", "actions": [ "Configure and maintain knowledge quality monitoring dashboards with alerting thresholds that trigger incident response workflows.", "Test knowledge base snapshot and rollback infrastructure quarterly to validate RTO compliance.", "Integrate knowledge incident alerts with the enterprise ITSM ticketing system for tracking and SLA management." ], "failure_signals": [ "Monitoring infrastructure does not cover all AI-facing knowledge stores.", "Snapshot and rollback infrastructure has not been tested in the prior quarter.", "Knowledge incidents are not tracked in the enterprise ITSM system." ] }, "grc_auditor": { "summary": "The incident response plan, test records, and incident logs are the primary evidence artifacts for demonstrating knowledge incident preparedness and regulatory compliance.", "actions": [ "Request the Knowledge Incident Response Plan and verify it is current, versioned, and approved by the Knowledge Governance Committee.", "Review records of the most recent tabletop exercise and confirm that findings were incorporated into the plan.", "Sample incident logs from the prior 12 months and verify that all incidents were handled per the plan with complete documentation." ], "metrics": [ "Annual tabletop exercise completion: target 100%.", "Incidents with complete documentation per plan: target 100%.", "Post-incident reviews completed within 30-day SLA: target \u226595%." ], "failure_signals": [ "No tabletop exercise has been conducted in more than 18 months.", "Incident logs show incidents handled without reference to the plan.", "Post-incident reviews are consistently completed late or not at all." ] }, "legal_counsel": { "summary": "Knowledge incidents can trigger notification and reporting duties: contaminated or erroneous content that influenced customer outcomes may require customer notice, regulator reports, and evidence preservation.", "actions": [ "Define the legal triggers (notification, EU AI Act Article 73 serious-incident reporting where applicable) in the incident playbook.", "Ensure incident evidence \u2014 affected outputs, timelines, remediation \u2014 is preserved in litigation-ready form.", "Review post-incident communications so factual statements match the preserved record." ], "failure_signals": [ "A reportable incident is closed internally without assessing notification duties.", "Incident evidence needed for a later claim was not preserved." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations have no knowledge-specific incident response capability and would handle knowledge incidents as ad-hoc operational issues. The key maturity step is integrating knowledge incident categories into the existing enterprise incident response framework." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "cloud-native" ], "implementers": [ "Incident Response Team", "Knowledge Engineering", "IT Operations", "GRC Team" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a710.2 \u2014 Nonconformity and corrective action", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a710.2 requires organizations to react to nonconformities by taking action to control and correct them, evaluate actions to eliminate root causes, and implement corrective actions. Knowledge incidents are nonconformities requiring structured response under this requirement.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 73 \u2014 Reporting of serious incidents", "fit": "direct", "rationale": "EU AI Act Article 73 requires providers of high-risk AI systems to report serious incidents to market surveillance authorities within defined deadlines. Knowledge-sourced AI failures can constitute serious incidents, making a documented incident response plan with reporting pathways a direct regulatory requirement.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "itil_4", "requirement_id": "Incident Management Practice", "fit": "direct", "rationale": "ITIL 4 Incident Management practice provides the operational framework for incident detection, classification, escalation, resolution, and review. Knowledge incident response procedures should be built as an extension of the ITIL 4 incident management process already present in most enterprises.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_30401", "requirement_id": "\u00a710.1 \u2014 Nonconformity and corrective action", "fit": "direct", "rationale": "ISO 30401:2018 \u00a710.1 (Nonconformity and corrective action) requires organizations to address nonconformities in knowledge management processes and take corrective action to prevent recurrence. Knowledge quality failures and poisoning incidents are direct nonconformities requiring structured response under this clause.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 13 \u2014 Data Quality Incident Management", "fit": "partial", "rationale": "DAMA DMBOK2 Chapter 13 addresses data quality incident identification, escalation, and remediation. The data quality incident management patterns in DMBOK2 directly inform knowledge incident classification and response procedure design.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://knowledge/controls/KG-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A versioned Knowledge Incident Response Plan must exist covering all four incident categories \u2014 poisoning, staleness-at-scale, citation error, and provenance failure \u2014 with documented containment, rollback, and post-incident review procedures; automated monitoring must be configured to trigger incident workflows; the plan must have been tested via tabletop exercise within the prior 18 months; and all prior-year incidents must have completed post-incident reviews within 30 days of closure.", "evidence_required": [ "knowledge_incident_response_plan versioned document with approval_date, incident_categories covering poisoning/staleness-at-scale/citation-error/provenance-failure, role_assignments, and containment and rollback procedures defined", "tabletop_exercise_record within prior 18 months showing scenario_type, participants, findings_count, and plan_update_date confirming findings were incorporated", "knowledge_monitoring_alert_configuration showing defined alert_rules for quality_score_drops, anomalous_citation_patterns, provenance_check_failures, and ingestion_volume_anomalies with threshold values", "incident_log for prior 12 months showing each knowledge incident with category, severity, containment_timestamp, rollback_executed (boolean), and post_incident_review_date", "rollback_capability_test_record for each production knowledge base showing tested_rto_minutes and last_test_date within prior 90 days" ], "machine_tests": [ "Query knowledge_monitoring_system for alert_rules where domain='knowledge' \u2192 assert rules exist covering all 4 trigger categories: quality_score_drop, citation_anomaly, provenance_failure, ingestion_volume_spike with non-null threshold values", "Query knowledge_base_snapshot_store for each production knowledge base \u2192 assert latest_snapshot_age_hours < 24 and rollback_last_tested_date within 90 days", "Query incident_log for prior 12 months where category starts with 'knowledge' \u2192 assert every record has containment_timestamp, rollback_executed (boolean), and post_incident_review_date within 30 days of incident_closed_date" ], "human_review": [ "Review the Knowledge Incident Response Plan to confirm quarantine procedures suppress artifact retrieval across all consuming AI pipelines including vector stores, caches, and embedding indices \u2014 not only the primary knowledge store interface", "Assess whether automated monitoring thresholds are calibrated to detect knowledge poisoning at a meaningful scale before widespread propagation into AI outputs rather than triggering only after obvious service degradation", "Review post-incident review records to verify root cause analysis produces updates to governance controls rather than only one-time technical fixes, ensuring systemic issues are not allowed to recur" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Routing knowledge incidents through the generic IT helpdesk without a knowledge-specific incident category, causing contaminated artifacts to continue propagating into AI outputs while the ticket waits in the general service queue", "Implementing rollback capability only at the knowledge database layer while failing to flush downstream caches, vector indices, and embedding stores that retain contaminated artifacts independently of the source knowledge base", "Defining incident categories at plan inception but not specifying quantitative detection thresholds, causing incident response activation to rely on subjective staff escalation rather than automated threshold-based triggering", "Treating post-incident review as a documentation formality rather than a governance control update process, resulting in recurring incidents from the same root cause categories across successive cycles", "Scoping knowledge incident notification only to internal operational SLAs and not aligning it with regulatory reporting obligations under EU AI Act Article 73, creating compliance gaps for incidents that qualify as serious" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KG" }, { "id": "KG-07", "layer": "KG", "plane": "control", "name": "Knowledge Program Metrics and Effectiveness Reporting", "plain": "The enterprise must define, collect, and report a standard set of metrics tracking knowledge quality, currency, coverage, governance compliance, and the measurable impact of knowledge governance on AI output quality \u2014 with reports delivered to the Knowledge Governance Committee and executive sponsor on a defined cadence.", "threat": { "tags": [ "metric-blindness", "governance-drift", "effectiveness-blindspot", "reporting-gap" ], "desc": "Without a defined metrics program, knowledge governance becomes a documentation exercise disconnected from actual AI output quality. Governance committees make decisions without empirical data, quality trends are invisible until they cause incidents, and program investments cannot be justified or prioritized. Metric-blind organizations systematically underinvest in knowledge governance relative to actual risk exposure." }, "standard": [ { "id": "iso_42001", "section": "\u00a79.1", "title": "Monitoring, measurement, analysis and evaluation" }, { "id": "iso_30401", "section": "\u00a79.1", "title": "Performance evaluation for knowledge management" }, { "id": "itil_4", "section": "Continual Improvement Practice", "title": "Measurement and reporting for service improvement" }, { "id": "dama_dmbok", "section": "Ch. 13", "title": "Data quality metrics and KPIs" } ], "sources": [ { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a79.1 \u2014 Monitoring, measurement, analysis and evaluation requirements informing the apeiris://knowledge/controls/KG-07 Knowledge Program Metrics and Effectiveness Reporting control.", "reviewed_on": "2026-07-02" }, { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements \u00a79.1 \u2014 Monitoring and evaluation requirements informing the apeiris://knowledge/controls/KG-07 Knowledge Program Metrics and Effectiveness Reporting control.", "reviewed_on": "2026-07-02" }, { "id": "itil_4", "title": "ITIL 4", "authority": "PeopleCert / Axelos", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "4", "published_on": "2019-02-28", "retrieved_on": "2026-07-02", "canonical_url": "https://www.axelos.com/certifications/itil-service-management/itil-4-foundation", "license": "proprietary", "status": "current", "flagship": false, "source_id": "itil_4", "relationship": "informative_reference", "rationale": "Establishes ITIL 4 Continual Improvement Practice requirements informing the apeiris://knowledge/controls/KG-07 Knowledge Program Metrics and Effectiveness Reporting control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 13 \u2014 Data Quality Metrics requirements informing the apeiris://knowledge/controls/KG-07 Knowledge Program Metrics and Effectiveness Reporting control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 9 \u2014 Risk management: monitoring effectiveness requirements informing the apeiris://knowledge/controls/KG-07 Knowledge Program Metrics and Effectiveness Reporting control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define a Knowledge Program Scorecard with metrics across five dimensions: quality (accuracy, completeness, consistency), currency (staleness rate, refresh lag), coverage (topic coverage ratio, gap count), governance compliance (policy adherence, ownership completeness), and AI output impact (citation accuracy rate, hallucination rate by knowledge domain). Automate metric collection and publish dashboards with monthly committee reporting and quarterly executive reporting.", "steps": [ "Define the Knowledge Program Scorecard with at least 15 metrics across the five required dimensions \u2014 quality, currency, coverage, governance compliance, and AI output impact \u2014 with baseline values, targets, and measurement methodology for each.", "Automate metric collection through knowledge base instrumentation, AI pipeline telemetry, and governance process tooling; publish a live dashboard accessible to knowledge stewards and governance committee members.", "Publish monthly metric reports to the Knowledge Governance Committee covering trend analysis, threshold breaches, and recommended actions; escalate material degradations to the executive sponsor within 5 business days.", "Deliver quarterly program effectiveness reports to the executive sponsor and, where applicable, the board/audit committee, summarizing governance investment vs. measured impact on AI output quality." ], "knowledge_engineer": { "summary": "Engineers are responsible for instrumenting knowledge bases and pipelines to produce the raw telemetry that feeds the metrics program. Automation is essential \u2014 manual metric collection introduces lag and errors.", "actions": [ "Instrument all knowledge stores and ingestion pipelines to emit quality, currency, and provenance telemetry to the metrics aggregation layer.", "Implement automated citation accuracy sampling that measures the rate of AI citations accurately reflecting their source knowledge artifacts.", "Build and maintain the knowledge governance dashboard so committee members have real-time visibility into program health." ], "failure_signals": [ "Metrics are collected manually or sporadically rather than automatically.", "Dashboard has not been updated in more than 30 days.", "AI output impact metrics (citation accuracy, hallucination rate by domain) are absent from the scorecard." ] }, "data_scientist": { "summary": "Data scientists own the AI output impact metrics that link knowledge quality to model behavior. These are the most important metrics for justifying knowledge governance investment.", "actions": [ "Define and implement hallucination rate by knowledge domain metrics using RAG pipeline telemetry and ground-truth evaluation sets.", "Contribute citation accuracy measurement methodology to the Knowledge Program Scorecard.", "Surface knowledge-domain-level quality signals in model evaluation reports to create a closed feedback loop with knowledge engineering." ], "failure_signals": [ "No AI output impact metrics are defined or measured.", "Hallucination rate is measured globally but not attributed to specific knowledge domains.", "Data science teams are not receiving or using knowledge quality metrics." ] }, "it_operations": { "summary": "Program metrics ride on operational telemetry: coverage, freshness, and control-health numbers reported to governance are produced by pipelines that must themselves be monitored and reliable.", "actions": [ "Automate the collection pipelines behind governance metrics and monitor their freshness.", "Alert when a reported metric goes stale rather than letting dashboards show old numbers.", "Reconcile operational dashboards with the governance report each cycle to catch divergence." ], "failure_signals": [ "Governance reports present weeks-old numbers as current because a collector died silently.", "Operational dashboards and the governance report disagree with no reconciliation." ] }, "grc_auditor": { "summary": "The metrics program and reporting records are the primary evidence for demonstrating that knowledge governance is operating effectively and improving over time.", "actions": [ "Request the Knowledge Program Scorecard definition and verify it covers all five required metric dimensions.", "Review the prior four quarterly executive reports and verify they include trend analysis and AI output impact metrics.", "Confirm that threshold breaches triggered documented escalation actions within the required 5-business-day window." ], "metrics": [ "Scorecard metrics with automated collection: target \u226580% of defined metrics.", "Monthly committee reports delivered on schedule: target 100%.", "Quarterly executive reports delivered on schedule: target 100%.", "Threshold breach escalations within 5-business-day SLA: target \u226595%." ], "failure_signals": [ "Scorecard does not include AI output impact metrics.", "Reports have not been delivered to the committee or executive in more than one reporting period.", "Metric collection is entirely manual with no automation." ] }, "legal_counsel": { "summary": "Effectiveness reporting is the record regulators read: metrics reported to governance bodies about knowledge controls will be compared against reality in any examination \u2014 accuracy and retention matter.", "actions": [ "Review governance-report claims about control effectiveness for accuracy against underlying evidence.", "Set retention for effectiveness reports to match regulatory examination horizons.", "Flag reported control failures that create disclosure considerations before reports circulate." ], "failure_signals": [ "A governance report overstates control coverage relative to the underlying evidence.", "Past effectiveness reports needed for an examination were not retained." ] } }, "maturity": { "current": "initial", "target": "quantitatively-managed", "notes": "Most organizations measure knowledge quality with ad-hoc spot checks and no AI output impact correlation. The critical maturity step is adding AI output impact metrics to create a feedback loop between knowledge quality and model behavior." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Knowledge Management Office", "GRC Team", "Executive Leadership", "Data Science" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a79.1 \u2014 Monitoring, measurement, analysis and evaluation", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a79.1 requires organizations to determine what needs to be monitored and measured for the AI management system, when results shall be analyzed and evaluated, and to retain documented information as evidence of results. A formal metrics program is the direct implementation of this requirement.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_30401", "requirement_id": "\u00a79.1 \u2014 Monitoring and evaluation", "fit": "direct", "rationale": "ISO 30401:2018 \u00a79.1 requires organizations to determine when and how to monitor, measure, analyze, and evaluate knowledge management processes and outcomes. The Knowledge Program Scorecard is the primary artifact implementing this requirement.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "itil_4", "requirement_id": "Continual Improvement Practice", "fit": "partial", "rationale": "ITIL 4 Continual Improvement practice provides the measurement and reporting model for service quality improvement that directly informs the structure of knowledge program metrics reporting. Its Plan-Do-Check-Act cycle with defined KPIs maps to the metrics program cadence required by this control.", "normative_force": "industry-framework", "source_version": "4", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 13 \u2014 Data Quality Metrics", "fit": "direct", "rationale": "DAMA DMBOK2 Chapter 13 provides the canonical framework for defining data quality KPIs including completeness, accuracy, consistency, currency, and uniqueness dimensions. These map directly to the quality and currency metric dimensions required in the Knowledge Program Scorecard.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9 \u2014 Risk management: monitoring effectiveness", "fit": "partial", "rationale": "EU AI Act Article 9 requires that the risk management system be subject to ongoing review and verification of effectiveness. A metrics program that measures knowledge governance effectiveness provides the empirical basis for demonstrating that the risk management system is functioning as designed.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" } ], "canonical_id": "apeiris://knowledge/controls/KG-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A Knowledge Program Scorecard must be in active operation with at least 15 defined metrics covering all five dimensions \u2014 quality, currency, coverage, governance compliance, and AI output impact \u2014 with automated collection for at least 80% of metrics, monthly reports delivered to the Knowledge Governance Committee, and quarterly effectiveness reports delivered to the executive sponsor with threshold breach escalations completed within 5 business days.", "evidence_required": [ "knowledge_program_scorecard_definition document listing all defined metrics with dimension_tag, measurement_methodology, baseline_value, target_value, and collection_method (automated or manual) for each", "metrics_dashboard_export dated within 30 days showing current values for all scorecard metrics with automated_collection flag per metric", "monthly_committee_report for the prior three consecutive months containing trend_analysis, threshold_breach_log, and recommended_actions with assigned owners", "quarterly_executive_report for the prior two consecutive quarters including governance_investment_summary and AI_output_impact_metrics section", "threshold_breach_escalation_log for the prior 12 months showing breach_detected_timestamp, escalation_timestamp, escalation_recipient, and resolution_action for each breach event" ], "machine_tests": [ "Query metrics_catalog where domain='knowledge' \u2192 assert count >= 15 and distinct values of dimension field equals 5 (quality, currency, coverage, governance_compliance, ai_output_impact all present)", "Query metrics_collection_log for past 30 days \u2192 assert count of metrics with at least one automated_collection_record divided by total defined metrics >= 0.80", "Query report_delivery_log where report_type='knowledge_committee_monthly' and delivery_date in prior 90 days \u2192 assert count >= 3 and every record has delivered_timestamp non-null", "Query threshold_breach_log where domain='knowledge' \u2192 assert every breach event has escalation_timestamp within 5 business days of breach_detected_timestamp" ], "human_review": [ "Review the scorecard definition to confirm AI output impact metrics \u2014 specifically citation accuracy rate and hallucination rate by knowledge domain \u2014 are defined with specific measurement methodologies and ground-truth evaluation sets rather than aspirational placeholders without collection mechanisms", "Assess whether monthly committee reports include recommended actions with named owners and follow-up dates, or whether they are purely descriptive trend summaries with no accountability for corrective action", "Verify that data science teams are actively contributing to and consuming AI output impact metrics rather than the metrics program operating in isolation from the teams with closest visibility to model behavior" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Defining scorecard metrics but collecting them manually on a quarterly cycle, introducing lag that makes threshold detection meaningless and renders automated breach escalation within 5 business days impossible", "Including only process and input metrics such as ownership completeness and policy adherence while omitting AI output impact metrics such as hallucination rate by knowledge domain, making it impossible to connect governance investment to actual model behavior outcomes", "Publishing the knowledge quality dashboard with access restricted to the knowledge engineering team, preventing governance committee members and executive stakeholders from having direct visibility needed to exercise oversight", "Measuring hallucination rate as a single global aggregate across all knowledge domains rather than attributing it to specific domains, making it impossible to identify and prioritize the highest-risk knowledge areas for remediation investment", "Handling threshold breach escalations informally via email without logging the breach event, escalation timestamp, and resolution action, creating an audit gap that prevents compliance reporting from being factually grounded" ], "update_status": "current", "schema_version": "1.1.0", "layer_code": "KG" }, { "id": "KG-08", "layer": "KG", "plane": "both", "name": "KnowledgeAttestation Production", "plain": "The enterprise must produce a KnowledgeAttestation artifact \u2014 a structured, signed, and time-stamped attestation certifying that all 11 prior knowledge domain controls (KS through KG-07) have been implemented, evidenced, and reviewed \u2014 suitable for consumption by downstream relying parties, AI governance systems, and regulatory submittals.", "threat": { "tags": [ "attestation-gap", "evidence-incompleteness", "governance-theater", "certification-failure" ], "desc": "Without a terminal attestation artifact, knowledge governance is a collection of disconnected controls with no mechanism for relying parties to verify that the full governance program is in place. AI systems deployed without a valid KnowledgeAttestation carry unquantified knowledge risk that is invisible to downstream consumers, deployers, and regulators. Governance theater \u2014 where controls exist on paper but evidence is not collected or signed \u2014 is only detectable through attestation production failures." }, "standard": [ { "id": "iso_42001", "section": "\u00a79.2, \u00a79.3", "title": "Internal audit and management review \u2014 AI governance evidence" }, { "id": "eu_ai_act", "section": "Art. 17, Art. 47", "title": "Quality management system and EU declaration of conformity" }, { "id": "w3c_prov", "section": "PROV-DM \u00a75.4", "title": "Bundles" }, { "id": "dama_dmbok", "section": "Ch. 3", "title": "Data Governance" } ], "sources": [ { "id": "iso_42001", "title": "ISO/IEC 42001:2023", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 42001:2023 \u00a79.2\u20139.3 \u2014 Internal audit and management review requirements informing the apeiris://knowledge/controls/KG-08 KnowledgeAttestation Production control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act", "title": "EU AI Act (Regulation (EU) 2024/1689)", "authority": "European Union", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-07-02", "canonical_url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng", "license": "EU-public-sector-information", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes EU AI Act (Regulation (EU) 2024/1689) Art. 17 \u2014 Quality management system; Art. 47 \u2014 EU declaration of conformity requirements informing the apeiris://knowledge/controls/KG-08 KnowledgeAttestation Production control.", "reviewed_on": "2026-07-02" }, { "id": "w3c_prov", "title": "W3C PROV Data Model", "authority": "World Wide Web Consortium", "source_type": "standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2013-04-30", "retrieved_on": "2026-07-02", "canonical_url": "https://www.w3.org/TR/prov-dm/", "license": "open-access", "status": "current", "flagship": false, "source_id": "w3c_prov", "relationship": "implementation_pattern", "rationale": "Establishes W3C PROV Data Model PROV-DM \u00a75.4 \u2014 Bundles requirements informing the apeiris://knowledge/controls/KG-08 KnowledgeAttestation Production control.", "reviewed_on": "2026-07-02" }, { "id": "dama_dmbok", "title": "DAMA-DMBOK 2nd Ed", "authority": "DAMA International", "source_type": "standard", "normative_force": "best-practice", "version": "2 (2nd Edition, Revised 2024)", "published_on": "2017-07-05", "retrieved_on": "2026-07-02", "canonical_url": "https://www.dama.org/cpages/body-of-knowledge", "license": "proprietary", "status": "current", "flagship": false, "source_id": "dama_dmbok", "relationship": "informative_reference", "rationale": "Establishes DAMA-DMBOK 2nd Ed Ch. 3 \u2014 Data Governance requirements informing the apeiris://knowledge/controls/KG-08 KnowledgeAttestation Production control.", "reviewed_on": "2026-07-02" }, { "id": "iso_30401", "title": "ISO 30401:2018 \u2014 Knowledge Management Systems Requirements", "authority": "ISO", "source_type": "standard", "normative_force": "certification-standard", "version": "2018", "published_on": "2018-11-01", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/68683.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_30401", "relationship": "implementation_pattern", "rationale": "Establishes ISO 30401:2018 \u2014 Knowledge Management Systems Requirements \u00a79.2\u20139.3 \u2014 Internal audit and review requirements informing the apeiris://knowledge/controls/KG-08 KnowledgeAttestation Production control.", "reviewed_on": "2026-07-02" }, { "id": "iso_27002", "title": "ISO/IEC 27002:2022 \u2014 Information Security Controls", "authority": "ISO/IEC", "source_type": "standard", "normative_force": "voluntary-standard", "version": "2022", "published_on": "2022-02-15", "retrieved_on": "2026-07-02", "canonical_url": "https://www.iso.org/standard/75652.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_27002", "relationship": "implementation_pattern", "rationale": "Establishes ISO/IEC 27002:2022 \u2014 Information Security Controls \u00a75.36 \u2014 Compliance with policies and standards requirements informing the apeiris://knowledge/controls/KG-08 KnowledgeAttestation Production control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Implement an automated attestation production pipeline that aggregates evidence artifacts from all 11 prior knowledge controls, validates evidence completeness against the Apeiris evidence ontology, computes a composite knowledge assurance score, and produces a signed KnowledgeAttestation artifact in the canonical Apeiris format. Attestations are versioned, time-stamped, and published to the enterprise evidence store. Relying parties consume attestations via the apeiris://knowledge/controls/KG-08 endpoint.", "steps": [ "Define the KnowledgeAttestation schema conforming to the Apeiris evidence ontology, including fields for evidence_id, actor, intent, action, resource, policy, obligation, verdict, blocking_effect, confidence, confidence_basis, collected_at, valid_from, valid_until, reviewed_on, source_freshness_status, residual_risk, producer_verifier, consumer_verifiers, evidence_completeness_status, runtime_gate_required, integrity.hash (sha256), and integrity.signature (Ed25519).", "Build an attestation aggregation pipeline that pulls evidence artifacts from all 11 prior knowledge control points (KS through KG-07), validates each artifact against the evidence schema, and computes per-control verdicts (pass/fail/conditional/inconclusive/not-applicable) using defined acceptance criteria.", "Implement a composite knowledge assurance scoring model that weights control verdicts by control criticality tier and computes an overall KnowledgeAttestation verdict and confidence score, with blocking_effect set based on the lowest-scoring critical control.", "Sign the produced KnowledgeAttestation with the enterprise Ed25519 attestation key, publish it to the evidence store with a canonical URI at apeiris://knowledge/controls/KG-08, and notify registered consumer verifiers of the new attestation version.", "Trigger attestation re-production within 24 hours of any knowledge incident closure, material change to the knowledge governance program, or policy update affecting any of the 11 upstream controls." ], "knowledge_engineer": { "summary": "Engineers implement and maintain the attestation production pipeline. The pipeline is the technical embodiment of the entire KG control layer \u2014 it proves that governance is operating, not just documented.", "actions": [ "Implement and maintain the attestation aggregation pipeline with connectors to all 11 upstream knowledge control evidence stores.", "Ensure the pipeline enforces the full Apeiris evidence ontology schema and rejects incomplete or schema-invalid evidence artifacts.", "Implement automated re-triggering of attestation production on defined trigger events and publish the new attestation to the canonical endpoint." ], "failure_signals": [ "Attestation pipeline has coverage gaps \u2014 fewer than 11 upstream controls contribute evidence.", "Produced attestations fail schema validation against the Apeiris evidence ontology.", "Attestation has not been re-produced within 24 hours of a known trigger event." ] }, "data_scientist": { "summary": "The KnowledgeAttestation asserts quantitative claims \u2014 coverage, quality, freshness \u2014 that must be backed by reproducible measurement; an attestation built on unverifiable numbers is governance theater.", "actions": [ "Validate every quantitative claim in the attestation against reproducible analysis before it is signed.", "Version the measurement code behind attestation metrics with the attestation itself.", "Refuse inclusion of metrics whose collection was broken during the attestation period, and disclose the gap." ], "failure_signals": [ "An attestation ships with a coverage figure nobody can regenerate.", "A broken collector's gap period is papered over in the attested metrics." ] }, "it_operations": { "summary": "Attestation production is an operational pipeline: evidence collection, aggregation, signing, and publication must run reliably on schedule, with signing keys protected and the process itself auditable.", "actions": [ "Automate evidence collection and attestation assembly with run logs retained per policy.", "Protect attestation signing keys in managed key infrastructure with access audit.", "Alert when scheduled attestation production slips or an evidence feed is missing." ], "failure_signals": [ "The attestation deadline is missed because an evidence feed silently broke.", "Signing keys are held on an engineer's workstation rather than managed key infrastructure." ] }, "grc_auditor": { "summary": "The KnowledgeAttestation is the definitive audit artifact for the entire knowledge governance program. Its completeness, accuracy, and currency are the primary evidence targets for external audits and regulatory reviews.", "actions": [ "Obtain the most recent KnowledgeAttestation artifact and verify its schema conformance, signature validity, and evidence_completeness_status.", "Cross-reference each of the 11 upstream control evidence artifacts referenced in the attestation against the corresponding control requirements.", "Verify that the attestation valid_until date is current and that re-production triggers are functioning as designed." ], "metrics": [ "KnowledgeAttestation production on schedule: target 100% of scheduled cycles.", "Attestation evidence completeness: target evidence_completeness_status = complete.", "Signature validity: target 100% of produced attestations have valid Ed25519 signatures.", "Re-production within 24 hours of trigger events: target \u226595%." ], "failure_signals": [ "Most recent attestation is expired (valid_until in the past).", "evidence_completeness_status is incomplete or partial.", "Attestation signature is invalid or signing key is not registered with the enterprise attestation authority.", "Fewer than 11 upstream controls contributed evidence to the attestation." ] }, "legal_counsel": { "summary": "The KnowledgeAttestation is a formal declaration of governance compliance that may be submitted to regulators, included in contractual representations, or used in litigation. Its legal weight depends on the integrity of the underlying evidence and the attestation signing chain.", "actions": [ "Review the KnowledgeAttestation schema and production process to confirm that the attestation meets the documentation requirements of EU AI Act Article 17 and any applicable sector-specific regulations.", "Confirm that the attestation includes appropriate scope limitations, caveats, and residual_risk disclosures that prevent misrepresentation as an absolute compliance guarantee.", "Ensure that the signing key management procedure includes legal hold provisions for attestation artifacts subject to litigation or regulatory investigation." ], "failure_signals": [ "Attestation schema contains no scope limitations or residual risk disclosures.", "Attestation production process is not documented in a manner suitable for regulatory submission.", "Signing key management lacks legal hold provisions." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "KnowledgeAttestation production is a new capability for most enterprises. The primary prerequisite is that all 11 upstream controls are instrumented to produce machine-readable evidence artifacts conforming to the Apeiris evidence ontology." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise", "cloud-native" ], "implementers": [ "Knowledge Management Office", "GRC Team", "Legal Counsel", "Platform Engineering" ], "frameworks": [ { "framework": "iso_42001", "requirement_id": "\u00a79.2\u20139.3 \u2014 Internal audit and management review", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a79.2 and \u00a79.3 require organizations to conduct internal audits and management reviews of the AI management system, retaining documented information as evidence. The KnowledgeAttestation is the structured evidence artifact that satisfies the documentation retention requirements of these clauses.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 17 \u2014 Quality management system; Art. 47 \u2014 EU declaration of conformity", "fit": "direct", "rationale": "EU AI Act Articles 17 and 47 require providers of high-risk AI systems to maintain a documented quality management system and to draw up an EU declaration of conformity. The KnowledgeAttestation serves as the primary documentation artifact demonstrating that the knowledge governance component of the QMS is implemented and evidenced.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "w3c_prov", "requirement_id": "PROV-DM \u00a75.4 \u2014 Bundles", "fit": "direct", "rationale": "W3C PROV-DM \u00a75.4 defines the bundle construct for grouping provenance descriptions and giving the group its own provenance. The KnowledgeAttestation production pipeline implements this concept, aggregating per-control evidence artifacts into a signed, attributable governance attestation.", "normative_force": "voluntary-standard", "source_version": "2013", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "dama_dmbok", "requirement_id": "Ch. 3 \u2014 Data Governance", "fit": "partial", "rationale": "DAMA-DMBOK 2nd edition Chapter 3 (Data Governance) describes governance oversight practices \u2014 evidence of governance activities, management sign-off, and reporting to governance bodies \u2014 that inform the KnowledgeAttestation production process. The fit is partial because DMBOK does not define a signed attestation artifact.", "normative_force": "best-practice", "source_version": "2", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "informs" }, { "framework": "iso_30401", "requirement_id": "\u00a79.2\u20139.3 \u2014 Internal audit and review", "fit": "partial", "rationale": "ISO 30401:2018 \u00a79.2 and \u00a79.3 require organizations to evaluate knowledge management system performance and conduct management reviews. The KnowledgeAttestation provides the structured audit trail and review record required by these clauses.", "normative_force": "certification-standard", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_27002", "requirement_id": "\u00a75.36 \u2014 Compliance with policies and standards", "fit": "adjacent", "rationale": "ISO/IEC 27002:2022 \u00a75.36 requires organizations to regularly review compliance with policies, standards, and technical controls. The KnowledgeAttestation production process implements this review requirement for the knowledge governance domain, producing a signed compliance artifact.", "normative_force": "voluntary-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://knowledge/controls/KG-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A valid KnowledgeAttestation artifact must exist at the canonical endpoint with evidence_completeness_status='complete', a valid Ed25519 signature verified against the registered enterprise attestation public key, valid_until date in the future, and evidence contributions from all 11 upstream knowledge controls (KS through KG-07), with the artifact conforming to the Apeiris evidence ontology schema with zero validation errors.", "evidence_required": [ "knowledge_attestation_artifact in canonical Apeiris format with evidence_id, actor, intent, action, resource, policy, obligation, verdict, blocking_effect, confidence, confidence_basis, collected_at, valid_from, valid_until, integrity.hash (sha256), and integrity.signature (Ed25519) fields all populated", "attestation_evidence_manifest listing all 11 upstream control evidence artifact references (KS-01 through KG-07) with per_control_verdict and evidence_artifact_id for each of the 11 controls", "ed25519_signature_verification_record confirming the attestation signature validates against the enterprise attestation public key and the signing key_id matches the registered key in the enterprise attestation authority", "attestation_pipeline_run_log for prior 30 days showing automated trigger events, pipeline_run outcomes, schema_validation_error_counts, and re-production timestamps relative to trigger events" ], "machine_tests": [ "Fetch latest KnowledgeAttestation from apeiris://knowledge/controls/KG-08 endpoint \u2192 assert evidence_completeness_status='complete', valid_until > today, and upstream_control_count == 11", "Verify Ed25519 signature on fetched attestation artifact against enterprise attestation public key \u2192 assert signature_valid=true and signing_key_id matches a registered active key in the enterprise attestation authority", "Query attestation_pipeline_log for trigger events (knowledge_incident_closure, material_change, policy_update) in prior 30 days \u2192 assert every trigger has a corresponding pipeline_run_completed_timestamp within 24 hours", "Validate fetched attestation JSON against Apeiris evidence ontology schema definition \u2192 assert schema_validation_errors count == 0" ], "human_review": [ "Review the attestation schema and production process documentation to confirm the artifact meets EU AI Act Article 17 quality management system documentation requirements and includes scope limitations, caveats, and residual_risk disclosures that prevent misrepresentation as an absolute compliance guarantee", "Assess the attestation pipeline evidence aggregation logic to verify it enforces genuine pass/fail verdicts per control based on collected evidence artifacts rather than defaulting all upstream controls to 'pass' in the absence of explicit failure evidence", "Verify signing key management procedures include key rotation processes, legal hold provisions that preserve verifiability of historical attestation artifacts for litigation or regulatory investigation, and documented key custodian assignments" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Producing attestation artifacts that reference upstream evidence placeholder records rather than actual collected evidence artifacts, creating governance theater where the attestation claims completeness but no real per-control verification occurred", "Using a shared symmetric key or password-based signing mechanism instead of an asymmetric Ed25519 key pair, preventing relying parties from cryptographically verifying attestation provenance without sharing the secret key", "Setting an excessively long valid_until date such as one year without automated re-triggering on material governance changes, allowing the attestation to become stale relative to the actual knowledge governance posture while appearing valid", "Aggregating upstream control evidence into the attestation without schema validation, accepting schema-invalid or incomplete evidence artifacts that would fail individual control requirements if directly evaluated by a relying party", "Producing attestations without scope limitations or residual_risk disclosures, creating a misrepresentation risk when the attestation is submitted to regulators or included in contractual compliance representations where it could be interpreted as an absolute assurance" ], "update_status": "current", "schema_version": "1.1.0", "cross_domain": { "feeds": [ "apeiris://agentic/controls/AA-01", "apeiris://agentic/controls/AA-05", "apeiris://compliance/controls/AU-08" ] }, "layer_code": "KG" }, { "id": "KR-09", "layer": "KR", "layer_code": "KR", "plane": "both", "canonical_id": "apeiris://knowledge/controls/KR-09", "lenses": null, "name": "Embedding and Vector-Store Integrity", "plain": "The embedding pipeline and vector store are hardened against embedding-inversion (recovering source text from vectors), cross-tenant/semantic-similarity leakage, and index-level poisoning \u2014 with tenant isolation and provenance on every indexed vector.", "threat": { "tags": [ "embedding-inversion", "vector-store-poisoning", "cross-tenant-leakage", "MR-KNOW" ], "desc": "Retrieval vector stores are an unguarded surface: embeddings can be inverted to recover source content, semantic-similarity search can bleed across tenants, and the index can be poisoned to steer retrieval (OWASP LLM08:2025 Vector and Embedding Weaknesses)." }, "standard": [ "OWASP LLM Top 10 \u2014 LLM08:2025 Vector and Embedding Weaknesses" ], "sources": [ { "id": "owasp_llm10", "title": "OWASP Top 10 for LLM Applications (2025)", "authority": "OWASP Foundation", "source_type": "industry-framework", "normative_force": "industry-framework", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-07-08", "canonical_url": "https://genai.owasp.org/", "relationship": "supporting_guidance", "note": "LLM08:2025 Vector and Embedding Weaknesses grounds this control." } ], "implementation": { "pattern": "Tenant-isolated vector stores with access-controlled retrieval, embedding-inversion resistance, and provenance + integrity on every indexed vector.", "steps": [ "Isolate vector namespaces per tenant/context; enforce access control on retrieval so similarity search cannot cross trust boundaries.", "Assess embedding-inversion risk and apply mitigation (access control, perturbation) for sensitive corpora.", "Bind provenance + an integrity check to every indexed vector so poisoned/injected entries are detectable.", "Monitor the index for anomalous insertions and retrieval-steering patterns." ], "knowledge_engineer": { "summary": "You build the embedding pipeline and vector store so that tenant namespaces are isolated, retrieval is access-controlled, and every indexed vector carries provenance plus an integrity check. Similarity search must not be able to cross a trust boundary, and an entry without valid provenance must be rejected at insertion rather than discovered later. Embedding-inversion resistance for sensitive corpora is part of the pipeline design, not a post-hoc patch.", "actions": [ "Partition vector namespaces per tenant or context and enforce access control at retrieval so a similarity query cannot return another tenant's vectors.", "Bind provenance and an integrity check to every indexed vector and reject insertions that lack valid provenance.", "Assess embedding-inversion risk for sensitive corpora and apply a mitigation (retrieval access control, perturbation) where source text could be reconstructed from vectors.", "Instrument the index for anomalous insertions and retrieval-steering patterns so poisoning attempts are detectable.", "Add tests that issue a tenant-A query and assert no tenant-B vectors return, and that insert a provenance-less entry and assert it is rejected." ] }, "data_scientist": { "summary": "Embedding quality and embedding-inversion risk are two sides of the same model choice. A model that packs enough of the source text into a vector to reconstruct it is exactly the model that leaks sensitive corpora, so the inversion assessment belongs in your evaluation, alongside retrieval quality. Cross-tenant semantic-similarity leakage also shows up as retrieval bleed that degrades relevance metrics if namespaces are not truly isolated.", "actions": [ "Run an embedding-inversion assessment for sensitive corpora, testing how much source text can be recovered from stored vectors, and record the result and any mitigation applied.", "Include cross-namespace retrieval checks in evaluation so semantic-similarity leakage across tenants is caught as a quality and confidentiality regression.", "Weigh inversion resistance against retrieval accuracy when selecting or tuning the embedding model rather than optimizing accuracy alone.", "Carry per-vector provenance into retrieval error analysis so a poisoned or anomalous entry can be traced to its source." ] }, "it_operations": { "summary": "You run the vector store as production infrastructure: tenant isolation enforced in configuration, retrieval access control resolving through managed credentials, and index integrity monitored continuously. Because this control requires review before deployment, an isolation or provenance gap is a release blocker, not a backlog item. The steady-state job is watching the index for anomalous insertions.", "actions": [ "Enforce per-tenant namespace isolation in vector-store configuration and fail closed if a retrieval request cannot be bound to an authorized tenant.", "Resolve retrieval and indexing credentials through the managed secrets store and rotate them on the platform schedule.", "Monitor and alert on anomalous index insertions and retrieval-steering patterns so poisoning is caught in operation.", "Verify provenance-and-integrity checks stay enabled on every write path, including bulk re-index and backfill jobs." ] }, "grc_auditor": { "summary": "The auditable artifacts are the vector_store_policy and the embedding_inversion_assessment for sensitive corpora. Confirm the policy actually specifies tenant isolation, retrieval access control, and a per-vector provenance and integrity scheme, and that the inversion assessment exists with any mitigation recorded. Because the control requires review, the review record and its findings are part of the evidence, not just the policy text.", "actions": [ "Obtain the vector_store_policy and verify it defines tenant isolation, retrieval access control, and a per-vector provenance/integrity scheme.", "Request the embedding_inversion_assessment for each sensitive corpus and confirm a mitigation is documented where risk is present.", "Verify the two machine tests (cross-tenant retrieval isolation and provenance-less insertion rejection) run and pass, and sample recent results.", "Confirm the required review was performed and that identified gaps have assigned owners before the store is used in production." ] }, "legal_counsel": { "summary": "Embedding-inversion is a data-protection exposure: if regulated source text can be reconstructed from stored vectors, the vector store holds a derived copy of that data with the same obligations attached. The inversion assessment and the tenant-isolation policy are the records showing the enterprise identified and controlled that exposure. Cross-tenant leakage in a multi-customer store is a confidentiality and contractual concern as much as a technical one.", "actions": [ "Confirm the embedding_inversion_assessment covers corpora subject to privacy, confidentiality, or contractual restrictions and that mitigations align with those obligations.", "Verify tenant-isolation guarantees in the vector_store_policy match the confidentiality commitments made to customers in a multi-tenant deployment.", "Ensure provenance records are sufficient to establish the source and rights basis of indexed content if its use is later challenged.", "Check that retention and deletion obligations extend to derived vectors, not only the original documents." ] } }, "validation": { "design_check": [ "Vector namespaces are tenant/context isolated and retrieval is access-controlled. [ref:owasp_llm10]", "Every indexed vector carries provenance + an integrity check; embedding-inversion risk is assessed for sensitive corpora." ], "runtime_check": [ "Retrieval rejects cross-tenant matches and index writes without valid provenance." ] }, "maturity": { "current": "initial", "target": "defined" }, "coverage_note": "Complements EC-07/EC-03 (retrieved-content trust + memory-write validation) with embedding-store-specific integrity.", "frameworks": [ { "framework": "owasp_llm10", "requirement_id": "LLM08:2025", "fit": "direct", "rationale": "OWASP LLM08:2025 Vector and Embedding Weaknesses is the named threat class.", "normative_force": "industry-framework", "source_version": "2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against" } ], "capability_risk": { "capability_level": "none", "access_mode": "internal", "autonomy": "none", "external_reach": "internal", "irreversibility": "reversible", "data_sensitivity": "internal", "deployment_scale": "enterprise", "affected_party_impact": "medium" }, "validation_objective": "Prove that the vector store is tenant-isolated with access-controlled retrieval, that embedding-inversion risk is assessed and mitigated for sensitive corpora, and that every indexed vector carries provenance and an integrity check against poisoning.", "evidence_required": [ "vector_store_policy: tenant isolation, retrieval access control, and per-vector provenance/integrity scheme", "embedding_inversion_assessment for sensitive corpora with any applied mitigation" ], "machine_tests": [ "Issue a retrieval query as tenant A -> assert no tenant-B vectors are returned.", "Insert an index entry without valid provenance -> assert it is rejected." ], "human_review": [ "Review which corpora are sensitive enough to warrant embedding-inversion mitigation." ], "blocking_effect": "requires-review", "normative_status": "industry-framework", "anti_patterns": [ "A single shared vector namespace across tenants relying on post-filtering.", "Indexing embeddings with no provenance, so poisoned vectors are indistinguishable from legitimate ones." ], "update_status": "current", "lens_enrichment": "ap42 2026-07-08" } ] } }