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 reaches the lender because it is established in the Union and the agent makes a creditworthiness assessment, an Annex III §5(b) high-risk use case. Read the calendar with it. The Article 6(2) and Annex III high-risk stack — Articles 12 to 15 and the Annex IV file — applies from 2 December 2027, deferred from 2 August 2026 by Article 1(40)(b) of Regulation (EU) 2026/1744 (the Digital Omnibus on AI, OJ L of 24 July 2026, in force 27 July 2026); the Annex I embedded route applies from 2 August 2028, subject to Article 2(13), inserted by Article 1(3) of the same Regulation, which permits limitation where sectoral law provides equivalent or higher protection. Its own predecessor limb was 2 August 2027, not 2 August 2026 — the two Annexes ran on different clocks before the amendment and they still do. What binds this lender in 2026 is the Article 50 transparency layer, which sits in Chapter IV, was not deferred, and applies from 2 August 2026. 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 — on three different clocks.

Two. An Indian broker runs an order-routing agent for retail clients on infrastructure hosted outside India. SEBI's algorithmic-trading rules apply to the order flow. The Digital Personal Data Protection Act 2023 applies because the client is a Data Principal in India, and it reaches the operator wherever the infrastructure sits. 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.

Where the obligations collapse into one field.

Start with what the corpus is, because the reasoning that follows is a model applied to it and not a structure stored inside it. api/data/regulations.json is a flat map: regime id to regime record, each regime record holding a sub_clauses array. A sub-clause carries six keys on every one of the 223 rows — id, citation_text, parent_obligation, regulator_text_url, regulator_text_sha256, summary — plus an optional seventh, attestable, present on 65 of them. parent_obligation groups sub-clauses within one regime. There are no cross-regime edges in the file of any kind: no equivalence edge, no specialisation edge, no contradiction edge, no stored rationale, no reviewer initials. Nothing in the next three paragraphs is a data structure a reader could query.

What the overlap actually is, then, is a reasoning rule, and the place it lands is the obligation-mapping prompt rather than a graph traversal. Two sub-clauses are equivalent when they ask for the same evidence field. One specialises the other when it is a stricter case of it. 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 second specialises the first. An evidence field written against § 500.6(a)(2), in particular the per-action authorization record with its detection-and-response semantics, also speaks to Article 12(1) for the same action. The reverse does not hold: an Article 12(1) lifetime-log that does not detect Cybersecurity Events does not answer § 500.6(a)(2). Read that as a statement about the two obligations, not as a stored fact, and not as something a package asserts: the obligation corpus carries no § 500.6 sub-clause, so a package reports NYDFS Part 500 as classified and in scope, not evaluated, and the § 500.6(a)(2) reading here is Warrant's, drawn from the regulation. Nothing in the corpus records the relationship. It shows up in the output because both sub-clauses were rendered into the same mapping call and the assessment cited both against the same action — which is also why the relationship has to be re-derived on every run rather than looked up.

Compress the regimes that way and an N-by-M integration problem becomes one corpus. As at digest 6871ee8b that corpus holds 20 regimes, 223 cited sub-clauses, 117 distinct regime-and-obligation groupings and 10 jurisdiction codes, with 47 sub-clauses marked attestable. Warrant maps agent actions to publicly citable regulation, and labels each source for the status it actually has rather than counting them all as law. Binding and in force: the EU AI Act (Articles 12, 13, 14, 15, 50 and Annex IV), the UK FCA Consumer Duty, NYDFS Part 500, and SEBI's algorithmic-trading rules. Enacted but not yet operative: India's DPDP Act 2023, whose substantive duties await notified rules. Supervisory guidance rather than an enforceable standard: US Federal Reserve SR 26-2 — and its footnote 3 places generative and agentic AI outside its scope, so an agentic trace maps to it as governance design, never as a compliance requirement. A committee report rather than adopted regulation: the RBI's FREE-AI framework. Voluntary: NIST AI RMF. Every citation resolves to text on the issuer's own domain, and any reviewer can open it. We do not map paywalled standards, superseded guidance as though current, draft consultations as though final, or repealed statutes.

The mapping pass, one filter and one call.

The mapping pass is one call, not a fan-out. There is no per-jurisdiction parallel lookup and no per-regime lookup. The pass filters the corpus once, renders the surviving sub-clauses into the obligation-mapping prompt, and makes a single request.

