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 dashboard gathers all of this on one screen. Settings runs down a section nav — Mode · Connections · DORA scope · Keep it current · 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

Run it on a schedule

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

The exit code is the contract:

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.

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

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

To notify another system on every run, 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.

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

Bring the team's work home — dora 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

regixo dora 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). Preview with --dry-run; take the claim side on a conflict with --force:

$ regixo dora 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:

$ regixo seal pull clm_7f3a9c2e4b1d8056

✓ pulled 4/4 sealed artifact(s) → .regixo/remote-seal
  signed & sealed by Anna Kessler (Data Protection Officer, Northwind Data 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.