one agent. many jurisdictions.

The cross-border compliance reality.

Multi-jurisdictional AI compliance is not a thought experiment. It is the default state of any agent operating on the open internet in 2026. Three scenarios.

One. A German consumer-credit lender runs a B2C lending agent on US-hosted infra. The agent serves German residents primarily and a small UK book opportunistically. On a single lending decision, the EU AI Act applies because the lender is established in the Union and the agent makes a creditworthiness assessment, an Annex III §5(b) high-risk use case. FCA Consumer Duty Principle 12 applies to the UK customers on the same agent. GDPR applies to every personal-data field. Three regulators, one decision.

Two. A Singapore healthcare AI clinic exposes a triage agent to Indian patients through a partner telemedicine app. MAS FEAT applies to the clinic as a financial-services-adjacent operator. The India DPDP Act 2023 applies because the patient is a Data Principal in India. The clinic does not have a presence in India. The DPDP Section 16 extra-territorial reach attaches anyway. Two regulators, one action.

Three. A New York fintech with a Frankfurt office runs a single underwriting agent. NYDFS Part 500 applies because the firm is a Covered Entity under § 500.1(e). The EU AI Act applies because the Frankfurt office is established in the Union. FCA Consumer Duty applies because the firm has UK customers on the same agent. The CISO signs one set of certifications. The Frankfurt notified body recognises another. The FCA Senior Manager recognises a third.

In each case, the regulator wants evidence she can recognise on first read. Specific clause citations, specific authorization records, specific timestamps not under the firm's own control. The shape of the evidence is regime-specific. The shape of the underlying agent action is not.

The obligation graph, where it collapses.

The way Warrant collapses N regimes into one mapping pass is the obligation graph. A directed graph. Nodes are obligations at the sub-clause level, not the regulation level. Edges are equivalence and specialisation relationships drawn by hand, then audited.

An equivalence edge says two sub-clauses ask for the same evidence field. A specialisation edge says one sub-clause is a stricter case of the other. The classic example. EU AI Act Article 12(1) is general:

NYDFS § 500.6(a)(2) is a specialisation, narrower in scope (financial services), stricter in framing (Cybersecurity Events specifically):

The graph encodes that the second specialises the first. An evidence field that satisfies § 500.6(a)(2), in particular the per-action authorization record with its detection-and-response semantics, also satisfies Article 12(1) for the same action. The reverse is not true. An Article 12(1) lifetime-log that does not detect Cybersecurity Events does not satisfy § 500.6(a)(2).

Compress the nine regimes through this graph and a 9-by-N integration problem becomes a single corpus of around 340 distinct evidence-relevant obligations. The nine: EU AI Act, FCA Consumer Duty (PS22/9), NYDFS Part 500, Federal Reserve SR 26-2, RBI FREE-AI (Framework for Responsible and Ethical Enablement of AI), SEBI Retail Algorithmic Trading Framework, India DPDP Act 2023, MAS FEAT, and the SEBI Investment Adviser regime.

The mapping pass, one lookup per jurisdiction.

The mapping pass is one obligation lookup per declared jurisdiction. Not nine. Not one per regime per action. The declared jurisdictional set is produced earlier from the trace's customer-resident, infra-host, and product-domain signals. Per-jurisdiction obligation lookup fans out in parallel, each lookup reads only that jurisdiction's obligation subset, and the merged result is the trace's citation list. The records come back in the canonical citation schema, grounded in the trace.

Output volume scales linearly with declared jurisdictions, not exponentially. A trace declared US-only returns roughly 30 to 60 obligations. A trace declared US plus EU plus UK returns roughly 80 to 130. A trace declared all six in-corpus jurisdictions returns roughly 220 to 340. The graph keeps the count bounded, because equivalence edges deduplicate and specialisation edges hierarchically nest.

The citation schema is the same shape every page on this site uses, every PDF body carries, and every eval compares against. Six fields. Two paired axes: snake_case identifiers for code and package matching, court-document display strings for the auditor's eye.

# api/data/citation.py
class ObligationCitation(BaseModel):
    framework_id: str             # snake_case: "eu_ai_act" | "nydfs_part_500" | "fca_consumer_duty" | "sr_11_7"
    framework_display: str        # court-document: "EU AI Act" | "23 NYCRR Part 500" | "FCA Consumer Duty" | "SR 11-7"
    sub_clause_id: str            # canonical short form: "art_12.par_1" | "500.6.a.2" | "principle_12" | "section_iii_b"
    sub_clause_display: str       # court-document: "Art. 12(1)" | "§ 500.6(a)(2)" | "Principle 12" | "§ III.B"
    canonical_text: str           # verbatim regulator text
    canonical_source_url: HttpUrl # EUR-Lex CELEX:32024R1689, dfs.ny.gov, fca.org.uk, ...

