Architect your catalog for your organization

Your first run maps one database. An organization catalog is a deliberate set of sources, a chosen mode, and a committed regixo.yml your whole team shares. This page is the whole set-up job, in order: five steps take you from that first laptop run to a plan the whole team scans the same way. Work them top to bottom; each ends with a way to check it landed.

Walk one company through all five steps (the worked example)

Before the reference, set one real estate up end to end so the five steps are concrete. Aurelia Payments is an authorised EU payments firm. Its product runs on a Postgres database in the EU; it bills through Stripe (US-hosted); it analyses in a Snowflake warehouse in the EU; and a dbt manifest describes how the warehouse models derive from the app tables. Here is each step for it:

The five sections below are that same run, walked in full — the decision inside each step, then exactly how to make it, then how to check it landed.

Step 1 · Plan the sources you scan

You don't have to connect everything on day one. Start with what the machine you're on can already reach — a database whose DATABASE_URL is set, a Stripe test key in the environment — then add the rest one at a time.

Decide what goes in — the walk

Because everything scanned and flagged personal becomes a candidate activity, and there is no per-table “leave this out” switch, choosing the sources is choosing the record's boundary. For each system you could point Regixo at, ask in order:

Do this. Run the first scan where a source is already reachable:

$ regixo start

Then add each further warehouse or SaaS, one at a time — each entry carries the name of the env var that holds its secret, never the secret:

$ regixo add postgres

Full connector detail: Connect your sources.

Check it. regixo status summarises the reachable estate against the target; regixo sources lists each source with a ✓ or ✗. The map opens at the portal with the datasets it found. Here is Aurelia's estate after the first scan — the two live sources in, Stripe and Snowflake still waiting on their env vars:

sources:  4 configured · 2 reachable · 2 unreachable (snowflake-dwh, stripe)
datasets: 4 mapped · 4 hold personal data
columns:  20 in total · 9 hold personal data
coverage: ⚠ 2 of 4 sources reached — the map EXCLUDES snowflake-dwh, stripe (fix: regixo doctor)
record:   RoPA drafted — DRAFT · DORA register (DRAFT); review: regixo open · forward to your compliance team: regixo invite

✓ app-db  [sql/postgres]  reachable · last scan 11m ago
✓ dbt  [dbt/dbt]  reachable · last scan 11m ago
✗ snowflake-dwh  [sql/snowflake]  couldn't connect · Regixo does not record when it was last read
✗ stripe  [saas/stripe]  couldn't connect · Regixo does not record when it was last read
  remove one:  regixo sources remove <id> --yes

Read the coverage meter as a target

A partial estate is normal and honest. When a source can't be reached, Regixo marks it and keeps the count truthful — “4 of 6 reachable”. Treat that ratio as a rollout target, not a one-off result: the goal is to close the gap over successive sessions, not to reach 6 of 6 on the first run. There are three real routes to bring an unreachable source in — none of them a dead end:

• Bring the key — set up your own VPN or SSH tunnel and give Regixo a connection string that reaches the host through it. There is no --tunnel flag; Regixo just needs a reachable host on the normal DATABASE_URL.
• Bring Regixo inside — run regixo start on a machine inside the network and merge the maps (see Roll it out).
• Describe it — hand Regixo a CSV of the schema (regixo add manual --from schema.csv). No live system, no secret.

Step 2 · Set the mode

One setting decides what your team's portal leads with. All three still scan metadata only; the difference is emphasis — and, for catalogOnly, visibility. Set it once in regixo.yml (below) so every teammate's portal opens the same way.

Which mode to pick — the walk

Ask these in order and stop at the first “yes”:

The reference for exactly what each mode does:

Check it. Read the settings back — the fastest confirmation, no browser needed. Ask your agent, or run regixo config:

$ regixo config

Regixo settings — ./regixo.yml
  catalog-only   off — EU compliance (RoPA + DORA) shown
  intent         compliance
  dora           on

Change a setting:  regixo config catalog-only on|off

Then open the portal (regixo open) to see the emphasis land: intent: compliance opens on the record and ends the run on the hand-off; catalogOnly: true shows no Record, DORA or Unlock surface at all. regixo config catalog-only on|off flips catalogOnly live without hand-editing the file.

Step 3 · Declare DORA scope

DORA binds authorised or registered financial entities, and the catalog can't infer whether you are one — so it's an explicit opt-in that adds the DORA Register DRAFT alongside the RoPA. It is not a one-way door: you can turn scope on or off at any time — flip it off and the register drops out of view, flip it back on and it returns, drafted from the same map. Three equivalent ways to declare it:

dora: true

In regixo.yml — the committed, team-wide way. The object form (dora: with refPeriod / baseCurrency / nca) also turns scope on and carries the EBA filing parameters.

regixo start --dora

Turns scope on for a run from the command line.

the first-run question

On an interactive first run Regixo asks “Is your organisation a regulated financial entity?”; answering yes sets scope.

The DORA register only appears when DORA scope is on — see The DORA register for what the map part-fills and what your team supplies.

