Roles, ownership & governance

Regixo is built for two people who are rarely the same person: the engineer who installs it and the compliance lead who pays and signs. Governing a record is five concrete acts — know who does which job, assign the four per-record roles, change a role and confirm it took, invite a colleague and confirm the email went, and hand over a machine token safely. Each one below tells you the click or command, and how to check it actually happened.

Assign one team, all the way through (the worked example)

Before the reference, staff one record end to end so the roles are concrete. Aurelia Payments has claimed its record; here is who gets which role, and why:

The five sections below are that same set-up, walked in full — the decision inside each act, the click or command, and the honest way to confirm it landed.

Step 1 · Know who installs and who pays

The whole product is shaped around a hand-off, so the roles start there:

• The engineer installs. Free, no budget, no account. They run regixo start, correct mechanical flags, enrich the catalog and forward a draft. They hold the data access, not the legal duty.
• The compliance lead pays. They hold the budget and the legal duty. They claim the forwarded draft, fill the legal calls with their team, and unlock a signed OFFICIAL record (€6,000 RoPA · €12,000 RoPA + DORA · from €18,000 Enterprise).

Step 2 · Assign the four per-record roles

Every paid record has its own team. Roles are per record, and price never moves on how many people you add — there are no seat licences. An admin assigns each person one of four roles from the record's Team card:

Which role for whom — the walk

For each colleague, ask these in order and stop at the first “yes”:

Give the widest role each person actually needs, and no wider — a preparer who never signs should not be an approver. There are no seat limits, so add everyone who touches the record.

The rules that keep ownership sound:

• First verified login becomes admin. Whoever first signs in on a claim is that record's admin, and manages who else reads, fills and signs.
• Only approver or admin unlock or sign. A preparer can fill every field but never confirms a legal call — that stays a deliberate act by someone with the authority.
• No seat limits. Add the whole team; the price is fixed per tier, not per user.
• The last admin can't be demoted or removed. A record is never left without an owner. Handover means promote a successor to admin first, then step down.
• Removing a member ends their sessions immediately. Access stops the moment the role is taken away — not at the next login.

Step 3 · Change a role — and confirm it took

The signing power is the one that matters: only an approver or an admin can confirm a legal field or sign the record. A preparer can fill every field but never confirms — so the moment you let someone sign is a deliberate role change, not a default. Make it on the record's Team card: pick the person, choose the new role, and Save.

Check it took. A role change is not a quiet badge flip. On Save the portal returns an explicit “Saved” confirmation, the member's row shows the new role, and the change is written to the record's audit trail under who made it and when. If you do not see the confirmation, the change did not land — nothing was saved silently. Read the row and the audit entry, not just the colour of a tag, before you trust that someone can now sign.

DORA teams

13 of DORA's 15 tables are vendor and contract facts a data map cannot see — they live with the people who own the paperwork. In practice that is procurement (who the ICT third parties are and what they cost), legal (the contracts, terms and exit clauses) and ICT-risk (criticality, substitutability). Give those people preparer or approver roles so they can fill the needs-you tables directly. Two ways in:

• From the engineer's side — regixo dora import <table> <file.csv> to bulk-add rows, or regixo dora set <table> <rowKey> <field> <value> for one cell.
• From the claim side — a preparer fills the same cells in the portal, saved “provided by you”.

What the map auto-starts versus what a person supplies is set out in The DORA register.

Step 4 · Invite a colleague — and confirm the email went

To bring a new person onto the record, an admin adds them by email on the Team card, picks a role, and chooses Send invite. Adding a genuinely new member sends them one email — “You were added to a compliance record on Regixo” — with the claim link and a one-line summary of what each role can do. They open the link and sign in with that same address (Step 5 below covers the sign-in itself).

Check the email went. The durable truth is the roster: the moment you Save, the person's row appears with their role, and the add is written to the audit trail. The email is a courtesy on top of that — best-effort, so it can lag. Confirm it landed the honest way: the new row is in the roster, the add is in the audit log, and — the only real proof of delivery — the invitee tells you they got it. If they didn't, re-send from the Team card; the roster row stands either way.

