Regixo docs
Get help
Operate day-to-day · runbooks

Playbooks for common events

The events that actually happen when you run Regixo — a source lands, a migration ships, an auditor asks, a licence lapses, an admin leaves. Each playbook below is a short runbook: the steps in order, and the one role that owns it. Nothing here is new behavior — it is the everyday loop, written down.

1 · A new data source lands

A new database or SaaS joins the estate and you want it on the map.

  1. Register it with regixo add <type> — it writes regixo.yml and stores only the env-var name, never the secret.
  2. Scan it in — regixo start, or let the scheduled regixo watch pick it up on its next run.
  3. Its datasets appear on the map, classified for personal data, and its activities join the RoPA draft (and the DORA register, if in scope).
  4. If the new source adds a core field to an already-signed activity, that activity is flagged for re-signing. If it only adds new activities or metadata, nothing signed is disturbed.

Owner — engineer. Detail: Connect your sources.

2 · A schema migration

A migration changes tables and columns under an estate Regixo already maps.

  1. regixo watch re-scans — metadata only — and diffs the new shape against the last one.
  2. The change is written to the append-only change log with its date, so the history is kept.
  3. Regixo classifies the change: a core-field change flags the affected signed activity for re-signing; a metadata refresh (a new column with no legal impact, a row-count shift) leaves the signature standing and is simply logged.
  4. If a signature was flagged, the compliance owner reviews the diff and re-signs that activity in the portal.

Owner — engineer, then the compliance lead if a signature was flagged. The seven core fields and the re-sign rule: Keep it current.

3 · regixo watch --ci returns exit 3

Your pipeline runs regixo watch --ci and it exits 3 — the signal that a core RoPA field changed and a signed record would need re-signing.

  1. CI treats exit 3 as a warning, not a failure — the ready-made recipe emits a ::warning:: and lets the merge through. Exit 3 exists only under --ci; plain regixo watch keeps the historic 0/1 contract.
  2. The run's markdown change summary lands in the CI step summary, and the re-sign needed email reaches the record's approvers and admins.
  3. An approver or admin opens the record, reads the diff behind the Review & re-sign → banner, and re-signs the flagged activity.

