How the organisation's data supports predictive analytics, AI, and machine learning, including transparency, bias mitigation, and model governance.
INT-01
Domain data support for advanced predictive analytics
How well does your domain's data support advanced predictive analytics (forecasting, propensity modelling, anomaly detection) beyond basic descriptive reporting?
Maturity level descriptions
Domain data has never been used for predictive analytics; it supports only basic descriptive reporting (what happened), not prediction (what is likely to happen). Domain data is consumed only for retrospective reporting, with no known predictive use and no assessment of whether it could support one.
Domain data has been used in one-off, exploratory predictive analytics efforts, but these were experimental and not adopted into standard practice. Data Engineer is aware of at least one exploratory predictive analytics attempt using domain data, but confirms it did not progress beyond experimentation.
Domain data feeds at least one defined, adopted predictive analytics use case, with data prepared and maintained specifically to support it. Data Engineer maintains or supports domain data specifically prepared for a named, adopted predictive analytics use case.
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.
Domain data is proactively maintained and evolved specifically to support advancing predictive capability (e.g. new feature engineering, expanded historical depth) ahead of emerging predictive analytics needs. Data Engineer's domain data strategy anticipates and prepares for future predictive analytics needs, rather than reacting only when a new use case is proposed.
INT-02
Domain data role in Decision Intelligence systems
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?
Maturity level descriptions
Domain data does not feed any Decision Intelligence system; all decisions using domain data are made manually by people, with no automated recommendation or decisioning layer. Decisions involving domain data are made entirely by individuals, with no system recommending or automating any part of the decision.
Domain data feeds an experimental or pilot Decision Intelligence capability, not yet trusted or used for real operational decisions. Data Engineer is aware of a pilot or experimental Decision Intelligence effort using domain data, but confirms it is not yet used for real decisions.
Domain data feeds a defined, adopted Decision Intelligence system for at least one operational decision area, with the Data Engineer aware of what decisions it influences. Data Engineer can name a specific decision area where a Decision Intelligence system uses domain data to recommend or automate outcomes.
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.
Domain data dynamically and continuously informs Decision Intelligence systems that adapt recommendations or automated decisions in near-real-time as underlying conditions change. Decision Intelligence systems fed by domain data adjust recommendations or automated actions continuously as domain conditions evolve, rather than operating on static, periodically-refreshed logic.
INT-03
Data Engineer involvement across the AI model lifecycle (data perspective)
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?
Maturity level descriptions
The Data Engineer has no defined role at any stage of the AI model lifecycle for models consuming domain data; involvement, if any, is accidental. Models are selected, trained, deployed, and retired with no expectation that the Data Engineer is involved or even informed at any stage.
Data Engineer is occasionally and informally involved at one lifecycle stage (most often data selection), depending on who is building the model. Data Engineer is sometimes informally consulted during data selection for a new model, depending on the individual data scientist's habits.
Data Engineer has a defined role at specific named lifecycle stages (e.g. data selection and validation) for priority models consuming domain data. Data Engineer performs a documented role at defined lifecycle stages for priority models, with that involvement recorded.
Data Engineer involvement spans most or all lifecycle stages (selection, validation, deployment sign-off, monitoring, retirement notification) for all models consuming domain data, tracked systematically. Data Engineer's domain tracks their involvement across the model lifecycle for all relevant models, with participation confirmed at each defined stage.
Data Engineer involvement is embedded structurally into the AI model lifecycle process itself (e.g. as a required workflow gate at each stage), rather than relying on individual initiative or tracking. The organisation's model lifecycle process technically requires Data Engineer sign-off or input at defined stages before a model can progress, for any model using domain data.
INT-04
Algorithm transparency — explainability of how domain data influences model decisions
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?
Maturity level descriptions
No information is available on how domain data elements influence any model's decisions; models using domain data are entirely opaque from a data-influence perspective. Neither the Data Engineer nor Data Consumers have any way to understand which domain data elements drive a given model's output.
Information on data influence can sometimes be obtained informally by asking the model's developer, if available and willing to explain. Data Engineer could potentially learn about data influence by asking the model developer directly, but confirms this is informal and not guaranteed.
Documented information exists (e.g. feature importance summaries) showing which domain data elements most influence outputs, for at least priority models. Data Engineer can access documented feature-importance or influence information for priority models consuming their domain's data.
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.
Domain data influence on model decisions is surfaced interactively and in real time (e.g. per-decision explanation showing which specific data points drove a specific output), without separate manual documentation. Users can interrogate a specific model decision to see exactly which domain data points drove it, in real time, within the tool itself.
INT-05
Bias identification and mitigation in domain data feeding AI models
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?
Maturity level descriptions
No assessment is made of potential bias in domain data used for AI models; bias, if present, would go undetected and unaddressed. Domain data is used in AI models with no consideration of whether it under-represents certain groups, embeds historical bias, or was collected in a skewed way.
Bias is occasionally suspected and discussed informally (e.g. "this dataset probably skews toward X"), but nothing has been formally assessed or documented. Data Engineer or data scientists have informally raised a bias concern about domain data without conducting or documenting a formal assessment.
A defined bias assessment process exists and has been applied to at least priority domain datasets used in AI models, with findings documented. Data Engineer participates in or reviews a documented bias assessment (e.g. representativeness analysis across known demographic or business segments) for priority AI-use datasets.
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.
Bias monitoring is continuous and increasingly automated, with statistical bias-detection tooling flagging emerging bias in domain data or model outputs, integrated with ongoing mitigation processes. Automated bias-detection tooling continuously monitors domain data and/or model outputs for emerging bias patterns, triggering mitigation review without waiting for a scheduled assessment.
INT-06
Model governance framework coverage for AI models consuming domain data
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?
Maturity level descriptions
No model governance framework exists, or if one exists, models consuming domain data are not known to be covered by it. Models using domain data are built and deployed with no reference to any governance framework, risk classification, or approval process.
Awareness exists that a governance framework applies "somewhere" in the organisation, but the Data Engineer cannot confirm whether models using their domain's data are actually covered. Data Engineer is aware a governance framework exists at the organisational level but cannot confirm its application to specific models using domain data.
The Data Engineer can confirm that priority AI models consuming domain data have gone through a defined governance process (risk classification, approval), with records available. Data Engineer can point to governance records (risk classification, approval documentation) for priority models consuming domain data.
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.
Model governance requirements are integrated directly into the model development and deployment pipeline, automatically requiring and verifying domain-level evidence (data quality, bias assessment, lineage) before a model can be classified as governance-compliant. The governance framework technically requires domain-level evidence to be attached and verified before a model can proceed through development or deployment stages.
INT-07
Data readiness and bias/representativeness sign-off during AI model development
During the **development** phase of an AI model using your domain's data, is there a defined Data Engineer sign-off confirming the data is sufficiently representative and free of known, unmitigated bias before model training proceeds?
Maturity level descriptions
No sign-off of any kind occurs during model development; data is used for training with no confirmation of representativeness or bias status. Model development proceeds using domain data with no checkpoint confirming representativeness or bias status before training begins.
Data Engineer input is occasionally sought informally during development, if a data scientist happens to ask, but this is not expected or consistent. Data Engineer has, at least once, been informally consulted about representativeness or bias during a model's development.
A defined sign-off step is required from the Data Engineer, confirming representativeness and known-bias status, before training proceeds for priority models. Data Engineer performs a documented sign-off confirming representativeness/bias status before training begins for priority models using domain data.
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.
Representativeness and bias checks are substantially automated (e.g. automated statistical representativeness testing against reference populations), with manual Data Engineer sign-off reserved for flagged exceptions or high-risk models. Automated checks assess representativeness and known bias indicators against domain data before training, with manual Data Engineer sign-off required only for flagged exceptions or high-risk cases.
INT-08
Validation gate before AI model implementation/deployment
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?
Maturity level descriptions
No checkpoint exists before deployment; models move into production using domain data with no validation that production data still matches training-time assumptions about representativeness or bias. A model is deployed to production with no check confirming that live domain data remains consistent with what it was trained and validated against.
A validation step is sometimes performed informally before deployment, depending on who is involved, but it is not a required or consistent step. Data Engineer or a Data Practitioner occasionally checks production data consistency informally before a model deployment, but this depends on individual initiative.
A defined validation checkpoint is required before deployment for at least priority AI models using domain data, with the check recorded. Data Engineer performs or confirms a documented validation step before a priority AI model is deployed to production using domain data.
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.
The validation gate is fully automated and technically enforced within the deployment pipeline (MLOps), making it impossible for a model to go live on domain data without passing validation, with gate performance continuously monitored. An automated gate is technically embedded in the deployment pipeline, preventing go-live without passing domain data validation, with monitoring of gate performance over time.
INT-09
Monitoring and feedback loop for domain data during AI model usage (production)
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?
Maturity level descriptions
No monitoring occurs once a model is in production usage; bias or transparency degradation linked to domain data would only be discovered by accident, if at all. Once a model is live, no one checks whether ongoing domain data changes are introducing bias or degrading explainability, and any such issue goes unreported.
Production bias or transparency issues are occasionally traced back to domain data informally, if someone happens to investigate, with no consistent process or reporting to the Data Engineer. Data Engineer has, at least once, learned informally that a production bias or transparency issue was linked to their domain's data, without a defined reporting process.
A defined process exists for monitoring production model bias/transparency and reporting suspected domain-data-related issues back to the Data Engineer, used for at least priority models. Data Engineer receives reports of suspected domain-data-related bias or transparency issues through a defined mechanism for priority models.
Domain-data-related production bias/transparency issues are logged, tracked to resolution, and used to update development sign-off (BIA-7) or deployment validation (BIA-8) criteria to prevent recurrence. Data Engineer's domain tracks confirmed domain-data-caused production issues through to remediation, with resulting updates made to development or deployment criteria.
Production model bias and transparency monitoring is continuously and automatically linked to domain data quality and representativeness monitoring, so that emerging domain-data-related degradation triggers investigation and remediation before material business or fairness impact occurs. Automated monitoring links live model bias/transparency signals to domain data quality and representativeness signals, triggering proactive investigation before a domain-data-related issue causes material business or fairness impact.