Data handling & what’s built

Two honest answers in one place: exactly what can leave your machine (and what never can), and what Regixo does today versus what is still on the roadmap. If a capability is designed but not built, it is on this page — never dressed up as shipped.

What leaves your machine, and what never does

Regixo is local-first. Reading your catalog, drafting the RoPA and DORA register, correcting a flag, wiring an agent — all of it happens on your machine. The scan reads metadata only and stays on your machine. Four commands upload, and only when you run them: regixo invite, regixo watch, regixo push and regixo start — and they send metadata only. regixo invite is the hand-off, and it shows you a preview of exactly what will go before it goes. The other three send the refreshed draft only once this machine is paired to a claimed record; an unpaired run sends nothing and says so.

Everything else is a count, not a name. This is the same ledger the regixo invite screen shows before the upload, computed from the payload itself — see it in place on the free portal’s Invite screen.

Thin it further — the redaction: policy

Metadata is confidential on its own: a table called layoffs_2026 leaks before anyone opens it. So you can mask names before they leave, in regixo.yml. Every key is optional.

redaction:
  hashOwners: true                     # the default — you only write this to turn it off
  redactDatasetNames:
    - layoffs_2026                     # an exact name, case-insensitive
    - /^hr_/                           # or a /regex/
  redactColumnNames:
    - salary

These keys reach names that ride inside a path or an activity title. The upload never carries a bare column name, type or table owner in the first place — that is the table above; this is the second line of defence for the names that do travel.

• hashOwners is on by default. Any owner email in the outbound metadata is replaced with owner-<8 hex>@redacted. You do not have to switch this on.
• Names are masked per segment. A match becomes redacted-<8 hex>, and the path keeps its shape — app-db/public/layoffs_2026 goes as app-db/public/redacted-9f2c4d7a, so the compliance team can still tell two activities apart without learning either name.
• Masking is stable, not reversible. The same name always produces the same token, so the record stays coherent across uploads; nobody can turn the token back into the name.
• It applies to every upload path. The policy is applied inside the payload builder, so invite, watch, push and start all obey it — there is no route that serialises an unredacted view.
• Your own catalog keeps the real names. Redaction governs only what leaves; the local map, search and the drafted files are unchanged.

Encryption at rest

Metadata is treated as confidential throughout — a table named patients_oncology leaks on its own. At-rest protection differs by side:

Honest today: the local store relies on your OS disk encryption plus 0600 file permissions. The portal’s per-claim encryption mechanism is built but not switched on — if REGIXO_DATA_KEY is unset the portal only warns, and stores its content as plain text; the encryption clause is not yet in effect. Enforced-mandatory encryption is a launch gate for the hosted portal. Per-tenant DB isolation has shipped in part (tenant content sits in a physical per-tenant database; the control plane still scopes the registry, sessions and tokens logically) and stays a launch gate until complete. The hosted portal is not yet live (see the roadmap table below).

Secrets

Secrets never live in regixo.yml. Each source names the environment variable that carries its connection string (connectionRef); Regixo resolves the value from your environment at scan time. Commit regixo.yml freely — it holds only variable names and non-secret config.

What’s built, and what’s on the roadmap

Regixo is a real product with real edges. The table states each capability’s status plainly, so nothing here promises more than the software does.