Which regimes survive the filter is decided by the corpus, not by the model. Each regime record declares applies_to_jurisdictions and applies_to_domains; the earlier classification stage supplies domain, jurisdictions and risk_tier, which are closed vocabularies it is reliable at, and the corpus decides the rest. That boundary is deliberate twice over. The model's own regime strings are prose — "EU AI Act Article 12" — so they would not resolve against corpus ids anyway; and letting the model choose its regimes would let it choose which obligations it is measured against. One consequence worth naming: the signed package has a classification.regimes array in its schema, and production leaves it empty, so the regime set a package covers is readable from its obligation rows and its coverage_by_regime map, not from that field.

Output volume is bounded above by the corpus rather than by the number of regimes a customer operates under: 223 cited sub-clauses is the hard ceiling for a trace that draws every regime in the corpus, and in practice the filter cuts that to the applicable subset before anything is mapped. What the reader gets is two shapes, and they are not the same shape — the corpus record in the repo, and the obligation row inside the signed package.

# 1 · corpus record, api/data/regulations.json. six keys, plus
#     an optional attestable flag on 65 of the 223 rows.
{
  "id": "eu_ai_act_art_12.1",
  "citation_text": "Article 12(1)",
  "parent_obligation": "automatic_logging",
  "regulator_text_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689",
  "regulator_text_sha256": null,   # null on 215 of 223 sub-clauses
  "summary": "High-risk AI systems shall technically allow for the automatic recording of events ('logs') over the lifetime of the system."
}

# 2 · what reaches the mapping prompt. id and summary only — the
#     source url stays in the repo and is never sent to the model.
<applicable_sub_clauses>
  <regime id="eu_ai_act_art_12" name="EU AI Act Article 12">
    <sub_clause id="eu_ai_act_art_12.1">High-risk AI systems shall technically allow...</sub_clause>
  </regime>
</applicable_sub_clauses>

# 3 · what gets signed. an OBJECT KEYED BY action_id, values are
#     arrays of six-property rows. additionalProperties: false.
"obligations": {
  "<action_id>": [
    {"id": "eu_ai_act_art_12.1", "compliance": "satisfied", "confidence": 0.0,
     "evidence": "...", "unvalidated": false, "applies_from": null}
  ]
}

Read the difference literally, because it is where the honest limits of the record sit. The corpus knows the display string and the source URL. The signed row does not: it carries the sub-clause id, verbatim from the corpus, and nothing that resolves to a document. A reader who wants the regulator's own text follows the id back into the published corpus at the digest the package names — which is why the digest is on the PDF. The evidence string is a concise quote or paraphrase drawn from the trace, written by the assessment. And there is no edge type of any kind on the signed row, so no field records that two obligations are equivalent, that one specialises the other, or that they conflict.

