Keep it current

Schemas drift, so your data catalog has to keep up. This page shows how to re-scan on a schedule, read exactly what changed, and never let the map go stale in silence. If you also keep the optional EU compliance record, the same loop flags what needs re-signing and pulls your compliance team's work back home — that part is under its own marked section at the end.

The portal gathers all of this on one screen. Settings runs down a section nav — Mode · Connections · DORA scope · Keep it current · Moving machines · About this install — and Keep it current is the one that matters here: every source with the age of its last scan, a copy-ready GitHub Actions recipe pre-filled with the env vars your regixo.yml names, and — folded under it — a cron one-liner for when there is no CI. It is honest about what it is: Regixo can't schedule itself.

name: regixo watch
on:
  schedule:
    - cron: '0 6 * * 1-5' # weekday mornings — tune to your change rate
jobs:
  watch:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npx regixo watch
        env: # from your regixo.yml — set these as repository secrets
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
          BIGQUERY_URL: ${{ secrets.BIGQUERY_URL }}
          HUBSPOT_TOKEN: ${{ secrets.HUBSPOT_TOKEN }}
          MYSQL_URL: ${{ secrets.MYSQL_URL }}
          SNOWFLAKE_URL: ${{ secrets.SNOWFLAKE_URL }}
          SQLSERVER_URL: ${{ secrets.SQLSERVER_URL }}
          STRIPE_API_KEY: ${{ secrets.STRIPE_API_KEY }}

Re-scan on demand — regixo watch

