The internet was designed to move data. Not to remember where it came from, who touched it, or whether any of it is true. Data provenance, the ability to verify the origin and integrity of information, was never part of the design.
That wasn’t an oversight. It was a deliberate architectural choice made in a world where the main challenge was getting packets from one machine to another at all. As a result, validation was someone else’s problem.
For most of the web’s history, that trade-off was manageable. You could still triangulate, check sources, and look at a photo to make a reasonable call about whether it was real.
That’s over now.
Generative AI can produce photorealistic images, convincing video, and fluent text at scale and at near-zero cost. Consequently, the gap between ‘real’ and ‘fabricated’ is no longer visible to the human eye. The problem compounds further: AI models are trained on web data, which increasingly includes synthetic content, which gets ingested into the next generation of models, which produces more synthetic content. In practice, the feedback loop is already running and accelerating.
The industry is building a fix. It’s not a product and it’s not a platform. Instead, it’s a stack of protocols, cryptographic, decentralised, and semantic, designed to add a verification layer to the web that was never there to begin with. Some people are calling it the ‘truth layer.’
Here’s what it actually consists of.
The conventional approach to detecting fake media is forensic: take a suspicious file, run analysis, try to spot manipulation artefacts. The problem, however, is that this is a permanent arms race. Every improvement in detection capability is eventually matched by an improvement in generation capability.
The smarter approach is upstream. Instead of trying to detect fakes after they’re published, you secure the data at the moment it’s created. This is what the C2PA standard does.
C2PA, the Coalition for Content Provenance and Authenticity, is an open technical standard for attaching cryptographically signed metadata to media files. Specifically, when a piece of content is captured by a camera or generated by an AI system, the software signs it using public-key cryptography and embeds a manifest directly in the file.
Every subsequent edit is appended to that manifest. For example, if someone opens the file in an image editor and modifies the pixels, that action is recorded and signed. Similarly, if someone else then runs it through an AI upscaler, that action is also recorded and signed.
If a bad actor alters the content without signing the change, the cryptographic seal breaks. As a result, anyone downstream can verify that the data provenance chain is intact, or see exactly where it was broken.
It’s worth being precise about what this does and doesn’t solve. C2PA doesn’t prevent someone from generating a deepfake. Instead, it creates the technical infrastructure to verify, at any point in a file’s lifecycle, whether the content has been altered and by whom. That’s a meaningful capability for journalism, legal proceedings, insurance claims, and any context where document authenticity has consequences.
The problem was never that we lacked tools to detect fakes. Detection is reactive, and you’re always one step behind. Provenance, by contrast, is structural. It changes the question from ‘is this real?’ to ‘can this be verified?’
C2PA is not a niche research project. Adobe, Microsoft, Google, Sony, Nikon, and the BBC are among the organisations that have committed to implementing it. Moreover, camera firmware, AI generation tools, and content management systems are all in scope. The standard is live and being deployed now: C2PA specification and implementation documentation
The asset-level problem is about individual files. The network-level problem, by contrast, is about how decentralised systems, particularly smart contracts running on blockchains, can access and verify data from the real world.
Smart contracts are self-executing programs that run automatically when conditions are met. For example, they can release payment when a shipment is delivered, or trigger an insurance payout when a flight is delayed. For that to work reliably, the contract needs a tamper-proof source of real-world data.
Blockchains are closed systems by design. They achieve consensus precisely because every node has access to exactly the same data. Connecting to an external data source breaks that model. If the contract pulls from a single API, that API becomes a single point of failure and, equally, a single point of manipulation.
Decentralised oracle networks solve this by replacing a single data source with a consensus mechanism. Instead of querying one source, the network queries multiple independent nodes. Those nodes then aggregate the data, run a consensus protocol, and deliver a result that is cryptographically verifiable. This means any party can confirm the data was produced by the agreed process, not by any single actor.
As a result, financial contracts, automated legal agreements, and supply chain verification systems can now operate on data that is tamper-proof by architecture, not just by trust. Chainlink is currently the most widely deployed implementation of this model: Chainlink documentation and network data
It would be a mistake to read this section and think it only applies to blockchain applications. The underlying principle, that data derived from distributed consensus is more trustworthy than data from a single source, applies to any system where data integrity is a security property. Furthermore, multi-source verification and consensus-based truth mechanisms will migrate into mainstream infrastructure as the tooling matures. To that end, organisations designing critical data pipelines today should already be watching this space.
The first two layers address the provenance of data in transit. The third, however, addresses something more fundamental: the internal reliability of AI systems themselves.
Large language models are probabilistic. They generate outputs by predicting what text is statistically likely given the input. By design, therefore, they do not have a native mechanism for distinguishing between things that are true and things that are merely plausible. This is the root cause of hallucination: the model produces confident, fluent output that is factually wrong, because factual correctness is not what the architecture optimises for.
One approach, grounded in research by Dong et al. (2015) on Knowledge-Based Trust, is to give AI systems a structured, verifiable knowledge layer that they validate against before producing output. Instead of treating all ingested data as equally reliable, the system estimates source credibility based on the factual accuracy of its claims, cross-referenced against an established baseline.
More recent architectures take this further with structured memory graphs. Rather than treating factual knowledge as a statistical pattern in training data, these systems store it as an explicit, auditable graph of entities and relationships. Before an AI agent produces an answer, it validates its reasoning against this graph. If the claim cannot be grounded in the graph, it is therefore flagged or withheld.
This moves AI systems from ‘generate what sounds right’ toward ‘generate what can be verified.’ Consequently, the output becomes accountable in a way that purely probabilistic generation is not.
There is a related but distinct problem at the infrastructure level: how AI models connect to external data sources securely and without leaking context across sessions.
The Model Context Protocol (MCP) is an open standard that addresses this directly. It defines a standardised way for AI models to connect to local and remote data sources, with explicit controls over what data flows where and when. For organisations building AI on top of sensitive or proprietary data, this is a foundational piece of the stack.
The relevance to data provenance is direct. Given that the pipeline feeding an AI model is the first point of contamination risk, if it is not verified and controlled, the quality guarantees on any AI output are meaningless. In other words, you can have the best model in the world and still produce unreliable results if the data coming in is contaminated, stale, or manipulated.
Model Context Protocol specification
These three layers, data provenance at the asset level, consensus-based verification at the network level, and knowledge grounding at the AI level, are not independent efforts. Rather, they are complementary responses to the same underlying problem: the web has no native mechanism for truth, and the systems being built on top of it are inheriting that gap.
None of this is fully deployed at scale yet. C2PA is rolling out across hardware and software vendors. Meanwhile, decentralised oracle networks are mature in the blockchain space but early in mainstream infrastructure. AI knowledge grounding, in turn, is an active research and engineering frontier.
The direction is clear, and the build is underway.
For organisations designing data infrastructure now, particularly those building AI systems that depend on the integrity of external data, the relevant question is not whether this stack will become important. Ultimately, it’s whether your architecture will be compatible with it when it does.
The web was built to move data. The next layer is being built to verify it. The organisations that get ahead of that shift will have a structural advantage. Notably, the ones that don’t will be retrofitting trust into systems that were never designed for it.
The term ‘truth layer’ is a useful shorthand but worth treating with some scepticism. No protocol stack makes the internet ‘true.’ What these systems provide is verifiability: the ability to check data provenance, confirm consensus, and ground claims in auditable knowledge. That is a narrower and more honest capability than ‘truth,’ and it is the one actually worth building for.
The distinction matters because it sets the right expectations for what these systems can and cannot do. They are infrastructure, not epistemology. Used correctly, they give you a reliable foundation. What you build on top of it is still your problem.
If this was useful, send it to whoever in your organisation is making decisions about AI infrastructure. Not because it’s a sales pitch, it isn’t, but because the architectural choices being made right now will be expensive to undo in three years.
© Copyright 2026 | Synaptizen | All Right Reserves.
© Copyright 2026 | Synaptizen | All Right Reserves.
© Copyright 2026 | Synaptizen | All Right Reserves.
© Copyright 2026 | Synaptizen | All Right Reserves.
