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. This page covers who does what — the two users, the four per-record roles, the DORA teams, how people sign in, the machine tokens that keep a hosted record fed, and the governance practices that keep an org catalog trustworthy over time.

Two users, two jobs

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).

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.

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.

DORA teams

About twelve of DORA's fifteen tables are vendor and contract facts that no data catalog holds — 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.

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.

Machine tokens

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 mints one from the “Connect a machine” card (or the CLI); it is shown once, as an env var to set:

REGIXO_SYNC_TOKEN=rgx_sync_9f2c…

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.

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 change classifications and the glossary. Reclassifying a column or confirming a glossary term is mechanical, but it shapes what the record says. Name the people who own those calls, the same way you'd name a code owner.
• 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.