Draft Assessment Report

Acme Retail Group · generated 9/15/2026, 9:40:16 PM · recommendations by template engine

Weighted maturity per dimension

Data StrategyAs-Is 3.1 · To-Be 4.5

Data GovernanceAs-Is 3.0 · To-Be 4.3

ArchitectureAs-Is 3.0 · To-Be 4.4

Data QualityAs-Is 3.1 · To-Be 4.3

MetadataAs-Is 2.9 · To-Be 4.3

Data AnalyticsAs-Is 3.1 · To-Be 4.3

IntelligenceAs-Is 3.0 · To-Be 4.3

Data CultureAs-Is 2.9 · To-Be 4.3

Dimension	As-Is	To-Be	Gap
Data Strategy	3.05	4.51	1.46
Data Governance	3.05	4.27	1.23
Architecture	2.96	4.43	1.47
Data Quality	3.06	4.31	1.25
Metadata	2.91	4.33	1.42
Data Analytics	3.07	4.28	1.22
Intelligence	2.97	4.34	1.37
Data Culture	2.95	4.32	1.37

SWOT analysis

Strengths

STR-06 (STR, As-Is 4.0, gap 1.0) — When additional resources, tools, or authority to fix a data quality or data access issue are required in your domain, how effectively can you use the organisation's data strategy to justify and secure that investment? [Marta Klein: Existing automated quality checks cover the core ingest paths.]
GOV-02 (GOV, As-Is 4.0, gap 1.0) — How consistently are data governance policies (data handling, classification, retention, Personally Identifiable Information treatment, etc.) actually followed in your domain's daily operations, as opposed to existing only on paper? [Marta Klein: Existing automated quality checks cover the core ingest paths.]
ARC-02 (ARC, As-Is 4.0, gap 1.0) — How well do the data flows into and out of your domain's datasets (APIs, file transfers, event streams, integrations with other systems) conform to defined organisational integration standards and support interoperability with other domains? [Marta Klein: Existing automated quality checks cover the core ingest paths.]
DQT-03 (DQT, As-Is 4.0, gap 1.0) — Once a data quality issue is identified in your domain, how effective, consistent, and timely is the process for actually fixing it? [Marta Klein: Existing automated quality checks cover the core ingest paths.]
MDT-02 (MDT, As-Is 4.0, gap 1.0) — How complete and accurate is the technical metadata (schema definitions, data types, formats, constraints, source system) documented for datasets in your domain? [Marta Klein: Existing automated quality checks cover the core ingest paths.]
DST-02 (DST, As-Is 4.0, gap 1.0) — When the same metric or calculated figure from your domain appears in multiple dashboards or reports, how consistently does it show the same value, calculated the same way? [Marta Klein: Existing automated quality checks cover the core ingest paths.]
INT-04 (INT, As-Is 4.0, gap 1.0) — For AI models that use your domain's data, how transparent is the explanation of how specific domain data elements influence the model's decisions or outputs? [Marta Klein: Existing automated quality checks cover the core ingest paths.]
CUL-03 (CUL, As-Is 4.0, gap 1.0) — When decisions are made within your domain, how consistently are they actually supported by reference to information assets and/or datasets, as opposed to being made on intuition, precedent, or authority alone, with data invoked only afterward if at all? [Marta Klein: Existing automated quality checks cover the core ingest paths.]
STR-02 (STR, As-Is 4.0, gap 1.0) — How clearly is the data strategy linked to the organisation's broader strategic goals, with measurable business Return On Investment tracked against that strategy? [Dana Voss: Existing automated quality checks cover the core ingest paths.]
GOV-01 (GOV, As-Is 4.0, gap 1.0) — How well-defined and formally established is the organisation's data governance operating model — its structure, charter, and program framework — at the enterprise level? [Dana Voss: Existing automated quality checks cover the core ingest paths.]
GOV-04 (GOV, As-Is 4.0, gap 1.0) — How reliably do significant data governance issues (breaches, high-impact quality failures, unresolved disputes) actually reach the Chief Data Officer or executive team, with clear decision rights for resolution? [Dana Voss: Existing automated quality checks cover the core ingest paths.]
DQT-01 (DQT, As-Is 4.0, gap 1.0) — Has the organisation defined and endorsed an enterprise-level risk appetite for data quality — how much quality risk it is willing to accept before requiring executive-level intervention? [Dana Voss: Existing automated quality checks cover the core ingest paths.]
MDT-01 (MDT, As-Is 4.0, gap 1.0) — Is there an executive-sponsored, enterprise-wide metadata and business glossary program, with defined coverage targets and accountable resourcing, or does metadata management happen only where individual teams choose to invest in it? [Dana Voss: Existing automated quality checks cover the core ingest paths.]
DST-02 (DST, As-Is 4.0, gap 1.0) — When the executive team or board looks at a key performance indicator, how confident can they be that everyone in the organisation, looking at the same KPI, sees the same number, calculated the same way? [Dana Voss: Existing automated quality checks cover the core ingest paths.]
INT-02 (INT, As-Is 4.0, gap 1.0) — Is there an executive-endorsed model governance framework covering the full AI model lifecycle (development, validation, deployment, monitoring, retirement), and does the organisation know how many models are actually in production against it? [Dana Voss: Existing automated quality checks cover the core ingest paths.]
CUL-01 (CUL, As-Is 4.0, gap 1.0) — Does the organisation have an executive-sponsored data literacy strategy, with defined, resourced learning and development pathways, or does data capability depend entirely on what individuals choose to learn on their own initiative? [Dana Voss: Existing automated quality checks cover the core ingest paths.]
STR-01 (STR, As-Is 4.0, gap 1.0) — To what extent are the data management priorities in your specific domain (the datasets, quality issues, and access requests you handle) explicitly aligned with the organisation's strategic data goals, rather than driven by ad hoc requests? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
STR-04 (STR, As-Is 4.0, gap 1.0) — How well does your domain's data currently meet the quality, documentation, labelling, and access-control standards required for responsible use in AI/GenAI systems (training, fine-tuning, retrieval-augmented generation, or prompting)? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
GOV-03 (GOV, As-Is 4.0, gap 1.0) — When a data governance issue occurs in your domain (a policy breach, an access anomaly, a data quality problem with compliance implications), how effective is the process for detecting, escalating, and resolving it? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
GOV-06 (GOV, As-Is 4.0, gap 1.0) — How well-defined, auditable, and consistently applied is the access approval process specifically for AI systems, models, pipelines, or agentic tools requesting access to data in your domain? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
ARC-02 (ARC, As-Is 4.0, gap 1.0) — How well do the data flows into and out of your domain's datasets (APIs, file transfers, event streams, integrations with other systems) conform to defined organisational integration standards and support interoperability with other domains? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
ARC-05 (ARC, As-Is 4.0, gap 1.0) — When your domain encounters real-world architecture constraints, technical debt, or friction (e.g. a data model that doesn't fit actual business needs, a slow or brittle integration, a platform limitation), how effectively does that experience feed back into and shape the organisation's data architecture roadmap? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
ARC-08 (ARC, As-Is 4.0, gap 1.0) — How completely and accurately can you trace which of your domain's datasets have fed into which AI/GenAI models, prompts, retrieval systems, or agents — and, conversely, trace a given AI output back to the domain data that informed it? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
DQT-03 (DQT, As-Is 4.0, gap 1.0) — Once a data quality issue is identified in your domain, how effective, consistent, and timely is the process for actually fixing it? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
DQT-06 (DQT, As-Is 4.0, gap 1.0) — For the datasets and processes in your domain, is there a defined understanding of how much data imperfection a downstream process can actually absorb before outcomes are materially affected — and is that tolerance measured, rather than assumed? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
DQT-09 (DQT, As-Is 4.0, gap 1.0) — When an AI/GenAI system produces poor-quality, biased, or hallucinated output, how effectively can that issue be traced back to underlying data quality problems in your domain, and how is that insight fed back to improve the source data? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
MDT-03 (MDT, As-Is 4.0, gap 1.0) — How easily can people who need to use your domain's data actually find and access relevant metadata (glossary definitions, technical documentation, lineage) without having to ask a specific individual? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
MDT-06 (MDT, As-Is 4.0, gap 1.0) — Is there a defined checkpoint that confirms a dataset has the required metadata (provenance, licensing, sensitivity classification, known limitations) before it is approved for use in an AI/GenAI initiative — and how consistently is that checkpoint applied? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
DST-02 (DST, As-Is 4.0, gap 1.0) — If someone looking at a chart or dashboard built on your domain's data wants to understand exactly what data it's built from, how it's defined, and how current it is, how easily can they find that out? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
INT-02 (INT, As-Is 4.0, gap 1.0) — To what extent does your domain's data feed Decision Intelligence systems — tools that combine data, analytics, and automation to recommend or directly make operational decisions — and how well understood is that role? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
INT-05 (INT, As-Is 4.0, gap 1.0) — How systematically is your domain's data assessed for potential sources of bias (unrepresentative samples, historical bias embedded in labels, skewed collection methods) before and during its use in AI models, and how are identified biases mitigated? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
INT-08 (INT, As-Is 4.0, gap 1.0) — Before an AI model using your domain's data moves from development into **implementation** (production deployment), is there a defined checkpoint confirming the data feeding it in production remains representative, unbiased, and consistent with what the model was trained and validated against? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
CUL-02 (CUL, As-Is 4.0, gap 1.0) — How effectively do data-focused roles (Data Engineer, data engineers, analysts) and business stakeholders in your domain actually work together, as opposed to operating as separate groups that hand work back and forth with limited shared understanding? [Ivan Petrov: Existing automated quality checks cover the core ingest paths.]
STR-CON-02 (STR, As-Is 4.0, gap 1.0) — To what extent do the datasets, reports and dashboards actually made available to you reflect your team’s stated business objectives, as opposed to being whatever happens to have been built historically or requested most loudly? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
STR-CON-05 (STR, As-Is 4.0, gap 1.0) — How clearly does the organisation’s Data Strategy tell you, as a Data Consumer, which data you may use in AI/GenAI tools, for what purposes, and under what constraints? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
GOV-CON-02 (GOV, As-Is 4.0, gap 1.0) — When you need access to a dataset, report or system you do not currently have, how clear, timely and consistently applied is the process for requesting, obtaining and, where relevant, losing that access? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
GOV-CON-05 (GOV, As-Is 4.0, gap 1.0) — If you encountered a data governance concern — data you can see but should not, an extract shared inappropriately, or a suspected privacy breach — how clear and effective is the path for raising it? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
ARC-CON-01 (ARC, As-Is 4.0, gap 1.0) — How reliably do the data platforms, reporting tools and systems you depend on perform when you need them — in terms of availability, speed and capacity at peak business times? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
ARC-CON-04 (ARC, As-Is 4.0, gap 1.0) — How well supported are you in getting data out of corporate platforms and into the tools you actually work in — spreadsheets, planning tools, models or documents — in a controlled and repeatable way? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
DQT-CON-02 (DQT, As-Is 4.0, gap 1.0) — How reliably is the data you use current enough for the decisions you make with it, and how clearly do you know how current any given figure actually is? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
DQT-CON-05 (DQT, As-Is 4.0, gap 1.0) — When you find something wrong in the data — a value that cannot be right, a missing record, a duplicate — how clear and easy is the path for reporting it? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
DQT-CON-08 (DQT, As-Is 4.0, gap 1.0) — When an AI or GenAI tool produces an output you use for work — a summary, an answer, a generated analysis — how well can you judge its reliability and report it when it is wrong? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
MDT-CON-03 (MDT, As-Is 4.0, gap 1.0) — Beyond definitions, how well are you given the context you need to interpret a dataset correctly — its coverage, collection method, known limitations and the situations it should not be used for? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
MDT-CON-06 (MDT, As-Is 4.0, gap 1.0) — How clearly can you tell, from the data asset itself, how sensitive it is and what you are permitted to do with it? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
DST-CON-01 (DST, As-Is 4.0, gap 1.0) — How well are you equipped with self-service business intelligence and visual analysis tools that let you answer your own business questions, rather than having to request every answer from a central team? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
DST-CON-04 (DST, As-Is 4.0, gap 1.0) — When the same measure appears in more than one report or dashboard, how consistently does it show the same value, calculated the same way? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
DST-CON-07 (DST, As-Is 4.0, gap 1.0) — How confident can you be that a dashboard or report faithfully represents the agreed business rules and definitions of the underlying data, rather than the report builder’s own interpretation? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
DST-10 (DST, As-Is 4.0, gap 1.0) — When a figure in a report does not look right to you, how effectively does that observation reach the people who can investigate it, and how well are you told the outcome? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
INT-CON-03 (INT, As-Is 4.0, gap 1.0) — When an analytical or AI system produces a score, recommendation or classification that affects your work, how well can you understand why it reached that result? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
INT-CON-06 (INT, As-Is 4.0, gap 1.0) — For model or AI outputs that affect people — clients, staff or citizens — how well are you informed about known bias and fairness limitations you should take into account? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
CUL-CON-02 (CUL, As-Is 4.0, gap 1.0) — To what extent do you and your colleagues actually participate in and complete the organisation’s data literacy and learning offerings, as opposed to them being available but unused? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
CUL-CON-05 (CUL, As-Is 4.0, gap 1.0) — How effectively do you and the organisation’s data specialists work together — as genuine collaborators on a shared problem, rather than as separate groups exchanging requests and deliverables? [Lena Novak: Existing automated quality checks cover the core ingest paths.]
CUL-CON-08 (CUL, As-Is 4.0, gap 1.0) — How consistently do the leaders you work with model and reinforce data-informed behaviour — asking for evidence, engaging with it seriously, and acting on it even when it is unwelcome? [Lena Novak: Existing automated quality checks cover the core ingest paths.]

Weaknesses

STR-07 (STR, As-Is 2.0, gap 2.0) — How regularly and rigorously does your domain assess its own data maturity, document a target capability state and the roadmap to close the gap, and track the progress against that gap over time? [Marta Klein: Ownership of STR-07 is informal and undocumented.]
GOV-03 (GOV, As-Is 2.0, gap 1.0) — How well-defined, auditable, and consistently followed is the process for granting, reviewing, and revoking access to data in your domain? [Marta Klein: Ownership of GOV-03 is informal and undocumented.]
ARC-03 (ARC, As-Is 2.0, gap 2.0) — How complete, accurate, and accessible is the documentation of your domain's data models, schemas, and data lineage (where data comes from, how it's transformed, and where it goes)? [Marta Klein: Ownership of ARC-03 is informal and undocumented.]
DQT-05 (DQT, As-Is 2.0, gap 1.0) — When a data quality issue occurs, how effectively does your domain investigate its root cause and take action to prevent it recurring, rather than simply fixing the symptom each time? [Marta Klein: Ownership of DQT-05 is informal and undocumented.]
MDT-03 (MDT, As-Is 2.0, gap 2.0) — How consistently do metadata definitions, naming conventions, and classifications in your domain align with organisation-wide standards, avoiding conflicting or duplicate definitions for the same business concept? [Marta Klein: Ownership of MDT-03 is informal and undocumented.]
DST-05 (DST, As-Is 2.0, gap 1.0) — When a business user spots something that looks wrong in a dashboard or report built on your domain's data ("this number doesn't look right"), how effectively does that get traced back to you and resolved at the source? [Marta Klein: Ownership of DST-05 is informal and undocumented.]
INT-05 (INT, As-Is 2.0, gap 2.0) — How systematically is your domain's data assessed for potential sources of bias (unrepresentative samples, historical bias embedded in labels, skewed collection methods) before and during its use in AI models, and how are identified biases mitigated? [Marta Klein: Ownership of INT-05 is informal and undocumented.]
CUL-05 (CUL, As-Is 2.0, gap 1.0) — How well-supported is your own ongoing development — access to training, peer learning, and skill development that keeps your capability current with evolving data priorities, practices, techniques and tools? [Marta Klein: Ownership of CUL-05 is informal and undocumented.]
STR-03 (STR, As-Is 2.0, gap 2.0) — How sustainable and well-governed is the funding model for data initiatives — is data funded as a one-off project cost, or as an ongoing, governed investment? [Dana Voss: Ownership of STR-03 is informal and undocumented.]
GOV-02 (GOV, As-Is 2.0, gap 1.0) — How comprehensively are data ownership and stewardship roles (Data Owners, Data Stewards, Data Custodians) established, assigned, and held accountable across the organisation? [Dana Voss: Ownership of GOV-02 is informal and undocumented.]
ARC-01 (ARC, As-Is 2.0, gap 2.0) — How well-governed are decisions to invest in, select, or retire major data platforms and technologies, from a strategic fit and scalability perspective? [Dana Voss: Ownership of ARC-01 is informal and undocumented.]
DQT-02 (DQT, As-Is 2.0, gap 1.0) — How reliably can the executive team or board see an accurate, consolidated picture of data quality performance across the organisation, rather than fragmented, team-level views? [Dana Voss: Ownership of DQT-02 is informal and undocumented.]
MDT-02 (MDT, As-Is 2.0, gap 2.0) — How confident can the organisation be that, in the event of an audit, regulatory inquiry, or major incident, it could produce reliable metadata and lineage evidence across the organisation, not just for the datasets a specific team happens to have documented well? [Dana Voss: Ownership of MDT-02 is informal and undocumented.]
DST-03 (DST, As-Is 2.0, gap 1.0) — How easily can business teams across the organisation find and confidently use certified, trustworthy data assets (datasets, reports, metrics), without relying on personal networks or tribal knowledge to know what exists and what can be trusted? [Dana Voss: Ownership of DST-03 is informal and undocumented.]
INT-03 (INT, As-Is 2.0, gap 2.0) — Does the executive team treat algorithm transparency and bias mitigation as an owned, resourced enterprise risk and ethics responsibility, with clear accountability, rather than a technical concern left entirely to individual data science teams? [Dana Voss: Ownership of INT-03 is informal and undocumented.]
CUL-02 (CUL, As-Is 2.0, gap 1.0) — At the executive team and board level, how consistently are significant decisions actually backed by data and evidence, as opposed to being made on intuition or precedent, with data invoked only afterward if at all? [Dana Voss: Ownership of CUL-02 is informal and undocumented.]
STR-02 (STR, As-Is 2.0, gap 2.0) — How regularly and rigorously does your domain assess its own data maturity, document a target state and the gap to close, and track progress against that gap over time? [Ivan Petrov: Ownership of STR-02 is informal and undocumented.]
GOV-01 (GOV, As-Is 2.0, gap 1.0) — How consistently are data governance policies (data handling, classification, retention, PII treatment, etc.) actually followed in your domain's daily operations, as opposed to existing only on paper? [Ivan Petrov: Ownership of GOV-01 is informal and undocumented.]
GOV-04 (GOV, As-Is 2.0, gap 2.0) — To what extent does your domain have defined data contracts or terms of use for its datasets, specifying obligations, permitted uses, and restrictions, and how consistently are these actually applied when access is granted? [Ivan Petrov: Ownership of GOV-04 is informal and undocumented.]
GOV-07 (GOV, As-Is 2.0, gap 1.0) — How effectively does your domain detect, investigate, and resolve issues arising from AI/GenAI systems' actual use of its data — including misuse, scope creep, data leakage into model outputs, or use beyond what was approved? [Ivan Petrov: Ownership of GOV-07 is informal and undocumented.]
ARC-03 (ARC, As-Is 2.0, gap 2.0) — How complete, accurate, and accessible is the documentation of your domain's data models, schemas, and data lineage (where data comes from, how it's transformed, and where it goes)? [Ivan Petrov: Ownership of ARC-03 is informal and undocumented.]
ARC-06 (ARC, As-Is 2.0, gap 1.0) — How well does your domain's data architecture support the structures and access patterns AI/GenAI initiatives actually need (e.g. vector embeddings, feature stores, unstructured/semi-structured data, retrieval-optimised storage), as opposed to only traditional relational/tabular patterns? [Ivan Petrov: Ownership of ARC-06 is informal and undocumented.]
DQT-01 (DQT, As-Is 2.0, gap 2.0) — How well-defined are data quality rules (accuracy, completeness, consistency, timeliness, validity) for the datasets in your domain, and how much of your domain's data do these rules actually cover? [Ivan Petrov: Ownership of DQT-01 is informal and undocumented.]
DQT-04 (DQT, As-Is 2.0, gap 1.0) — How is data quality in your domain measured using defined metrics and thresholds, and how is that measurement reported to relevant stakeholders? [Ivan Petrov: Ownership of DQT-04 is informal and undocumented.]
DQT-07 (DQT, As-Is 2.0, gap 2.0) — How well-defined are the quality standards your domain's data must meet specifically to be used in AI/GenAI training, fine-tuning, or grounding (e.g. RAG source material) — covering criteria like representativeness, bias, freshness, and label accuracy — as distinct from general data quality rules? [Ivan Petrov: Ownership of DQT-07 is informal and undocumented.]
MDT-01 (MDT, As-Is 2.0, gap 1.0) — How complete and accurate is the technical metadata (schema definitions, data types, formats, constraints, source system) documented for datasets in your domain? [Ivan Petrov: Ownership of MDT-01 is informal and undocumented.]
MDT-04 (MDT, As-Is 2.0, gap 2.0) — How confident can users be that the metadata describing your domain's data is accurate and reflects the data's current state, rather than being outdated or misleading? [Ivan Petrov: Ownership of MDT-04 is informal and undocumented.]
MDT-07 (MDT, As-Is 2.0, gap 1.0) — When an AI/GenAI system misuses, misinterprets, or retrieves the wrong domain data (e.g. due to unclear definitions, missing context, or poor documentation), how effectively does that experience feed back into improving your domain's metadata? [Ivan Petrov: Ownership of MDT-07 is informal and undocumented.]
DST-03 (DST, As-Is 2.0, gap 2.0) — When a Data Consumer spots something that looks wrong in a dashboard or report built on your domain's data ("this number doesn't look right"), how effectively does that get traced back to you and resolved at the source? [Ivan Petrov: Ownership of DST-03 is informal and undocumented.]
INT-03 (INT, As-Is 2.0, gap 1.0) — At which stages of the AI model lifecycle (data selection, training, validation, deployment, monitoring, retirement) does the Data Engineer have a defined, expected role regarding models that consume your domain's data? [Ivan Petrov: Ownership of INT-03 is informal and undocumented.]
INT-06 (INT, As-Is 2.0, gap 2.0) — How well do AI models consuming your domain's data fall under a defined model governance framework (risk classification, approval process, ongoing oversight requirements), and how well understood is that coverage at the domain level? [Ivan Petrov: Ownership of INT-06 is informal and undocumented.]
INT-09 (INT, As-Is 2.0, gap 1.0) — Once an AI model using your domain's data is in live **usage**, how effectively is ongoing bias, drift, or transparency degradation linked to domain data monitored, and how well do findings feed back into improving the domain's data or its governance? [Ivan Petrov: Ownership of INT-09 is informal and undocumented.]
CUL-03 (CUL, As-Is 2.0, gap 2.0) — How well-supported is your own ongoing development as a Data Engineer — access to training, peer learning, and skill development that keeps your capability current with evolving data practices and tools? [Ivan Petrov: Ownership of CUL-03 is informal and undocumented.]
STR-CON-03 (STR, As-Is 2.0, gap 1.0) — When you have a data need that is unmet — data you cannot get, a report that does not exist, or an obstacle that stops you using data in your decisions — how effectively does that reach the people who set the organisation’s Data Strategy? [Lena Novak: Ownership of STR-CON-03 is informal and undocumented.]
STR-CON-06 (STR, As-Is 2.0, gap 2.0) — How regularly are you, as a business consumer of data, actually included in the organisation’s assessment of its own data maturity, and do you see improvement resulting from it? [Lena Novak: Ownership of STR-CON-06 is informal and undocumented.]
GOV-CON-03 (GOV, As-Is 2.0, gap 1.0) — When you are granted access to data, how clearly are the applicable terms and conditions of use — what you may do with the data, what you must not do, and your obligations — communicated to and acknowledged by you? [Lena Novak: Ownership of GOV-CON-03 is informal and undocumented.]
GOV-CON-06 (GOV, As-Is 2.0, gap 2.0) — How clearly do the organisation’s governance rules tell you what you may do with organisational data when using AI/GenAI tools — including pasting data into a chat tool, uploading files, or using AI features embedded in business applications? [Lena Novak: Ownership of GOV-CON-06 is informal and undocumented.]
ARC-CON-02 (ARC, As-Is 2.0, gap 1.0) — To what extent can you reach the data you need through a small number of consistent, integrated entry points, as opposed to navigating many disconnected systems, extracts and local copies? [Lena Novak: Ownership of ARC-CON-02 is informal and undocumented.]
ARC-CON-05 (ARC, As-Is 2.0, gap 2.0) — When the tools and platforms you use create friction — something is too slow, an integration is missing, an interface is unusable — how effectively does that experience reach the people planning the data architecture? [Lena Novak: Ownership of ARC-CON-05 is informal and undocumented.]
DQT-CON-03 (DQT, As-Is 2.0, gap 1.0) — How confident are you that the datasets and reports you use contain all the records and fields they should, rather than silently omitting parts of the population you are analysing? [Lena Novak: Ownership of DQT-CON-03 is informal and undocumented.]
DQT-CON-06 (DQT, As-Is 2.0, gap 2.0) — Once you report a data quality issue, how effectively is it resolved, and how well are you kept informed of what happened? [Lena Novak: Ownership of DQT-CON-06 is informal and undocumented.]
MDT-CON-01 (MDT, As-Is 2.0, gap 1.0) — When you encounter a business term or measure in a report or dataset, how easily can you find an agreed, authoritative definition of what it actually means? [Lena Novak: Ownership of MDT-CON-01 is informal and undocumented.]
MDT-CON-04 (MDT, As-Is 2.0, gap 2.0) — When the same business concept appears in different systems, reports or business areas, how consistently is it defined and named, as opposed to carrying conflicting meanings? [Lena Novak: Ownership of MDT-CON-04 is informal and undocumented.]
MDT-CON-07 (MDT, As-Is 2.0, gap 1.0) — How effectively can you contribute to the organisation’s metadata — flagging an unclear definition, requesting a missing one, rating an asset, or adding usage context others would benefit from? [Lena Novak: Ownership of MDT-CON-07 is informal and undocumented.]
DST-CON-02 (DST, As-Is 2.0, gap 2.0) — How well prepared are you, through training and support, to use the analytical tools available to you correctly and confidently? [Lena Novak: Ownership of DST-CON-02 is informal and undocumented.]
DST-CON-05 (DST, As-Is 2.0, gap 1.0) — How well does the standard performance and KPI reporting you receive give you a consistent, comparable view of business performance over time and across business areas? [Lena Novak: Ownership of DST-CON-05 is informal and undocumented.]
DST-CON-08 (DST, As-Is 2.0, gap 2.0) — When you are looking at a chart or figure, how easily can you establish what data it is built from, how it is defined, and how current it is — without leaving the report? [Lena Novak: Ownership of DST-CON-08 is informal and undocumented.]
INT-CON-01 (INT, As-Is 2.0, gap 1.0) — To what extent do you have access to, and actually use, predictive or forward-looking analysis — forecasts, propensity scores, risk indicators, anomaly alerts — rather than only historical reporting? [Lena Novak: Ownership of INT-CON-01 is informal and undocumented.]
INT-CON-04 (INT, As-Is 2.0, gap 2.0) — How clearly do you understand when a model output should be relied upon and when your own judgement should take precedence — and how straightforward is it to record an override? [Lena Novak: Ownership of INT-CON-04 is informal and undocumented.]
INT-CON-07 (INT, As-Is 2.0, gap 1.0) — When a model output turns out to be wrong or unhelpful in practice, how effectively does that experience reach the people responsible for the model? [Lena Novak: Ownership of INT-CON-07 is informal and undocumented.]
CUL-CON-03 (CUL, As-Is 2.0, gap 2.0) — In your team, how consistently are decisions actually supported by reference to data, as opposed to being made on intuition, precedent or seniority with data cited afterwards if at all? [Lena Novak: Ownership of CUL-CON-03 is informal and undocumented.]
CUL-CON-06 (CUL, As-Is 2.0, gap 1.0) — How much do you and your colleagues genuinely trust the organisation’s data and reporting when it matters — and is that trust actively understood and managed? [Lena Novak: Ownership of CUL-CON-06 is informal and undocumented.]
CUL-CON-09 (CUL, As-Is 2.0, gap 2.0) — How well prepared are you to use AI and GenAI capability appropriately in your work — understanding what it is good at, where it fails, and what your responsibilities are when using it? [Lena Novak: Ownership of CUL-CON-09 is informal and undocumented.]

