Kindly fill up the following to try out our sandbox experience. We will get back to you at the earliest.
Metadata tagging explained: the five types of metadata tag with an example of each, who applies them and when, why automated tagging drifts, and what tags drive.
Updated on
Metadata tagging is the practice of attaching short structured labels to a data asset so that a person or a system can find it, judge it and apply a rule to it without opening it. Each label is a key and a value: owner = maria.santos, classification = PII, source_system = salesforce, retention = 7y. The asset can be a table, a column, a file, a dashboard or a cloud resource, and the same asset usually carries several tags at once.
The difference between a tag and a description is that a tag is written to be read by a machine. A description tells a person what a table is for. A tag tells a policy engine whether to mask a column, tells a retention job when to delete a row, and tells a search index which results to rank first. That is why the agreed vocabulary matters more than the wording: two teams writing PII, pii and Personally Identifiable have produced three tags and one problem.
A metadata tag has five parts, and most tagging schemes only write down the first three. There is the key, which names what is being recorded. There is the value, which records the answer. There is the asset the pair attaches to. Then there is the part that gets skipped: who or what set the tag, and when. Without those last two, nobody can answer whether a classification is current, and a classification nobody can date is a classification an auditor will not accept.
A real tagging system enforces this shape rather than trusting people to keep to it. The clearest published example is the set of rules AWS applies to resource tags. Its documented tag naming limits and requirements state that each resource may carry a maximum of 50 user created tags; that system tags beginning with the aws: prefix are reserved, do not count against that limit and cannot be edited or deleted; that each tag key must be unique on a resource and may hold only one value; that a key runs from 1 to 128 Unicode characters in UTF-8 and a value from 0 to 256; that keys and values are case sensitive; and that the generally allowed characters are letters, numbers, spaces and the set _ . : / = + - @ . Those limits were read on 6 September 2026.
The case sensitivity line is the one that catches teams out, and AWS says so plainly in the same guidance: decide once whether the key is CostCenter, Costcenter or costcenter and use that form everywhere, because to the platform they are three separate tags, and every cost report, access rule and automation built on them splits three ways.
A tag is one layer of a wider subject. If you want the parent explainer first, our article on what metadata is, its types and how it is managed covers the category, and technical metadata covers the schema level detail that tagging usually sits on top of.
Tagging began as library cataloging. A catalog card is a tag set: author, title, subject and shelf location, written in a fixed order so that any librarian could read any card. The Great Library of Alexandria is the usual starting point in this story, and the point that survives from it is not the age of the practice but its purpose, which was to make a collection searchable by someone who had not built it.
The version of that practice used online today has a documented origin. The Dublin Core workshops, which ran from 1995 and are recorded on the Dublin Core Metadata Initiative website, set out to agree a small element set that anyone describing a networked resource could use. That work is still published as DCMI Metadata Terms, a DCMI Recommendation dated 20 January 2020, and it still carries the fifteen original elements in the /elements/1.1/ namespace: contributor, coverage, creator, date, description, format, identifier, language, publisher, relation, rights, source, subject, title and type.
Naming those fifteen is the shortest honest answer to the question most teams actually have, which is what their descriptive tags should be. Start with the fifteen, keep the ones your assets genuinely have an answer for, and add only what your business needs on top. The same document also publishes vocabulary encoding schemes, which are the named controlled vocabularies a value may be drawn from, such as the Dewey Decimal Classification, Library of Congress Subject Headings and Medical Subject Headings. That is the second half of a standard, and it is the half most internal tagging schemes never write down.
The cloud era added a second lineage to the practice. Cloud platforms introduced resource tags for cost allocation, automation and access control, which is where the key and value shape and the hard character limits come from. Data platforms then pushed the same idea down to the column, which is what makes classification tagging possible at the scale a warehouse actually operates at.
Four of these types come from library cataloging and are the four the older literature names. The fifth comes from the data platform world and carries the most weight in a regulated company. Each row below gives a tag you could copy into a catalog this afternoon, and the standard the shape of it comes from.
| Type of tag | What it answers | A real example you can copy | Where the shape comes from |
|---|---|---|---|
| Descriptive | What is this, and what is it about? | subject = customer churn; creator = revenue analytics; title = Monthly churn base | The fifteen Dublin Core elements published in DCMI Metadata Terms |
| Structural | How do the parts fit together? | isPartOf = orders_2026; partition_key = order_date; page sequence in a scanned document | DCMI terms, plus the physical layout of the store the asset lives in |
| Administrative | Who runs this, what does it cost, and what may be done with it? | owner = maria.santos; CostCenter = FIN-204; Environment = prod; rights = internal only | Cloud resource tags, which is where the key and value shape and the character limits come from |
| Provenance | Where did this come from, and what has happened to it? | source_system = salesforce; ingested_by = fivetran; meta: {source_contract: v2} on a dbt model | The dbt meta config, compiled into manifest.json |
| Classification | How sensitive is this, and which rule applies to it? | classification = PII; special_category = health; retention = 7y | GDPR Articles 4(1) and 9(1), applied as a catalog policy |
Descriptive tags are what people search on, so they are the ones worth agreeing a vocabulary for first. Structural tags are what a system reads to reassemble something from its parts, and in a warehouse they are usually inherited from the schema rather than typed by hand. Administrative tags answer questions about running the asset rather than reading it, which is why finance and platform teams often care about them more than analysts do.
Provenance tags are the ones that decide whether a number can be trusted, because they record where it came from. This is also the type that is easiest to get right, since it can be written in the same change set as the model. The dbt meta config accepts key and value pairs on models, sources, seeds, snapshots, tests and individual columns, compiles them into manifest.json and surfaces them in the generated documentation, which means a provenance tag arrives as a pull request rather than as a form somebody filled in. That was read from the dbt documentation on 6 September 2026.
Classification tags are the subject of their own section below, because they are the ones with a legal consequence attached.
Metadata tags are applied at four points, and the rule to hold to is that a tag which decides anything should be set at the earliest point where the answer is already known, and changed only through the same route. A tag applied after the data has been queried for six months is documentation. A tag applied before it is published is control.
| Applied by | At what point | What it is good for | How it fails |
|---|---|---|---|
| The engineer who writes the model | In code, in the same change set as the SQL | Provenance, ownership and contract tags, which must never disagree with the model that produces the data | Nobody reviews the meta block, so it gets copied from the previous model and quietly inherits its owner |
| A rule in the platform | At ingest, when a new table or column arrives | Classification at scale, especially personal data, across thousands of columns no person will ever read | The rule matches column names rather than column content, so anything oddly named is missed |
| A named asset owner | In the catalog, when the asset is published or materially changed | Business meaning: what the table is for, which glossary term it maps to, who to ask about it | Ownership is recorded as a team rather than a person, so the field is filled once at launch and never again |
| An approver | Before the change is published | Classification changes and anything else with a legal or access consequence | The approval queue is treated as paperwork and cleared in bulk without anyone reading it |
The four are not alternatives. A working setup uses all of them, with each tag assigned to exactly one of the four so that two sources can never disagree. Which tag belongs to which point is a governance decision rather than a tagging one, and we cover the ownership model, the standard and the review workflow separately in our guide to metadata governance. The practical starting point for most teams is our four best practices for a metadata management strategy, which covers how to scope the work before any of it reaches a tool.
Classification is the one type of tag with a legal deadline attached, which is why it is worth being exact about. The consolidated text of the GDPR defines personal data in Article 4(1) as any information relating to an identified or identifiable natural person, and it names the identifiers explicitly: a name, an identification number, location data, an online identifier, or one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that person. That is wider than most tagging schemes assume. The online identifier column nobody thought of as personal data is usually the one that fails the audit.
Article 9(1) then names nine categories whose processing is prohibited unless one of the exemptions in Article 9(2) applies: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used to identify a person uniquely, health data, sex life and sexual orientation. Those nine are a ready made value list for a special category tag. Using them rather than a set invented in a workshop means your tag values line up word for word with the article a regulator will quote back at you.
Article 30(1)(c) closes the loop. It requires a controller record of processing activities to contain a description of the categories of data subjects and of the categories of personal data. Classification tags are how that description gets produced from the platform itself rather than from an annual survey that is out of date the day it is signed. All three articles were read from the EUR-Lex consolidated text on 6 September 2026.
| Classification tag value | What it means | What the tag drives |
|---|---|---|
| public | No restriction; may be shared outside the company | Nothing masked; the asset is searchable by everyone |
| internal | Company only; contains no customer or personal content | Default access; no masking; standard retention |
| confidential | Commercially sensitive; restricted by role | Role based access; export blocked or logged |
| PII | Personal data as defined in GDPR Article 4(1) | Masking for roles without a business reason to read it; inclusion in the Article 30 record; a list to work from when a deletion request arrives |
| special category | One of the nine categories named in GDPR Article 9(1) | Processing blocked unless an Article 9(2) exemption is recorded against the asset |
In practice a company runs the automatic and the manual route side by side. Decube data governance software classifies sensitive data and personal data automatically against predefined or custom policies, and lets a named owner categorize an asset by hand in the catalog when a rule cannot see what a column really holds. Every change to a policy passes through an approval workflow, which is what makes the classification defensible rather than merely present. The short video below shows what a classification policy looks like when it is set up that way.
Classification is also where tagging meets access. A classification tag is only worth setting if something enforces it, which in most stacks means masking policies and role based grants reading the tag rather than a person maintaining a grant list by hand. Our article on best practices for improving data security in your systems covers the controls that sit on the other side of that tag.
Automated tagging is the only way to tag a warehouse of any real size, and it is also the reason most catalogs contain classifications nobody trusts. The drift is predictable. There are five causes, and each has a control that holds it.
| Why the tag goes wrong | What it looks like in practice | The control that holds it |
|---|---|---|
| The rule matches the name, not the content | A rule that tags any column named user_id as personal data misses ref_9, which holds an email address | Sample the values as well as the name, and make the owner confirm any classification the rule scored as uncertain |
| New columns arrive after the rule last ran | The table was classified at onboarding and has gained six columns since, none of them classified | Rerun classification on schema change rather than on a schedule, so a new column is classified before anyone queries it |
| Tag values are free text | PII, pii and Personally Identifiable all exist in the catalog, and a policy written against one of them silently exempts the other two | A controlled vocabulary with a fixed value list, in the pattern DCMI publishes as vocabulary encoding schemes |
| Keys are case sensitive and nobody agreed the case | CostCenter, Costcenter and costcenter are three separate tags, and the cost report built on them splits three ways | Decide the capitalization once and apply it everywhere, which is the advice AWS gives in its own tagging guidance |
| Nobody owns the policy | A classification exists, is wrong, and no named person is accountable for correcting it | One named owner per classification policy, with an approval step and an audit trail on every change to it |
The first row is the one worth spending money on, because name matching is where most automated tagging quietly fails. Reading the values rather than the column name is profiling, and our four best practices for building a data profile covers how to do it without scanning everything you own every night.
There is a two minute test for whether your tagging has drifted. Pick a table that was classified six months ago and check whether its column list has changed since. If the columns have changed and the classification has not, the tagging is decorative. Decube classification policies apply to new columns as they arrive when they match the policy pattern, and every change to a policy passes an approval workflow, which is the pair of controls that keeps the second and fifth rows of that table honest.
A tag is worth maintaining only if something reads it. Five things read tags in a working data platform, and each one fails in a recognizable way when the tag is missing. If none of these five is true of your setup, the tagging project is a labeling project and it will be abandoned within a year.
| What reads the tag | The tag it reads | What it does with it | What happens when the tag is missing |
|---|---|---|---|
| Classification and audit reporting | classification, special_category | Produces the list of assets holding personal data and the evidence behind the GDPR Article 30 record | The record is assembled by survey once a year and is out of date on the day it is signed |
| Access policy | classification, owner | Masks or blocks columns for roles that have no business reason to read them | Access is granted at the table level, so a role that needs one column is handed all of them |
| Retention | retention, source_system | Deletes or archives records once they reach the stated age | Nothing is deleted, storage grows, and a deletion request has no list to work from |
| Discovery and search | descriptive tags, glossary term, owner | Ranks and filters results so a person finds the right table rather than the first one | People ask a colleague instead, and the answer depends on who they happened to ask |
| Lineage filtering | classification, domain, source_system | Narrows a lineage graph to the assets that matter, for example every downstream report fed by a column marked as personal data | The graph is complete and unreadable, so an impact question takes a day instead of a minute |
The last row is the one people underrate. A classification tag on its own says a column holds personal data. Column level lineage on its own says where that column ends up. Put together they answer a question neither answers alone, which is which dashboards would expose personal data if this one column were classified wrongly. Our explainer on data lineage tracking covers how that graph is built.
Discovery is the benefit most teams notice first, because it is the one they feel every day. Tags cut retrieval time by turning a browse into a filter, and organizations that label their assets consistently spend less of the working week looking for the right table. That is also the argument for putting tags where people already work rather than in a spreadsheet beside the platform, which is what a data catalog and metadata management platform is for.
These three terms get used as synonyms and they describe different work. The distinction is worth holding because buying the middle one does not give you the other two, which is the most common way a tagging program stalls in its second quarter.
| Question | Metadata tagging | Metadata management | Metadata governance |
|---|---|---|---|
| What it is | The act of attaching a labeled value to an asset | The machinery that collects, stores and serves metadata | The rules deciding which labels are required and who may set them |
| What it produces | Tags on tables, columns, files and cloud resources | A metadata store, a model, an API and a catalog interface | A standard, a required field list, an ownership register and a review workflow |
| Who does it | Engineers in code, rules at ingest, owners in the catalog | Platform engineering | A governance lead, with one named owner per asset |
| How you know it works | Required tags are present on the assets people actually query, and still present after the next schema change | Metadata arrives without anyone typing it | A change that breaks a required tag does not reach production |
| How it fails | Tags exist and disagree with each other | Metadata is collected accurately and nothing reads it | The standard exists on paper and no build enforces it |
Each of the three has its own article on this blog rather than a paragraph here. Metadata governance covers the policies, the owners and the review workflow. What metadata is and how it is managed covers the category. And if the question underneath yours is really about tooling, how a data catalog relates to metadata management answers that one directly.
Tagging programs fail on scope more often than on tooling. The order below is the one that survives contact with a real warehouse, and every step is finishable in a week.
Metadata tagging is worth the effort exactly when something downstream reads the tag, and worth very little when nothing does. If you want to see what it looks like when classification, ownership, approval and column level lineage all read the same tags, you can request a demo and bring one messy schema of your own to it.
Metadata tagging is the practice of attaching short structured labels to a data asset so that a person or a system can find it, judge it and apply a rule to it without opening it. Each label is a key and a value, such as owner = maria.santos or classification = PII, and it attaches to a table, a column, a file, a dashboard or a cloud resource. The point of a tag, as opposed to a written description, is that a machine reads it: a masking policy, a retention job, a search index or a lineage filter.
A tag has five parts: the key, which names what is being recorded; the value, which records the answer; the asset it attaches to; whoever or whatever set it; and when it was set. The last two are the ones usually missing, and without them nobody can say whether a classification is current. Systems read the key and value pair and act on it, which is why values have to come from an agreed list. PII, pii and Personally Identifiable are three tags to a policy engine, not one.
A table of customer orders might carry owner = maria.santos, domain = revenue, source_system = salesforce, classification = internal and retention = 7y, while the email column inside it carries classification = PII on its own. On a cloud resource the same idea looks like CostCenter = FIN-204 and Environment = prod. On a document it looks like the Dublin Core elements: creator, subject, date, rights.
Because tagging is the layer that turns a pile of data into something a rule can act on. Without tags, access is granted per table rather than per column, nothing is ever deleted on schedule, a personal data inventory has to be assembled by survey, and finding the right table depends on asking the right colleague. With tags that something actually reads, all four of those become queries.
It shortens retrieval from a browse to a filter, which is the benefit teams feel every day, and it makes four other things possible: classification and audit evidence, access policy enforced at the column rather than the table, retention that runs on its own, and lineage you can narrow to what matters. The test of whether your labeling is effective is not how many assets are tagged, it is whether any policy, query or report reads the tags.
Cloud cost allocation is the clearest one, because it is fully documented in public. AWS lets each resource carry up to 50 user created tags, with keys of 1 to 128 Unicode characters and values of up to 256, and companies use keys such as CostCenter, Environment and Project to split a single bill across teams. The documented trap is that keys and values are case sensitive, so CostCenter and costcenter are two separate tags and two separate lines in the report. The equivalent inside a data platform is a classification policy that tags any column matching a pattern as personal data, so a masking rule can act on it without anyone maintaining a list by hand.
It removes the two costs nobody budgets for: time spent looking for the right dataset, and the risk carried by data whose sensitivity nobody has recorded. A company with current classification tags can answer a regulator, run a deletion request and grant column level access from the catalog rather than from a meeting. One without them does all three by hand, slowly, and finds out what it holds during the audit.
A metadata tag is a single key and value pair attached to a data asset, such as classification = PII or owner = maria.santos. The key names the question being answered and the value answers it. A tag differs from a description in being written for a machine to read, which is why the value should come from a fixed list rather than being typed freely.
Five. Descriptive tags say what an asset is and what it is about. Structural tags say how its parts fit together. Administrative tags say who runs it, what it costs and what may be done with it. Provenance tags say where it came from and what happened to it on the way. Classification tags say how sensitive it is and which rule applies. The first four come from library cataloging; the fifth comes from the data platform world and is the one with a legal consequence attached.
Not usually, and the confusion costs people time. Meta tagging most often means the HTML meta tags on a web page: the title tag, the meta description, meta robots and the canonical tag, all of which exist to tell a search engine how to treat a page. Metadata tagging in a data context means labeling a table, a column, a file or a cloud resource so that a catalog, a masking policy or a retention job can act on it. The mechanics rhyme, the audiences do not. This article is about the second one.
Four parties, at four different points. The engineer who writes the model applies provenance, ownership and contract tags in code, in the same change set as the SQL. A platform rule applies classification tags when a new table or column arrives. A named asset owner applies business meaning in the catalog when the asset is published or materially changed. An approver signs off anything with a legal or access consequence before it goes live. Each tag should belong to exactly one of the four, so two sources can never disagree.
Five reasons. Rules match column names rather than column content, so an oddly named column holding an email address is missed. New columns arrive after the rule last ran. Tag values are free text, so PII, pii and Personally Identifiable coexist and a policy written against one exempts the others. Keys are case sensitive and nobody agreed the capitalization. And no named person owns the policy, so a wrong classification stays wrong. The controls are value sampling, reclassification triggered by schema change, a controlled vocabulary, one agreed capitalization, and one named owner per policy with an approval trail.
A PII tag marks an asset as holding personal data as GDPR Article 4(1) defines it, meaning any information relating to an identified or identifiable natural person, including a name, an identification number, location data or an online identifier. It usually drives three things: masking for roles with no business reason to read the column, inclusion in the Article 30 record of processing activities, and a list to work from when a deletion request arrives. A separate special category tag marks the narrower set of nine categories named in Article 9(1), whose processing is prohibited unless an Article 9(2) exemption applies.
First step to AI Readiness
Table of Contents
Sneak peek from the data world.
Bring lineage, quality, governance, and AI together in one platform—so your teams and AI agents can act with confidence.
_For%20light%20backgrounds.svg)
.svg){kind=small}
.webp)