One run re-scans your sources, appends the change log, re-drafts the RoPA (and the DORA register, if it's in scope), and reports which sources are getting stale.

$ regixo watch

▸ This checks for changes ONCE and then stops — it does not keep running in the background.
12 change(s): 3 column(s) added, 1 removed; appended to the change log.
review suggested for: Billing & payments (core fields changed; sign in the portal to make it official).
↳ re-draft written · view the changes:  regixo log

Procedure A · Schedule the re-scan

A one-off regixo watch keeps the map current only until the next schema change. The whole point of Procedure A is that you never have to remember to run it. Four steps, once:

Step 1 — pick cron or CI

Two ways to run it on a schedule. They do the same job; pick by where your team already automates:

Step 2 — add the exact recipe

CI. Add --ci and the run prints a markdown summary to stdout (pipe it into a CI step summary) and signals a core-field change through its exit code, so a pipeline can block or warn on a merge. There's a ready-made recipe at examples/github-actions/regixo-watch.yml; the load-bearing step is:

- name: Re-scan and summarise what changed
  env:
    DATABASE_URL: ${{ secrets.DATABASE_URL }}   # the env var(s) your regixo.yml names
  run: |
    set +e
    npx regixo watch --ci >> "$GITHUB_STEP_SUMMARY"
    code=$?
    set -e
    if [ "$code" -eq 3 ]; then
      echo "::warning::Core RoPA fields changed — review and re-sign if the record is sealed."
    elif [ "$code" -ne 0 ]; then
      exit "$code"
    fi

cron. No CI? A crontab entry does the same job — hourly here:

0 * * * *  cd /path/to/your/app && regixo watch

Step 3 — confirm it runs

Don't wait for a real change to find out the job works. Trigger a run by hand — the scheduled command is exactly the one from Re-scan on demand. On a quiet day it prints that nothing moved and exits 0:

## Regixo watch — no changes

_As of 2026-07-17T14:13:51.404Z._

Nothing moved since the last scan — the map is current.

Exit 0 and a one-line summary mean the schedule is wired correctly. Exit 1 means a paired cloud push failed — the local re-scan still finished, and the table below says so.

Step 4 — confirm --ci flags a core-field change

The exit code is the contract — this is the signal a pipeline blocks or warns on. Exit 3 is the one that matters: it fires only under --ci, when a moved core field would make a signed record need re-signing:

Plain regixo watch keeps the historic 0/1 contract, so an existing cron job never breaks. Exit 3 exists only under --ci, where a script is watching for it.

Optional — notify another system on every run

To tell a webhook whenever the map moves, POST the change summary to a URL. The egress is announced first and honestly scoped — dataset and column names plus change kinds only, never row values — and a delivery failure is a warning that never fails the local run:

$ regixo watch --webhook https://hooks.example.com/regixo

--json works on every mode for machine-readable output.

Read the change log — regixo log

The change log is append-only — a dated record of what moved in the map, and when. It's part of your evidence trail. Newest first:

$ regixo log

Change log (4 most recent, last watched 2 hours ago):
  2 hours ago       added              column:app-db/public/orders.refund_reason
  2 hours ago       core-field-changed activity:billing  retention: 24 months → 36 months
  yesterday         removed            column:app-db/public/users.legacy_ip
  3 days ago        metadata-refresh   activity:analytics

Narrow the window with --since (an ISO timestamp) and cap the rows with --limit:

$ regixo log --since 2026-07-01T00:00:00Z --limit 20

The same history renders in the browser at /ui/changes, grouped by date.

Procedure B · Respond to a re-sign (your side)

When a re-scan moves a core field of a signed activity, that signature no longer holds. Your side of putting it right is four moves, in order — and none of them is signing, which only a named person on the compliance team can do, on the portal:

1. Re-scan, or let CI do it. A moved core field of a signed activity is flagged in the regixo watch output itself — Re-scan on demand, above.
2. Read exactly what changed — which fields moved, and whether any was a core field that breaks a signature. What counts as a change ↓
3. Let the compliance side learn. A paired push carries the changed draft to the portal, stamps a heartbeat, and their re-sign alert goes out — pairing is the step that makes this automatic. Pair this machine ↓
4. Bring their signed work home once they've re-signed on the portal. pull & seal pull ↓

The sections below are those four moves in full. They only ever run when a signed record has drifted; a metadata-only change crosses no seam and needs nothing from you.

Move 2 · What counts as a change — and when you re-sign

Not every schema edit invalidates a signature. Regixo splits changes into two kinds:

• A core-field change — the substance of what a record covers moved. If the activity was signed, that signature no longer holds and the activity is flagged for re-sign.
• A metadata refresh — a new column with no legal impact, a row-count change, columns that moved but no core field. The signature stands; the change is logged and the activity marked "review suggested."

The seven core fields that trigger a re-sign flag:

• Purpose
• Lawful basis
• Retention
• Data categories
• Data subjects
• Recipients
• Transfers outside the EU

Move 3 · Keep the forwarded record current — pair this machine

Re-scanning keeps your local map fresh. If you forwarded a record to your compliance team, one more step keeps the hosted copy fresh too: pair this machine, so a re-scan also pushes the refreshed draft to the portal. Three commands send once this machine is paired: regixo watch, regixo start, and regixo push — which sends the record as it stands with no re-scan at all, so it still works when a source is unreachable or still waiting on a credential. Pairing is one env var, and it has three states:

A push carries the same metadata-only payload an invite does — table paths that look personal and the kinds of personal data in them, plus the drafted record. Never a row value, a column name, or a credential.

Send now, without a re-scan — regixo push

A re-scan sends as a side effect. When you have only changed the record — answered one of your three Article 30 fields, corrected a personal-data flag, asserted a data flow — there is nothing to re-scan, and regixo push is the direct way to send it:

$ regixo push
✓ hosted record updated → https://app.regixo.com
  This sent what is already on this machine. To pick up schema changes first, run:  regixo watch

It touches no database, so it works when a source is unreachable or still waiting on a credential — the case where a re-scan cannot get far enough to send anything. Unpaired, it says so and exits 1 rather than failing quietly:

$ regixo push
Not sent: this machine isn’t paired with the hosted record, so it cannot update it.
  Pair it: whoever claimed the record generates a machine token on the claim page (“Connect a machine”).
  Then set it as REGIXO_SYNC_TOKEN here, or paste it in  regixo open → Settings.

Commands that change the record but do not send on their own (classify, lineage) say so in their own output and name this command.

How your compliance team knows the map is still moving

A paired push is more than a data update — it is a heartbeat. Each regixo watch run stamps the token's last-seen time on the portal, and the hosted record shows when it last synced. So the compliance side never has to ask whether your re-scan ran; the record says so on its own face.

If a paired machine goes quiet, the portal does not wait for someone to notice a stale date. After a 7-day grace window with no sync, it flags the record as going stale.

That warning always shows on the record and in the audit trail. The email to the record's admins is on by default; each person can turn it off in their notification preferences.

The usual causes are plain:

• the machine running regixo watch is off
• its cron or CI job stopped
• the token was revoked

Move 4 · Bring the team's work home — pull & seal pull

The handoff is a round trip. Your compliance team fills legal and DORA fields on the forwarded claim link, and signs there. Two commands bring their work back to your machine. In both, the claim token is the capability — the same secret your regixo invite link carried.

Pull the filled-in fields

Prefer buttons? The free portal’s record page shows a banner the moment answers are waiting and brings them in with one click — the same merge as the command. regixo pull fetches the RoPA legal fields and DORA cells your team entered and merges them with eyes — a per-field diff, and it skips a field where your local answer is newer (never a blind overwrite). A field your compliance team deleted is removed here too — but only ever a row they filled: an answer you typed yourself is never removed by a pull, whatever arrives on the wire. Preview with --dry-run; take the claim side on a conflict with --force:

$ regixo pull clm_7f3a9c2e4b1d8056

✓ merged 5 fills from claim clm_7f3a9c2e4b1d8056 · 2 skipped (already merged or local is newer).
↳ see them:  regixo dora status   ·   regixo annotate list

A field your team confirmed is carried as confirmed, never fabricated — that was a human approver's decision on the portal, and the pull only transports it (Hard Rule #4).

Pull the signed seal

Once the team has signed and sealed, regixo seal pull checks the claim's status and, when it's sealed, downloads the official artifacts — the PDF, the record JSON, the attestation and the offline verifier — into <data-dir>/remote-seal/, so you hold the evidence locally:

Signed again? A re-signature is a new seal. regixo status then says “signed again on the portal — this machine holds the earlier seal” and names the command; the record page offers the same as a button. Re-run regixo seal pull to collect it.

$ regixo seal pull clm_7f3a9c2e4b1d8056

✓ pulled 4 of 4 sealed artifacts → .regixo/remote-seal
  signed & sealed by Dana Kessler (Data Protection Officer, Acme Europe BV) on 2026-07-03 · valid until 2027-07-03
  verify offline:  node .regixo/remote-seal/verify-attestation.mjs

If the record isn't signed yet, the command says so plainly and exits without error — "not yet" is a normal answer. Nothing is ever overwritten blindly.

How you know you're done

Procedure A is done when the schedule is proven, not just written:

• The scheduled run is in your repo (CI) or crontab, pointed at the env vars your regixo.yml names.
• You triggered it once by hand and saw it exit 0 with a summary — Step 3.
• Settings → Keep it current shows each source's last scan getting younger, not older.

Procedure B only ever runs when a signed record drifts — and it is done when the loop closes:

• A core-field change no longer shows an open Review & re-sign flag — because your compliance team re-signed it on the portal (not you).
• If you paired the machine, the hosted record's last synced time is recent — the heartbeat is beating.
• regixo seal pull brought the re-signed seal home, named with who signed and when.