Your Data Has No Papers – The Data Passport and the Data Guardian, v0.1

Data travels without its papers

Would you take a medicine that came without its package leaflet? No name of the active ingredient, no dosage, no warnings, no manufacturer. Of course not. Yet every day, organisations make decisions, train AI models and migrate systems on data that arrives exactly like that.

A dataset leaves its source and starts a second life. It is copied into a warehouse, joined with other data, sent to a partner, fed to an AI agent, migrated to a new platform. With every step it moves further away from the people who know what the data means. What travels along is the data itself, just the data. What stays behind is the knowledge that makes it usable: how it is built, what the values mean, which rules apply, what you are allowed to do with it, and where it comes from.

So the receiver starts guessing. They reverse-engineer column names, infer meanings from sample values, discover the rules by breaking them, and hope the licence allows what they are doing. The result is what the data seems to be, not what the source says it is.

This is not a niche problem. It shows up as:

• Secondary use that goes wrong because the original purpose, definitions and restrictions were never passed on
• Migrations that succeed technically while the meaning quietly stays behind in the old system
• AI that is confidently wrong, because the context it needed was never there
• Compliance risk, because nobody can show who is accountable for the data or under which conditions it may be used

Control already travels with the data in many organisations: access rights, classifications, retention. Meaning should travel too, and so should rules and declarations of the origin of the data. That is what the data passport is for.

A passport alone is not enough, though. A real passport works because two things exist: the document you carry, and the border control that checks it. Data needs both: a data passport that travels with the data, and a Data Guardian that acts on it.

Why a passport?

Think about what your own passport does. It is issued by an authority, not written by you. It says who you are, where you come from and what you are entitled to. It travels with you, wherever you go. And at every border, an officer does not need to investigate you from scratch: they read the passport, check it against you, and decide in minutes. Visas add conditions for a specific destination. Stamps build up a history of where you have been.

That combination is exactly what data lacks when it leaves its source:

• Issued by an authority — the owner of the data, not whoever happens to receive it
• Travels with the holder — the description moves along with the data, instead of staying behind in the source system
• Checked at the border — the receiver verifies instead of reverse-engineering
• Conditions per destination — what you may do with the data depends on where it goes and why
• A trail of stamps — every integration, transformation and handover leaves a record

The idea is not new outside the data world. Wherever things move between parties who do not know each other, papers travel with them:

• Logistics. A container does not cross a border on trust. The bill of lading, the packing list and customs declarations describe what is inside, who shipped it, who owns it and under which conditions it may move. Nobody opens every container to guess its contents.
• Product passports. The EU is introducing digital product passports, starting with batteries: a record of materials, origin, carbon footprint and repair information that follows the product through its life, to recycling.
• Aviation. An aircraft part without its release certificate is treated as unapproved, however good it looks. No papers, no installation.

In every one of these domains, the lesson is the same: you do not judge what something is by looking at it. You read what the accountable party declared, and you check it. Data is still the exception: we accept it without papers and spend our time guessing. It doesn’t have to stay that way, though.

The data passport: four facets, seven elements

So what would a data passport look like? A data passport is everything a receiver needs to know to use a dataset with confidence, supplied by the source and travelling with the data. It answers four questions, the four facets:

• Model — how is it built?
• Meaning — what does it represent?
• Rules — what must be true, and what may I do with it?
• Origin — where does it come from?

For practical use, the four facets break down into seven elements. Each facet has a core element with the same name; Model and Rules add further elements. Each element is named after what it lets the receiver do:

Two design choices matter here.

1. Understanding is purpose-independent. The passport describes the dataset as it is, not whether it fits your use. Fitness for a specific purpose is judged afterwards, by the receiver, using the passport.
2. The passport is functional, not technical. It says what must be known, not which format to use. A concrete passport can be built from existing standards, as long as it is readable and exchangeable.

The result: the receiver works with what the source says the data is:

• Faster, because they read instead of reverse-engineer and guess.
• Earlier, because go/no-go decisions can be made at the start.
• More correct, because meaning and rules are authoritative.
• Safer, because conditions of use and ownership are explicit.
• Scalable, because the producer maintains one authoritative description that every consumer reuses.

Example: groundwater levels

What does that look like in practice? An illustrative passport v0.1 for a fictional dataset: groundwater level measurements from a regional water authority, shared with a municipality that wants to use it for planning new housing. The last column is explained in the next section.

Without this passport, the municipality would likely have assumed the levels were in metres, or relative to ground level, and used them for decisions about individual parcels. Each of those is a plausible guess. Each is wrong. The passport turns three expensive mistakes into three minutes of reading.

