Classify & correct

The classifier reads column names and types, so it gets most flags right and some wrong. This page shows how to fix a mis-classified column — mark a missed one, clear a false positive — and make the fix stick across every future scan. A correction is a mechanical fact you are allowed to set; it never touches a legal call.

Correct one flag all the way through (the worked example)

Before the detail, do one correction end to end. A telemetry table’s ip column is flagged as personal, but it holds server addresses — here is that fix through all four steps:

Every correction is that same four-step loop. The rest of the page is each step in full.

Step 1 · Find a wrong flag

Two things go wrong, and both have the same fix:

• A false positive — a column flagged as personal that isn't. A server_ip in a telemetry table is infrastructure, not a data subject's address.
• A missed column — personal data the name didn't reveal. A status column that actually holds a health status is Special category (Art. 9), but "status" reads as ordinary.

The classifier shows its reasoning on every flag (the matched rule and its confidence — see Read the map), so a wrong call is easy to spot. You correct it one of two ways: from your project — say it to your coding agent, or run the command yourself — or in the Map. Both write the same correction.

Why some flags are wrong at all: the classifier only ever saw names and types — a bland name hides, a suggestive one false-flags — and its recall is benchmarked only in English, German, French and Dutch. So non-English schemas and oddly-named columns are exactly where your eyes matter most. The language coverage →

Step 2 · Decide if it’s really wrong — is this personal data?

Before you touch a flag, decide what the column actually is. Regixo’s four calls all answer one question — does this column point to a living person? Ask these in order and stop at the first yes; the answer is the call you set:

The trap is the join: an id that looks anonymous on its own is personal if it can be traced back to a person through another table. When you can’t decide, treat it as personal — a defensible map errs toward including a person’s data, not hiding it. This is a call about the column’s content, a mechanical fact you may set; it is never a legal judgement (those stay the compliance team’s — see the rule at the foot of this page).

Step 3 · Correct it — from your project

Review every flag in one pass

Don't hunt through the map column by column. Hand the whole catalog to your coding agent and let it do the first pass:

Hand it the playbook first. Regixo's own classifier is built so that it can only read column names and types — it has no way to reach the values. Your agent does. That limit holds because the playbook states it, not because your agent will infer it: run regixo classify --skill and give your agent the output. It carries the two lines it must never cross, the exact commands, and the column-id format.

A good pass does three things:

• Fixes the clear mistakes — a missed nickname, an over-flagged ip.
• Hands the ambiguous ones back to you instead of guessing.
• Shows you every change it made, column by column.

Nothing it does is hidden or final: regixo classify list shows every correction that landed, and regixo classify clear reverts any of them.

Fix a single column

Once you know which flag is wrong — spotted on the map, or reported back by your agent — one command sets or clears a column's personal-data classification:

$ regixo classify set <columnId> <personal|special|criminal|not>

The four calls map onto the mechanical flag Regixo carries for the column:

personal

Ordinary personal data — the column holds it, no special article applies.

special

Special category under Art. 9 (health, ethnicity, religion, biometric, sexual orientation, trade-union…). Flags it and its own count.

criminal

Criminal-offence data under Art. 10 — a separate class from Art. 9.

not

Not personal data — clears the flag (suppresses a false positive).

Clear a false positive on that infrastructure IP:

$ regixo classify set app-db/public/logs.ip not

Corrected app-db/public/logs.ip → not. It flows into your RoPA draft and survives a re-scan. Undo: regixo classify clear app-db/public/logs.ip

Mark a column the name hid — a health status the classifier read as ordinary:

$ regixo classify set app-db/public/patients.status special

Undo a correction and hand the call back to the classifier:

$ regixo classify clear app-db/public/logs.ip

List every correction you've made — this shows only the columns a human has overridden, which is the set worth auditing:

$ regixo classify list

Your PII corrections (these survive a re-scan):
  app-db/public/logs.ip → not  (ip)
  app-db/public/patients.status → special  (status)

Add --json to any of these for machine-readable output. Every command is non-interactive — a missing or unknown column id is a coded CLASSIFY_INPUT_INVALID error, never a prompt.

Step 3 · Correct it — in the portal

The same correction, from the Map instead of the terminal — use whichever fits the moment; both write the identical fix. Start on the Map. The rail on the left is one fold per source; the filters above it carry live counts — Personal data, Art. 9, Art. 10 — so the columns worth checking are a click away. Open the source, pick the dataset.

Every column in the pane carries a Correct control. Open it and you get a "This column is" select with the same four calls — Personal data / Special category · Art. 9 / Criminal offence · Art. 10 / Not personal data — and Save. Picking one writes the identical correction regixo classify writes, and the fine print says it plainly: a mechanical fix, never a legal judgement. It overrides Regixo's detection, survives every re-scan, and is logged in What changed. Once a column is corrected, its row says corrected by you and a second button appears — Revert to Regixo's call — which hands the flag back to the classifier. Use whichever surface fits the moment: the Map when you're reading the estate, your project when you're scripting, working headless, or handing the job to your agent.

Step 4 · Check the correction stuck

Confirm it in two moves. First, regixo classify list (Step 3, above) shows every correction that landed — if a fix you asked for isn’t there, it didn’t take; run it again with the exact column id. Second, on the Map the corrected column’s row reads corrected by you and its dataset gains a ✓ corrected chip. Then it holds — a re-scan never wipes it, and here is why.

A correction is stored outside the scan snapshot. When regixo watch re-scans a source, the classifier re-derives its own flags from scratch — but your corrections are layered back on top afterwards, so a re-scan never wipes them. The correction then re-flows everywhere the flag is read: the Map, the RoPA draft, the personal-data counts, and the agent surface.

Branch · a pattern across your estate — tune the classifier in regixo.yml

When a correction isn't about one column but a naming pattern across your estate, encode it once in regixo.yml under pii. Two knobs, applied at scan time to every column by name:

version: 1
pii:
  extraPatterns:                 # extra regex, tested against the column name (case-insensitive)
    - "member_ref$"              # our internal person key — flag anything ending member_ref
    - "^crm_.*_id$"
  allowList:                     # exact column names to suppress entirely (case-insensitive)
    - country                    # a plain country column — not personal on its own
    - server_ip

pii.extraPatterns

Regex patterns matched against the column name. A hit adds a personal-data flag (confidence 0.7). A malformed pattern is ignored, never an error. These only add ordinary personal flags — they can't set Art. 9 or Art. 10; use classify … special|criminal for that.

pii.allowList

Exact column names (case-insensitive) to suppress before any rule runs. Use it to silence a recurring false positive across the estate — a column named country everywhere, say.

Rule of thumb: a pattern for many columns, classify for one. regixo.yml holds only names and non-secret config, so commit it freely — and a teammate's clone gets the same classification on their own scan.

How you know the correction stuck

• It appears in regixo classify list — the audit list of every human override.
• On the Map, the column’s row reads corrected by you, and its dataset shows a ✓ corrected chip in the rail.
• It survives a re-scan — regixo watch re-derives Regixo’s own flags, then layers yours back on top — and flows into your RoPA draft’s data categories.

When no flag on your list still looks wrong, the map is right. Making it richer — with the context a scan can’t infer — is the next step.