How people sign in

Two paths to a verified identity, and Regixo records which one was used — honestly, as email-verified versus sso — because the assurance travels with a signature.

Magic link

The default that births the account. The claim page emails a one-time link — it works once, for 15 minutes, and shows a confirm page first (so a link-scanner can't consume it). Clicking through creates the user and a session. Assurance is recorded as email-verified.

Company SSO (OIDC)

A generic OpenID Connect client for Okta, Microsoft Entra and Google Workspace, configured per record by an admin:

say

“Require SSO for everyone on our Regixo portal account, using our Okta tenant.”

Copy

🔑Your agent fills in everything except the token — you put that in .env yourself.

Show the commandHide the commandShow the sentenceHide the sentence

run

$ regixo admin sso set --claim <clm_…> \
    --issuer https://your-org.okta.com \
    --client-id <id> --client-secret-env OKTA_SECRET --require

The client secret is passed by env-var name and stored sealed — never printed. --require disables magic-link sign-in for that record, so everyone comes through your IdP. Assurance is recorded as sso.

Step 5 · Mint and hand over a machine token safely

A hosted record stays current by having a machine push refreshed metadata. That machine authenticates with a sync token, not a person's login. An admin generates one from the “Connect a machine” card on the claim page (its own annex, beside “Your team”); the portal shows it once, right there, as the env var to set — that one-time reveal is your “generated” confirmation. Copy it now; you cannot see it again.

REGIXO_SYNC_TOKEN=rgx_sync_9f2c…

It is a secret, so it moves the way every secret does:

1. Generate it where it will run, if you can. The engineer who owns the CI runner or the scheduled machine is best placed to generate the token and drop it straight into that machine's environment — the token never has to travel.
2. If someone else must hand it over, use a password manager. Put the one-time value in a shared vault entry and give the engineer access to that entry. Never paste a token into a chat message or an email — send the vault entry, not the secret.
3. The engineer sets it as REGIXO_SYNC_TOKEN. On the machine, in .env (or a CI secret), never in regixo.yml. A paired regixo watch then pushes refreshed metadata on its schedule.

Check it landed. The admin lists the record's tokens (regixo admin machines, or the “Connect a machine” card) and sees the new machine; after the engineer's first scheduled scan, the record's “what changed” feed updates — proof the pairing works, with no one re-forwarding a draft.

Company-owned, not personal

It belongs to the record, not to whoever made it, so it survives staff turnover. It is not a login and not the licence key.

Ingest-only

It can push metadata-only drafts and nothing else — it can never unlock, sign or export. A leaked token can add to the map; it can't touch the legal record.

Revocable per machine

List and revoke tokens individually (regixo admin machines <token> / admin machine rm). Kill one CI runner's token without disturbing the others. Those two, and every other regixo admin subcommand, are listed in the operator surface.

Governance practice

Roles decide who can act; governance is the org agreement on how they do. A few practices keep an org catalog defensible:

• Decide who may reclassify a column, and who may assert a data flow. Both are mechanical calls anyone may make — and both change your record: the categories of personal data are built from the flags, and a cross-system flow is suggested as a recipient under Art. 30(1)(c) for your compliance team to confirm. Name the people who own them, the same way you'd name a code owner. (Descriptions and glossary terms change nothing in the record, so they need care, not control — see what each one changes.)
• Sign off deliberately. Only an approver or admin confirms a legal field or signs — keep that a reviewed act, and let preparers stage the fills for them.
• Share enrichment through version control. regixo catalog export writes a committable regixo-catalog.json (descriptions, glossary, asserted lineage, classification overrides). regixo catalog import is merge-only and never downgrades a confirmed answer. Commit it and your team standard is reviewable in a pull request.
• Treat pii.extraPatterns / pii.allowList as org PII policy. extraPatterns teaches the classifier your own personal-data column names; allowList suppresses known false positives. Both live in the committed regixo.yml, so the policy is one file the whole org shares.
• Commit regixo.yml — settings, never secrets. It carries sources (by env-var name), intent, DORA scope, the controller identity and PII policy. Reviewing it in git is how a team keeps the estate honest.