These lags matter in normal circumstances. During periods of heightened volatility or geopolitical shocks they can render traditional forecasting methods unreliable. 

The stopgap: nowcasting and its limits

To bridge the gap between when data is collected and when it is published, institutions including the Bank of England use a technique called nowcasting: producing early estimates of certain data, such as GDP growth, before official data become available, by drawing on high-frequency indicators such as survey data, card payments and real-time economic activity indices.  The Bank of England's Monetary Policy Committee uses models informed by statistical analysis but ultimately relying on judgement that reflects all available information.  Models based on survey information tend to be more accurate early in a quarter, while high-frequency output data from the ONS become more useful later. 

However, nowcasting carries reallimitations in government contexts. Three are worth naming:

Transitory volatility. An unexpected event, such as a strike, a major climate incident or a geopolitical shock, generates a spike in data that a nowcast can misread as a shift in trend rather than a one-off event.  Bank of England research on flexible modelling approaches shows that signals shift between indicator types across the release cycle, and models must account for this to avoid misleading early readings. 

Structural breaks. Critical events such as the COVID-19 pandemic caused lasting changes to consumer behaviour that were hard to identify and incorporate into models. The Bank of England noted that during the pandemic, models performed better by shifting towards indicators for the service and housing sectors that captured the disruptions from lockdowns.  The challenge was that pre-pandemic patterns no longer reflected post-pandemic realities.

Representativity bias. The data used for nowcasting can systematically exclude certain groups. The ONS's Labour Force Survey (LFS) provides a clear example. In October 2023, low response rates raised concerns over the representativeness of the survey sample, and ONS temporarily suspended production of LFS-based estimates. The LFS response rate fell to 14.6% in April to June 2023, against 47.9%i n April to June 2013, increasing volatility and uncertainty across estimates,particularly for geographic breakdowns such as Wales and Scotland and for certain age groups. The Office for Statistics Regulation (OSR) concluded that the LFS statistics should continue to be labelled "official statistics in development" given these challenges. ONS is developing a Transformed Labour Force Survey (TLFS) using a digital collection approach, with some options for completing the transition potentially taking until 2027 to finalise. 

These examples are not outliers.They reflect a structural problem affecting government organisations that relyon multiple data sources which are neither as reliable nor as timely as thedecisions they are meant to inform.

The underlying issue: a legacy data architecture problem

The root cause in most cases is not bad data collection but poor data architecture. Government organisations frequently hold data that is siloed within departmental systems, inconsistently documented and lacking sufficient metadata, making it difficult to repurpose. The Central Digital and Data Office (CDDO) has acknowledged that government does not have a consistent framework around data ownership, and that this lack of shared understanding of roles, accountabilities and responsibilities prevents effective cross-government data sharing. 

The government's own diagnosis,set out in the Transforming for a Digital Future: 2022 to 2025 Roadmap for Digital and Data, identifies that data quality is inconsistent and frequently poor, and that effective data sharing between departments is limited. The 2021 Spending Review committed £8 billion to digital, data and technology transformation by 2025, in part to address costly and outdated legacy systems. 

What is a data mesh, and why does it need governance?

One response to this problem,which has gained significant traction in both the public and private sectors,is the data mesh. The term was defined by Zhamak Dehghani in 2019 while she was working as a principal consultant at Thought works. Data mesh is asociotechnical approach to building a decentralised data architecture, shifting responsibility for analytical data from a central data team to the domain teams that know the data best, supported by a platform team that provides a domain-agnostic shared infrastructure. It is founded on four core principles: domain ownership, data as a product, self-serve data platform, and federated computational governance. 

The appeal in a government context is clear. Rather than requiring a central IT team to own and maintain all data, each department or domain holds accountability for its own data, making it available to others as a trusted, documented product. The CDDO's data ownership model for government formalises exactly this kind of structure, defining three roles: Data Owner (a senior individual responsible for a logical grouping of data, with in-depth knowledge of the business strategy in that area), Data Steward (responsible for day-to-day operational activities), and Data Custodian (responsible for capturing, storing and disposing of data).  The model applies to all central government departments and arm's length bodies. 

However, it is vital to note that adopting a full, decentralised data mesh architecture is not mandatory to achieve modern data capabilities. Organisations do not need to take on the organisational complexity of a mesh architecture to implement and benefit from the core concepts of data products and data contracts.

The risk, whether within a data mesh or a more centralised framework, is that without strong shared standards, a data mesh can replicate the siloing problem it was designed to solve. Different departments applying different methodologies to the same source data can produce conflicting outputs, undermining the trust that data-driven decisions require.

The answer to this risk is the data contract, the foundation of a data product-based approach.

Data products and data contracts: the foundation of trust

A data product is are usable, self-contained package that combines data, metadata, semantics and templates to support diverse business use cases. A data contract isa formal agreement between a data producer and data consumers that defines the quality, structure, semantics and availability of that data. Unlike a legal contract written in plain language, a data contract is written in code, typically YAML or JSON, making it enforceable through automation rather than manual processes. 

