Unlock, sign & maintain

Free gives you the whole map and a DRAFT record — forever. Paid unlocks the defensible one: the DRAFT stamp comes off, the record is signed under a named person, and it is kept current. This page covers what it costs, what signing actually is, what OFFICIAL adds, and how the seal stays honest over time.

What it costs

Pricing is published, self-serve, and all-in — one yearly charge, no setup fee. The plan is worked out from two answers at unlock, never guessed from your scanned data:

• How many staff? — up to 50 · 51–250 · more than 250.
• A regulated financial firm? — authorised or registered with a financial regulator (that is who DORA applies to). Most unregulated startups answer no.

The €6,000 and €12,000 tiers close with a card, no salesperson. More than 250 staff routes to the Enterprise conversation — still a published floor price, invoiced, never "ask us". You manage the subscription later from Account → Billing.

Before you sign: name the controller

An Article 30 record is the controller's record. Regixo refuses to seal one whose controller is unnamed — an official document with no responsible organisation is indefensible. The refusal is the coded error CONTROLLER_REQUIRED, raised before any signing happens.

Supply the registered legal name once, either way:

regixo.yml — the engineer

controller: { name: "Northwind Data BV", contact: "dpo@northwind.example" } — headless, committed with the config.

the claim page — the compliance team

Fill the organisation field on the record; it is persisted before the seal step opens.

What signing is

Signing produces a simple electronic signature over the exact bytes of the record. Regixo serialises the official record, takes its SHA-256, and signs that hash with a dedicated Ed25519 attestation key — separate from any licence key. The signing timestamp is set by the server and is immutable; it is never taken from the client.

The seal also states how the signer was identified. One of three assurance levels is recorded, and the artifact never overstates it:

sso

A real authenticated session through the organisation's single sign-on. The strongest level.

email-verified

A magic-link sign-in proved control of the email address (the account layer's default).

env-declared

An identity declared at unlock via env var — marked non-production on the artifact, since no one verified it. Fine for a dry run, not for a filing.

The signed bytes also bind the signer's organisation and role, so the seal proves "an authorised officer of <organisation>", not just a verified inbox. The signer therefore appears in full capacity — name, role, organisation — wherever the signature is shown.

What OFFICIAL adds over DRAFT

The record body is the same shared renderer in both states — OFFICIAL is a superset of the DRAFT, never a thinner copy. What changes is the evidence around it:

• The DRAFT watermark comes off, replaced by a running ● OFFICIAL — ATTESTED mark on every page.
• A seal card lays out the signature facts (below).
• A standalone offline verifier (verify-attestation.mjs) ships next to the artifact, plus ATTESTATION_KEYS.md in the public repo — so anyone can check the seal with no Regixo server in the loop.
• Every signature seals an immutable snapshot; the change log and version history keep the diffs.

The seal card carries these rows, each stating exactly what it is:

The Content seal line under Technical details is the SHA-256 of the file a verifier can recompute — flip a single byte and the check fails. The When row is honest about what backs the time today; see What is not built yet.

The green band above reads “✓ Audit-ready · sealed <date>” only when every legal call has been confirmed. If any are still open, the band says so instead — “✓ Sealed · <date> — N legal calls below still need confirming” — and the card adds a What’s still left for you row. A seal records who signed and freezes the bytes; it never confirms a legal call on your behalf, so it will not claim a readiness the record itself denies.

Unlock — the command that flips DRAFT → official

In the portal the compliance team answers the two questions, pays, and signs — that flips the record to OFFICIAL. On the command line the same licence activation is regixo verify (paid): it validates the licence for the tenant and enables the sealing path.

The four steps sit in a block at the foot of the claimed record. On the record below the licence is already paid, so step 2 reads nothing to choose or pay; on an unlicensed record that step is where you answer the two questions and the published price appears.

$ export REGIXO_LICENCE_KEY='rgx_live_…'
$ regixo verify
$ regixo seal pull <claimToken>

$ export REGIXO_LICENCE_KEY='rgx_live_…'
$ regixo verify

The seal is produced on the machine that holds the record. The engineer brings the sealed copy home with regixo seal pull, so the OFFICIAL artifact lives next to the source it describes:

$ regixo seal pull <claimToken>

The forker's copy has no regixo verify to unlock — sealing lives in the private layer and was never in the public code. Gating is the absence of code, not a switch.

Re-sign when a core field moves

The record keeps changing as your data does. A signature does not silently follow it. When regixo watch re-scans and a core field of a signed activity moves, that activity is flagged as needing re-signing — and only that one:

Renew each year

The licence is yearly — annual renewal is the model, because the record is a living document, not a one-time file. An expiry warning shows from 30 days out; the record stays fully OFFICIAL while it warns. On lapse the tenant flips back to draft-only — no data is deleted — with a renewal banner.

Renew from Account → Billing. For a regulated entity the DORA register carries a hard annual deadline, so the yearly cadence is not optional there.

The evidence pack

The defensible deliverable a compliance team can put in front of an auditor is the record plus its proof. Its parts:

• Official record (PDF) — the sealed Article 30 document, no DRAFT stamp.
• Source attestations — each mechanical field traced to the system it came from, as of a date.
• Append-only change log — every change since the first draft.
• Immutable snapshots — one per signature.
• Machine-readable bundle — the record as data; for DORA, the xBRL-CSV package.
• Attestation public key + the offline verifier — plus printed verification instructions in the PDF.

Anyone holding the exported folder can check the seal without Regixo — run the verifier next to attestation.json:

$ node verify-attestation.mjs

Cross-check the key against ATTESTATION_KEYS.md in the public Regixo repository. The evidence is designed to outlive the vendor.

What is not built yet