That last one matters for conflicts, so state it plainly rather than implying a mechanism. Where two obligations cannot both be satisfied by the same field, both rows are emitted and both are printed under the action. Neither is dropped, and neither is silently preferred. What does not exist is a field that names the pair or classifies the conflict — the conflict is legible from reading the two rows together, and labelling it would require a new schema version, because the package root is closed.

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 — and warrant-v1 has no signer field of any kind. The package names no person and no role, so none of these attestations is evidenced by it. What the PDF closes with is a Signature & Attestation section recording the corpus digest, the analysis configuration digest and the models that produced the determination. The human sign-offs each regime demands stay in the institution's own governance record.

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. These are the four judgement fields on the authorizations[] row, and each holds a string, not a boolean. within_purpose: "yes" (advisory action against an advisory agent). preconditions_met: "yes" (FCA suitability assessment present in the trace). human_oversight_appropriate: "no" (the trace lacks a senior-manager attestation row, surfaced as a Consumer Duty Principle 12 gap). reversible: "yes" (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 map cites the obligation, not a claim that every one is already enforceable: the EU AI Act rows drawn from Chapter III, Section 2 — Articles 12 to 15 — carry an application date of 2 December 2027 for Annex III high-risk systems and 2 August 2028, subject to Article 2(13), for the Annex I embedded route, per Article 113 as replaced by Article 1(40)(b) of Regulation (EU) 2026/1744, while Article 50 applies from 2 August 2026. Those dates are stated here, in prose, and the reason to say so is that the package does not reliably carry them. The obligation row has an applies_from property for exactly this job, and it is gated: deferral labelling defaults to report-only, so unless an operator switches the mode to emit, nothing reaches the aggregate, the PDF or the receipt and applies_from stays absent. A reviewer reading a package produced under the shipped defaults will not find the clock on the row and has to read the regime's application date out of the corpus at the digest the package names.

Read the middle column of the table literally. It names properties of the signed warrant-v1 package as defined in api/spec/warrant-v1-evidence.schema.json, which sets additionalProperties: false at the root and on every actions[] and authorizations[] row — so a field name absent from the schema is prohibited, not merely unimplemented. Three of the eight rows below have no field at all, and one maps only in part. Collapsing works for obligations that ask for the same thing; it cannot conjure a field for an obligation the package does not evidence.

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 documentation expectation — the last of those carried as voluntary governance design rather than an obligation, since SR 26-2 is supervisory guidance and its footnote 3 excludes agentic AI. The PDF prints all fourteen. Its sections, in order, are the cover, the Executive Summary with its gaps and per-regime coverage, a Corpus Diff when the attestation has a parent to diff against, one Warranted Action block per action carrying the Authorization Assessment and the Regulatory Obligations Triggered, and Signature & Attestation. There is no Conflicts section and no Sign-Off section. Each obligation row carries the corpus citation and the evidence for it. 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 is principled: it happens where regulators write equivalent or specialising obligations. It does not happen to procedural shapes regulators have deliberately kept distinct.

How the corpus stays current.

The mapping is only as useful as the corpus is current. Three pieces, described as they run rather than as they were once planned.

A source URL on every sub-clause. Each sub-clause record carries regulator_text_url, the address the summary 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. meity.gov.in for the India DPDP Act 2023. There is no second-hand source in the corpus. Nine of 223 sub-clauses carry no URL, and those are the ones a reviewer should press on. The URL lives in the repo corpus and is not carried on the signed package, so a reader follows the row's regime id back into the corpus at the digest the package names.

A citation gate, weekly on the network and on every pull request offline. There is no daily job that hashes regulator text and pages a reviewer, and no per-sub-clause change detection: the corpus has a regulator_text_sha256 field for that purpose and it is populated on 8 of 223 sub-clauses. What runs instead is a two-part gate. Offline, on every pull request and with no network: every regulatory identifier appearing in the public pages or the corpus must exist in an allowlist, corpus and public copy are cross-checked for scope agreement, and a citation pointing at a listing page rather than the instrument is rejected. Live, once a week on a schedule: every recorded source URL is re-fetched and the recorded quotation must be present in what comes back, because a 200 is not support. Weekly rather than daily is the deliberate choice — statutes and supervisory letters do not change daily, and the failures that actually shipped here were fabricated and inverted citations, which the offline half catches before merge.

What the gate does not establish. It shows the cited text is where the corpus says it is. It does not show the pipeline picked the right clause for the action in front of it. Stage 1 classification accuracy is not measured. A measured number with named failure classes is in progress, and until it exists no accuracy figure is published on this site.

The corpus version id is printed on every PDF. A reviewer holding two packages can tell from their digests whether both were assessed against the same law, and the running API refuses to start when the corpus file it loads does not match its pin, so a changed corpus cannot be served quietly under an old id. One limit to be straight about: the corpus itself is not published. It is versioned and licensed to design partners under MNDA, so today the digest establishes which corpus was used, and a reviewer outside that set cannot yet pull the matching snapshot and re-derive it.

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

The regulator wants to know whether the AI behaved as the rules require over the life of the system. EU AI Act Article 12(1) names the mechanism: the system must technically allow the automatic recording of events over its lifetime. Read that as a logging-capability duty and not a retention duty — Article 19 is what sets the retention period, with a six-month floor, and conflating the two turns a capability requirement into an indefinite archive nobody wrote. The other sources ask the same underlying question in their own registers, at their own statuses. NYDFS § 500.6(a)(2), binding, asks it as cybersecurity-event audit trails. FCA Consumer Duty PS22/9, binding, asks it as good-outcomes evidence under Principle 12. SR 26-2 asks it as senior-management-accountable model risk, as supervisory guidance rather than an enforceable standard, and its footnote 3 puts generative and agentic AI outside its scope. The RBI's FREE-AI framework asks it as responsible-and-ethical enablement, in a committee report that has not been adopted as regulation. The India DPDP Act 2023 names the Data Principal and the Data Fiduciary's duties to that Principal, and is enacted with its substantive duties awaiting notified rules.

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