Opportunities

STR-04 (STR, As-Is 3.0, gap 2.0) — To what extent are the data management priorities in your specific domain (the datasets, quality issues, and access requests you handle) explicitly aligned with the organisation's strategic data goals, rather than driven by ad hoc requests? [Marta Klein: Formalise ownership and add a monthly review of STR-04.]
STR-07 (STR, As-Is 2.0, gap 2.0) — How regularly and rigorously does your domain assess its own data maturity, document a target capability state and the roadmap to close the gap, and track the progress against that gap over time? [Marta Klein: Formalise ownership and add a monthly review of STR-07.]
ARC-01 (ARC, As-Is 3.0, gap 2.0) — How consistently do the data models, schemas, and structures used in your domain conform to the organisation's defined data architecture standards and modelling conventions? [Marta Klein: Formalise ownership and add a monthly review of ARC-01.]
ARC-03 (ARC, As-Is 2.0, gap 2.0) — How complete, accurate, and accessible is the documentation of your domain's data models, schemas, and data lineage (where data comes from, how it's transformed, and where it goes)? [Marta Klein: Formalise ownership and add a monthly review of ARC-03.]
MDT-01 (MDT, As-Is 3.0, gap 2.0) — How completely are the business terms and data elements in your domain defined in a shared business glossary, with definitions that are agreed and understood by the people who use them? [Marta Klein: Formalise ownership and add a monthly review of MDT-01.]
MDT-03 (MDT, As-Is 2.0, gap 2.0) — How consistently do metadata definitions, naming conventions, and classifications in your domain align with organisation-wide standards, avoiding conflicting or duplicate definitions for the same business concept? [Marta Klein: Formalise ownership and add a monthly review of MDT-03.]
INT-01 (INT, As-Is 3.0, gap 2.0) — How well does your domain's data support advanced predictive analytics (forecasting, propensity modelling, anomaly detection) beyond basic descriptive reporting? [Marta Klein: Formalise ownership and add a monthly review of INT-01.]
INT-05 (INT, As-Is 2.0, gap 2.0) — How systematically is your domain's data assessed for potential sources of bias (unrepresentative samples, historical bias embedded in labels, skewed collection methods) before and during its use in AI models, and how are identified biases mitigated? [Marta Klein: Formalise ownership and add a monthly review of INT-05.]
STR-03 (STR, As-Is 2.0, gap 2.0) — How sustainable and well-governed is the funding model for data initiatives — is data funded as a one-off project cost, or as an ongoing, governed investment? [Dana Voss: Formalise ownership and add a monthly review of STR-03.]
ARC-01 (ARC, As-Is 2.0, gap 2.0) — How well-governed are decisions to invest in, select, or retire major data platforms and technologies, from a strategic fit and scalability perspective? [Dana Voss: Formalise ownership and add a monthly review of ARC-01.]
MDT-02 (MDT, As-Is 2.0, gap 2.0) — How confident can the organisation be that, in the event of an audit, regulatory inquiry, or major incident, it could produce reliable metadata and lineage evidence across the organisation, not just for the datasets a specific team happens to have documented well? [Dana Voss: Formalise ownership and add a monthly review of MDT-02.]
INT-03 (INT, As-Is 2.0, gap 2.0) — Does the executive team treat algorithm transparency and bias mitigation as an owned, resourced enterprise risk and ethics responsibility, with clear accountability, rather than a technical concern left entirely to individual data science teams? [Dana Voss: Formalise ownership and add a monthly review of INT-03.]
STR-02 (STR, As-Is 2.0, gap 2.0) — How regularly and rigorously does your domain assess its own data maturity, document a target state and the gap to close, and track progress against that gap over time? [Ivan Petrov: Formalise ownership and add a monthly review of STR-02.]
GOV-02 (GOV, As-Is 3.0, gap 2.0) — How well-defined, auditable, and consistently followed is the process for granting, reviewing, and revoking access to data in your domain? [Ivan Petrov: Formalise ownership and add a monthly review of GOV-02.]
GOV-04 (GOV, As-Is 2.0, gap 2.0) — To what extent does your domain have defined data contracts or terms of use for its datasets, specifying obligations, permitted uses, and restrictions, and how consistently are these actually applied when access is granted? [Ivan Petrov: Formalise ownership and add a monthly review of GOV-04.]
ARC-01 (ARC, As-Is 3.0, gap 2.0) — How consistently do the data models, schemas, and structures used in your domain conform to the organisation's defined data architecture standards and modelling conventions? [Ivan Petrov: Formalise ownership and add a monthly review of ARC-01.]
ARC-03 (ARC, As-Is 2.0, gap 2.0) — How complete, accurate, and accessible is the documentation of your domain's data models, schemas, and data lineage (where data comes from, how it's transformed, and where it goes)? [Ivan Petrov: Formalise ownership and add a monthly review of ARC-03.]
ARC-07 (ARC, As-Is 3.0, gap 2.0) — How well do the connections between your domain's data and AI/ML pipelines, model-serving platforms, or GenAI tools (RAG systems, agent frameworks, model training pipelines) conform to defined integration standards? [Ivan Petrov: Formalise ownership and add a monthly review of ARC-07.]
DQT-01 (DQT, As-Is 2.0, gap 2.0) — How well-defined are data quality rules (accuracy, completeness, consistency, timeliness, validity) for the datasets in your domain, and how much of your domain's data do these rules actually cover? [Ivan Petrov: Formalise ownership and add a monthly review of DQT-01.]
DQT-05 (DQT, As-Is 3.0, gap 2.0) — When a data quality issue occurs, how effectively does your domain investigate its root cause and take action to prevent it recurring, rather than simply fixing the symptom each time? [Ivan Petrov: Formalise ownership and add a monthly review of DQT-05.]
DQT-07 (DQT, As-Is 2.0, gap 2.0) — How well-defined are the quality standards your domain's data must meet specifically to be used in AI/GenAI training, fine-tuning, or grounding (e.g. RAG source material) — covering criteria like representativeness, bias, freshness, and label accuracy — as distinct from general data quality rules? [Ivan Petrov: Formalise ownership and add a monthly review of DQT-07.]
MDT-02 (MDT, As-Is 3.0, gap 2.0) — How consistently do metadata definitions, naming conventions, and classifications in your domain align with organisation-wide standards, avoiding conflicting or duplicate definitions for the same concept? [Ivan Petrov: Formalise ownership and add a monthly review of MDT-02.]
MDT-04 (MDT, As-Is 2.0, gap 2.0) — How confident can users be that the metadata describing your domain's data is accurate and reflects the data's current state, rather than being outdated or misleading? [Ivan Petrov: Formalise ownership and add a monthly review of MDT-04.]
DST-01 (DST, As-Is 3.0, gap 2.0) — How confident can you be that dashboards and reports built on your domain's data accurately reflect the agreed definitions, business rules, and calculations for that data, rather than a report-builder's own interpretation? [Ivan Petrov: Formalise ownership and add a monthly review of DST-01.]
DST-03 (DST, As-Is 2.0, gap 2.0) — When a Data Consumer spots something that looks wrong in a dashboard or report built on your domain's data ("this number doesn't look right"), how effectively does that get traced back to you and resolved at the source? [Ivan Petrov: Formalise ownership and add a monthly review of DST-03.]
INT-04 (INT, As-Is 3.0, gap 2.0) — For AI models that use your domain's data, how transparent is the explanation of how specific domain data elements influence the model's decisions or outputs? [Ivan Petrov: Formalise ownership and add a monthly review of INT-04.]
INT-06 (INT, As-Is 2.0, gap 2.0) — How well do AI models consuming your domain's data fall under a defined model governance framework (risk classification, approval process, ongoing oversight requirements), and how well understood is that coverage at the domain level? [Ivan Petrov: Formalise ownership and add a monthly review of INT-06.]
CUL-01 (CUL, As-Is 3.0, gap 2.0) — When decisions are made within your domain, how consistently are they actually supported by reference to data, as opposed to being made on intuition, precedent, or authority alone, with data invoked only afterward if at all? [Ivan Petrov: Formalise ownership and add a monthly review of CUL-01.]
CUL-03 (CUL, As-Is 2.0, gap 2.0) — How well-supported is your own ongoing development as a Data Engineer — access to training, peer learning, and skill development that keeps your capability current with evolving data practices and tools? [Ivan Petrov: Formalise ownership and add a monthly review of CUL-03.]
STR-CON-04 (STR, As-Is 3.0, gap 2.0) — When your area needs investment in data — a new data source, a fixed report, better access, or a tool — how transparent and strategy-based is the process by which that request is prioritised or declined? [Lena Novak: Formalise ownership and add a monthly review of STR-CON-04.]
STR-CON-06 (STR, As-Is 2.0, gap 2.0) — How regularly are you, as a business consumer of data, actually included in the organisation’s assessment of its own data maturity, and do you see improvement resulting from it? [Lena Novak: Formalise ownership and add a monthly review of STR-CON-06.]
GOV-CON-04 (GOV, As-Is 3.0, gap 2.0) — How well do you understand, and consistently follow, the organisation’s data policies in your everyday work — classification and handling of sensitive data, retention, and treatment of personal information — as opposed to relying on general caution? [Lena Novak: Formalise ownership and add a monthly review of GOV-CON-04.]
GOV-CON-06 (GOV, As-Is 2.0, gap 2.0) — How clearly do the organisation’s governance rules tell you what you may do with organisational data when using AI/GenAI tools — including pasting data into a chat tool, uploading files, or using AI features embedded in business applications? [Lena Novak: Formalise ownership and add a monthly review of GOV-CON-06.]
ARC-CON-03 (ARC, As-Is 3.0, gap 2.0) — When you use a dataset or report, how easily can you establish where the underlying data actually comes from, how current it is, and what has been done to it along the way? [Lena Novak: Formalise ownership and add a monthly review of ARC-CON-03.]
ARC-CON-05 (ARC, As-Is 2.0, gap 2.0) — When the tools and platforms you use create friction — something is too slow, an integration is missing, an interface is unusable — how effectively does that experience reach the people planning the data architecture? [Lena Novak: Formalise ownership and add a monthly review of ARC-CON-05.]
DQT-CON-04 (DQT, As-Is 3.0, gap 2.0) — When you open a dataset or report, how clearly can you see its current quality status — known issues, certification, or any warning that it should be used with caution? [Lena Novak: Formalise ownership and add a monthly review of DQT-CON-04.]
DQT-CON-06 (DQT, As-Is 2.0, gap 2.0) — Once you report a data quality issue, how effectively is it resolved, and how well are you kept informed of what happened? [Lena Novak: Formalise ownership and add a monthly review of DQT-CON-06.]
MDT-CON-02 (MDT, As-Is 3.0, gap 2.0) — When you need data for a new question, how easily can you find out what data and reports already exist across the organisation, without relying on personal networks? [Lena Novak: Formalise ownership and add a monthly review of MDT-CON-02.]
MDT-CON-04 (MDT, As-Is 2.0, gap 2.0) — When the same business concept appears in different systems, reports or business areas, how consistently is it defined and named, as opposed to carrying conflicting meanings? [Lena Novak: Formalise ownership and add a monthly review of MDT-CON-04.]
MDT-CON-08 (MDT, As-Is 3.0, gap 2.0) — For AI-assisted outputs and AI-supported datasets you use, how well are you told what they were built from, what their limitations are, and what they may be relied on for? [Lena Novak: Formalise ownership and add a monthly review of MDT-CON-08.]
DST-CON-02 (DST, As-Is 2.0, gap 2.0) — How well prepared are you, through training and support, to use the analytical tools available to you correctly and confidently? [Lena Novak: Formalise ownership and add a monthly review of DST-CON-02.]
DST-CON-06 (DST, As-Is 3.0, gap 2.0) — Before commissioning or building something new, how easily can you find out whether a report or analysis that answers your question already exists? [Lena Novak: Formalise ownership and add a monthly review of DST-CON-06.]
DST-CON-08 (DST, As-Is 2.0, gap 2.0) — When you are looking at a chart or figure, how easily can you establish what data it is built from, how it is defined, and how current it is — without leaving the report? [Lena Novak: Formalise ownership and add a monthly review of DST-CON-08.]
INT-CON-02 (INT, As-Is 3.0, gap 2.0) — To what extent are recommendations, prioritisations or automated decisions generated by analytical or AI systems part of your everyday workflow, and how clearly is their role defined? [Lena Novak: Formalise ownership and add a monthly review of INT-CON-02.]
INT-CON-04 (INT, As-Is 2.0, gap 2.0) — How clearly do you understand when a model output should be relied upon and when your own judgement should take precedence — and how straightforward is it to record an override? [Lena Novak: Formalise ownership and add a monthly review of INT-CON-04.]
CUL-CON-01 (CUL, As-Is 3.0, gap 2.0) — How well equipped do you feel to interpret data correctly in your work — reading charts accurately, understanding measures and their limits, and recognising when a conclusion is not supported by the data? [Lena Novak: Formalise ownership and add a monthly review of CUL-CON-01.]
CUL-CON-03 (CUL, As-Is 2.0, gap 2.0) — In your team, how consistently are decisions actually supported by reference to data, as opposed to being made on intuition, precedent or seniority with data cited afterwards if at all? [Lena Novak: Formalise ownership and add a monthly review of CUL-CON-03.]
CUL-CON-07 (CUL, As-Is 3.0, gap 2.0) — How well supported is your ongoing development in data skills beyond initial training — keeping pace with new tools, techniques and organisational data practice? [Lena Novak: Formalise ownership and add a monthly review of CUL-CON-07.]
CUL-CON-09 (CUL, As-Is 2.0, gap 2.0) — How well prepared are you to use AI and GenAI capability appropriately in your work — understanding what it is good at, where it fails, and what your responsibilities are when using it? [Lena Novak: Formalise ownership and add a monthly review of CUL-CON-09.]