Authority and evidence: who signs?

You may say: we already do much of this. That is true. The passport introduces few new elements; it brings existing ones together into one concept. What is new is what a real passport adds: accountability. Statements can be signed by an accountable owner, so they carry authority, and each statement shows the evidence behind it.

A passport is only as strong as its signature. Anyone can write a description of a dataset; a passport carries the statement of someone who is accountable for it.

That is why a passport records two separate things for every statement.

Basis — how do we know this?

• Declared — stated by people who know the data: the owner or the source team
• Observed — measured from the data itself, for example by profiling
• Assumed — inferred, for example by a tool or an AI that suggests a definition

Endorsement — who stands behind it?

• Signed — an accountable owner has reviewed it and takes responsibility for it
• Unsigned — not (yet) endorsed by anyone accountable

The two are independent. A declared definition can be unsigned while the source team is still drafting it. An observed row count can be signed by the owner as correct for this release. And a signed declaration can still be contradicted by what is observed in the data. Authority comes from the signature; evidence comes from the basis. A strong passport has both.

This distinction becomes essential with AI. AI tools are getting very good at generating metadata: proposing definitions, detecting units, suggesting classifications. That is valuable. But AI can raise the evidence; it can never supply the authority. A generated description stays assumed and unsigned until an accountable person reviews and signs it.

It also makes the most measurable part of data quality sharp: the distance between what someone declared and what the data does. If the owner declares that every customer has a valid postcode and the profile shows 4% empty, that gap is a quality issue anyone can see and measure. Consumers can add their own requirements on top, for their own purpose. But the gap between declaration and data is where every quality conversation can start, on facts instead of opinions.

So a passport can grow step by step: start with what is observed and assumed, add declarations, and collect signatures as owners take responsibility.

The Data Guardian: the police, not the judge

A passport that nobody checks is a document on a shelf. So the passport needs a counterpart: the Data Guardian, software that acts on the passport where data lands — in a warehouse, a data lake, a data-centric application, at an export or a data-sharing border, or in front of an AI agent.

Think of a trias politica:

The Guardian is not the authority. It applies what the passport says, and when something is unclear it escalates to people.

Its responses are graded, not just yes or no:

• allow
• allow with conditions
• recommend
• warn
• deny
• escalate
• record

How firm it is depends on policy and risk. The declared policy decides what happens; evidence is what triggers it. A broken quality rule may only lead to a warning, because the data is still usable for most purposes. But if the Guardian observes what looks like personal data in a dataset declared safe to share, a sensible policy holds the export until someone has looked, even though the observation is not yet certain. That keeps the Guardian helpful where it can be, and firm where it must be.

Inheritance is where the Guardian really earns its keep. When two datasets are combined, the new dataset needs a passport too. The Guardian drafts it. It carries forward the conditions of use from every source, checks whether they are compatible, and escalates conflicts it cannot resolve, because two licences can simply contradict each other. It flags meaning or unit conflicts (is “revenue” in both sets the same thing?) and records lineage. But it drafts; it never signs. Authority stays with people.

Back to the groundwater example. The municipality joins the measurements with its own parcel data. The Data Guardian drafts a passport for the combined set: it carries forward the attribution requirement and the ban on parcel-level legal decisions, checks that the municipality’s own conditions are compatible, and flags the clash between centimetres and metres before anyone builds a report on it.

Border police and street police

Just as a country has two kinds of police, the Data Guardian works in two modes, depending on where it stands.

At the border: intake and exit. When data enters a platform or leaves it — an ingestion, an export, a share with a partner, a request from an AI agent — the Guardian acts like border police. It processes the request: is there a passport, is it valid, does the intended use match the conditions? Then it decides: let it through, let it through with conditions, hold it, or refuse. This is where the Guardian is most active, because a border is the moment to stop a problem before it spreads.

Inside the country: the warehouse or lake. Once data is in, the Guardian works more like street police. It mostly observes. It watches the data against the passport — do the declared rules still hold, has the profile drifted, is a column suddenly used in a way the conditions do not allow? — and it checks actions as they happen: queries, joins, new derived datasets. Most of the time it warns, records and recommends. It only intervenes when the policy calls for it.

Both work from the same passport. The difference is not the law, but the moment and the place where it is applied.

A light Data Guardian, in advisory mode inside one warehouse or lake, can often be built with existing tooling. A Guardian that works across platforms and organisations is a longer road.

A passport with a chip: machine-readable

