Trusted Data Framework

Purpose

How do organisations make complex change measurable, trustworthy and actionable?

Most organisations do not have a shortage of data. The harder problem is knowing what that data represents, where it came from, whether it can be trusted, and whether it is good enough for the decision at hand.

The Trusted Data Framework makes those connections visible. It traces a practical route from the real world through data and meaning to decisions and outcomes. This helps teams see where trust is breaking down and choose a focused next step that is small enough to test.

The approach is useful wherever data supports important change: a regulated platform, a migration, an analytics product, an AI system, an operational environment or a digital twin. The aim is not another framework deck. It is a clearer view of the problem, the decision it affects and what needs to happen next.

Three questions sit at the heart of the approach: What is real? How do we know what to trust? How can local evidence contribute to larger change?

Why Trusted Data

These questions have followed me through very different kinds of work. The Trusted Data Framework is my current way of bringing them together; it was not the name of the earlier research or delivery work from which they emerged.

Evidence and assurance — how do we know?

Trust starts with a simple question: how do we know?

Where did this number come from? Was the right method used? What was checked independently? What remains uncertain?

I first encountered these questions through carbon monitoring, reporting and verification. The domain has changed, but the discipline remains relevant in data quality, migration, analytics and AI: important decisions need evidence that can be traced, checked and challenged.

This continuity does not mean that earlier carbon work was AI governance. It means that the habit of asking for reliable evidence still matters.

Transformation at scale — how does local evidence support system-level change?

Large-scale change is usually the result of many smaller changes working in the same direction.

Earlier in my career, energy-efficiency programmes made this very tangible. A single intervention might be small, but thousands of measurable interventions can add up to a significant outcome.

The same principle appears in enterprise transformation. Strategy matters, but progress happens through individual systems, data domains, controls, teams and decisions. Each change needs to make sense locally and connect back to the larger goal.

That is what think globally, act locally means to me in practice.

Representation and context — how do digital records remain connected to reality?

Data is always a representation of something else: a customer, an asset, an event, a place or a point in time.

For example, two systems may both appear to hold the “same” customer. A field-by-field comparison can show whether the records match. Identity and provenance help answer the harder questions: are these really the same customer, and which source should we rely on?

This connection between digital records and reality is central to spatial-temporal research, enterprise data and digital twins. It also matters whenever different systems describe the same real-world thing in different ways.

Together, these ideas connect assurance, transformation at scale, and representation and context without pretending that they began as one named methodology.

Data-to-Decision Pathway

The Data-to-Decision Pathway helps locate where trust is breaking down. It does not suggest that change happens in a simple straight line.

Each layer asks a practical question:

1. Reality: what exists or has happened?
2. Representation: how do we record it?
3. Identity: are different systems referring to the same thing?
4. Raw Data: what have we observed or measured?
5. Curated Data: what is reliable enough to reuse?
6. Semantic Layer: what does the data mean in business or operational context?
7. Knowledge: which relationships, rules and context matter?
8. Intelligence: what can reasonably be inferred?
9. Decision: what action or judgement should be taken?
10. Business Outcome: did the action create the intended change?

A migration may fail at Identity because two systems disagree about who a customer is. An AI assistant may fail at Knowledge because it has found relevant documents but cannot tell which one reflects the current system. Finding the weak point before choosing a technology can prevent a much larger and more expensive mistake.

Business Outcome is not the end. An action changes the operating reality, and that change becomes new evidence. Trust works as a feedback loop:

Reality → Evidence → Decision → Change → New Reality

Keeping trust working

Three practical disciplines support every part of the pathway. They are a simple way to organise the work, not extra layers in the model.

Govern

Decide who owns what, who can approve change, what evidence is needed and what happens when something falls outside the rules.

Good governance makes decision rights and responsibilities clear. It also gives teams a workable way to handle exceptions, escalation and change.

Assure

Check whether the evidence is good enough for the intended use. Test assumptions, reconcile differences and make unresolved uncertainty visible.

Assurance means having enough evidence to rely on something — and being clear when you do not.

Observe

Keep watching. Data changes, systems drift and controls fail. Teams need to see when information becomes stale, quality drops, lineage breaks or an outcome moves away from what was intended.

Trust needs ongoing signals, not a one-off approval.

Some controls can be made executable or observable through data contracts, quality rules, lineage and provenance requirements, access policies, AI usage controls or release gates. Governance as code is one useful implementation pattern; it is not the whole meaning of governance.

From Data to Trusted Context

Consider an AI assistant that finds five documents about the same system. One is old, one describes the intended design, one reflects what is actually deployed, and two disagree. Retrieval alone cannot tell the assistant which document should answer the current question.

That is why AI-ready data increasingly means AI-ready context. The system needs to know which source matters for this question, how current it is, where it came from and where genuine disagreement remains.

A well-prepared data foundation connects records to their identity, meaning, quality, lineage, provenance and authority. Analytics, applications and AI systems can then reuse that context instead of reconstructing it differently each time.

Semantics helps not because the model suddenly becomes smarter, but because ambiguity is reduced before reasoning begins.

Spatial-temporal context is especially useful when location, assets, infrastructure or events matter. It can connect records across systems and keep digital representations grounded in the reality they describe. This is a distinctive lens within the Framework, not a requirement for every data problem.

How the Framework Is Used

The work normally begins with a real decision or delivery problem, not with a demand to implement every part of the Framework.

1. Find where trust is breaking down.
2. Clarify the decision, user and outcome that matter.
3. Understand what evidence is available and what is still uncertain.
4. Choose a practical next step that is small enough to test.
5. Agree what success and failure would look like.
6. Make ownership, controls and exceptions clear.
7. Watch whether the change continues to work as expected.
8. Scale only when the results support wider reuse.

The next step might be a readiness assessment, a focused quality or migration intervention, a semantic alignment workshop, or a small observability pattern.

The point is not to deploy the whole Framework. It is to use enough structure to make the next important decision safer and clearer.

What Comes Next

A useful next step should match the decision, the available evidence and the cost of being wrong.

• Explore consulting assets: choose a focused assessment, pattern or delivery accelerator.
• Review the delivery model: see how assessment, design, governance, operation, improvement and scale become client work.
• Learn about Steven's perspective: understand why assurance, transformation and reality-grounded data come together in this approach.