Threats

GOV-03 (GOV, As-Is 2.0, gap 1.0) — How well-defined, auditable, and consistently followed is the process for granting, reviewing, and revoking access to data in your domain? [Marta Klein: Observed during the Data Maturity review of the Data Steward domain.]
DQT-05 (DQT, As-Is 2.0, gap 1.0) — When a data quality issue occurs, how effectively does your domain investigate its root cause and take action to prevent it recurring, rather than simply fixing the symptom each time? [Marta Klein: Observed during the Data Maturity review of the Data Steward domain.]
DST-05 (DST, As-Is 2.0, gap 1.0) — When a business user spots something that looks wrong in a dashboard or report built on your domain's data ("this number doesn't look right"), how effectively does that get traced back to you and resolved at the source? [Marta Klein: Observed during the Data Maturity review of the Data Steward domain.]
CUL-05 (CUL, As-Is 2.0, gap 1.0) — How well-supported is your own ongoing development — access to training, peer learning, and skill development that keeps your capability current with evolving data priorities, practices, techniques and tools? [Marta Klein: Observed during the Data Maturity review of the Data Steward domain.]
GOV-01 (GOV, As-Is 2.0, gap 1.0) — How consistently are data governance policies (data handling, classification, retention, PII treatment, etc.) actually followed in your domain's daily operations, as opposed to existing only on paper? [Ivan Petrov: Observed during the Data Maturity review of the Data Engineer domain.]
GOV-07 (GOV, As-Is 2.0, gap 1.0) — How effectively does your domain detect, investigate, and resolve issues arising from AI/GenAI systems' actual use of its data — including misuse, scope creep, data leakage into model outputs, or use beyond what was approved? [Ivan Petrov: Observed during the Data Maturity review of the Data Engineer domain.]
ARC-06 (ARC, As-Is 2.0, gap 1.0) — How well does your domain's data architecture support the structures and access patterns AI/GenAI initiatives actually need (e.g. vector embeddings, feature stores, unstructured/semi-structured data, retrieval-optimised storage), as opposed to only traditional relational/tabular patterns? [Ivan Petrov: Observed during the Data Maturity review of the Data Engineer domain.]
DQT-04 (DQT, As-Is 2.0, gap 1.0) — How is data quality in your domain measured using defined metrics and thresholds, and how is that measurement reported to relevant stakeholders? [Ivan Petrov: Observed during the Data Maturity review of the Data Engineer domain.]
MDT-01 (MDT, As-Is 2.0, gap 1.0) — How complete and accurate is the technical metadata (schema definitions, data types, formats, constraints, source system) documented for datasets in your domain? [Ivan Petrov: Observed during the Data Maturity review of the Data Engineer domain.]
MDT-07 (MDT, As-Is 2.0, gap 1.0) — When an AI/GenAI system misuses, misinterprets, or retrieves the wrong domain data (e.g. due to unclear definitions, missing context, or poor documentation), how effectively does that experience feed back into improving your domain's metadata? [Ivan Petrov: Observed during the Data Maturity review of the Data Engineer domain.]
INT-03 (INT, As-Is 2.0, gap 1.0) — At which stages of the AI model lifecycle (data selection, training, validation, deployment, monitoring, retirement) does the Data Engineer have a defined, expected role regarding models that consume your domain's data? [Ivan Petrov: Observed during the Data Maturity review of the Data Engineer domain.]
INT-09 (INT, As-Is 2.0, gap 1.0) — Once an AI model using your domain's data is in live **usage**, how effectively is ongoing bias, drift, or transparency degradation linked to domain data monitored, and how well do findings feed back into improving the domain's data or its governance? [Ivan Petrov: Observed during the Data Maturity review of the Data Engineer domain.]
STR-CON-03 (STR, As-Is 2.0, gap 1.0) — When you have a data need that is unmet — data you cannot get, a report that does not exist, or an obstacle that stops you using data in your decisions — how effectively does that reach the people who set the organisation’s Data Strategy? [Lena Novak: Observed during the Data Maturity review of the Data Consumer domain.]
GOV-CON-03 (GOV, As-Is 2.0, gap 1.0) — When you are granted access to data, how clearly are the applicable terms and conditions of use — what you may do with the data, what you must not do, and your obligations — communicated to and acknowledged by you? [Lena Novak: Observed during the Data Maturity review of the Data Consumer domain.]
ARC-CON-02 (ARC, As-Is 2.0, gap 1.0) — To what extent can you reach the data you need through a small number of consistent, integrated entry points, as opposed to navigating many disconnected systems, extracts and local copies? [Lena Novak: Observed during the Data Maturity review of the Data Consumer domain.]
DQT-CON-03 (DQT, As-Is 2.0, gap 1.0) — How confident are you that the datasets and reports you use contain all the records and fields they should, rather than silently omitting parts of the population you are analysing? [Lena Novak: Observed during the Data Maturity review of the Data Consumer domain.]
MDT-CON-01 (MDT, As-Is 2.0, gap 1.0) — When you encounter a business term or measure in a report or dataset, how easily can you find an agreed, authoritative definition of what it actually means? [Lena Novak: Observed during the Data Maturity review of the Data Consumer domain.]
MDT-CON-07 (MDT, As-Is 2.0, gap 1.0) — How effectively can you contribute to the organisation’s metadata — flagging an unclear definition, requesting a missing one, rating an asset, or adding usage context others would benefit from? [Lena Novak: Observed during the Data Maturity review of the Data Consumer domain.]
DST-CON-05 (DST, As-Is 2.0, gap 1.0) — How well does the standard performance and KPI reporting you receive give you a consistent, comparable view of business performance over time and across business areas? [Lena Novak: Observed during the Data Maturity review of the Data Consumer domain.]
INT-CON-01 (INT, As-Is 2.0, gap 1.0) — To what extent do you have access to, and actually use, predictive or forward-looking analysis — forecasts, propensity scores, risk indicators, anomaly alerts — rather than only historical reporting? [Lena Novak: Observed during the Data Maturity review of the Data Consumer domain.]
INT-CON-07 (INT, As-Is 2.0, gap 1.0) — When a model output turns out to be wrong or unhelpful in practice, how effectively does that experience reach the people responsible for the model? [Lena Novak: Observed during the Data Maturity review of the Data Consumer domain.]
CUL-CON-06 (CUL, As-Is 2.0, gap 1.0) — How much do you and your colleagues genuinely trust the organisation’s data and reporting when it matters — and is that trust actively understood and managed? [Lena Novak: Observed during the Data Maturity review of the Data Consumer domain.]