Modern passports have a chip. The printed page is still there for people to read, but the chip holds the same information in a form a machine can check, digitally signed by the issuing country. At an automatic border gate, the machine reads the chip, verifies the signature, compares the face, and opens the gate in seconds. Officers only step in when something does not match.

A data passport should work the same way: readable for people, and machine-readable for software. A PDF description on a SharePoint site is a printed page without a chip. Useful, but nothing can accurately act on it automatically.

How does it stay with the data? In practice, a passport can travel as a manifest file alongside an export, as a reference to a catalogue entry that the receiving platform looks up, or inside the metadata layer of modern table formats. The concept does not prescribe one mechanism. It requires that the link between data and passport is never lost.

What a machine-readable passport makes possible:

• Speed — the Data Guardian can check a routine request in seconds, instead of a person checking it in days.
• Scale — thousands of datasets and requests, without a manual review for each one. The producer maintains one authoritative description that every system and every consumer reuses.
• Generated checks — declared rules can be turned directly into data quality tests and validations, instead of being rewritten by hand in every pipeline.
• Tamper evidence — like the chip’s signature, a signed passport shows whether its statements were changed after the owner signed them.
• Context for AI — agents and models can read meaning, rules and conditions of use before they touch the data, instead of guessing from column names.
• Exchange between organisations — in data spaces and data sharing agreements, passports can be checked automatically at the border, without a meeting for every dataset.
• Change detection — when a new version of a passport arrives, software can see what changed and alert the consumers known to depend on it.
• Auditability — every check, decision and exception is recorded, which makes it much easier to show regulators and auditors how data was used.

As with a real passport, the machine does the routine work and people handle the exceptions. That is what makes the approach scale, provided the systems are connected and the rules are written in machine-readable form.

What it is not: another standard

The passport is not a new file format and does not compete with existing standards. It describes what must travel with a dataset. Existing standards can deliver much of the how:

Isn’t this just a data contract? There is real overlap, and a good data contract can implement a large part of a passport. The difference is emphasis. Contracts are usually set up around a known relationship between a producer and its consumers. The passport is built to keep context intact where nobody planned for it: future consumers, integrations, migrations and secondary use. And it puts explicit accountability, who signed what, at the centre.

In data management terms, the passport brings together what the DAMA DMBOK spreads over several knowledge areas — metadata, data quality, governance, security — into one artifact that travels with the data.

One passport, many places

So what does it take to have a data passport? Less than you might think. A data passport is a logical whole, not necessarily one file. In most organisations the parts already exist, scattered: the model in the data platform, definitions in a business glossary, quality results in a monitoring tool, lineage in a catalogue, licences in a contract register.

A first passport can simply connect those parts: one entry per dataset that points to where each element lives, with an owner who signs for the whole. This is also how you give existing data its papers after the fact. You do not have to wait for new data: link what is already known about a dataset, fill the most painful gaps, and have the owner sign.

Over time, the parts can come together into one passport document: a data file that people can read and edit through a friendly view, that software can check, and that AI can help keep up to date. But the logical passport comes first. You can start tomorrow, with the systems you already have.

Much of the work does not have to be done by hand:

That last row is the point. Machines can produce most of the passport; only people can make it a passport, by signing it.

Start small: a passport v0.1

A passport does not have to be complete to be useful. Completeness is gradual, not all-or-nothing.

A realistic first version for one dataset:

1. Origin — who owns it, which system it comes from, which version. Often known in an hour.
2. Model and Contents — largely generated from the platform and a profiling run.
3. Meaning — the ten terms that cause the most confusion, defined and signed. Not all two hundred columns.
4. Conditions of use — licence, personal data, and any purpose restrictions.
5. Rules and Quality — a handful of declared rules, with their measured outcome.

The Data Guardian can grow along with it, in three maturity levels:

Most organisations can reach Advisory with existing tooling. That alone changes the conversation: people start asking for the passport before they use the data.

An invitation

This is version 0.1. It is a starting point, not a finished standard, and it will get better with your input.

Three ways to take part:

1. Critique it. What is missing? What would not work in your organisation? Where does it overlap with what you already do?
2. Try it. Pick one dataset that is reused often or about to be migrated, and write its passport v0.1. Notice how long it takes, and how much you did not know.
3. Send me a dataset. Email me at ronald@ronaldbaan.com and I will draft its passport with you and share what we learn, with your permission.

One question to take back to your organisation: look at the data behind your next big decision. Who signed for it?

Ronald Baan — Mastering Data, ronaldbaan.com