How a regulator becomes a regulator.

The principle is the rubric.

Anyone can spoof an email domain. The strength of a regulator's binding to the Warrant audit path is exactly as strong as the weakest step in the onboarding rubric. The team treats this as a hard floor.

The rubric exists for three reasons:

• Identity strength. The signed letter + callback combination resists impersonation at the level the regulator's own legal team operates at — no higher, no lower.
• Liability. The signed letter is the artefact attorneys will look at if the binding is ever disputed. It is filed, stored, and tamper-evidently pinned in the Postgres identity record so a regulator cannot later claim "I did not authorise this access."
• Compliance hook. EU AI Act Article 41 (3) and the comparable supervisory-authority sections in SEBI, RBI FREE-AI, NYDFS Part 500, and MAS AIRM all assume a known counterparty. Warrant's rubric is what makes the counterparty knowable.

What the regulator's legal team sends.

The team accepts a single PDF on the regulator's letterhead, signed by an authorised legal officer. The minimum content set is fixed; anything missing means the package is returned without progress and a fresh letter is required.

• L1 Letterhead identifying the regulator (legal entity name + statutory authority reference).
• L2 ISO 3166-1 alpha-2 jurisdiction code (or the multi-region form like US-NY) the binding will be scoped to. One letter = one jurisdiction.
• L3 Name + title of the legal officer signing the letter.
• L4 Name + title of the technical point-of-contact who will receive the bound token. Cannot be the same person as L3.
• L5 A statement that the regulator authorises Warrant Labs to bind the named technical contact to the jurisdiction code from L2.
• L6 The regulator's published switchboard number (no direct extensions). This is the number the team will dial back; do not provide a number the L4 contact controls.
• L7 Signature, date, and an authentication element appropriate to the jurisdiction (wet-ink, qualified electronic signature, seal — the regulator's choice).

How the letter is stored.

The PDF is reduced to a tamper-evident fingerprint that lands in the letter_fingerprint column of the regulator identity record at onboarding completion. The PDF itself is stored encrypted at rest under the WLI custody envelope; the fingerprint is the public-record pointer regulators can use to confirm the team is holding the same letter they sent — independently, without contacting Warrant.

The phone call.

A Warrant Labs maintainer dials the L6 switchboard within five business days of receiving the letter. The receptionist is asked to connect to the L3 legal officer by name and title, not to the L4 technical contact. The script below is the version on the maintainer's call sheet.

CALLBACK SCRIPT — v0.1

Maintainer: "This is [name] from Warrant Labs returning the
            signed letter dated [DATE] received from your office.
            May I speak with [L3 NAME], [L3 TITLE]?"

[connected to L3]

Maintainer: "I am calling to confirm three details from the
            letter before we bind your nominated technical
            contact to the Warrant audit path.

            First — the letter authorises us to bind one technical
            contact named [L4 NAME], [L4 TITLE]. Can you confirm
            that?

            Second — the binding will be scoped to the jurisdiction
            code [L2 CODE], and to that code only. Cross-jurisdiction
            access requires a separate letter. Can you confirm that?

            Third — once the binding is active, your technical contact
            will receive a sealed envelope at your registered office
            with the activation token. The token will not be sent
            by email or any electronic channel. Can you confirm
            the registered office address is [from public registry]?"

[Three yes answers]

Maintainer: "Thank you. I will close the call here and complete
            the binding within two business days. If you receive
            any communication from someone claiming to be Warrant
            Labs requesting credentials, treat it as fraudulent
            and contact us at the address printed on your copy
            of the letter."

[disconnect]

If any of the three confirmations is missing, ambiguous, or comes from a person who did not sign the letter, the maintainer ends the call and the package is returned without progress. The team logs the disposition in the operator runbook either way.

The maintainer records the date and timestamp of the successful callback in callback_verified_at. That timestamp is the moment the identity moves from pending to active in the Postgres state.

What changes in the database.

The team operates against the regulator_identities table defined in migration 0005. One row per legal entity per jurisdiction. The columns the rubric drives:

• jurisdiction — from L2.
• legal_entity_name — from L1.
• letter_fingerprint — the tamper-evident pointer to the signed letter, computed at receipt.
• callback_verified_at — set at the moment the callback completes.
• status — pending at letter receipt; flipped to active on callback completion; flipped to revoked if and only if the regulator's legal team sends a follow-up revocation letter under the same rubric.
• last_attested_by — the maintainer who ran the rubric.

Row-level security on the table is configured by migration 0005 (PRE-C.1). The warrant_regulator role only sees rows where status = 'active' AND the row's jurisdiction matches the calling session's set jurisdiction. Pending and revoked rows are invisible to regulator sessions, which is intentional — a regulator in onboarding should not be able to query themselves.

What the regulator's technical contact receives.

Once the identity is active, the team issues a jurisdiction-scoped activation token defined in PRE-C.5. The token carries a scope claim of the form regulator:read:jurisdiction/{code}, so a regulator's access is bound to exactly one jurisdiction. The token is sealed in tamper-evident packaging and couriered to the regulator's registered office named on the letter. It is not sent by email.

The technical contact uses the token to call GET /regulator/aggregate?jurisdiction={code}. The endpoint returns 403 if the token's scope does not match the queried jurisdiction; it returns 401 if the token is not present, expired, or revoked. Either response is recorded against the bound identity in the append-only audit log (PRE-C.6).

Rotation.

Tokens have an explicit expiry of twelve months from issuance. Rotation runs the same rubric in compressed form: a fresh signed letter referencing the prior letter's tamper-evident fingerprint, and a confirmation callback. The team will not issue a renewal without the rubric.

Failure modes the team commits to handling.

• The letter is for a jurisdiction not in the active corpus. The team returns the letter with the list of jurisdictions Warrant currently maps. The regulator can request corpus extension separately; corpus changes follow a different review path described in Deployment Standard §"Corpus pinning".
• The callback connects but the L3 officer is no longer at the regulator. The team requests a fresh letter signed by the current officer. The team does not accept a verbal substitution.
• The bound technical contact leaves the regulator. The regulator's legal team sends a revocation letter under the same rubric naming the prior token by its issued identifier. The token's status flips to revoked and a fresh letter is required for any replacement contact.
• A token is suspected compromised. The technical contact reports the incident on the regulator's published channel. The team verifies the report via the L3 callback path, revokes the token immediately on confirmation, and issues a replacement under the standard rubric.
• The regulator asks for a copy of their own audit log. The bound technical contact calls GET /regulator/audit-log with their token. The endpoint returns the regulator's own access history scoped to their jurisdiction; the entries are tamper-evident and independently verifiable per PRE-C.6, so a Warrant-Labs-internal compromise cannot rewrite the history.

How to reach the team.

Regulator onboarding correspondence goes to [email protected]. Legal teams may also send paper to the registered office published in the Warrant Labs corporate registry filing — the team commits to a five-business-day response window from receipt of a compliant letter.

Operator-facing technical questions go to [email protected]; please do not send onboarding letters there.