Walkthrough · keeping it defensible
A change, and a re-sign
A signed record is only defensible while it still describes reality. Months after the compliance team signed, a schema migration lands and moves a legal-relevant field. Here is that drift caught end to end: a nightly check flags it, the portal surfaces it, and the compliance lead re-signs — with the old seal kept intact. Nothing re-signs itself.
Where this picks up
The record is already unlocked and signed (see The compliance
team). This walkthrough is the maintenance loop that keeps it that way. Screens below are static
examples of what you'll see, not live widgets.
1
Put it on a schedule engineer
Drift is only caught if something looks. The engineer copies the ready-made GitHub
Actions recipe to
.github/workflows/regixo-watch.yml, so CI runs
regixo watch --ci on a schedule. The --ci flag prints a markdown summary
into the run's step summary and exits 3 when a core RoPA field changed — a signal a pipeline
can key on.what you'll see — regixo-watch.yml (the load-bearing step)
- name: Re-scan and summarise what changed
env:
DATABASE_URL: ${{ secrets.DATABASE_URL }}
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 sealed."
elif [ "$code" -ne 0 ]; then
exit "$code"
fiOne scheduled job. It re-scans metadata only — names and types, never row values —
and nothing is uploaded unless you deliberately pair a sync token.
Full detail: Keep it current →
2
A schema migration lands engineer
Weeks later, an ordinary migration ships: the app adds a
marketing_consent
column to app-db/public/users. It looks small, but it changes what the "Marketing &
email outreach" activity processes — its data categories, one of the seven core fields. The next
scan simply folds the new column into the Map; the Map states what is, not what moved. To see
what changed — and what it costs a signed record — you go to What changed, which is the
next two steps.No one tells Regixo about this by hand. The scheduled scan finds it on its own.
3
The nightly run flags it
The next morning's CI run re-scans, sees that a core field moved, and exits 3.
The markdown summary lands in the run's step summary, calling out exactly what changed and what it
means for a signed record.
what you'll see — GitHub step summary (regixo watch --ci)
## Regixo watch — 2 changes _As of 2026-07-05T06:00:11Z._ ### app-db/public/users +1 added - ＋ `marketing_consent` ### Core fields changed — affects the record These alter what a signed record covers, so they are flagged for re-sign. Re-signing stays a human act — Regixo never re-signs for you. - **Marketing & email outreach** — Data categories: `contact, account` → `contact, account, consent` _Metadata only — dataset/column names and change kinds; never row values._
Exit 3 is the flag. The CI step turns it into a build warning — the change is
surfaced, the pipeline doesn't fail, and re-signing is left to a human.
4
It surfaces in the portal
The same run keeps the hosted record current, so the What changed feed shows the
new column. And because a signed activity drifted, a gold banner appears at the top of the
record — the re-sign is now visible to the compliance team, not buried in a CI log.
What changed
1 change since you signed may need a re-sign. Your RoPA record was sealed on 14 Mar. The changes marked “affects the record” below alter what it covers, so the signed version no longer matches your data. Nothing happens behind anyone’s back — a signer re-confirms when ready.
Review & re-sign →1 change affects the record · 2 since the seal
Today 6 Jul
A new column users.marketing_consent appeared.
Regixo spotted it on the last scan. Open the dataset to check whether it holds personal data.
A core field changed on Marketing & email outreach — dataCategories. affects the record
contact, account→contact, account, consent
This alters what your signed record covers, so the change is marked for re-sign.
1 Mar 2026 1 Mar
Initial scan — the baseline.
63 datasets, 398 columns across 10 sources
Your starting point — every later change on this page is measured against this first scan.
The change and its consequence sit together: what moved, and the one activity whose
signature it unsettled.
5
The compliance lead re-signs compliance
The approver clicks Review & re-sign → and lands on Before you sign —
the page that stands between them and something irreversible. It is honest that this is a re-seal:
You are RE-sealing, followed by every activity that changed since the last seal and the fields
that moved, and the reminder that the previous seal stays in the version history. It also states
exactly how strong this signature is — open What kind of signature is this? and it says, in
order, that this is a simple electronic signature under eIDAS Art. 25(1) and not a
qualified one, that the time comes from the server's clock, and what an independent counter-stamp
would add. Any legal entry still blank is named here, because it will seal as an open gap — the
seal never confirms a legal entry for you. Then: 🔓 Sign & seal, or Go back and keep
reviewing.
Before you sign
You are about to sign and seal this record as dana@acme.eu (dana@acme.eu). This removes the DRAFT stamp and records a simple electronic signature (eIDAS Art. 25(1)) under your name.
What kind of signature is this?
- It is a simple electronic signature. Under EU law (eIDAS Art. 25(1)) it cannot be denied legal effect, or refused as evidence, solely because it is electronic. It is not a qualified electronic signature — that needs a government-issued certificate Regixo does not require.
- The time comes from our server's clock. That records when you signed. On its own it is not an independent timestamp.
- An independent counter-stamp adds more. Where one is configured, a third-party timestamp authority stamps the signature, proving it existed no later than that moment — still not an eIDAS qualified timestamp, but no longer resting on our clock alone. Your sealed record names which one it carries.
You are RE-sealing — 1 activity changed since the seal of 2026-03-14:
- Marketing & email outreach — personal data categories
The previous seal stays in the version history; re-signing seals the record as it stands now.
Regixo could suggest a value for every legal entry — review them before you seal; they record as suggestions for your confirmation, and the seal never confirms a legal entry for you (a person must).
Nothing new leaves your systems when you sign — signing only seals what you already see.
The signer sees exactly what changed before committing — no blind re-seal. The signing
act, and its timestamp, stay a human decision.
6
The trail stays intact
Re-signing does not erase the past. Version history is a table on the record —
one row per seal, newest first, marked current — and every row carries the four things an
auditor asks for: when it was Sealed, who Signed it, its Attestation id, and the
Files that seal covers. Each version downloads with its own attestation, and between any
two rows there is a what changed link. Nothing is overwritten: the old seal is still there,
still downloadable, still checkable offline with
verify-attestation.mjs.Record of Processing Activities — OFFICIAL
Version history
Every seal is kept — immutable versioning is part of the official record. Each version downloads with its own attestation; check any of them offline with verify-attestation.mjs.
| Sealed | Signed by | Attestation | Files |
|---|---|---|---|
| 2026-03-14 current | dana@acme.eu | att_bbbbbbbbbbbbbbbbbbbbbbbb | PDF · JSON · seal · what changed |
| 2025-11-02 | dana@acme.eu | att_aaaaaaaaaaaaaaaaaaaaaaaa | PDF · JSON · seal |
↓ current record (JSON) · ↓ current seal (attestation.json) · ↓ offline verifier · day-to-day changes →
One continuous, dated trail. That continuity is what makes the record defensible
months later.
The loop, closed
A migration moved a legal field; a scheduled check caught it; the portal surfaced it; a human re-signed;
the old seal was kept. That is the whole keep-current-and-defensible cycle — run once, then repeated
every time the data drifts.
What does and doesn't trigger a re-sign
A metadata-only change — a new non-legal column, a row-count estimate moving — is not a
re-sign. The signature stands; the change just lands in the change log. A re-sign is triggered only when
one of the seven core fields of a signed activity moves: purpose, lawful basis,
retention, data categories, data subjects, recipients, and transfers
outside the EU. The
exit 3 signal is --ci only — plain regixo
watch keeps the historic 0/1 exit codes. And whatever moves,
Regixo never re-signs for you — the seal is always a human act.