Owner — approver (the engineer's pipeline raises the flag). Exit-code contract and the recipe: Run it on a schedule.

4 · "Where is our customer data, and what's personal?"

An internal question — mapping the estate for a review, a design, or a risk assessment. There are three real ways to answer it, all reading the same catalog.

  1. The map — search the dashboard, apply the Personal data filter, and open a dataset page to see its columns and what each was classified as.
  2. The terminal — regixo search <words> ranks datasets and columns with the same engine as the dashboard.
  3. An AI agent — a connected assistant reads the catalog through get_dataset and the other read tools, read-only by construction.
What this is, and is not This is internal discovery — finding where data lives across your systems. It is not a data-subject access, right-of-access, or erasure workflow: Regixo has no DSAR feature, by design, and does not answer requests from individuals. It maps your estate; acting on a person's request stays with your own processes.

Owner — anyone with access. Detail: Read the map · Use an AI agent.

5 · Audit or regulator readiness

Someone asks for evidence. Here is what you can actually hand over, and — just as important — what Regixo does not claim.

  1. The official Article 30 record (PDF) — the living, sealed RoPA with the DRAFT stamp off and a running OFFICIAL — ATTESTED mark. It reflects the current data, kept fresh by the loop.
  2. The DORA pre-submission package — the xBRL-CSV package for the Register of Information, validated against the regulation's table structure and key datapoint formats. See the honest caveat below.
  3. The change log — the append-only history of what moved, with per-field "verified as of" dates tracing each mechanical field to the system it came from.
  4. The standalone offline verifier — verify-attestation.mjs ships next to the artifact, so anyone can check the seal with no Regixo server in the loop. Cross-check the key against ATTESTATION_KEYS.md in the public repo.
  5. The free draft evidence bundle — regixo evidence assembles the RoPA and DORA drafts, the change log and the source list into one machine-readable bundle with a per-artifact SHA-256. Draft-only; it attests nothing.

Build the free bundle — regixo evidence

One command packs your drafts into a single JSON file — no licence, nothing uploaded. The bundle holds four things, each with its own SHA-256:

The map itself — your dataset and column inventory, descriptions, glossary and lineage — is not in the bundle. For that, send the map: regixo share.

say

“Use Regixo to pack my draft records into one evidence bundle I can hand to an auditor.”

Show the commandHide the commandShow the sentenceHide the sentence
run
$ regixo evidence
then

One file — .regixo/evidence.json — holding a manifest and every artifact inline. It runs entirely on your machine. --json writes it to stdout instead, which is how an agent reads it.

Check what you're handing over: the manifest is stamped "stamp": "DRAFT". That is the honest word — this bundle attests nothing. It is a tidy, hashed package of your drafts, not a signed record. The signed, sealed OFFICIAL bundle is the paid step. Note that each run stamps a fresh generatedAt, and the RoPA's fingerprint covers it — so re-running on an unchanged catalog still gives you a new file and a new RoPA hash. The fingerprints bind the manifest to the content inside this file; they are not a way to prove nothing changed between two runs.

Show what it prints in the terminalHide the terminal outputShow what your agent reportsHide what your agent reports
example output
✓ evidence bundle written → .regixo/evidence.json
  3 artifact(s) · DRAFT (no seal — the signed bundle is the paid step)
  · RoPA_DRAFT.json  sha256:bb327672f703…
  · change-log.json  sha256:ddad32adead0…
  · sources.json  sha256:3366192505f1…
↳ a machine reads the whole bundle:  regixo evidence --json

Check a bundle you were handed — regixo evidence verify

Re-computes every fingerprint from the content embedded in the file and prints a ✓ or ✗ per artifact. Exit code 1 (EVIDENCE_HASH_MISMATCH) if any part no longer matches:

say

“Check that every part of my Regixo evidence bundle still matches its fingerprint.”

Show the commandHide the commandShow the sentenceHide the sentence
run
$ regixo evidence verify .regixo/evidence.json
then

A ✓ per artifact, then a closing line stating what the check does not prove. Edit one byte of a part without touching the manifest and that part turns ✗, with a non-zero exit — useful in CI.

Read the ✓ for exactly what it is. The fingerprints live inside the bundle, so anyone who edits a part can also re-stamp the manifest and the ✓ comes back. It catches corruption and careless edits — not someone determined. Regixo's own output says so; see the warning below.

Show what it prints in the terminalHide the terminal outputShow what your agent reportsHide what your agent reports
example output
  ✓ RoPA_DRAFT.json — fingerprint matches the embedded content
  ✓ change-log.json — fingerprint matches the embedded content
  ✓ sources.json — fingerprint matches the embedded content
✓ 3 artifact(s) verified — every part still matches the fingerprint the manifest recorded.
  (each fingerprint is a sha256 over that part’s compact JSON — the manifest’s "hashAlgorithm")
  A fingerprint list is not a signature: this catches corruption and careless edits, not
  someone who re-stamped the manifest. This bundle is stamped DRAFT and carries no signature.
A ✓ is not a signature — know what you are relying on

The fingerprints are stored in the same file as the content they fingerprint. Change an artifact, re-compute its hash in the manifest, and the ✓ comes back — with the altered content still inside.

  • Use it for — a truncated download, an accidental edit, a CI gate.
  • Do not use it for — proof to a regulator that the bundle is untampered. Nothing here is signed.
  • The signed step — a seal anyone can check offline against Regixo's published attestation key, with no Regixo server in the loop, bound to the exact artifact bytes (Unlock, sign & maintain).
Stated plainly — the bounds of the evidence

The DORA package is a pre-submission package, not a guaranteed filing. It is validated against the table structure and key datapoint formats — it is not certified submittable, and the official export deliberately refuses (EBA_TAXONOMY_UNVERIFIED) until the vendor verifies the EBA taxonomy and DPM code-map constants. Your authority still sets the submission channel and runs its own validation.

There is no single assembled "official evidence pack" yet. The parts above ship individually; the one-file export is tracked for a later release. Regixo also does not reconstruct the record as of an arbitrary past date — the immutable snapshots are the ones taken at each signature.

Timing rests on the signing server's clock for now. Until an RFC 3161 timestamp authority is configured, every seal records timestampProof: none and the artifact says so.

No promises about the outcome. Regixo has no DSAR feature and gives no legal advice. It never promises you will pass an audit or avoid fines — no software can. The signer owns the legal judgment.

Owner — compliance lead / approver. What OFFICIAL adds and how the seal stays honest: Unlock, sign & maintain.

6 · Licence renewal

The licence is a one-time yearly charge. It lapses if you do nothing, but nothing is ever deleted.

  1. From 30 days out — an expiry warning shows (and the 30-day and 7-day emails go to admins). The record stays fully OFFICIAL the whole time it warns.
  2. At expiry — the tenant drops to draft-only and a renewal banner appears. No record, seal, or history is deleted; the OFFICIAL surface is simply paused.
  3. To renew — Account → Billing → Renew, via the Stripe Customer Portal. On payment the OFFICIAL state comes straight back.

Owner — compliance lead / billing owner. Pricing and the renew flow: Renew each year.

7 · The sole admin leaves the company

The one person who administers a record is leaving. Regixo protects against a record with no owner.

  1. Promote a successor first. Add or promote another person to admin on that record. The last admin can never be removed or demoted — so the handover has to happen before the departure, not after.
  2. Then the leaver steps down. Once a second admin exists, the departing person can be removed or can step down. Removing a member ends their active sessions.
  3. Account erasure is separate. regixo admin user rm (and the portal's "Close my account" request) erases a person's Regixo account — and it refuses while that person is the sole admin of any record, naming those records so you transfer them first. This is account lifecycle, not a data-subject request.
Account erasure is not a GDPR DSAR Removing a Regixo user or closing a tenant is account housekeeping — ending someone's access to the tool. It is not a data-subject right-of-erasure workflow, which Regixo does not provide.

Owner — admin. Roles and transfers: Roles & governance.

8 · A source goes stale (stale-loud, or never scanned)

A source hasn't been scanned in a while, or can't be reached, and its banner has gone loud.

  1. Read the banner. The map marks the source and keeps coverage honest ("4 of 6 reachable"). It warns; it never blocks the rest of the scan.
  2. Fix reachability — three real routes, whichever fits: bring the key (a reachable connection string through your own VPN or tunnel — there is no --tunnel flag), bring Regixo inside (run it on a machine inside the network and merge the maps), or describe it (import a CSV of the schema when you can't connect at all).
  3. Re-scan. Run regixo watch now, or let the schedule pick it up — the age resets and the banner clears.

Owner — engineer. The three routes in full: When a database can't be reached.

The commands behind every playbook Each step above maps to one regixo command. Every one runs headless, with --json, so a script or an agent drives it the same way you do. The full list is next.
← Back
Operating cadence by role
REGIXO — documentation · short runbooks for the events that actually happen · Command reference