A scan captures structure. It can't know what a table is for, that data flows from Stripe into your users table, or what your team means by "MRR". You add that context — as descriptions, asserted lineage and a glossary — and share it as one committable file. Everything on this page lives beside the catalog, so it survives every re-scan.
regixo watch re-derives the map from your sources, then layers your
context back on top — so a re-scan refreshes the schema without ever clobbering the work you added.Descriptions are drafted locally and deterministically — composed from metadata only
(humanised names, the personal-data kinds present, lineage neighbours). No row values are read, and
nothing is sent to a cloud model. A draft is always marked suggested so it's
never mistaken for a confirmed fact.
There is one job here — get everything described — and the quickest route runs in two steps: Regixo drafts every description in one command, then your agent rewrites the ones that matter in your own words. These are not two competing ways to do the same thing; step 2 improves what step 1 wrote. The order is load-bearing — step 1 overwrites anything step 2 produced, so run it first (the warning below says why). You can skip step 1 and let your agent write all of them, but it will spend a call per description where one command already wrote them all.
One run drafts a description for every dataset and every column you have mapped — you never go one at a time. This is Regixo's own draft: composed from the metadata already in your catalog, deterministic, and it calls no model. It needs no agent, and it is the fastest way to get from nothing to complete coverage.
“Have Regixo draft descriptions for every dataset and column in my catalog from the scan — no model, just the metadata.”
$ regixo describe draft --allDrafted 24 suggested description(s). Review: regixo describe list
The count is descriptions, not datasets — one dataset with four columns is five of them. Each
lands suggested, and stays that way until a person confirms it.
kept 1 human/confirmed). Everything else it rewrites, with no flag and no prompt: its own
earlier draft, and any description your AI agent suggested — those are
suggested/model, not human. So sweep first, improve after; and
regixo describe confirm the ones worth keeping before you ever sweep again.A draft is a restatement of metadata: it can say a table looks like it holds email addresses,
and that it feeds orders. It cannot say why the table exists — no scanner can. That
is what step 2 is for.
Step 1 leaves you complete but generic: "The iban column (text) — financial (card/IBAN), flagged by its field name." True, and nobody's idea of a description. Your coding agent works from the same names and types, but writes plain English — so hand it the catalog it just filled:
“Draft descriptions for my datasets in Regixo. Mark them as your suggestions — I’ll confirm them.”
No single command does this. Your agent reads the schema, writes each line itself, and runs regixo describe set <id> "…" --model once per dataset. Each lands suggested · AI-drafted — visibly not a human's, and never confirmed. Confirming is a separate command, and the playbook tells your agent not to run it: that act is yours.
Give it the playbook first — regixo describe --skill prints it. It holds the agent to
names and types (it must never read your data to describe it), and it forbids
describe confirm: an agent may propose a description, never sign one off.
To fill a single gap. Re-drafting the same dataset yields the same text — the generator is deterministic — so to improve a thin one, write it yourself or ask your agent:
“Draft a description for the dataset app-db/public/orders in Regixo — mark it as your suggestion.”
$ regixo describe draft app-db/public/ordersA description composed from metadata only — humanised names, the personal-data kinds
present, lineage neighbours. No row values are read, and nothing is sent to a cloud model.
It lands marked suggested.
Check it worked — then do your half: read it on the Map. It says suggested, and it will keep saying that until you confirm it. Confirming is a person's act, so it carries no sentence and your agent will not run it.
Drafted 5 suggested description(s). Review: regixo describe list
Prefer your own words? Write one directly (it's saved as suggested, sourced to a
human), then confirm it when you're happy — a confirmation is your sign-off:
$ regixo describe set app-db/public/orders "Completed and pending customer orders; one row per order." $ regixo describe confirm app-db/public/orders
This one’s yours. Confirming is your sign-off, not your agent’s.
Set REGIXO_SIGNER_EMAIL first and the confirmation carries your name. Without
it, Regixo records that a human confirmed — but not which one.
List datasets with their current description, status and source. Each row also shows a
#N shortcut you can use in place of the full id:
“Show me the descriptions in my Regixo catalog, and which datasets still have none.”
$ regixo describe listEvery dataset with its current description, its status and where it came from.
Check it worked: the status column is the whole point. suggested is a
proposal; confirmed means a person signed off. Your agent's work is never
confirmed — if it claims otherwise, look again.
Datasets — draft a description with `regixo describe draft <id>` (or the #N shown here):
#1 app-db/public/orders
confirmed/human: Completed and pending customer orders; one row per order.
#2 app-db/public/users
suggested/heuristic: Users. Holds email, name, IP address. Feeds Billing & payments.
#3 app-db/public/logs
(no description yet)The full set is list · draft · set · confirm · clear. When several sources describe a
dataset, Regixo shows the most trustworthy: confirmed human > suggested human > dbt doc
> suggested heuristic > none. A re-draft never overwrites a human or confirmed description
unless you pass --force; --all drafts every dataset at once.
All of it lands on the Map, and the Map tells you where the gaps are: the rail's Undescribed filter carries a live count (16, here), and every dataset with no description wears an ✎ undescribed tag in its source fold.
Open one of them and its Description box sits under the columns table. It says what it knows, and what it doesn't:
bigquery / regixo_test / customers, before anyone has written oneNot described yet — say what this dataset is for, in one line, so your team and any agent reading the catalog know what it is.
A description you type is yours. A drafted one is built from the table and column names on this machine — nothing leaves it.
“Draft a description for the dataset “bigquery/regixo_test/customers” in Regixo — mark it as your suggestion.”
On a dataset, the same actions are the Description box: type one and press Save, or press Draft one for me to have Regixo compose it from the metadata. Once there is a description the buttons change with its state — Re-draft from metadata and Confirm while it is still only a suggestion, Clear to drop it. A confirmed one shows ✓ confirmed with who wrote it and when; a draft from your agent shows suggested · AI-drafted, so the two can never be mistaken for each other. The box says it plainly: A description you type is yours. A drafted one is built from the table and column names on this machine — nothing leaves it.
Regixo derives lineage automatically where the database exposes it — dbt model graphs, and Postgres/Redshift view→table edges. What it can't infer is a cross-system flow: Stripe customers landing in your users table, an export feeding a warehouse. You assert those once, and they survive every re-scan.
Look at what you already have first. Regixo derives flows on every scan wherever a source
exposes them — your dbt manifest's ref() graph, and Postgres/Redshift view→table
dependencies. regixo lineage list shows them. You may have a graph already and not know
it.
For everything else, don't hunt pair by pair. Your coding agent is sitting in the code Regixo never reads — the ETL script, the Airflow DAG, the Stripe webhook, the nightly export. That is where the missing flows are, so hand it the job:
“Map the data flows between my datasets in Regixo by reading this project’s code — record only a flow you can point at in it.”
No single command does this. Your agent runs regixo lineage add once per flow, and the playbook makes it give you the file and line behind each one — so you can open the file and check it. Hand it the playbook first: regixo lineage --skill.
orders.user_id → users.id is a reference, not data moving. The playbook tells
your agent to record only what it can cite, and to list what it couldn't prove instead of
guessing — check the citations it hands back. A missing flow is a gap you can fill; an invented
one is a company named in a record that never received a row.When you already know the one Regixo missed:
“Record the flow from our Stripe customers into our users table in Regixo.”
$ regixo lineage add stripe/stripe/customer app-db/public/usersOne flow recorded, tagged as your assertion — not something Regixo inferred. It survives every re-scan, which is the point: a Stripe-into-your-database hop is invisible to any scanner.
Check it worked: open either dataset and the new chip is in its river, captioned asserted by you — not via dbt, not via the warehouse. Both endpoints must already be datasets in the map — if one isn't, the command fails loudly rather than inventing it, so a silent success means it really landed.
Asserted stripe/stripe/customer → app-db/public/users. See: regixo lineage list --origin=user
Both endpoints must be datasets already in the map. Asserting the same flow twice is a no-op — the command is idempotent. List edges, optionally filtered by where they came from:
“Show me the data flows I asserted myself in Regixo.”
$ regixo lineage list --origin=userThe flows you asserted, as opposed to the ones Regixo derived from dbt or from the warehouse's own view graph.
Check it worked: the flow you just asked for is in this list. If it isn't, one of the two dataset ids didn't resolve — ask your agent to search for the right ones first.
Lineage edges (origin: user) — assert one with `regixo lineage add <from> <to>`: [user] stripe/stripe/customer → app-db/public/users
--origin= takes user (your assertions), dbt,
warehouse (the auto-derived kinds), or all for everything. To remove an
assertion, read its edge id from regixo lineage list --json and pass it to
remove — only your own user edges are removable, since the auto-derived ones
are regenerated on the next scan:
“Remove the data flow I asserted by mistake from my Regixo catalog.”
$ regixo lineage remove <edgeId>
regixo watch regenerates only the auto-derived edges (dbt and
warehouse). Your asserted (user) edges are left alone — assert a flow once
and it stays.On the dataset, the flows draw as a vertical river — Comes from above, the dataset on
the trunk, Feeds into below, arrows pointing the way the data moves. Every chip reads
name · source (so customers · app-db and customers · mysql-db are
two different tables, plainly), and under each one a caption says who claims the flow:
asserted by you, via dbt, via the warehouse. A dashed chip is an endpoint Regixo
hasn't scanned. It is dataset-level only — Regixo never implies which column went where.
hubspot / script / contacts, and the Assert a flow control under itComes from2 direct
Feeds into2 direct
Arrows point the way data moves — down the page, into contacts and out of it. Flows inside your warehouse (including your dbt models) are found by the connector on each scan; flows between systems you assert yourself. Dataset-level only — Regixo never implies column-level flow. dashed = an endpoint Regixo hasn’t scanned; its caption says who claims the flow.
Under the river is an Assert a flow control: pick the direction (out of this dataset / into this dataset), name the other dataset — the field suggests every scanned id — and press Assert. It joins two datasets Regixo has scanned, and a typo fails by name, never a silent save. Beside it, the standing dataset-level marker: an assertion says data moves between two datasets and nothing finer. Each edge you asserted carries a remove; the auto-derived ones are left to the scanner.
The glossary is a flat term → definition → linked-datasets map, served as context to both humans and AI agents.
Two things fill it: Regixo seeds what the scan can see, and your agent proposes the terms only your business knows. Neither overwrites a term you already have, so run them in any order, as often as you like.
One command, whole catalog. It seeds candidates from what the scan already knows — personal-data
flags, DORA scope, recurring dataset-name tokens — each marked suggested and attributed to
regixo:
“Seed starter glossary terms in Regixo from what the scan already knows — I’ll confirm the right ones.”
$ regixo glossary suggest✓ 1 term suggested — marked “suggested” until you confirm it: Personal data ↳ review & confirm: regixo glossary confirm <term> (or edit it at /ui/glossary)
Expect a short list. A scan can only ever offer generic terms — it has no idea what your company means by anything. On the four-source catalog above it seeded exactly one: Personal data. It is a floor, not a glossary. Step 2 is where the real vocabulary comes from.
A scan can see that a column looks like personal data. It cannot know that MRR is your north-star metric, or what your company means by an active customer. Your coding agent is already in the repo, with the code and the names your team actually uses — so that is the job to give it. Ask for the whole vocabulary in one request; there is no bulk command, so it writes the terms one at a time:
“Propose glossary terms for my Regixo catalog as suggestions — I’ll confirm the ones that are right.”
No single command does this. Your agent runs regixo glossary set <term> "…" --suggest once per term. Each lands suggested, attributed to agent — never confirmed. Confirming is a separate command, and the playbook tells your agent not to run it: that act is yours. Hand it the playbook first: regixo glossary --skill.
Nothing it proposes is binding, and nothing you already wrote is at risk: a --suggest
term never overwrites an existing one. Review the list, keep what's right, and confirm those.
Define one yourself — a human-typed term is saved confirmed — and link the datasets it
names:
$ regixo glossary set MRR "Monthly recurring revenue — the normalised monthly subscription total." --datasets=stripe/stripe/subscription
This one’s yours. Confirming is your sign-off, not your agent’s.
Or have your agent propose just one. With --suggest the term lands
suggested, attributed to agent:
“Add MRR to the Regixo glossary as a suggestion, linked to the datasets it applies to.”
$ regixo glossary set MRR "Monthly recurring revenue — the normalised monthly subscription total." --datasets=stripe/stripe/subscription --suggest
A suggestion is a candidate, not a fact — a human promotes it with confirm:
$ regixo glossary confirm MRR
This one’s yours. Confirming is your sign-off, not your agent’s.
“Show me our Regixo glossary — the terms, and which are still only suggestions.”
$ regixo glossary listYour team's shared vocabulary — each term, its definition, the datasets it is linked to, and whether it is still only a suggestion.
Check it worked: a term your agent proposed reads suggested — check & confirm.
Promoting it is yours, and it records who did it.
Glossary — define a term with `regixo glossary set <term> <definition>`: MRR — Monthly recurring revenue — the normalised monthly subscription total. [stripe/stripe/subscription] Active subscriber · suggested — check & confirm — A subscription in a paying state. ↳ confirm a suggestion: regixo glossary confirm <term>
The full set is list · set · suggest · confirm · remove. Terms are
searchable and are exposed to agents — see Use an AI agent. You can
also add and edit them in the browser at /ui/glossary.
The Glossary page reads as a dictionary: a search box, an A–Z strip (a letter nobody has
used yet is greyed out), then the terms grouped under their initial. Each card carries the term, its
state (✓ confirmed, or suggested until a person promotes it), its definition, and the
datasets it appears in — as source-qualified chips (fintech-loans /
borrowers), so a table called customers in two systems is never two things wearing
one name. A dot on a chip marks a dataset with a column that looks personal; a term with no links says
no datasets linked rather than showing an empty row.
9 terms · 23 dataset links
A record of whether a person has opted in to a communication channel (email, SMS). The lawful basis for marketing; must be auditable and revocable.
GDPR roles. A controller decides why and how personal data is used; a processor only acts on instructions from the controller. Each source on your map is tagged with its role.
The Glossary composer does the same work: + Add term opens it — a name, a definition, and a dataset picker grouped into one fold per source (with a filter, and a tray of the ones you have ticked, each chip source-qualified). Edit reopens a term; a suggested one carries a Confirm you can press in place. An empty glossary offers a shortcut — + Add all three as suggested — to seed three starter terms you then check. A tour: the free portal tour.
A different surface. An assistant registered against the read-only
regixo mcp server reads the descriptions and lineage you add
(get_dataset, get_lineage) and the glossary
(get_glossary), so the context you write here becomes answers. It writes nothing.
To have an agent draft descriptions, terms or flows, ask your coding agent — it runs the
commands above, and its work lands as suggested for you to confirm.
See Use an AI agent.
Two commands. Pick by who you're sending it to:
regixo catalogEverything above — descriptions, glossary terms, classifications, RoPA answers, DORA cells, asserted lineage — travels as one committable JSON file. It carries no scanned schema, no secrets and no row values, so each machine regenerates the map itself from its own scan and layers the shared context on top.
“Export my Regixo catalog notes so I can commit them for the team.”
$ regixo catalog exportOne committable JSON file holding the descriptions, terms, corrections, asserted lineage and legal answers your team has built. It carries no scanned schema, no secrets and no row values — each machine regenerates the map from its own scan.
Check it worked: open regixo-catalog.json and look. If you find a connection
string or a table's contents in there, something is very wrong — it is designed to be safe to
commit.
✓ team catalog written → ./regixo-catalog.json
your team's descriptions, terms, corrections and legal answers — no scanned schema, no secrets, no row values
descriptions 5 · glossary terms 3 · classifications 2 · RoPA answers 6 · DORA cells 0 · lineage edges 1
↳ commit it next to regixo.yml — teammates run `regixo catalog import regixo-catalog.json` after their first scan.Pass --out <path> to write it elsewhere; the default is
regixo-catalog.json. A teammate imports it after their own scan. Import is
merge-only — nothing local is ever deleted, and a confirmed answer is never downgraded.
Preview first with --dry-run:
“Show me what importing a teammate’s regixo-catalog.json would change, without writing anything.”
$ regixo catalog import regixo-catalog.json --dry-runNothing is written. A dry run tells you exactly what a real import would change, so a teammate's file never surprises you.
Check it worked: import is merge-only — nothing local is deleted, and a confirmed answer is never downgraded by an incoming suggestion. The preview says so line by line; read it before you let your agent apply it for real.
dry run — nothing was written. Importing regixo-catalog.json would do: descriptions: 2 added · 1 updated (newer) · 0 kept (yours is newer) · 1 kept (confirmed) glossary terms: 3 added · 0 updated (newer) · 0 kept (yours is newer) · 0 kept (confirmed) ↳ apply it: regixo catalog import regixo-catalog.json
Then apply it for real:
“Merge my teammate’s regixo-catalog.json into my Regixo catalog.”
$ regixo catalog import regixo-catalog.jsonsuggested one, never silently downgraded. A confirmation is a human decision (Hard
Rule #4); the merge transports it, it never invents one.regixo shareYour compliance team, your manager, an auditor: people who don't run Regixo, and who may have no access to the databases at all. The notes file needs a Regixo catalog to import into, so it gives them nothing on its own. Send them the map — as one HTML file they open in a browser:
“Use Regixo to write my data map to a single HTML file I can send to my compliance team.”
$ regixo shareOne file — a briefing, with the whole map underneath it as evidence. It opens with what looks like personal data and where it lives, which systems hold it, where data moves between them, what Regixo could not see, and the legal calls only a person can make. Every system, table and column from your last scan sits below that. There is nothing to install, no server to run, and it reaches nothing when opened: not the internet, not your databases.
Check it worked: open the file yourself — and read it, because you are about to send it. It is a document, not a copy of your screen: nothing in it can be saved, signed or sent, and it is a snapshot of your last scan, not a live view. It says so at the top.
✓ written → ./regixo-map.html
4 tables · 4 systems · metadata only (names, types, and any descriptions your team wrote) — never the values inside your data
it opens as a briefing for your compliance team: what looks like personal data, where it lives,
what Regixo could NOT see, and the four calls only a person can make.
The full map is underneath it, as evidence.
one self-contained file: no install, no server, and it reaches nothing on the internet when opened
↳ read it first — it carries your table and column names, which are themselves confidential.
Then send it however your team already shares — Slack, email, Drive, the repo. They just open it in a browser.regixo open →
the map) carries a Send this map to your compliance
team card: Make the file downloads it through your browser, and See what they'll get
opens the real briefing in a new tab so you can read it before you send it. It is the same document,
byte for byte — the only difference is where it lands (your downloads folder, rather than
./regixo-map.html next to your project).
Once you've made one, the card also tells you whether your map has changed since — so you can see at a glance whether the copy your team is holding still matches. Regixo knows a file was made; it cannot know whether you sent it, and it never claims to.
regixo share writes your whole map into a file you hand to someone else, so it is the one to
read before you send. It holds metadata only — table and column names, types, owners, and any
descriptions your team wrote — and never the values inside your data. But metadata is not
harmless, and a description is free text: a table called patients_oncology tells a
story before anyone opens it, and a description reading “accounts flagged after the Q3 incident”
tells a bigger one. Treat the file as confidential, and send it the way your team already sends
confidential things.Pass --out <path> to write it elsewhere; the default is regixo-map.html.
--title "Acme Ltd" sets the heading (it defaults to your controller name from
regixo.yml) — worth setting when the file is going outside your team.