Check it. With scope on, the portal grows a DORA lens next to the record, and regixo status reports the register alongside the RoPA. With it off, neither appears.

Step 4 · Name the load-bearing fields

A coherent org catalog reads consistently across sources. Set four things per source, and know that two of them — region and role — feed the compliance record rather than just labelling a row. Get these two right and the record's transfer and controller/processor calls start from the truth.

id

A short, stable slug (app-db, billing-stripe). It's how the source is referenced in lineage, in regixo test <id>, and in commit diffs — pick it once and keep it.

label

The human display name on the map (“Application database”). Cosmetic — make it the name your team already uses.

region load-bearing

The host region (eu-central-1, us-east-1). Not cosmetic: it feeds the RoPA “transfers outside the EU” suggestion. A US-hosted source with EU personal data is exactly the transfer your compliance team must account for, and region is how Regixo raises it.

role load-bearing

controller or processor — your GDPR role for this source. It feeds the controller/processor classification in the record. To decide: do you determine why and how this data is processed — is it your product's own data? → controller. Do you hold or process it on someone else's behalf, or does a third party process it for you? → processor. Default is controller; Stripe and other SaaS processors default to processor (they process on your behalf). Set it honestly per source.

Check it. Open the record and read an activity: a US-hosted source with EU personal data raises the “transfers outside the EU” suggestion, and a processor source is marked as such. If a transfer you expect is missing, the source's region is probably wrong — fix it in regixo.yml and re-scan.

Step 5 · Commit a shared regixo.yml

The whole point of the file is that it carries no secrets — only env-var names and non-secret config — so you commit it and the whole team scans the same estate. Here is a multi-source example carrying every decision from steps 2–4 — intent, DORA scope, the controller identity, the load-bearing fields and an org PII policy:

version: 1
intent: compliance          # step 2 — portal leads with the record + ends on the hand-off
dora: true                  # step 3 — regulated financial entity — add the DORA register draft

controller:                 # the Art. 30(1)(a) organisation the record is FOR
  name: Aurelia Payments Oy
  contact: dpo@aurelia.example

sources:                    # step 1 — the estate; step 4 — region + role per source
  - id: app-db
    kind: sql
    driver: postgres
    label: Application database
    connectionRef: DATABASE_URL     # the env-var NAME, never the secret
    region: eu-central-1            # EU — no transfer raised
    role: controller                # Aurelia's own product data
  - id: stripe
    kind: saas
    driver: stripe
    label: Stripe (billing)
    connectionRef: STRIPE_URL
    region: us-east-1               # US — feeds the "transfers outside the EU" call
    role: processor                 # Stripe processes on your behalf
  - id: snowflake-dwh
    kind: sql
    driver: snowflake
    label: Snowflake DWH
    connectionRef: SNOWFLAKE_URL
    region: eu-west-1
    role: processor
  - id: dbt
    kind: dbt
    driver: dbt
    label: dbt lineage
    path: dbt/manifest.json         # warehouse model-to-model lineage
    target: app-db

pii:                        # org PII policy — extend / suppress the classifier
  extraPatterns:
    - "^cust_ref$"                   # your own personal-data column names
  allowList:
    - internal_batch_id             # never flag this one (false-positive)

Check it. Commit the file and have a teammate clone the repo, set their own .env, and run regixo start. They should get the same source list and the same map you do — git diff regixo.yml is now the reviewable record of every estate change. If their scan differs, a secret or an env-var name is out of sync, not the committed config.

Beyond the five steps · one map, two lenses

Regixo keeps a single catalog and renders it through two lenses: the free Data lens (the map — datasets, columns, owners, personal-data flags) and the Compliance lens (the RoPA record, and the DORA register when in scope). The record is derived from the map, never typed twice. Correct a classification on the map and the RoPA activity's data categories update on their own; there is no second place to edit the same fact. That single-source-of-truth design is why an org catalog stays internally consistent as it grows.

Walked step by step in Your first session; the classifier itself is Classify & correct.

Lineage — automatic inside, asserted across

Two kinds of data flow, two ways Regixo gets them:

Automatic, inside a warehouse

A dbt manifest.json (regixo add dbt --from … --target …) gives the model-to-model ref graph, and on Postgres/Redshift the scanner reads pg_depend / pg_rewrite to emit view→table edges. No warehouse rows are read.

Human-asserted, across systems

A Stripe→database flow crosses systems no scanner can join. Assert it once with regixo lineage add <from> <to>; the edge is tagged “asserted by you” and survives every re-scan.

Enrich as an org standard

Three enrichments turn a bare map into shared organizational knowledge. All three run locally — no network call, no model call — and each is persisted outside the scanned snapshot, so a re-scan never clobbers the work your team layered on.

regixo describe

A one-line description per dataset (“Registered customer accounts — one row per person”). Regixo drafts it from metadata; a human confirms. Feeds the team and any connected AI agent.

regixo glossary

House terms and their meaning, so “MRR” or “data subject” means one thing across the org. glossary suggest proposes seeds; a human confirms.

regixo lineage

The asserted cross-system edges above — the flows the catalog standard should record because no scanner can.