One of the biggest problems in cloud operations is not a lack of data. It is a lack of trusted data.
Most organisations may not have cost tools; however they will more than likely have monitoring tools, asset records, dashboards, and spreadsheets. The issue is that these sources often live in isolation. Cost may come from one place, ownership from another, runtime behaviour from somewhere else, and infrastructure reality from a different system again. As a result, teams spend too much time questioning the data before they can act on it.
This is where CloudPilot’s first lens becomes critical: source of truth.
What Lens 1 means
Lens 1 asks a simple but important question:
Where is this data coming from, and should we trust it for this purpose?
In the context of CloudPilot, this starts with cost. Are costs being uploaded manually by the user? Are they being imported from a hyperscaler such as AWS? Are they coming from billing exports, optimisation APIs, or internal allocation logic? Each source has a different level of authority, freshness, and intended use.
The same principle applies across the platform. Ownership data should not be guessed from runtime signals. Drift should not be inferred from billing. Runtime utilisation should not be treated as a substitute for financial records. Each domain needs a clear source of truth.
Source of truth does not mean one module owns everything
A common misunderstanding is that a “single source of truth” means one system should contain every answer. In practice, that is rarely realistic or desirable.
In CloudPilot, a single source of truth means something different: the platform provides a unified view across multiple authoritative systems, with each module owning the truth for its own domain.
That is a much more practical and trustworthy model.
For example:
- FinOps should be the source of truth for financial interpretation, cost allocation, and optimisation decisions based on billing data.
- CMDB should be the source of truth for ownership, metadata, service relationships, and organisational context.
- Cloud Control should be the source of truth for discovered resources and drift between intended and actual infrastructure.
- Monitoring should be the runtime source of truth, showing what is happening in the environment now.
CloudPilot’s value comes from bringing these truths together in one architecture, not from pretending they are all the same type of truth.
Why this matters in CloudPilot
Without this lens, platforms become noisy and unreliable.
For example, a team may see a high-cost resource in a FinOps dashboard but have no confidence in who owns it. Or they may discover an unmanaged resource in Cloud Control but have no way to connect it back to cost. Or they may see a rightsizing opportunity based on billing alone, without runtime evidence from Monitoring to show whether the recommendation is safe.
CloudPilot addresses this by treating each module as an authority in its own area while allowing those areas to reinforce each other.
That means CloudPilot is not simply aggregating data. It is creating a model where:
- billing tells you what you are paying
- monitoring tells you how the resource is behaving
- CMDB tells you who owns it and what it supports
- Cloud Control tells you whether it is aligned to intended state
- the platform then presents these together in a way that supports action
This is what moves CloudPilot beyond dashboards and into decision support.
The FinOps question: full cost view or cloud optimisation view?
For CloudPilot, an important design question is whether FinOps is intended to represent the full cost view or whether it is currently focused on the cloud optimisation layer.
That distinction matters.
A full cost view implies broader financial truth, including billing imports, allocations, forecasting, and showback or chargeback logic. A cloud optimisation view is narrower and focuses on improvement opportunities such as rightsizing, idle resources, and usage-based waste reduction.
Both are valuable, but they are not the same thing.
CloudPilot should be clear about this because the answer affects how the platform is positioned and how the other modules connect into it. If FinOps is the broader financial lens, other modules enrich it with context. If it is currently optimisation-focused, then it is one part of a larger financial truth model still being developed.
How CloudPilot addresses the issue
CloudPilot solves the source-of-truth problem by defining boundaries between modules while still connecting them through a unified architecture.
Instead of forcing every module to generate cost data, CloudPilot allows each one to contribute the right type of truth:
- FinOps contributes financial truth and optimisation insight
- CMDB contributes ownership and service truth
- Cloud Control contributes infrastructure reality and drift truth
- Monitoring contributes runtime and utilisation truth
This creates a more trustworthy operating model. Teams no longer need to ask, “Which system should I believe?” They can understand which system is authoritative for which decision.
For example:
- If the question is, “What are we spending?” the answer should come from FinOps.
- If the question is, “Who owns this?” the answer should come from CMDB.
- If the question is, “Does this resource really exist and is it managed correctly?” the answer should come from Cloud Control.
- If the question is, “Is this resource actually being used?” the answer should come from Monitoring.
CloudPilot then ties those answers together in one place.
This is the key principle behind Lens 1 in CloudPilot
A unified architecture is more powerful than forced centralisation.
Trying to make one module own every type of truth usually leads to duplication, stale data, and low confidence. A better approach is to let each module own its domain while the platform creates a trusted, connected view across them.
That is how CloudPilot can address one of the biggest real-world problems in cloud operations: not just a lack of visibility, but a lack of confidence in what teams are seeing.
Summary
Lens 1 is ultimately about trust.
If organisations do not trust where data comes from, they will not act on recommendations, no matter how polished the interface is. CloudPilot’s approach should therefore be clear: each module has a role, each module has a domain of truth, and the platform’s job is to unify those truths into something actionable.
That is what makes a single source of truth credible in CloudPilot. Not one module doing everything, but one platform making the right truths work together.