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 planning layer — which sources to onboard and in what order, how the three modes change what the dashboard leads with, and which config fields feed the compliance record rather than just labelling a box.

Plan the estate

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.

1. Map what's reachable. Run regixo start where a source is already configured. It scans structure only — names, types, owners — and you have a map in minutes.
2. Add each further source with regixo add <type> — one entry per warehouse or SaaS, each carrying the name of the env var that holds its secret, never the secret. Full connector detail: Connect your sources.
3. Enrich, then hand off. Once the map is real, layer on descriptions, a glossary and cross-system lineage (below), then forward the draft to your compliance team.

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.

Choose the mode

One setting decides what your team's dashboard leads with. All three still scan metadata only; the difference is emphasis — and, for catalogOnly, visibility.

Turn DORA scope on

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. 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 is a scoped second act — see The DORA register for what the map auto-fills (about 3 of 15 tables) and what your team supplies.

Source conventions — and which fields are load-bearing

A coherent org catalog reads consistently across sources. Set four things per source, and know that two of them feed the compliance record rather than just labelling a row.

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. Default is controller; Stripe defaults to processor (it processes on your behalf). Set it honestly per source.

A real, committed 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. A multi-source example carrying intent, DORA scope, the controller identity and an org PII policy:

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

controller:                 # the Art. 30(1)(a) organisation the record is FOR
  name: Northwind Payments GmbH
  contact: dpo@northwind.example

sources:
  - id: app-db
    kind: sql
    driver: postgres
    label: Application database
    connectionRef: DATABASE_URL     # the env-var NAME, never the secret
    region: eu-central-1            # feeds the "transfers outside the EU" call
    role: controller
  - id: warehouse
    kind: sql
    driver: redshift
    label: Analytics warehouse
    connectionRef: REDSHIFT_URL
    region: eu-west-1
    role: controller
  - id: billing-stripe
    kind: stripe
    label: Stripe (billing)
    connectionRef: STRIPE_API_KEY
    role: processor                 # Stripe processes on your behalf

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)

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, nothing leaves the machine, and — critically — 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.