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, a glossary and flag corrections — and share it as one committable file. Everything on this page lives beside the catalog, so it survives every re-scan.
There are exactly four things a person can add on top of a scan. The compliance engine reads two of them; the other two never reach it — by construction, not by omission: the RoPA generator is handed your datasets, your columns, your sources and your lineage, and a dataset is only its id, its source and its name. A description never reaches it. A glossary term does not appear anywhere in the compliance engine at all.
This is not a ranking of value. Describing your tables is the one thing you write that everyone else reads — your team, search, any AI agent. It simply has nothing to do with the RoPA.
| What you can add | What it changes in your record | What it changes for your team |
|---|---|---|
Correct a flagregixo classifyHow → |
a lot Your record's categories of personal data are built from these flags (Art. 30(1)(c)). A wrong flag is a wrong record. This is the one that matters most. | The map stops calling a column personal when it isn't — and starts, when it is. |
Draw a data flowregixo lineageHow → |
one field A flow out of an activity into another system is suggested as a recipient (Art. 30(1)(c)) — a candidate your compliance team confirms, never a settled value. A missing recipient leaves that entry incomplete. | The map shows a hop the scanner cannot see — a webhook, a nightly export, a reverse-ETL sync. |
Describe a tableregixo describeHow → |
nothing Not one character. purpose (Art. 30(1)(b)) is a legal field only a human fills; a description does not fill, seed or improve it. |
The one thing you write that everyone else reads. Your teammates, search, and any agent reading the catalog. |
Define a termregixo glossaryHow → |
nothing Not one character. It does not travel in the file regixo share sends your compliance team either. |
Shared vocabulary, so your team and any agent mean the same thing by the same word. |
Two goals bring people to this page, and they sort the same four things differently. Find yours below, do what it lists in the order shown, and skip the rest — nothing you skip blocks anything, and you can come back for any of it later.
Your draft record already exists. Regixo scanned, classified and drafted it. You can hand it to
your compliance team right now — regixo invite. Then:
stg_cust_evt is for. They cannot decide why the company holds
a table they cannot identify — so a description does not fill the purpose field, it is how a human
answers it.Then the two things above that you were told to skip become the main event. Describe your tables — the highest-value thing you can write. Define the terms your team argues about. Draw the flows. Correct the flags. This is the work; none of it is required, and each piece pays off on its own. The rest of this page is how, one procedure at a time.
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.What it does: gives every table and column a plain-English line your team, search and any agent can read. When to do it: whenever someone who doesn't know your schema will read the catalog — which is almost always. The shape: draft the whole catalog in one command (step 1), improve the ones that matter (step 2), then check it on the Map.
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.
What it does: records a data flow between two datasets that no scan could observe — a Stripe webhook, a nightly export, a reverse-ETL sync. Why it matters: a flow out of a processing activity is suggested as a recipient in your GDPR record, so a real one you leave out leaves that entry incomplete. The shape: see what Regixo already derived (step 1), let your agent map the rest from the code (step 2) or record a single flow yourself (step 3), then check each one on its dataset.
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. In the C2 fintech sandbox, two flows arrive from dbt with no work at all:
Lineage edges — assert one with `regixo lineage add <from> <to>`: [dbt] app-db/public/customers → app-db/public/stg_customers (known via dbt — not scanned) [dbt] app-db/public/payments → app-db/public/daily_payments (known via dbt — not scanned)
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. Both endpoints must be datasets already in the map; a typo fails by name rather than saving a phantom flow:
“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.
What it does: agrees a shared term → definition → linked-datasets map, served to your team and any agent so everyone means the same thing by the same word. When to do it: when your team argues about what a word means — MRR, "active customer". The shape: let Regixo seed what the scan can see (step 1), have your agent propose the terms only your business knows (step 2), then confirm the right ones — check them on the Glossary screen.
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. Below it, regixo glossary list and the Glossary screen are how you check what landed
and confirm the suggestions worth keeping:
$ 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 subscription in a paying state.
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.
What it does: gets your work off your machine and to a person. The shape: pick the file for who you're sending to (below) → make it → read it before it leaves → send it. The two audiences take two different files, so the first decision picks the rest of the steps.
regixo catalogEverything above — descriptions, glossary terms, classifications, RoPA answers, DORA cells, asserted lineage — travels as one committable JSON file. It carries no row values and no credentials, and it is not a copy of the map: each machine regenerates that from its own scan and layers the shared context on top. It does name the tables and columns your team annotated — every row is keyed by one — so treat it like the rest of your schema.
“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 row values and no credentials, and it is not a copy of the map — each machine regenerates that from its own scan. It does name the tables and columns you annotated, and what each was labelled: a table name leaks on its own, so commit it beside the schema it describes and treat it no more freely than that.
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 row values, no credentials
it names the tables and columns you annotated, so treat it like the rest of your schema
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.The same file is how you move — to a new laptop, or into CI. Your install is four things. Only the map rebuilds itself; here is what happens to the other three:
regixo.yml. It holds only the names of
the environment variables your credentials live in, never a value, which is what makes it safe to
commit. Check that you actually did. If you ran regixo start in a project with
no regixo.yml at the root, Regixo wrote one into .regixo/ — the folder
most projects tell git to ignore. Then it does not travel, and a clone arrives with no
sources at all..env on the new machine yourself.regixo start re-scans and regenerates every
dataset, column and source.regixo catalog export
carries.The portal shows you all four — and checks, against your install, whether git will really
carry your config and your notes file — under Settings → Moving to another machine, which also
writes the file for you. It is the same file, in the same place, that regixo catalog export
writes.
.regixo/ folder across — projects normally tell git to ignore that
folder, so it is a manual copy, and it only works while the old machine is still in front of you.regixo share, walked in fullYour 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 instead — as one HTML file they open in a browser. It is a three-step procedure, and the middle step is not optional:
dres check, and the warning below it)Step 1 — make the file:
“Use Regixo to write my data map to a single HTML file I can send to my 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 it looks to be in, 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. The top states what it is: a metadata-only snapshot, names and types, never a value, and every classification a “looks like”. It is a document, not a copy of your screen, and it is your last scan, not a live view.
✓ 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 —
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 if you did send it, you can see at a glance whether that copy still matches what Regixo sees today. 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.
There is no "100% complete" to reach here — enrichment is optional and open-ended. You are done when the pieces you chose in the decision are in place:
regixo describe list has a line for every dataset that mattered, and
the Map's Undescribed filter reads the count you expect (0, if you set out to describe
everything).regixo lineage list --origin=user, each captioned asserted by you on its
dataset.regixo glossary list, the
right ones confirmed.None of this gates the hand-off. Your draft has existed since the scan finished, and forwarding it never waited on a single word here — enrichment makes the map better, it is not a step you must clear to move on.