Operating cadence by role

A signed record is only worth the paper it seals if it still matches your data next month. Regixo turns that into a rhythm, not a project: data changes, the map catches up, the record re-drafts, a person re-signs what moved, and the licence renews once a year. This page gives each role its part of that rhythm — what to run, when, and where the human judgment stays.

The living-record loop, as a rhythm

The whole product is one loop that never really ends. Each turn has a named owner:

1. Data changes. A migration ships, a source is added, a table gains a column. — everyone who ships
2. The map catches up. A scheduled regixo watch re-scans metadata only, appends the change log, and re-drafts the RoPA (and the DORA register, if it is in scope). — engineer
3. The record refreshes. The draft you can read in the portal, and the artifacts you forward, reflect the new shape of the estate. — automatic, on each watch
4. Drift is flagged. When a core field of a signed activity moves, that activity — and only that one — is marked for re-signing. A metadata-only change leaves the signature standing. — engineer surfaces it, approver acts
5. A person re-signs. Re-signing is a human act in the portal. Regixo decides which activities are stale and shows the diff; it never re-seals for you. — compliance lead / approver
6. The licence renews. The record is a living document, so the licence is yearly. — compliance lead / billing owner

The calendar at a glance

Four roles keep the loop turning. Most weeks only the engineer touches it; the compliance side moves on a monthly and yearly beat.

Roles are a portal concept — preparers fill, approvers confirm and sign, admins run the account. See Roles & governance for who can do what.

Engineer — every sprint (the checklist)

The engineer owns the machine-side of the loop: keep the map true to the estate, and keep the plumbing that refreshes it running. Two concrete cadences — do the first every sprint, the second the moment a migration lands:

Each sprint — in order:

1. Let the scheduled regixo watch run (your CI step or cron line). Nothing to type if it is scheduled — just confirm the run is green.
2. Register any source that landed this sprint: regixo add <type> — it stores the env-var name only, then the next scan maps it.
3. Correct any wrong personal-data flag: regixo classify set, or the Map's Correct control. Mechanical only; it survives a re-scan.
4. Pull the team's fills home: regixo pull <claim-token> — a per-field merge of what the compliance team confirmed on the claim.

On a migration — the moment tables or columns change:

1. Re-scan now, don't wait for the schedule: regixo watch. It re-reads metadata only and diffs the new shape.
2. Read what moved: regixo log — the running change history.
3. If a signed activity's core field moved, that one activity is flagged for re-sign and the re-sign needed email fires to the approvers on its own — no message to send. If nothing signed moved, the change is just logged.

Each item below is the same in detail, with its owning how-to page.

Keep the scan scheduled

Make regixo watch a scheduled job — a CI step or a cron line — so the map never goes stale in silence. watch is one-shot by design: it checks once and exits, which is what makes it safe to schedule. The recipe and the exit-code contract are in Keep it current.

Add new sources as they land

regixo add <type> registers a database or SaaS — storing only the env-var name, never the secret. Then a scan brings its datasets onto the map. See Connect your sources.

Correct PII flags — mechanical only

When the classifier is wrong, fix it with regixo classify set or the Map's Correct control. This sets a column's personal-data flag — a mechanical fact — and never confirms a legal field. Corrections persist outside the snapshot, so a re-scan never wipes them. See Classify & correct.

Enrich so the map explains itself

Add the context a scan can't infer: regixo describe (dataset and column descriptions, deterministic and local), regixo glossary (business terms), and regixo lineage (cross-system flows a scanner can't see). All survive a re-scan. See Enrich & share.

Pull the team's work home

When the compliance team fills legal or DORA fields on the claim, regixo pull merges those fills back into your local store — a per-field diff, never a blind overwrite. A field the team confirmed is carried as confirmed; the pull only transports the human's decision, it never fabricates one. See Bring the team's work home.

Compliance lead / approver — monthly and yearly (the checklist)