class Edge(BaseModel):
    src: str                      # framework_id + "." + sub_clause_id
    dst: str                      # framework_id + "." + sub_clause_id
    kind: Literal["equivalent", "specialises", "contradicts"]
    rationale: str                # human-authored, audited quarterly
    audited_by: str               # reviewer initials + date

The split is deliberate. The snake_case framework_id and sub_clause_id are what code reads, what the eval compares, and what the package field-matches against. The framework_display and sub_clause_display are what renders into the UI, the PDF body, the blog citations, and any regulator-facing surface. Both forms are stored on every record. The PDF carries both, so the record can be matched by id without parsing display text — and the package stays independently verifiable without contacting Warrant.

contradicts is a first-class edge kind. Where two obligations cannot both be satisfied by the same field, the graph holds the conflict explicitly so the mapping emits both, and the rendered evidence package surfaces both. We do not silently choose one.

The table that does not collapse.

Be honest about what does not share. Three areas where collapsing would be a category error.

Notification windows. Time-bound obligations are rarely interchangeable. NYDFS § 500.17(a)(1) requires notice within 72 hours of a Cybersecurity Event. The FCA does not impose a 72-hour rule under Consumer Duty. The SEBI Retail Algorithmic Trading Framework requires a 6-hour reporting window for specific algo-trading incidents. A single agent action that triggers all three regimes will produce three different notification clocks. The PDF prints the three clocks side by side and starts each clock from the regime-defined trigger event. We do not pick the strictest and pretend it covers all three.

Executive sign-off framing. Who signs is regime-specific. NYDFS § 500.17(b)(2) requires the highest-ranking executive of the Covered Entity to co-sign the annual material-compliance certification. The EU AI Act has no equivalent personal sign-off. Article 43 instead requires conformity assessment by a notified body or via internal control. SEBI Retail Algorithmic Trading Framework names the principal officer. SR 26-2 requires senior-management sign-off but does not name the title. These are different procedural shapes. Mapping them to a single "signer" field would be wrong. The PDF carries a Sign-Off section with a row per applicable regime.

Definition of personal data. The phrase is the same across regimes. The definition is not. GDPR Article 4(1) defines "personal data" as any information relating to an identified or identifiable natural person. NYDFS § 500.1(k) defines Nonpublic Information across three prongs, including business information whose tampering would cause material adverse impact. India DPDP defines "Digital Personal Data" with its own carve-outs and the broader Data Principal/Data Fiduciary architecture. The three sets overlap. None is identical. A trace that touches a customer's name plus account number is in scope under all three, but the evidence field that satisfies each is shaped differently. The PDF prints the regime's definition before the obligation, so a regulator reading the document never has to import another document to know what "personal data" means in this context.

A worked example, UK customer, US infra.

A US-incorporated wealth platform runs an AI advisory agent on US infra. The agent recommends a structured product to a UK-resident retail customer. Walk the evidence the trace yields.

Jurisdiction. The trace yields the declared jurisdictional set: {UK, US_NY, EU}. UK because the customer is UK-resident. US_NY because the platform is a NY-licensed entity. EU because the trace's data-processor chain includes a Frankfurt-resident vector store the agent retrieved from. Domain: investment-advisory. Risk tier: high (Annex III §5(b) creditworthiness adjacent, plus FCA retail).

Actions. The trace yields a flat list of action objects. The recommend action carries the specific structured product (CUSIP, issuer, capital-protection level), the customer context (age band, declared risk tolerance, investable assets band), and the evidence basis (which factors the agent weighed and the source documents it retrieved).

Authorization. Each action carries a per-action authorization record. within_purpose: true (advisory action against an advisory agent). preconditions_met: true (FCA suitability assessment present). human_oversight_appropriate: false-flag (the trace lacks a senior-manager attestation row, surfaced as a Consumer Duty Principle 12 gap). reversible: true (no order placed yet). justification: free-text grounded in the trace.

Obligations. The mapping yields the obligation tuples. For this single recommend action, fourteen obligations are returned, citing four distinct regimes.

The remaining six rows cover GDPR Article 6 lawful basis, GDPR Article 22 automated-decision rights, FCA SYSC senior-management responsibility, EU AI Act Article 13 transparency, EU AI Act Article 26 deployer obligations, and the SR 26-2 expectation on model documentation. The PDF prints all fourteen. The five sections are Header, Action chain, Authorization assessment, Obligation map, and Conflicts plus Sign-Off. Each row carries the verbatim regulator text excerpt, and each row is a record mapped to a specific EU AI Act obligation. The whole package is independently verifiable without contacting Warrant, and evidence carries the region it was produced in.