Data contracts are the governance mechanism that prevents a data mesh from fragmenting into chaos. Key elements of a data contract include schema definitions, data quality rules, service level agreements (SLAs) specifying when data will be available and how long it will be retained, role-based access definitions, and infrastructure and server information to make the data discoverable. 

In a government context, this directly addresses the structural problem: when does the data arrive, in what form, and who is accountable if it does not meet the agreed standard?

A data contract defines exactly this, creating an auditable, version-controlled specification that bothproducers and consumers can rely on.

The CDDO's guidance on making essential shared data assets (ESDAs) available across government requires that each ESDA is assessed against the government data quality framework, aligned with a minimum metadata specification, and published via an API meeting government standards. Essential shared data assets are defined as data sets critical to cross-government service delivery, legislative compliance, policy formulation or national statistics. This is, functionally, the same discipline that data contracts enforce: documented, quality-assured,access-controlled data with a named owner.

Towards a data-driven organisation: Aker's approach

This is the context in which Aker Systems works as a trusted partner for the UK Government. Our core expertise lies in designing and implementing data infrastructures for highly sensitive environments, including Critical National Infrastructure and national security frameworks, where data integrity and availability are paramount. The goal is not to replace existing data sources but to transition organisations from a legacy model of batch-based, informally governed data into a data product-oriented architecture that delivers measurable benefits: increased trust in data, reduced time to publish new datasets, the removal of data redundancies and silos and the foundation for an AI-ready data platform.

The UK government's own guidelines on making government datasets ready for AI, published in January2026 by the Government Digital Service and the Department for Science, Innovation and Technology, state that the effectiveness, safety and legitimacy of AI adoption are fundamentally constrained by the quality, structure and governance of underlying data. AI-ready data is defined as accurate,complete, consistent, secure and enriched with metadata so it can be trusted and understood by both humans and machines. Datasets should be managed as strategic data products requiring ongoing oversight. 

Organisations that do not have this foundation in place before they attempt AI implementation face a well-documented failure mode: as the National Audit Office has highlighted,providing raw data or basic APIs without information on data quality or provenance can lead to misunderstanding and misuse, particularly in AI capabilities that learn at scale without contextual awareness. 

Aker's delivery model is structured around four concrete stages

Define a self-service platform. The central IT team stops being a data bottleneck and becomes a provider of infrastructure that lets domain teams publish, transform and govern their data without needing deep infrastructure expertise. This directly addresses the pattern the CDDO roadmap identified: siloed development in individual departments leading to varying levels of digital maturity. 

Write and enforce data contracts. Each data product is governed by a contract specifying schema, semantics, service levels (freshness, completeness, update frequency and latency windows), lineage, access controls and change-manage mentrules.  Version control means that schema changes are introduced in a way that gives downstream consumers time to adapt, preventing the pipeline failures that affect more than half of data engineers at least monthly. For government organisations, this is the mechanism that prevents two departments from producing conflicting figures from the same source data, which has been at the heart of the LFS and GDP measurement challenges.

Deploy the data platform. Whether cloud-based or on-premises, the platform delivers two critical capabilities:technical abstraction, so domain owners can publish data without running their own infrastructure; and a data catalogue and access portal, where consumers can find, understand and access the data they need without requiring specialist knowledge of the infrastructure behind it. This mirrors the government'sown Data Marketplace ambition, which the CDDO committed to as part of Mission Three of the 2022 to 2025 roadmap: creating a cross-government catalogue and marketplace to make it easier for civil servants to find and access the data they need for delivery and decision-making. 

Aker's products CEP (Cloud Enablement Platform) and DEP (the Data Enablement Platform) provide the technology layer that underpins these capabilities, ensuring an operational resilience architecture capable of protecting mission-critical public services.

Operate and improve continuously. A data product is never finished. Source data changes,consumer requirements evolve, and methodologies are updated. Owners of data products must monitor that SLAs are met, gather feedback from consumers and implement improvements, and ensure scalability and interoperability as new domains are added. The government AI-readiness guidance recommends assigning data stewardship and defining ownership roles as part of the AI-readiness lifecycle, and using standard metadata and quality monitoring as data moves from raw ingestion through enrichment to curated release. Aker builds these monitoring and feedback loops into delivery from the outset, not as are trofit.
‍
‍

Connecting data modernisation to AI readiness

An important objective of data ownership in government is the shift from treating data as an asset to treating it as a product, which requires that government defines and proactively measures how and where data is used and adds value.  This is also the precondition for AI. The government's AI-readiness framework specifies that fora dataset to be considered AI-ready, it must meet four pillars: technical optimisation (structured and formatted for efficient use by machine learning systems), overall quality and adherence to standards (accurate, complete, consistent), legal and regulatory compliance, and responsible management throughout the data lifecycle. 

A data-product oriented architecture, governed by data contracts and served through a self-service platform, directly maps to these four pillars.

It also directly aligns with the UK government's AI Opportunities Action Plan, which states that the realisation of AI-driven public value depends not only on computational capability but on the availability of accessible, consistent, high-quality and trustworthy datasets. 

‍