The compliance owner does not watch a firehose. The job is to review what moved, and to re-sign only when the substance changed. You don't have to sit on the portal: the emails below bring you in exactly when a decision is needed.

The clicks, at a glance:

1. Monthly — open the record and read the What changed timeline. Metadata noise most months; the signature stands.
2. When the re-sign email arrives — open the diff behind the gold Review & re-sign → banner and re-run the attestation over the flagged activity (only that one, never the whole record).
3. Yearly — renew at Account → Billing → Renew via the Stripe Customer Portal; OFFICIAL comes straight back.

Each in detail:

Monthly — read the record and "What changed"

Open the record and the What changed timeline. It is a dated list of what moved in the map since you last looked. Most months it is metadata noise and the signature stands. A stale “last updated” time here is your cue that the engineer's scan has stopped running.

On drift — confirm and re-sign

When a core field of a signed activity moves, Regixo sends the “re-sign needed” email to the record's approvers and admins at the moment the drift is detected — on the scheduled watch or a machine push that finds the change — so the email and the gold Review & re-sign → banner arrive together. Open the diff, and an approver or admin re-runs the attestation over the changed record. Only the affected activity is flagged, never the whole record. The full flow is in Unlock, sign & maintain.

Watch for a stalled sync — the alert, and how to tune it

If a paired machine stops pushing re-scans, Regixo tells the humans on its own — two signals. (1) The claim page raises a missed-sync warning banner and writes an audit entry — always on, for everyone, once a paired machine goes silent past the grace window (7 days by default; change the window with REGIXO_SYNC_STALE_DAYS). (2) An email — “your hosted record stopped updating” — to the record's approvers and admins, on by default in the hosted portal; each person can turn it off in their notification preferences. You don't have to poll. When either fires, ask the engineering team to check the scheduled watch; a silently-stalled pipeline is the one way a record drifts without anyone noticing.

Yearly — renew the licence

The licence is a one-time yearly charge, not an auto-renewing subscription. Renew from Account → Billing via the Stripe Customer Portal. An expiry warning shows from 30 days out and the record stays fully OFFICIAL while it warns; on lapse the tenant drops to draft-only with a renewal banner and nothing is deleted.

Preparer and the DORA contributors

Two roles fill the fields a scanner can never know. They work on their own cadence — whenever the facts change — not on a calendar.

Preparer — the RoPA legal fields

When a new activity appears on the record, someone has to supply the fields a scan can't decide: purpose, lawful basis, retention, transfers, security measures. A preparer fills them; an approver confirms. A preparer's fill is a draft answer — it is not "confirmed" until an approver takes that legal judgment on. See Fill the RoPA.

Procurement / legal / ICT-risk — the DORA contract rows

The Register of Information's contract, vendor and function tables are facts about your suppliers, not your schema. Fill them with regixo dora import (a CSV per table) and regixo dora set (rule a provider in or out of scope), or in the claim cells in the portal. Ruling a provider in scope and marking a function critical are legal judgments — approver only. See Filling the tables.

Staleness — a warning, never a block

Regixo tracks how long it has been since each source was last scanned, and says so plainly. The thresholds are per source:

• At 30 days — the source is flagged as getting stale. A quiet warning.
• At 90 days — the warning goes loud. The map still renders; the record still stands.

These are warnings, not gates. A stale source never blocks a scan, a draft, or a signature — it just tells you the truth about how fresh the evidence is, so no one reads the record as more current than it is. The fix is always the same: re-scan the source (schedule it, or run regixo watch now).

What Regixo emails you

Regixo is quiet by design. It does not send a daily digest or a stream of nudges — it sends a short, fixed list of messages that each mark a real moment in the loop:

The lifecycle notices (expiring, expired, re-sign) and the stopped-updating alert are on by default and can each be silenced per person in notification preferences. Team invites and purchase confirmations are transactional and always send. Nothing here is a marketing drip.