Leading practices at target level

STR: The CDO mandate is reviewed and reaffirmed on a defined cycle, with authority and scope adjusted as the organisation's data agenda matures, and performance against the mandate is tracked. The CDO's mandate, scope, and success measures are reviewed at least annually against organisational priorities, with outcomes reported to the executive team or board.
STR: ROI against the data strategy is tracked and reported on a regular cycle, with the executive team or board reviewing actual versus targeted business value. A tracked ROI dashboard or report is reviewed by the executive team or board on a defined cadence, comparing actual outcomes to strategy targets.
STR: Data investment is portfolio-managed, with funding prioritised across competing initiatives based on strategic value and tracked return, reviewed on a defined cycle. A data investment portfolio is actively managed, with funding reallocated between initiatives based on tracked value and strategic priority.
STR: Roadmap execution is tracked against milestones on a regular cycle, with variances reported to the executive team or board and remediation action taken. A tracked execution dashboard compares actual roadmap progress to planned milestones, reviewed regularly with remediation action for variances.
GOV: The governance operating model is reviewed and matured on a defined cycle, with its effectiveness measured and reported to the executive team or board. The operating model is reviewed at least annually, with effectiveness measures (e.g. issue resolution time, policy compliance rate) reported to senior stakeholders.
GOV: Compliance is measured using defined enterprise metrics and thresholds, tracked over time, with the executive team or board reviewing trends and exceptions. Enterprise-wide compliance metrics are tracked period-over-period, with trends and exceptions formally reviewed by the executive team or board.
GOV: Escalated issues are tracked to resolution with defined response-time expectations, and patterns across escalations are reviewed to identify systemic governance gaps. Escalated issues are logged and tracked to resolution against response-time expectations, with periodic review of escalation patterns for systemic causes.
ARC: Platform and technology investments are tracked as a managed portfolio, with scalability and resilience metrics reviewed regularly against organisational growth plans. A technology investment portfolio is actively managed, with scalability/resilience metrics reviewed against forecast organisational growth on a defined cycle.
ARC: Data movement risk is tracked against a remediation plan, with technical debt reduction resourced and progress reported to the executive team. A remediation plan addressing identified risk areas is resourced and actively progressed, with status reported to the executive team on a defined cycle.
DQT: Actual data quality performance is systematically measured against the risk appetite, with breaches reported to the executive team or board and tracked to resolution. Quality performance is measured against defined risk appetite thresholds, with breaches formally reported and tracked through to resolution at executive level.
DQT: Root-cause findings are systematically translated into funded, tracked systemic improvement initiatives, with progress reported to the executive team or board. Systemic improvement initiatives derived from root-cause findings are funded and tracked, with progress formally reported at executive level.
MDT: The metadata program's coverage and quality are tracked against enterprise-wide targets, with progress reported to the executive team on a defined cycle. Coverage and quality metrics are tracked against enterprise-wide targets, with progress formally reported to the executive team.
MDT: Metadata and lineage audit-readiness is tracked across the organisation, with material gaps closed on a defined cycle and readiness reported to the executive team or board. Audit-readiness tracking covers the organisation's material data domains, with closure of identified gaps reported to the executive team or board.
DST: Self-service analytics adoption is tracked across the organisation, with usage and semantic layer coverage expanding on a defined roadmap and reported to the executive team. Adoption metrics and semantic layer coverage are tracked against a roadmap, with expansion progress reported to the executive team.
DST: All material enterprise KPIs are certified and consistency is systematically checked across reports, with discrepancies tracked to resolution. Comprehensive KPI certification covers all material enterprise metrics, with systematic consistency checks and tracked resolution of any discrepancy found.
INT: AI initiatives are tracked as a managed portfolio against the strategy, with value, risk, and resourcing reviewed by the executive team on a defined cycle. A managed AI portfolio is reviewed on a defined cycle, with value, risk, and resourcing decisions made at executive level.
INT: All models in production are covered by the governance framework and tracked in a comprehensive inventory, with lifecycle status reported to the executive team on a defined cycle. A comprehensive model inventory covers all production models, tracked against governance framework requirements, with status reported to the executive team.
INT: Bias mitigation and transparency requirements are systematically applied and tracked across all material AI initiatives, with findings reported to the executive team or board. Comprehensive application of bias mitigation and transparency requirements is tracked across all material AI initiatives, with findings formally reported at executive level.
INT: Realised value is tracked across the full AI portfolio, with underperforming initiatives identified and reviewed, and results reported to the executive team. Portfolio-wide value tracking identifies underperforming initiatives for review, with consolidated results reported to the executive team.
CUL: Literacy pathway participation and outcomes are tracked across the organisation, with investment adjusted based on measured skill gaps and reported to the executive team. Participation and outcome data across literacy pathways inform adjusted investment, reported to the executive team on a defined cycle.
CUL: The collaboration model extends across the organisation's material business areas, with effectiveness tracked and reported to the executive team. Comprehensive collaboration model coverage is tracked for effectiveness, with results reported to the executive team on a defined cycle.
STR: Domain priorities are consistently and measurably aligned to strategic goals, with alignment tracked as part of regular reporting. Data Engineer's domain backlog/priority list is reviewed against strategic goals on a defined cadence, with a tracked alignment metric (e.g. % of active work items mapped to a strategic goal).
STR: Assessments are conducted on a regular, enforced cadence; gaps are translated into tracked improvement actions/workstreams with owners and timelines, and progress is reviewed on schedule. Data Engineer's domain has an active improvement plan derived directly from the gap analysis, with named owners, target dates, and a defined review checkpoint (e.g. quarterly) where progress is formally checked against the plan.
STR: Dataset-level AI/GenAI suitability and constraints are formally reviewed and updated on a regular cycle, aligned to specific named AI/GenAI use cases and their risk profiles. Data Engineer participates in a periodic review connecting specific domain datasets to specific approved AI/GenAI use cases, with constraints tailored to each use case's risk level.
STR: Readiness is systematically tracked across the domain's datasets, with identified gaps assigned as remediation actions and progress monitored against defined AI/GenAI data-quality thresholds. Data Engineer maintains or contributes to a tracked register of AI/GenAI readiness status per dataset, with remediation actions owned and progressed against thresholds (e.g. minimum completeness, bias-testing status).
GOV: Access is role-based, tied to defined access tiers, with periodic reviews to confirm access remains appropriate and revoke what is no longer needed. Access levels map to defined roles/tiers rather than being granted individually each time, and a scheduled review process (e.g. quarterly) identifies and removes stale or excessive access.
GOV: Issues are logged, tracked to resolution, and reviewed for root cause, with response-time expectations and accountability for closure. Data Engineer's domain has a tracked issue log showing time to detection, escalation, resolution, and a documented root-cause note for at least significant issues.
GOV: Data contracts/terms of use are applied consistently across all datasets in the domain (not just priority ones), are version-controlled, and are reviewed on a defined cycle. Every dataset in the domain has an associated, current terms-of-use record; Data Engineer can confirm coverage is comprehensive and terms are periodically reviewed and updated.
GOV: AI/GenAI governance policy is comprehensive, covering distinct AI use-case types (training, RAG, prompting, agentic access) with differentiated rules, and is reviewed on a defined cycle as AI usage evolves. Data Engineer applies differentiated rules depending on the specific type of AI use (e.g. stricter rules for training-data inclusion than for read-only RAG retrieval), with policy reviewed periodically against emerging AI use patterns in the domain.
GOV: AI system access is role/purpose-based (e.g. tiered by use case risk), tracked separately from human access, with periodic review to confirm AI access remains appropriate and is revoked when a pipeline or tool is decommissioned. Data Engineer maintains or reviews a register of AI systems/pipelines with access to domain data, tagged by use case and risk tier, with scheduled reviews that revoke access for retired or changed AI initiatives.
ARC: Conformance to architecture standards is tracked across all domain data structures, with non-conformance logged as remediation debt and progressed on a defined cycle. Data Engineer maintains or contributes to a tracked conformance register for the domain, with identified deviations assigned as remediation items with owners and timelines.
ARC: Domain data flows are systematically reviewed for interoperability, with integration standards conformance tracked and non-conformant legacy flows scheduled for remediation. Data Engineer's domain maintains an inventory of integration points with conformance status, and legacy non-conformant flows are tracked as planned remediation work.
ARC: Documentation covers all domain datasets (not just priority ones), including detailed lineage (transformations, source systems, Data Consumers), and is kept current through a defined maintenance process. Data Engineer follows a defined process (e.g. documentation updated as part of change management) ensuring full-domain coverage and detailed lineage remain accurate over time.
ARC: Storage placement across the domain's full dataset inventory is systematically reviewed on a defined cycle, with mismatches tracked as migration/optimisation actions. Data Engineer's domain has a tracked register of storage placement reviews, with identified mismatches assigned as remediation actions with owners and timelines.
ARC: Domain architecture issues are logged, tracked, and reviewed as part of a defined process, with outcomes reported back to the reporting Data Engineer and reflected in architecture planning. Data Engineer receives confirmation and status updates on reported architecture issues, and can see whether/how the issue influenced the architecture roadmap or backlog prioritisation.
ARC: AI/ML integration points are systematically tracked for conformance, performance, and reliability, with legacy or non-conformant connections scheduled for remediation. Data Engineer's domain maintains an inventory of AI/ML integration points with conformance and reliability status, with remediation tracked for problem connections.
ARC: AI/GenAI data lineage is tracked comprehensively across all domain datasets used in AI initiatives, including transformation steps (e.g. chunking, embedding, feature engineering), and is kept current through a defined process. Data Engineer's domain maintains comprehensive, current AI-specific lineage records covering all relevant datasets and the transformations applied before AI use.
DQT: Data quality rules cover the domain's full dataset inventory (not just priority datasets), are version-controlled, and are reviewed and updated on a defined cycle. Data Engineer ensures rule coverage extends across the domain, with rules reviewed periodically to confirm they still reflect actual business requirements.
DQT: Quality metrics are tracked on a dashboard, monitored against defined thresholds, and reviewed on a regular (e.g. weekly/monthly) basis across the domain's full dataset inventory. Data Engineer reviews a quality dashboard covering the domain on a regular cadence, with defined thresholds indicating when a metric requires attention.
DQT: Quality issues are logged, tracked to resolution with defined response-time expectations, and remediation outcomes are verified (i.e. confirmed fixed, not just closed). Data Engineer's domain maintains a tracked issue log showing detection date, remediation action, resolution date, and verification that the fix actually resolved the problem.
DQT: Root cause findings are systematically translated into upstream preventive actions (e.g. source system fixes, validation rules added at entry point), tracked to completion. Data Engineer's domain has a tracked register linking root cause findings to specific preventive actions, with owners, timelines, and confirmation of implementation.
DQT: Tolerance thresholds are defined and tracked across the domain's significant downstream processes, with data quality actively managed against these thresholds rather than against a single uniform quality bar. Data Engineer manages quality effort proportionally — prioritising fixes for imperfections that matter to a process's actual tolerance threshold, and consciously not over-investing in fixing imperfections that don't.
DQT: AI-specific quality standards are systematically applied and tracked across all domain datasets used in AI initiatives, with non-conformant data flagged and remediated before use. Data Engineer maintains a tracked register of AI-use datasets and their conformance to AI-specific quality standards, with remediation actions tracked for non-conformant data.
DQT: The quality gate is consistently applied across all AI/GenAI use of domain data, with pass/fail outcomes tracked and failed data blocked pending remediation. Data Engineer's domain tracks quality-gate outcomes across all AI-related data releases, with failed validations blocking pipeline entry until resolved.
DQT: AI output issues traced to source data quality are logged, tracked to remediation, and used to update the domain's data quality rules or AI-specific quality standards. Data Engineer's domain tracks confirmed data-quality-caused AI issues through to remediation, with resulting updates made to quality rules (DQ-1) or AI-specific standards (DQ-8) to prevent recurrence.
MDT: Existing metadata is systematically reviewed against the standard, with identified inconsistencies (duplicate or conflicting definitions) tracked and resolved on a defined cycle. Data Engineer's domain maintains a tracked list of identified metadata inconsistencies, with resolution actions assigned and progressed.
MDT: Metadata for the domain's full dataset inventory is discoverable via the catalogue, with usage tracked to understand whether users are actually finding what they need. Data Engineer ensures comprehensive catalogue coverage for the domain and reviews catalogue usage/search data to identify discoverability gaps.
MDT: Metadata currency is tracked across the domain's full dataset inventory, with staleness flagged (e.g. metadata not reviewed within a defined window) and remediation tracked. Data Engineer's domain tracks metadata review dates across the full inventory, with overdue reviews flagged and assigned for action.
MDT: AI-specific metadata coverage extends across all domain datasets used in AI initiatives, is kept current, and is reviewed as AI use cases evolve. Data Engineer maintains comprehensive AI-specific metadata coverage for all domain datasets in active AI use, with periodic review as use cases change.
MDT: The metadata completeness gate is consistently applied across all AI/GenAI use of domain data, with pass/fail outcomes tracked and incomplete datasets blocked pending remediation. Data Engineer's domain tracks metadata gate outcomes across all AI-related data approvals, with incomplete metadata blocking approval until resolved.
DST: Accuracy checks are systematically applied across the domain's dashboards/reports, with discrepancies tracked and corrected, and recurring root causes addressed. Data Engineer's domain tracks accuracy-check outcomes across dashboards/reports, with identified discrepancies corrected and recurring causes investigated.
DST: All dashboards/reports using domain data include source, definition, and freshness information as a standard, enforced practice, kept current as underlying data changes. Data Engineer's domain has a standard requiring source/definition/freshness annotation on all dashboards/reports, checked and kept current as part of ongoing practice.
DST: Reported issues are logged, tracked to resolution, and the root cause is identified in source data, metadata, or calculation logic, with the reporting user informed of the outcome. Data Engineer tracks dashboard/report issues to resolution, identifying whether the cause was source data, metadata, or calculation logic, and informs the reporting user.
INT: Domain data supports multiple predictive analytics use cases, with predictive model performance and data adequacy for prediction systematically tracked. Data Engineer's domain tracks data adequacy across multiple predictive use cases, with performance monitored and gaps addressed.
INT: Domain data's role in Decision Intelligence systems is tracked across multiple decision areas, with Data Engineer input sought on data adequacy and decision quality reviewed. Data Engineer's domain has visibility into multiple Decision Intelligence use cases, contributing to periodic review of data adequacy and decision quality.
INT: Data-influence transparency information is systematically available and reviewed for all models consuming domain data, with the Data Engineer able to assess whether it is adequate to explain model behaviour to stakeholders. Data Engineer's domain ensures transparency documentation exists for all relevant models, with periodic review of whether it genuinely supports stakeholder understanding.
INT: Bias assessment is systematically applied across all domain datasets used in AI models, with identified biases tracked as mitigation actions (e.g. rebalancing, additional data collection, exclusion) and progressed to resolution. Data Engineer's domain tracks bias findings through to mitigation action, with owners, timelines, and confirmation that mitigation was implemented.
INT: All AI models consuming domain data are systematically tracked against governance framework requirements, with the Data Engineer contributing domain-level evidence to ongoing oversight activities. Data Engineer's domain maintains a tracked view of governance status for all relevant models, contributing evidence (data quality, bias findings, lineage) to oversight reviews.
INT: The sign-off is consistently required and tracked for all AI models using domain data, with training blocked until sign-off is complete and any identified bias mitigated. Data Engineer's domain tracks sign-off status across all relevant model development efforts, with training gated on completed, satisfactory sign-off.
INT: The validation gate is consistently applied across all AI model deployments using domain data, with pass/fail outcomes tracked and deployment blocked pending remediation on failure. Data Engineer's domain tracks validation gate outcomes across all relevant model deployments, with failures blocking go-live until resolved.
CUL: Evidence-backed decision-making is the norm across most decision types in the domain, with the quality and use of supporting data reviewed as part of decision governance. Data Engineer's domain reviews decision quality and data usage as part of governance, with evidence-backed decisions being the observed norm rather than the exception.
CUL: Cross-functional collaboration is systematic and covers the domain's significant initiatives, with joint accountability for outcomes and collaboration effectiveness periodically reviewed. Data Engineer's domain has joint accountability structures (shared goals, joint sign-off) for significant initiatives, with collaboration effectiveness reviewed periodically.
CUL: The Data Engineer's development is actively tracked and reviewed (e.g. as part of performance/development conversations), with progress against the defined pathway monitored and support adjusted as needed. Data Engineer's development is reviewed on a defined cycle (e.g. as part of regular performance conversations), with progress tracked and support adjusted based on identified needs.
STR: Strategy communication to business users is systematic and measured — delivered on a defined cycle, with awareness and comprehension actively checked rather than assumed. The Data Consumer participates in periodic strategy refreshers, and the organisation measures business-user awareness (e.g. through a survey or completion tracking) and acts on the result.
STR: Alignment between provided data assets and business objectives is tracked and reviewed on a defined cycle, with unaligned or unused assets identified. The Data Consumer’s area participates in a periodic review of its data assets against current objectives, with usage measured and obsolete reports retired.
STR: Prioritisation decisions are consistently made against documented criteria tied to strategic value, with outcomes and rationale tracked and visible to requesters. The Data Consumer can see where their request sits in a prioritised backlog and why it was ranked as it was, with decisions tracked over time.
STR: AI data-use guidance for business users is reviewed and updated on a defined cycle, differentiated by use case and risk, with adherence monitored. The Data Consumer receives guidance that distinguishes between use cases (drafting, summarising, analysis) with different data rules, and adherence is periodically checked.
STR: Assessment findings from business users are translated into tracked improvement actions with owners and timelines, and progress is reviewed on schedule. The Data Consumer can identify at least one improvement in their data experience that traces directly to an assessment finding, with an owner and target date.
GOV: Ownership is documented for all datasets business users consume, kept current through a defined review cycle, and contact routes are measured for responsiveness. The Data Consumer finds current ownership information for essentially any dataset they use, and enquiries are answered within a defined expectation.
GOV: Access is granted against defined roles or tiers rather than individually negotiated, with turnaround measured against a stated expectation and periodic reviews removing access no longer needed. The Data Consumer’s access is derived from their role, requests are fulfilled within a published service expectation, and access they no longer need is proactively removed.
GOV: Compliance by business users is systematically measured, with controls configured to support correct behaviour and deviations identified through monitoring rather than by accident. The Data Consumer works within systems that enforce classification and handling rules, and compliance is measured and reported (for example through sampling or automated checks).
GOV: Concerns raised by business users are logged, tracked to resolution and reviewed for root cause, with response expectations and closure accountability documented. The Data Consumer receives acknowledgement and a resolution outcome within a stated timeframe, and significant issues carry a documented root-cause note.
GOV: AI data-use rules are differentiated by use case and data sensitivity, reviewed on a defined cycle, with business-user adherence monitored. The Data Consumer follows rules that differ by scenario (drafting versus analysis, internal versus public tools) and adherence is periodically checked and reported.
GOV: Onward sharing is controlled and recorded — sensitive data carries handling markings, external sharing requires defined approval, and sharing activity is monitored. The Data Consumer’s external sharing goes through a defined approval, sensitive material carries visible markings, and sharing activity is auditable.
ARC: Availability and performance are measured against the stated expectations, reported, and capacity is planned against actual business demand including peaks. The Data Consumer experiences consistent performance at known peak periods because capacity is planned for them, and performance against expectation is reported.
ARC: End-to-end lineage is documented and maintained for business-facing assets, showing transformations between source and report, with currency displayed at the point of use. The Data Consumer can trace a figure in a report back through its transformations to the source system, and sees a refresh timestamp on the report itself.
ARC: Extraction routes are governed and monitored — controlled by access rights, logged, and subject to defined rules on retention and onward handling of extracted data. The Data Consumer’s exports are permitted by role, logged, and subject to stated rules on how long extracted data may be retained.
ARC: Business-user friction is systematically collected and analysed for patterns, feeding a tracked technology improvement backlog with outcomes reported back. The Data Consumer receives an outcome on raised constraints, and recurring friction is visible in a tracked improvement backlog.
DQT: Accuracy is measured against defined thresholds, reported to business users on a regular basis, and breaches are visibly acted upon. The Data Consumer sees a regular accuracy measure for the data they depend on and observes remediation when it falls below threshold.
DQT: Timeliness is measured against the published commitments, reported, and failures to refresh are proactively communicated to affected users. The Data Consumer is notified when a refresh fails or is delayed, before they act on stale data, and timeliness performance is reported.
DQT: Quality status is measured, kept current, and reported across the business-facing estate, with coverage of certification tracked. The Data Consumer finds current quality status on essentially all the assets they use, and the organisation measures how much of the estate carries it.
DQT: Reporting is easy and in-context, reports are tracked with stated response expectations, and reporting volumes are monitored as a quality signal. The Data Consumer can raise an issue directly from the report or dataset, receives acknowledgement within a stated timeframe, and reporting patterns are analysed.
DQT: Resolution is tracked against defined response and fix expectations, with performance reported and root cause recorded for significant issues. The Data Consumer’s issues are resolved within stated timeframes, and they can see that recurring problems have documented root causes.
DQT: Actual quality is measured against the documented business tolerances, with breaches reported to affected decision-makers. The Data Consumer is informed when data falls below the standard agreed for their decision, before that decision is made.
DQT: AI output quality is measured, reported errors are tracked to resolution, and recurring failures are traced back to the underlying data. The Data Consumer’s reports of wrong AI output are tracked, and they can see that underlying source data problems are corrected as a result.
MDT: Catalogue coverage, search success and adoption are measured, with gaps actively closed and business-user search behaviour used to improve the catalogue. The Data Consumer usually finds what they need first time, and the organisation measures search success and closes discovered gaps.
MDT: Context documentation is maintained on a defined cycle, its completeness is measured, and caveats are actively surfaced to users of affected assets. The Data Consumer is alerted to a newly identified limitation on a dataset they use, rather than discovering it independently.
MDT: Conformance to standard definitions is tracked across business-facing assets, with non-conforming variants scheduled for remediation. The Data Consumer increasingly finds the same figure defined identically across reports, with remaining exceptions documented and being addressed.
MDT: Currency is measured across the documented estate, stale entries are flagged, and completion of review is tracked and reported. The Data Consumer sees stale entries clearly marked, and the organisation reports on how much documentation is current.
MDT: Classification coverage is measured and maintained, reviewed on a defined cycle, and drives the handling controls applied to business users. The Data Consumer finds current classifications on essentially all assets they use, and those classifications visibly determine what they can do with them.
MDT: AI asset documentation is maintained on a defined cycle, its coverage measured, and material changes to sources or limitations are communicated to affected users. The Data Consumer is informed when an AI tool’s underlying sources or known limitations change materially.
DST: Self-service provision, adoption and usage are measured, with access aligned to business need and support arrangements maintained. The Data Consumer’s use of the tool is measured, provisioning follows a defined process, and support is available when they need it.
DST: Capability is assessed and tracked, training is targeted to identified gaps, and support performance is measured. The Data Consumer’s capability level is known, training is matched to their actual gaps, and support response is measured.
DST: Certification coverage is measured and maintained, uncertified proliferation is actively managed, and consumption of certified assets is tracked. The Data Consumer finds a certified asset for essentially every significant business question, and duplication is actively reduced.
DST: Consistency is measured across business-facing reporting, discrepancies are tracked as defects and remediated on a defined cycle. The Data Consumer sees consistent figures across reports, and any discrepancy they raise is logged as a defect and fixed.
DST: Catalogue coverage and search effectiveness are measured, duplication is monitored, and new requests are checked against existing assets before work begins. The Data Consumer’s new report request triggers a check for existing equivalents, and duplication rates are monitored.
DST: Conformance of reports to agreed definitions is verified as part of a defined review, tracked, and non-conformance is remediated. The Data Consumer uses reports that have been formally reviewed for definitional conformance, with exceptions tracked to closure.
DST: Compliance with the supporting-information standard is measured across the reporting estate, with gaps remediated on a defined cycle. The Data Consumer finds consistent supporting information on essentially all certified reports, with coverage measured.
DST: Review compliance is tracked, review findings are recorded, and publication without approval is detectable and addressed. The Data Consumer can rely on published reporting having been approved, because unapproved publication is detected and corrected.
DST: Queries are tracked to resolution with stated response expectations, outcomes are communicated back, and query patterns are analysed. The Data Consumer receives an explanation of what was found within a stated timeframe, and recurring queries are analysed.
INT: The effect of decision support on business outcomes is measured, override rates are tracked, and the scope of automation is reviewed on a defined cycle. The Data Consumer’s acceptance and override of recommendations is measured and reviewed, informing where automation is appropriate.
INT: Explanation quality is measured, business-user comprehension is assessed, and explanations are improved where they are not understood. The Data Consumer’s understanding of explanations is tested and acted upon, rather than assumed.
INT: Override rates and reasons are measured, reviewed against model performance, and used to determine where reliance is appropriate. The Data Consumer’s overrides are analysed alongside outcomes, and reliance guidance is adjusted on the evidence.
INT: The register is maintained on a defined cycle, adoption and unapproved use are monitored, and business users are supported in using approved capability well. The Data Consumer sees a current register, receives support in using approved tools, and unapproved use is detected and addressed.
INT: Fairness is monitored in production, results are reported to business users, and concerns raised by them are investigated and tracked. The Data Consumer receives periodic fairness monitoring results and can raise a fairness concern that is formally investigated.
CUL: Literacy levels are assessed and tracked across the business population, development is targeted at identified gaps, and improvement is reported. The Data Consumer’s literacy has been assessed, development targeted accordingly, and progress reported over time.
CUL: Participation and completion are measured and reported, with follow-up where completion lags and content adjusted on the basis of feedback. The Data Consumer’s area has visible completion rates, gaps are followed up, and their feedback shapes the content.
CUL: Evidence use in decision-making is monitored, decision quality is reviewed against outcomes, and gaps in available evidence are identified and addressed. The Data Consumer’s decisions are reviewed against outcomes, and where evidence was missing that gap is raised and addressed.
CUL: Support demand and responsiveness are measured, capacity is matched to demand, and recurring questions inform self-service improvement. The Data Consumer receives help within a stated expectation, and recurring questions lead to better documentation or tooling.
CUL: Collaboration is sustained and measured, with joint working arrangements, shared objectives and rework or satisfaction tracked. The Data Consumer works with data specialists under shared objectives, and the effectiveness of that collaboration is measured.
CUL: Development participation and capability growth are tracked, pathways are refreshed as tools and practice change, and time to learn is actively supported. The Data Consumer has supported time for development, their progression is tracked, and content stays current.
CUL: Leadership data behaviour is observed and reinforced through governance and performance mechanisms, with accountability for evidence-based decisions. The Data Consumer observes leaders being held accountable for whether decisions were evidenced, not only for outcomes.
CUL: AI literacy is assessed and tracked, content is updated as capability changes, and responsible-use practice is monitored. The Data Consumer’s AI literacy is assessed, kept current as tools change, and their practice is observed and supported.

Recommendations

Address 22 stuck low-maturity area(s) (e.g. GOV-03) before they compound.