Where it would be wrong to collapse.

The conformity assessment process under EU AI Act Article 43 is a procedural artefact involving a notified body or internal control depending on the Annex III category. The senior manager attestation under NYDFS § 500.17(b)(2) is a personal certification by the highest-ranking executive of the Covered Entity, accompanied by the CISO. The principal officer obligations under the SEBI Retail Algorithmic Trading Framework are operational responsibilities tied to a SEBI-registered intermediary. Three obligations, three procedural worlds.

It would be wrong to print one row that says "executive attestation" and pretend the three are interchangeable. A regulator who reads such a row knows immediately the document was generated by something that does not understand its own regime. The Warrant PDF prints them separately. The collapsing the graph does is principled: it collapses where regulators write equivalent or specialising obligations. It does not collapse procedural shapes regulators have deliberately kept distinct.

How the corpus stays current.

The graph is only as useful as the corpus is current. Three operational pieces.

Canonical source URL per regime. Every obligation node carries the canonical URL the text excerpt was drawn from. EUR-Lex CELEX:32024R1689 for the EU AI Act. dfs.ny.gov for the NYDFS Part 500 PDF. fca.org.uk for the Consumer Duty Policy Statement. federalreserve.gov for the SR 26-2 letter (URL filename SR2602.pdf). sebi.gov.in for the SEBI Retail Algorithmic Trading Framework. rbidocs.rbi.org.in for the RBI FREE-AI release. mas.gov.sg (with an Allen and Gledhill mirror as a fallback) for the MAS FEAT principles. meity.gov.in for the India DPDP Act 2023. There is no second-hand source in the corpus. Every excerpt is sourced from the regulator's own public URL or the regulator's published PDF.

Daily diff job. A scheduled job pulls each canonical URL, hashes the relevant section, and compares to the stored text_excerpt_hash. A change writes a row to the corpus changelog and pages the on-call corpus reviewer. A reviewer can either confirm the change is editorial (no semantic shift) or escalate to a corpus version bump.

# corpus-diff 2026-05-08T03:14:22Z
~ nydfs.part_500.500_17.a.1                # editorial: en-dash → en-dash unicode
~ sr_26_2.sec_iii.par_2.attest             # editorial: footnote renumber 12→13
! sebi.retail_algo.principal_officer        # SEMANTIC: scope expanded to all algo orders
+ rbi.free_ai.principle_7.subclause_b       # new: pages on-call
= eu_ai_act.art_12.par_1                    # unchanged

Eval suite re-runs on corpus change. Any corpus change runs the full citation-precision benchmark against a frozen set of 200 traces. The benchmark measures whether the cited sub-clause matches the obligation the trace actually triggers. A drop below the precision floor blocks the corpus version bump. The eval catches stale references the same day.

The corpus version id is printed on every PDF, which is independently verifiable without contacting Warrant. A regulator who picks up a Warrant evidence package from any of the customer-region stores can re-derive the corpus the package was evaluated against by reading the version id and pulling the matching corpus snapshot from the public mirror.

Globalisation made the regulator's job harder, not yours.

The regulator wants to know whether the AI behaved according to its lifetime obligations. EU AI Act Article 12(1) names this directly: logs over the lifetime of the system. Every other regime says the same in its own register. NYDFS § 500.6(a)(2) says it as cybersecurity-event audit trails. FCA Consumer Duty PS22/9 says it as good-outcomes evidence under Principle 12. RBI FREE-AI says it as responsible-and-ethical-enablement. MAS FEAT says it as Fairness, Ethics, Accountability, Transparency. SR 26-2 says it as senior-management-accountable model risk. The India DPDP Act 2023 names the Data Principal and the Data Fiduciary's lifetime obligations to that Principal.

The regimes ask the same underlying question. The boundary between an "EU agent" and a "US agent" and an "India agent" is mostly an artefact of where the user happens to be sitting. The agent is one system. Its lifetime is one stream of events. Globalisation made the regulator's coordination problem harder. The regulator did not stop wanting the same evidence. Warrant compresses the boundary into a single artefact a regulator in any of the six jurisdictions can pick up and read, independently verifiable without contacting Warrant.

One agent. Many jurisdictions. One PDF. Drop a trace at warrant.build/demo. Sample for the worked example at /samples/eu-fintech.pdf. Independently verifiable without contacting Warrant at /verify.

Questions a compliance officer asks first.