Use case

Governed Datasets

Every dataset gets a name tag — who owns it, who may read it, how fresh it must be, how long it's kept — and the system enforces the tag, not a policy PDF.

The short version

Picture a library where every book has a card: who takes care of it, who's allowed to borrow it, and when it goes back on the shelf. A governed dataset is that card for your data — and the doors actually check it. An AI agent that isn't on the card simply can't open the drawer.

How it flows
Dataset gets its cardRules written as codeCatalog guards every queryAgents inherit the rulesAudit is one query

The problem, in plain words

You're about to plug an AI agent into the customer database, and someone asks the reasonable question: 'wait — can it see salaries? The old records we were supposed to delete? The table with the credit card notes?' Nobody is quite sure. The access rules live in a policy document from two years ago, the actual database permissions were copied from whoever was hired before you, and the two have quietly drifted apart. So the project stalls — or worse, it doesn't, and the agent reads something it never should have seen.

What we set up

We attach the rules to the data itself. Each dataset declares, in code: who owns it, how sensitive it is (internal, confidential, or regulated), which roles may read it, how fresh it must be, and how long it's kept before deletion. A data catalog (Unity Catalog, Polaris, Lake Formation, or DataHub — a card index for your data that also guards the doors) enforces those rules the moment anyone or anything runs a query. AI retrieval goes through the same doors: an agent inherits exactly the permissions of the person it works for, nothing more.

How it works, step by step

  1. Give every dataset an owner

    A named person or team, not 'the data team'. When something is wrong with this table, this is who gets the message.

  2. Label its sensitivity

    Internal, confidential, or regulated. The label decides how careful every downstream reader has to be.

  3. Declare who may read it

    Access is granted to roles (job functions), not to individuals — so a job change doesn't turn into permissions archaeology.

  4. Set freshness and retention

    How out-of-date is too out-of-date, and when old records must be deleted. Both written down, both checkable.

  5. Let the catalog enforce it

    Every query — from a person, a dashboard, or an AI agent — passes through the catalog, which applies the rules at that moment. No side doors.

  6. Keep a list of who depends on it

    Downstream consumers are registered, so changing or retiring a dataset starts with knowing who it affects.

What changes for you

Before: answering 'who can see this data?' means a chat thread, three guesses, and a nervous shrug. After: it's a query against the catalog, answered in seconds, and the answer is enforced — not aspirational. Bringing a new agent or analyst on board becomes a role assignment instead of copying the last person's permissions and hoping. What it won't do: it won't decide the rules for you. Who should see what is still a human call — the system just makes sure the call, once made, is actually followed.