# Regulatory Snapshot documentation — full text > Every page of https://docs.regsn.app concatenated in navigation order. Per-page source URLs below; the per-page markdown twins (append .md to any page URL) are the smaller units. --- # Regulatory Snapshot Source: https://docs.regsn.app/ (markdown: https://docs.regsn.app/index.md) > Multi-jurisdiction regulatory horizon scanning — product guide and developer API documentation. **Regulatory Snapshot is a horizon-scanning workspace.** You configure the jurisdictions and regulatory areas that matter to you, run a scan, and a few minutes later read the result as a dated, cited briefing: a pressure heatmap, an executive narrative, trends, a deadline timeline, and a per-item audit trail. Re-running the same scope tracks what has changed between runs, and Studio turns any scan into shareable artefacts — decks, tearsheets, infographics, audio and video. Everything the app does with scans is also reachable over a JSON API. These docs cover the two ways in, plus the shared vocabulary: - [Using the app](https://docs.regsn.app/using) - [API for developers](https://docs.regsn.app/api) - [Concepts](https://docs.regsn.app/concepts) - [Glossary](https://docs.regsn.app/glossary) ## Common starting points - [Your first scan](https://docs.regsn.app/using/first-scan) — the order form walked end-to-end, from empty state to reading the result. - [The app at a glance](https://docs.regsn.app/using) — the tab bar, the More menu, the ticker, filters, and how the surfaces fit together. - [Reading the Overview](https://docs.regsn.app/using/overview) — the executive hero, the four editorial panels, the pressure heatmap, and the Change Monitor. - [Make your first API request](https://docs.regsn.app/api/quickstart) — create a key, run a scan, poll it, download an export. - [Authentication](https://docs.regsn.app/api/authentication) — how bearer keys work and how to rotate them. - [Scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots) — the lifecycle both the app and the API share. ## One model, two doors The product and the API expose the same objects. A **scan** is a run; it produces a **snapshot** — the dated, self-contained result holding items, trends, an executive summary and a source index. Identical-scope re-runs group into a **series**, which is what change tracking reads. The dashboard tabs are different readings of one loaded snapshot; every Studio artefact and API export derives from one named snapshot. [Concepts](https://docs.regsn.app/concepts) explains this model in plain terms — ten minutes there makes both doors easier. ## Scope These pages document what you can reach through the product and the public `/v1` API — no more. How scans are computed, and the engineering behind the product, is deliberately out of scope. For terminology, the [glossary](https://docs.regsn.app/glossary) is the fast path; every page cross-links its neighbours. --- # The app at a glance Source: https://docs.regsn.app/using (markdown: https://docs.regsn.app/using.md) > How Regulatory Snapshot is laid out — the tab bar, the More menu, the ticker strip, filters, and how the viewing surfaces fit together. This section walks through the working surfaces of Regulatory Snapshot — the views you use to read a completed [scan](https://docs.regsn.app/concepts/scans-and-snapshots), follow the live regulator wire, audit where every finding came from, and manage your archive. One page per surface, each written as a walkthrough. Everything in the app hangs off one object: the **loaded snapshot** — the saved result of a scan. Most views are different reads of that same snapshot; a few (the Feed, your Snapshots archive) stand outside it. If you have not run a scan yet, start with [Your first scan](https://docs.regsn.app/using/first-scan); the app shows a curated sample dataset until your own results exist, and automatically loads your most recent snapshot on each visit. This page is the map. It covers the navigation model, the shared chrome that appears on every tab, and where each deeper walkthrough lives. ## The navigation model The primary tab bar carries the five reading surfaces, in this order: **Overview · Briefing · Trends · Timeline · Studio** Everything else lives behind the **More** menu: **Feed · Sources · Snapshots · Scheduled** (plus **Map**, and **Graph** when the loaded scan carries relationship-graph data) Two things are deliberately *not* tabs: - **New Scan** — the button at the top right opens the scan order form in place. See [Your first scan](https://docs.regsn.app/using/first-scan). - **Scan Ready** — a green pill that appears when a finished scan is waiting to be loaded. One click loads it; if several are waiting, it opens a picker. The More menu also links out to the [API](https://docs.regsn.app/api/quickstart) and to this documentation site. | Surface | What it is for | Walkthrough | |---|---|---| | Overview | The executive read: summary, deadlines, priorities, the pressure heatmap, and the Change Monitor | [Overview](https://docs.regsn.app/using/overview) | | Briefing | The long-form analyst narrative, with citations and a chaptered audio edition | [Briefing](https://docs.regsn.app/using/briefing) | | Trends | Cross-jurisdiction patterns the scan identified | [Trends](https://docs.regsn.app/using/trends) | | Timeline | Every dated item laned by jurisdiction on a zoomable horizon | [Timeline](https://docs.regsn.app/using/timeline) | | Studio | Turn the snapshot into artefacts — decks, briefs, audio and more | [Studio](https://docs.regsn.app/using/studio) | | Feed | The global regulator wire, independent of any scan | [Feed](https://docs.regsn.app/using/feed) | | Sources | The audit trail: provenance, verification and trust signals per item | [Sources](https://docs.regsn.app/using/sources) | | Snapshots | Your archive — load, rename, re-scan, delete, and follow series | [Snapshots](https://docs.regsn.app/using/snapshots) | | Scheduled | Recurring scans that run on a timetable | [Scheduled scans](https://docs.regsn.app/using/scheduled-scans) | **Warning:** The **Briefing** tab only appears when the loaded snapshot carries an executive narrative. If you load an older or lighter scan and Briefing vanishes from the bar, nothing is broken — that scan has no narrative to show. ### Map and Graph The two remaining More-menu surfaces are further readings of the loaded snapshot. **Map** plots the scan's jurisdictions on a world map, each country shaded by the same severity-weighted scoring as the heatmap — click a country to open its items. **Graph** draws the snapshot's relationship graph — nodes, edges and clusters — and joins the More menu only when the loaded scan carries graph data; Map is always there. ## How the pieces fit ```mermaid flowchart LR W[New Scan order form] -->|runs| S[(Snapshot)] SC[Scheduled scans] -->|run on a timetable| S S --> O[Overview] S --> B[Briefing] S --> T[Trends] S --> TL[Timeline] S --> SR[Sources] S --> ST[Studio artefacts] A[Snapshots archive] -->|load / re-scan| S F[Feed — global wire] ``` A scan produces a snapshot; the reading tabs are views of whichever snapshot is loaded; the archive is where snapshots live between sessions. The Feed is the one reading surface that does not depend on the loaded snapshot at all — it is the live wire of regulator announcements across every jurisdiction the platform tracks. ## The shared chrome Every tab sits inside the same shell. Three pieces are worth knowing before you read any single view. ### The ticker strip The mono line under the tab bar is a running readout of what you are looking at. On most tabs it reads: ``` ITEMS 24 · JUR 03 · HIGH-IMPACT 07 · DEADLINES 11 · ● SCAN 14-07-2026 ``` `ITEMS` and `JUR` count the items and jurisdictions currently in view; `HIGH-IMPACT` and `DEADLINES` appear only when non-zero; the trailing `● SCAN` tag is the loaded scan's date, in DD-MM-YYYY. The ticker re-tunes itself per tab — on Sources it carries trust statistics, on Snapshots it counts your archive, on Scheduled it shows the next run time. Each walkthrough notes its own variant. ### Filters The filter cluster offers three facets — **Likelihood** (Confirmed, Likely, Possible, Uncertain), **Impact** (High, Medium, Low) and **Status** (Effective, Implementation Phase, Final Rule, Consultation, Proposed). Each chip shows how many levels are selected (`Impact 2/3`); each dropdown has a per-facet **CLEAR** that resets that facet to everything. Filters narrow the *items* of the loaded scan, so they only appear on item-scoped surfaces: Overview, Briefing, Trends, Timeline (and Map/Graph). On Feed, Studio, Sources, Snapshots and Scheduled the cluster hides — those surfaces are not item lists to be narrowed. **Warning:** Even where the filter chips are visible, not everything re-filters. The heatmap and the Timeline recompute from the filtered items; the Briefing narrative and the Trends ledger are editorial output written at scan time and do not change as you toggle facets. If a count looks "stuck", that is why. ### The utility cluster To the right of the filters: - **Export & Import** — Import JSON, Export JSON, Export CSV, and (where the integration is enabled) [sending the scan's sources to NotebookLM](https://docs.regsn.app/using/studio#send-a-scan-to-notebooklm). Studio owns the richer artefact lineup — see [Studio](https://docs.regsn.app/using/studio). - **Language** — switches the dashboard between English, Français, Deutsch, Español, Italiano, 中文 and 日本語. Editorial content is translated on demand; your choice persists across devices. - **Theme** — light and dark. Also persisted per user. - **Account** — profile and sign-out. Every tab ends with the same footer band: the AI-generated-content disclaimer and a mono stamp of the product name, data mode and the loaded scan date. The data mode reads `SAMPLE DATA` (the built-in sample dataset, before any result of your own is loaded), `LIVE DATA` (a scan's results streamed straight in) or `CURRENT DATA` (a saved snapshot loaded from the archive, including imported JSON). ## Keyboard shortcuts | Key | Action | |---|---| | `1`–`9` | Switch tabs | | `R` | Reset all filters | | `Esc` | Close any open menu, dropdown, filter sheet or the item-detail panel | The digits follow the app's internal tab order, which is close to — but not exactly — the visible bar-then-More order. `1` is always Overview; what a given number opens shifts when the loaded scan carries a conditional tab (with a Briefing present, `2` opens it and everything after moves down one). ## On mobile Below tablet width the tab bar becomes a scrollable pill row (the active pill centres itself), and the filter cluster collapses into a **Filters (n)** button that opens a bottom sheet with the same three facets. The theme and account controls move beside it. Item detail opens as a full-screen sheet. ## Where to go next Start with the [Overview walkthrough](https://docs.regsn.app/using/overview) — it is the surface you land on, and it introduces the item-detail panel that the Timeline and Sources pages reuse. If you want the conceptual grounding first, read [the object model](https://docs.regsn.app/concepts) and [Scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots). Quick practical answers — costs, run times, languages, where artefacts land — are collected in the [FAQ](https://docs.regsn.app/using/faq). Developers can drive everything on this page programmatically — see the [API quickstart](https://docs.regsn.app/api/quickstart). --- # Your first scan Source: https://docs.regsn.app/using/first-scan (markdown: https://docs.regsn.app/using/first-scan.md) > A start-to-finish walk through the scan order form — who you are, where to look, what to watch, how far ahead — and reading the result. A scan is one commission: you fill in a short order form — who you are, where to look, what to watch, how far ahead — check the live cost estimate, and press **Start scan**. A few minutes later (or a few hours, if you choose the cheaper batch lane) you have a [snapshot](https://docs.regsn.app/concepts/scans-and-snapshots): a structured, sourced read of the regulatory landscape you described, ready to explore in the [dashboard](https://docs.regsn.app/using/overview). This page is a tutorial. It takes one concrete path from an empty account to a finished, readable scan. For the conceptual picture first, read [Scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots). The whole form lives on a single page. Numbered sections **01–05** run down the left; a live **order ticket** sits on the right, restating your choices and pricing them as you go; a run bar pins to the bottom with the same estimate and the same **Start scan** button. Nothing advances or submits until you press it. **The example we build throughout:** you work at a UK asset manager and want a 12-month view of AML / KYC and sustainable-finance regulation across the UK, the EU, and Switzerland. ### Open the order form Sign in and choose **New scan**. The order form opens under the heading *"Set regulatory scan parameters, then run."* On your first visit every section is empty and the **Recent scans** list at the foot of the page says so — *"You haven't saved any scans yet — your first run will appear here."* From your second scan onwards the form arrives pre-filled from your last run (the header says which scan it carried the configuration from), and **Reset to defaults** clears the scan shape — who, where, what, when — back to an empty form, leaving the engine choice untouched. ### 01 Who — say who you are Section **01 Who** offers a row of entity-type pills: *Global Asset Manager, Hedge Fund, Private Investment / VC, Insurer, Universal Bank, Retail Bank, Investment Bank, Payments / Fintech, Crypto / DeFi, Custodian / CSD, Market Infrastructure, General / Multi-sector*. Pick as many as apply. Your choice steers what the research looks for and the register the briefing is written in — an asset manager and a payments firm get meaningfully different readings of the same rule. For our example, select **Global Asset Manager**. ### 02 Where — choose jurisdictions Section **02 Where** lists the built-in jurisdictions as pills — US, EU, UK, Singapore, Hong Kong, Japan, Australia, Switzerland, Canada, Brazil, India — with preset chips above them (*G7, EMEA, APAC, Americas, EU+, Global Major*) that select a whole region in one click. Two behaviours worth knowing: - **Presets replace the pill selection** rather than adding to it — clicking *EMEA* gives you exactly EU, UK, and Switzerland. Custom jurisdictions you have added by hand (marked ★) are always kept. - Anything not on the pill list can be typed into **Add custom…** — it joins the selection as a ★ chip. Each jurisdiction scales cost and runtime roughly linearly, so start narrow. For our example, click the **EMEA** preset: EU, UK, and Switzerland light up, and the ticket's WHERE row updates to match. ### 03 What — choose regulatory areas Section **03 What** works the same way: the built-in areas — *Banking / Prudential, Capital Markets, Digital Assets / Crypto, AML / KYC, Payments, Data Privacy, Operational Resilience, ESG / Sustainable Finance, Sanctions, Research Bundling / Unbundling* — plus **Add an area…** for anything free-form, which joins as a ★ chip (click a custom chip to remove it). For our example, select **AML / KYC** and **ESG / Sustainable Finance**. ### 04 When — set the horizon Section **04 When** is a single segmented control: **3 · 6 · 12 · 18 · 24 · 36 months**. The horizon bounds which deadlines, trends, and watch-list items make the cut — it does not change the price. For our example, choose **12 mo**. ### 05 Output — language and verification Section **05 Output** controls how the result reads: - **Output language** — one of seven: English, French, German, Spanish, Italian, Mandarin Chinese, Japanese. A non-English choice adds a translation pass with a locked glossary, so regulatory terms stay consistent. - **Citation audit** — a verification toggle. When it is on, every claim in the narrative is checked against its source before the dashboard renders. It defaults on for the verified engines and can be switched on for the classic one (the engines are compared under **Advanced**, below). Leave the language on **English** and the citation audit at its default for our example. Below section 05 sits an **Advanced** accordion ("The machinery"). It lets you compare the three analysis engines — with a live cost figure for each — and inspect the quality-control line your scan rides, station by station. The defaults are deliberately good; for a first scan, leave it closed. ### Read the ticket Glance at the order ticket on the right. For our example it now reads, in compact ticket codes: | Row | Value | |---|---| | WHO | ASSET-MGR | | WHERE | EU · UK · SWITZERLAND | | WHAT | AML/KYC · ESG | | HORIZON | 12 MONTHS | | ENGINE | the current engine and its verification state | | LANGUAGE | ENGLISH | Beneath the rows: a live estimate — a dollar range and an expected runtime, recomputed as you change the form — and the scan shape ("3 JURISDICTIONS × 2 AREAS"). The ticket footer is honest about what the number is: **"Estimate, not a quote."** ### Choose when to run Still on the ticket, **When to run** offers two lanes: - **Expedite — run now.** Full price, live progress; results stream into the dashboard as they arrive. - **Batch — later today.** Roughly 50% lower cost; results typically arrive within a few hours. An optional field lets the scan **email you when it's ready**. Not every engine has a batch lane — the ticket tells you when the selected engine can't run as a batch. For a first scan choose **Expedite — run now**, so you can watch it work. ### Start the scan Press **Start scan** — on the ticket or on the bottom run bar; they are the same button. It stays disabled until the form has a horizon, at least one jurisdiction, and at least one area (the fine print under the button says exactly that). The dashboard opens and results arrive progressively — a banner notes that the executive summary appears once the analysis completes. Runtime matches the ticket's estimate; a three-jurisdiction, two-area scan is at the shorter end. ### Read the result When the run finishes you are looking at a populated dashboard: the [Overview](https://docs.regsn.app/using/overview) heatmap of activity by jurisdiction and area, an [Analyst Briefing](https://docs.regsn.app/using/briefing) with an executive summary, plus [Trends](https://docs.regsn.app/using/trends) and a deadline [Timeline](https://docs.regsn.app/using/timeline), all scoped to exactly what you ordered — EMEA, AML/KYC + ESG, twelve months out. The scan is saved automatically. It now appears in **Recent scans** on the order form and in [My Snapshots](https://docs.regsn.app/using/snapshots), and it is the raw material for everything in the [Studio](https://docs.regsn.app/using/studio). ## You now have - A finished snapshot: EU + UK + Switzerland, AML/KYC + ESG/Sustainable Finance, 12-month horizon, citation-audited, in English. - A saved entry in **Recent scans** — **Reload** fills the form with its configuration for tweaking; **Rerun** runs it again as-is. - A dashboard you can read now and [turn into artefacts](https://docs.regsn.app/using/studio) — decks, tearsheets, podcasts — whenever you need them. **Warning:** **Common first-scan pitfalls** - **Everything, everywhere.** Selecting every jurisdiction pill and every area makes a first scan slow and expensive — cost scales roughly linearly with each jurisdiction. Start with one region preset and two or three areas; widen later. - **Preset surprise.** Region presets *replace* your jurisdiction pills (★ customs excepted). If you hand-picked US and then click EMEA, US is deselected — the ticket's WHERE row always shows the truth. - **Greyed Start button.** The CTA needs a horizon, ≥1 jurisdiction, and ≥1 area. If it's greyed, one of the three is missing. - **Batch with a typo'd email.** In the batch lane, an invalidly formatted notification email blocks the Start button until fixed or cleared. **Note:** **Tip** — the form remembers. Every setting persists from your last scan, so the second scan is usually a ten-second edit: open the form, nudge one pill, press Start. For a standing rhythm instead, see [Scheduled scans](https://docs.regsn.app/using/scheduled-scans). ## Where next - [Reading the Overview](https://docs.regsn.app/using/overview) — what the heatmap is telling you. - [Studio](https://docs.regsn.app/using/studio) — turn this snapshot into decks, tearsheets, audio, and more. - [Scheduled scans](https://docs.regsn.app/using/scheduled-scans) — put this configuration on a weekly rota. - [The `/v1` API](https://docs.regsn.app/api/quickstart) — run the same scan programmatically. --- # Overview Source: https://docs.regsn.app/using/overview (markdown: https://docs.regsn.app/using/overview.md) > Reading the Overview tab — the executive summary, deadlines, priorities, the regulatory-pressure heatmap, the item-detail panel and the Change Monitor. The Overview is where the app lands you: a one-screen executive read of the loaded [snapshot](https://docs.regsn.app/concepts/scans-and-snapshots). It is built for the first ten minutes with a fresh scan — what is the bottom line, what has a date on it, what should I do, where are regulators leaning, and where is the pressure concentrated. It is one long column: an executive hero at the top, four editorial panels, the regulatory-pressure heatmap, and the Change Monitor at the bottom. Everything that is item-shaped clicks through to the same item-detail panel, which this page also documents (the Timeline and Sources reuse it). If you prefer prose to panels, the [Briefing](https://docs.regsn.app/using/briefing) is the narrative edition of the same scan. The Overview is the scannable one. ## The executive hero The top of the page carries: - **The title** — your snapshot's name (or its areas × jurisdictions if you never renamed it). - **Executive Summary** — the scan's bottom-line paragraph. Small numbered markers in the text are citations; hover or tap one to see which sources back that sentence. - **BOTTOM LINE** — a one-line distillation, when the scan produced one. - **A `TOPICS` count** — the number of distinct areas in view — complementing the `ITEMS` and `JUR` counts in the ticker strip. - **Sentiment** — an aside giving the scan's overall posture read (for example *Tightening.*) with a one-sentence rationale. It appears only when the scan produced a sentiment; nothing is fabricated for scans that did not. ## The four panels Each panel pairs a label with a headline you will recognise from the product: | Panel | Headline | Contents | |---|---|---| | Upcoming Deadlines | *The agenda.* | Dated obligations, soonest first | | Focus | *What to do about it.* | Numbered priorities with cited detail | | Enforcement Priorities | *Where regulators are leaning.* | Per-regulator enforcement posture | | Watch List | *On our radar.* | Early-stage developments worth tracking | Panels only render when the scan produced their content — a narrow scan may legitimately show fewer of them. ### The agenda — reading a deadline row Each row carries a coloured square for nearness (red within ~30 days, ochre within ~9 months, green beyond, grey once past), the jurisdiction, the deadline itself, its date in DD-MM-YYYY, and a status: `T-45d` (45 days to go), `PAST`, or `TBD` when no date is confirmed. Under each row a thin track fills as the deadline approaches — a full track means it is on top of you. Rows that match an item in the scan are clickable and open that item in the detail panel. Rows without a matching item are informational only. ### Where regulators are leaning Enforcement rows are grouped by regulator and carry a trend chip: **Intensifying**, **New Focus** or **Steady**. Like the Focus panel, the detail sentences carry citation markers you can inspect. ## The pressure heatmap — *At a glance.* The heatmap crosses what the product labels your scan's **topics** (rows) — its areas, custom topics included — against its **jurisdictions** (columns). Each cell prints a pressure score out of 10; the colour bands read: | Band | Score | |---|---| | LOW | 0–4 | | ELEVATED | 5–7 | | CRITICAL | 8–10 | The score is not a count. It is a severity-weighted average of the items in that cell: an item counts for more the higher its impact and the firmer its likelihood, normalised to /10. One confirmed high-impact item can outscore five uncertain low-impact ones — deliberately. The item count survives in the cell's tooltip. Around the grid: each row ends in a **Σ** total, a Σ row totals each column, and the side rail lists the top three **Peak Cells**. Click any populated cell to open its items in the detail panel; empty cells print `—`. **Warning:** The heatmap recomputes from the current filters. If you have narrowed Likelihood to *Confirmed* only, scores drop and cells empty — check the filter chips (or press `R` to reset) before concluding an area has gone quiet. ## The item-detail panel Clicking a heat cell, an agenda row (or, elsewhere, a Timeline chip or a Sources title) slides in the shared **Item Detail** panel: the area · jurisdiction pairing in the header, an item count, the scan date, and one card per item. Each card shows: - Title, plus **status / likelihood / impact** badges. - A **sourcing-confidence chip** where the scan assessed one — *Primary regulator source*, *Supranational body* or *Secondary commentary* (see [Sources](https://docs.regsn.app/using/sources) for what these mean). - **"Underpins N editorial claims"** — when the citation audit tied this item to sentences in the summary or narrative. - An **instrument chip** when the item is bound to a tracked instrument — clicking it jumps to the Change Monitor focused on that instrument (below). - Regulator, expected date (DD-MM-YYYY, or TBD), tags, and the summary with its own citation markers. - **View source →** when the item carries a source URL. Close with `×` or `Esc`. On mobile the panel is a full-screen sheet. ## The Change Monitor — *What's changed.* Below the heatmap sits the Change Monitor: the panel that compares the loaded scan against your previous scan of the **identical scope**. The header tells you the gap ("compared with your scan 7 days earlier"); the body separates what it can prove from what it merely observed: - **Confirmed events** — the only things allowed to headline. Each row is a typed regulator event (*Consultation opened*, *Consultation closed*, *Rules adopted*, *Date set or moved*, *Guidance issued*, *Enforcement*, *Regulator activity*) with the regulator, the document date and a link to the document itself. - **Coverage movements** (collapsed by default) — composition, not change: items *newly observed* this run (some of which were in force before your window — newly shown, not new), and items *not shown this run* with how often they have surfaced before. - **Unverified assertions** — things this scan asserted without a verifiable dated document. Visible, never headline-grade. - When nothing confirmed happened, the panel says so and lists what the regulators *did* publish in the window — an affirmative null, not an empty box. The comparison needs a baseline. On the first-ever run of a configuration the panel says: *"No historic identical scan — nothing to compare against. Re-run this configuration to track change over time."* Re-running the same scope — by hand from [Snapshots](https://docs.regsn.app/using/snapshots) (**↻ Re-Scan**) or on a timetable via [Scheduled scans](https://docs.regsn.app/using/scheduled-scans) — is what builds the series the comparison reads from. The full model of what counts as a change lives at [Changes between scans](https://docs.regsn.app/concepts/changes). **Warning:** "Identical scope" is strict: the same jurisdictions, topic areas and custom topics. Add one topic and you have started a new series — the next Change Monitor will have no baseline until that new scope has run twice. If you meant to widen your coverage permanently, accept the one-scan reset; if you only wanted a one-off look, run it as a separate scan and keep your recurring scope untouched. ## Worked example: from cell to source in four clicks Say your scan covers *Digital Assets / Crypto* and *Operational Resilience* across the EU and UK, and the EU × Digital Assets / Crypto cell prints **8**. 1. The cell is CRITICAL band. Hover: "score 8/10, 4 items" — high severity, modest volume. 2. Click the cell. The detail panel opens with the four items; one is *Confirmed · High* with a *Primary regulator source* chip and "Underpins 3 editorial claims". 3. Read its summary; tap a citation marker to see the backing source, then **View source →** to open the regulator's own document. 4. Back on the Overview, the agenda shows the same instrument with `T-62d` — it has a compliance date inside your horizon. That is your finding: confirmed, high-impact, dated, and primary-sourced. ## A non-obvious tip The Change Monitor's instrument focus is reachable from anywhere the detail panel opens. If a colleague asks "has anything actually happened on DORA since last month?", open any DORA item's detail card and click its instrument chip — the app jumps to the Overview with the Change Monitor open, filtered to that instrument's confirmed events, each with its document link. It is the fastest evidence-backed answer in the app. ## Where next - [Briefing](https://docs.regsn.app/using/briefing) — the same scan as a narrative, with audio. - [Timeline](https://docs.regsn.app/using/timeline) — the agenda's dates plotted on a horizon. - [Sources](https://docs.regsn.app/using/sources) — the audit trail behind every chip and marker you saw here. - [Changes between scans](https://docs.regsn.app/concepts/changes) — the concepts behind the Change Monitor. --- # Briefing Source: https://docs.regsn.app/using/briefing (markdown: https://docs.regsn.app/using/briefing.md) > Reading the Analyst Briefing — the narrative edition of a scan, with a reading index, inline citations, a pull quote, and a chaptered audio edition. The Briefing is the scan's narrative edition: a long-form analyst read of the same snapshot the [Overview](https://docs.regsn.app/using/overview) summarises in panels. It is written for handing to someone — a board member, a general counsel, your future self — and for reading top to bottom rather than scanning. It is the one tab that is conditional: **Briefing appears in the tab bar only when the loaded snapshot carries an executive narrative**. Load a scan without one and the tab is not there. The page is laid out like an article: a masthead, a measured reading column, and an analyst's margin down the right with the reading index, a pull quote and the audio companion. On mobile the margin dissolves into the flow — contents chips under the standfirst, the pull quote inset after the opening, and the audio bar pinned to the bottom. ## The masthead - **Kicker** — *Analyst Briefing* plus the scan's topics. - **Headline and standfirst** — an edited headline and a one-sentence framing such as *"Three priorities for the quarter ahead — EU · UK."* Older snapshots that predate the edited fields fall back to the scan title and a counts sentence; nothing is invented. - **LISTEN** — the audio chip: `▶ LISTEN · 9 MIN`. See [The audio edition](#the-audio-edition). ## The reading index **In this briefing** lists every section — Introduction, the numbered priorities, then the trailing sections (Trends, Key deadlines, Watch list). It is a scroll-spy: the current section is highlighted, finished sections gain a tick, and clicking an entry jumps to it. On mobile the same index renders as chips under the standfirst. ## The reading column The narrative is divided by ruled section dividers: 1. **Introduction** — the framing, opened in the house all-caps style. 2. **Priorities** — numbered `PRIORITY 01`, `02`, … Each divider can carry a right-hand tag naming the jurisdiction and instrument (for example `EU · MiCA`); each section is a headline plus argued prose. 3. **Trailing sections** — *Trends* (tagged CROSS-CUTTING), *Key deadlines* (tagged NEXT 12 MONTHS) and *Watch list* (tagged with its item count). 4. **BOTTOM LINE** — the tight closing line, when the scan produced one. 5. **End matter** — a colophon and the ruled source list backing the citations above. ### Citations Sentences carry small numbered markers — `[3]` — placed by the scan's citation audit. Hover or tap a marker to see the backing source's title, host and tier; consecutive markers collapse into one. A dimmed or unnumbered marker means attribution was unavailable for that sentence — the sentence stands, unattributed, rather than being silently dressed up. **Warning:** Citation markers are an attributor, not a fact-checker: they tell you *which* retrieved source backs a sentence, not that the source is correct. The [Sources](https://docs.regsn.app/using/sources) tab is where you interrogate the sources themselves — verification badges, confidence chips and the audit's working. ### The pull quote When the scan produced one, the margin carries a pull quote with a sentiment attribution (for example *Sentiment — Tightening*). It is the same sentiment read the Overview hero shows; the quote itself appears only here. ## The audio edition The briefing has a spoken edition. Press **LISTEN** in the masthead (or the play control in the margin's audio bar) to start it; the bar shows elapsed and total time and is seekable. When the audio was generated with a section map for this exact snapshot, the bar becomes **chaptered**: one segment per section, named with the same labels as the reading index (plus a final *Bottom line* chapter when one was spoken). Click a chapter to jump. When no matching map exists — older artefacts, or audio whose section map no longer lines up with the narrative on screen, as can happen just after a language switch — the bar degrades honestly to a plain seek bar rather than showing wrong chapters. Two behaviours worth knowing: - Leaving the Briefing tab stops the readout — the audio belongs to the reading surface, it does not follow you around the app. - Switching the dashboard language switches the narrative, and the audio edition follows the language where one exists. ## Actions In the margin (footer row on mobile): - **Export PDF** — opens the export menu to produce the document edition. The full artefact lineup lives in [Studio](https://docs.regsn.app/using/studio). - **Send** — jumps to Studio with this snapshot in hand. - **Copy link** — copies the current address to your clipboard. ## Worked example: a Monday read Your weekly scan has landed and the standfirst says *"Four priorities for the quarter ahead — EU · UK."* 1. Skim the reading index: four priorities, tagged `EU · MiCA`, `EU · DORA`, `UK · CP24/xx`, `EU/UK · AI`. That is the shape of the week. 2. Press **LISTEN** and let the Introduction chapter play while you scan the agenda on another screen — then seek straight to the UK consultation's chapter (fourth on the bar, after Introduction), because that one is yours. 3. Read that priority in full. A claim about scope looks surprising — tap its `[5]` marker, open the source, and confirm the wording against the regulator's own page. 4. Finish with **BOTTOM LINE**, then **Export PDF** for the compliance channel. Ten minutes, and every claim you forwarded is one tap from its source. ## A non-obvious tip The standfirst's priority count is a fast quality check on cadence. If last week's briefing had three priorities and this week's has six, something moved — open the Overview's [Change Monitor](https://docs.regsn.app/using/overview#the-change-monitor--whats-changed) before reading further, and let the confirmed-events list tell you whether it is genuine regulator activity or a widened watch list. ## Where next - [Overview](https://docs.regsn.app/using/overview) — the panel edition of the same scan. - [Sources](https://docs.regsn.app/using/sources) — interrogate the citations' sources. - [Studio](https://docs.regsn.app/using/studio) — turn the briefing into shareable artefacts. --- # Trends Source: https://docs.regsn.app/using/trends (markdown: https://docs.regsn.app/using/trends.md) > Reading the Trends tab — the ledger of cross-jurisdiction patterns a scan identified, the five pattern types, and the legend that explains them. The Trends tab is the scan's pattern ledger: the movements it identified that span more than one jurisdiction or regime. Where the [Overview](https://docs.regsn.app/using/overview) tells you what is happening item by item, Trends tells you what the items add up to — convergence here, divergence there, a regime interlocking with another. It is written for the "so what" conversation: when someone asks not *what did the FCA publish* but *where is this all going*, this is the tab you open. The layout is a numbered editorial ledger down the left and a rail on the right holding the pattern-type legend. The standfirst states the scope plainly: *"Three patterns from the loaded scan — Crypto-assets across the EU and UK."* ## The five pattern types Every trend carries exactly one type, assigned by the scan. The legend in the rail defines them: | Type | Reading | |---|---| | **Convergence** | Jurisdictions moving towards a shared approach | | **Acceleration** | The pace of regulatory change is increasing | | **Interconnected** | Obligations that interlock across regimes | | **Divergence** | Jurisdictions splitting on approach | | **Emerging** | A new pattern forming — early signals only | Each type has its own line-glyph (converging lines, diverging lines, a dashed rising line for emerging, and so on) — the glyph is an encoding, so a colour-blind reader gets the same information. The legend also counts each type's occurrences in the loaded scan, including `00` for types that did not appear. As the legend's foot note says: **types are assigned by the scan — not user-editable**. The legend is a key, not a filter. ## Reading a trend entry Each entry in the ledger carries: - A running number (`TREND 01`) and the **type chip**. - The **title** — the pattern's theme. - **Jurisdiction chips** — but only when they differentiate. If every trend in the scan covers the same set of jurisdictions, the chips are suppressed as redundant; they return the moment the sets differ. - The **description** — the argued paragraph. - **Leader:** — which jurisdiction is setting the pace, when the scan named one. - **Related** — tags naming the scan items that evidence the pattern, or `NONE RECORDED IN THIS SCAN` when the pattern rests on the narrative alone. ## Worked example: reading a convergence Your scan of *Payments* across the EU, UK and Singapore shows: > **TREND 02 · Convergence** — *Operational-incident reporting converges on 24-hour notification* > EU · UK · SG > Description: all three regulators moved towards a 24-hour initial-notification window this quarter… > Leader: EU > Related: DORA incident-reporting RTS · FCA operational-incidents CP · MAS notice revision Read it in three steps. The type says *shared approach forming*; the leader says *the EU text is the template the others are tracking*; the related tags name the three items to open (via the Overview or [Timeline](https://docs.regsn.app/using/timeline)) if you need dates and sources. If your firm operates in only one of the three, the leader is still the jurisdiction to read first — that is where the eventual shape of your own regime is being drafted. **Warning:** The trend ledger is editorial output written at scan time. The filter chips in the toolbar do not narrow it — toggling Likelihood or Impact changes the Overview and Timeline, not this ledger. Equally, there is no click-through from a trend to an item detail; use the Related tags as your index into the other tabs. ## When the ledger is empty A scan that found no cross-jurisdiction movement says so: *"No cross-jurisdiction patterns detected — patterns appear when the scan identifies movement that spans two or more jurisdictions or regimes."* This is common for single-jurisdiction scans, where by construction nothing can converge or diverge. If patterns matter to you, scope your scan across at least two jurisdictions — see [Your first scan](https://docs.regsn.app/using/first-scan). ## A non-obvious tip Read the legend's zero rows, not just the populated ones. A quarter of *Convergence 03 · Divergence 00* followed by a quarter of *Divergence 02* is a regime starting to fracture — visible in the counts before any single item makes it obvious. Comparing legends across a snapshot [series](https://docs.regsn.app/using/snapshots#series--re-runs-of-the-same-scope) is the cheapest trend-of-trends analysis available. ## Where next - [Timeline](https://docs.regsn.app/using/timeline) — when the items behind a pattern actually land. - [Overview](https://docs.regsn.app/using/overview) — item-level detail behind the Related tags. - [Snapshots](https://docs.regsn.app/using/snapshots) — build the series that lets you compare pattern mixes over time. --- # Timeline Source: https://docs.regsn.app/using/timeline (markdown: https://docs.regsn.app/using/timeline.md) > Reading the Timeline tab — dated items laned by jurisdiction, zoom and Today controls, the key-deadlines strip, and the status legend. The Timeline answers the planner's question: **what lands, and when**. Every dated item in the loaded scan is plotted on a horizontal month axis, grouped into swimlanes by jurisdiction, so you can see the next four quarters as shapes rather than a list. It is the tab for sequencing work — which obligations stack up in the same month, which jurisdiction's cluster hits first, how much clear water you have after the current crunch. The masthead states the scope (*"What lands, and when — EU, UK"*), and its meta line carries the two numbers that frame everything below: how many **dated items** the scan holds and the **span** they cover (for example `SPAN AUG 2026 – MAR 2028`). ## Dated versus undated Only items with a real expected date are plotted. Items whose date is unconfirmed (`TBD`) are excluded from the canvas and counted honestly in the toolbar — `4 undated`. They still exist everywhere else in the app; the Timeline refuses to place them at a fictional point on an axis. **Warning:** An empty-looking Timeline does not mean an empty scan. Check two things before concluding nothing is coming: the **undated** counter (early-stage proposals often have no date yet), and the filter chips — the Timeline plots the *filtered* items, and a narrowed Status facet can empty whole lanes. `R` resets the filters; the empty state also reminds you. ## The controls | Control | What it does | |---|---| | `− Zoom Out` / `+ Zoom In` | Steps the horizontal scale between 0.3× and 3.0× | | `Reset` | Returns to 1.0× | | `▶ Today` | Scrolls the canvas so today is centred | | `ZOOM 1.3×` | The current zoom readout | | `Showing n of m` | Appears only when filters are narrowing the view | The tab opens already scrolled to the neighbourhood of today, so the first thing you see is the near horizon, not last year's left margin. ## Reading the canvas From top to bottom: - **Month axis** — months across the top, with the year marked at each January. - **Key deadlines strip** — the scan's headline deadlines (the same ones the Overview's *agenda* panel lists) plotted as small ticks on the same axis: `Key deadlines — 5 in span · 2 beyond →`. Hover a tick for its title. - **TODAY marker** — a labelled vertical rule: `TODAY · 20-07-2026`. - **Jurisdiction bands** — one band per jurisdiction, each labelled with its item count. Within a band, overlapping items stack into parallel lanes automatically. Each item is a chip: a status glyph, the title, and up to two tags. Hover (or keyboard-focus) a chip for the tooltip — title, status, likelihood, impact, date, regulator and summary. Click it to open the full item in the shared [item-detail panel](https://docs.regsn.app/using/overview#the-item-detail-panel). ## The status legend The legend under the canvas orders the five statuses by risk exposure: | Glyph | Status | Risk reading | |---|---|---| | ● | Effective | Highest risk — a live obligation | | ▶ | Implementation Phase | High risk | | ■ | Final Rule | Medium risk — final text, clock running | | ○ | Consultation | Lower risk — still shapeable | | ◇ | Proposed | Lowest risk — direction only | Two edge treatments carry extra encoding: **Proposed chips have a dashed edge, Consultation chips a dotted edge** — the two "not yet settled" statuses are visibly provisional even at a glance. ## Worked example: sequencing Q4 Your scan covers the EU and UK and the compliance plan for Q4 needs dates. 1. Open the Timeline; it lands centred on today, `18 DATED ITEMS · SPAN AUG 2026 – MAR 2028`. 2. In the filter cluster, narrow **Likelihood** to Confirmed + Likely and **Status** to Effective, Implementation Phase and Final Rule. The toolbar now reads `Showing 9 of 18 · 3 undated` — the plan should rest on these nine. 3. Zoom out one step. October–November shows an EU cluster of four chips stacked in two lanes; the UK band is clear until January. 4. Hover the October chips: two share the same effective date. Click each, read the detail cards, and note the regulators. That double-landing is your Q4 pinch point — the rest of the quarter is sequencing, not scrambling. ## A non-obvious tip Use the **key-deadlines strip's "beyond →" count** as a horizon alarm. `2 beyond →` means two headline deadlines fall outside the plotted span — typically past the right edge of your scan's horizon. If that number is non-zero when you plan, re-run the scan with a longer horizon before committing dates; the strip is telling you the picture is cropped. ## Where next - [Overview](https://docs.regsn.app/using/overview) — the same deadlines as a table, with the filling-track treatment. - [Sources](https://docs.regsn.app/using/sources) — verify the source behind any chip you are about to put in a plan. - [Snapshots](https://docs.regsn.app/using/snapshots) — re-run the scan when the horizon needs extending. --- # Feed Source: https://docs.regsn.app/using/feed (markdown: https://docs.regsn.app/using/feed.md) > Reading the Feed — the live wire of regulator announcements across every tracked jurisdiction, independent of the loaded scan, with region and regulator filters. The Feed — *The wire.* — is the app's live ticker of regulator announcements: the most recent publications from every regulator the platform tracks, newest first, across all jurisdictions. It sits under the **More** menu, tagged *Live wire*. It is the one reading surface that is **independent of the loaded scan**. Your snapshot is a considered, point-in-time analysis of a scope you chose; the wire is everything, as it lands. Use the scan to decide what matters; use the wire to see what has happened since — or what is happening outside your scope entirely. The header carries the wire's own statistics — `ENTRIES · REGULATORS · REGIONS` and `LATEST` (the newest entry's date) — and the toolbar below shows a `LIVE WIRE` badge and the filters. ## Reading the wire Entries are grouped by day (*Mon 12 May 2026*, with an entry count per day) and each row reads left to right: - **Date** — a `~` prefix means the publication date could not be confirmed via the regulator's own feed and is a best estimate. - **Regulator code** — colour-tinted by jurisdiction, so a column of FCA rows reads differently from a column of ESMA rows at a glance. - **Regulation ID** — when the announcement maps to a known identifier. - **Title**, and the **topic area** when one was classified. - **↗** — rows with a link open the regulator's own page in a new tab. Rows without a link are informational. There is no pagination; the list ends with `END OF WIRE · N ENTRIES`. ## Filtering the wire Three narrowing tools, all in the toolbar: - **Region chips** — one chip per region present in the wire, with counts. The wire's regions are broad codes: `UK`, `US`, `EU`, `APAC`, `CH` (Switzerland), `CA` (Canada) and `INTL` (supranational bodies). One region at a time; click the active chip again (or **All**) to widen back out. - **Regulator dropdown** — narrow to a single regulator; combines with the region selection. - **◎ This scan's scope** — a one-tap preset that appears when a snapshot is loaded: it maps your scan's jurisdictions onto wire regions and shows only those. Picking the preset clears any single-region chip and vice versa — they are two different ways of asking the same question. While filtered, the toolbar shows `X of N`; **Clear** resets everything. **Warning:** Scan jurisdictions and wire regions are different vocabularies. Your scan may say *Singapore*, *Japan* and *Australia* — the wire files all three under `APAC`. The **This scan's scope** preset does that mapping for you, but it necessarily widens: scoping a Singapore-only scan onto the wire shows the whole APAC region, not Singapore alone. Use the regulator dropdown to tighten the last step. ## Worked example: the gap since your last scan Your loaded snapshot is dated `07-07-2026` (the `● SCAN` tag in the ticker strip shows this on every tab) and you want to know what your regulators have published in the fortnight since. 1. Open **More → Feed**. The wire loads newest-first; `LATEST` confirms it is current. 2. Click **◎ This scan's scope**. The wire narrows to your scan's regions — say `EU` and `UK`. 3. Read down the day groups from today back to 07-07-2026. Two ESMA rows and one FCA row land in that window; one carries the regulation ID you have been tracking. 4. Click the row, read the regulator's page, and if it changes the picture, go to [Snapshots](https://docs.regsn.app/using/snapshots) and **↻ Re-Scan** your configuration — the next [Change Monitor](https://docs.regsn.app/using/overview#the-change-monitor--whats-changed) will then confirm and date the change formally. ## A non-obvious tip The wire is the cheapest way to sanity-check a *quiet* Change Monitor. If the panel reports nothing confirmed and you find that hard to believe, scope the wire to your scan's regions and read the window yourself — if the wire is also quiet there, the silence is real, not a scanning artefact. The two surfaces draw on the same announcements, so agreement between them is meaningful. ## Where next - [Overview → Change Monitor](https://docs.regsn.app/using/overview#the-change-monitor--whats-changed) — the formal, evidence-graded version of "what happened since". - [Changes between scans](https://docs.regsn.app/concepts/changes) — why the wire and the Change Monitor grade evidence differently. - [Snapshots](https://docs.regsn.app/using/snapshots) — re-run your scope when the wire shows movement. --- # Sources Source: https://docs.regsn.app/using/sources (markdown: https://docs.regsn.app/using/sources.md) > Reading the Sources tab — the audit trail behind a scan: the Trust Scorecard, per-item provenance and verification badges, the audit's working, and the methodology key. The Sources tab — *Sources — the audit trail.* — is where the scan shows its working. Every item in the loaded snapshot is traced to the document behind it, and the page lays out what was searched, how citations were matched, what was verified, and how the scan was configured. It exists for the moment trust is questioned: before you forward a briefing to a regulator-facing committee, when a number looks surprising, or when someone asks "how do we know this?". The hero's meta block sets the tone immediately — the engine the scan ran on, and the citation-audit verdict: `CITATION AUDIT ● COMPLETE · 41/44 EDITORIAL CLAIMS CITED`. On this tab the ticker strip swaps to trust statistics: `ITEMS · JURISDICTIONS · CLAIMS CITED · VERIFIED`. Segments the snapshot cannot support are omitted rather than shown as zero — an absent number is honest, a fabricated `0` is not, and the page holds that line throughout. ## The Trust Scorecard — *The trust numbers.* The scorecard is the one-panel summary, with an audit-status dot in its header (green *Citation audit complete*; amber for partial, failed or timed out; muted when the audit was not run). Its cells: | Cell | What it measures | |---|---| | Editorial claim coverage | How many of the summary's and narrative's claims carry at least one citation — `41 of 44` with a bar | | Sourcing confidence | The mix of high / medium / low / missing confidence across items | | Source cross-reference | The mix of verified / domain / unverified / no-source items | | Surfaced source tiers | The mix of source tiers behind the scan's citations | | Tunnel substitutions | How many sources were upgraded from an aggregator to the primary regulator | Cells hide individually when a snapshot lacks that data — older snapshots may show a shorter card. ## Source provenance — *Where each item comes from.* The main list groups items by jurisdiction. Each item row carries: - The **title** — click it to open the item in the shared [detail panel](https://docs.regsn.app/using/overview#the-item-detail-panel). - A **sourcing-confidence chip**, assessed at scan time: - **Primary regulator source** — sourced from a primary regulator document. - **Supranational body** — from a supranational standards body. - **Secondary commentary** — from commentary rather than the regulator itself; treat with more care. - The **source URL**, with a cross-reference badge: - `✓ verified` — this exact URL was found in the corpus of pages the scan actually retrieved. - `≈ domain` — a page on the same domain was retrieved, but not this exact URL. - `? unverified` — neither the URL nor its domain appears in the retrieved corpus. - Or, plainly, a **no source URL** line when the scan could not attach one. - Status, impact, likelihood and topic pills. The two signals are deliberately independent: the chip grades *what kind* of source, the badge grades *whether the scan can prove it retrieved it*. A `Primary regulator source` that is `? unverified` is a different risk from `Secondary commentary` that is `✓ verified`. ## Analysis — the working Beneath provenance sit the audit's collapsible worksheets: - **Search queries & sources** — the actual queries issued, turn by turn, with each turn's retrieved source URLs expandable underneath. - **Citation matching** — `x/y ITEMS ATTRIBUTED`, with per-item scored source matches. When items could not be attributed above threshold, an amber band says so rather than hiding it. - **Source cross-reference** — the counts behind the ✓/≈/? badges: exact matches, domain matches, unverified, and no-source. - **Relevance filtering** — appears only on older snapshots that used a retrieval-filtering step; current scans do not produce it. ## Scan configuration — *How this scan was run.* The configuration panel records the run itself: jurisdictions, topic areas, the engine, the time horizon, entity types and any custom topics, followed by one row per analysis stage that ran — including whether the verification and citation-audit stages were enabled for this scan, and which translation languages were requested. The foot line stamps `SCANNED` date and time, `DURATION`, `SEARCHES`, and the scan's cost (plus a running total of any export costs for this snapshot). On sample data this panel says *"Run a live scan to see configuration details here."* ## Methodology — the key The final panel, *Methodology — how to read the trust signals*, is the in-product key to everything above: the ✓/≈/? badge semantics, the three confidence chips (including "tunnelling" — the silent upgrade of an aggregator link to the primary regulator, with the stated reason in the chip's tooltip), and the amber audit chip. Its most important sentence is worth restating here: **the `[N]` citation markers are an attributor, not a fact-checker.** The audit selects which retrieved source backs each editorial sentence; it never asserts the source is true. An amber *Citation audit partial* chip means some markers may be missing or inactive — not that the scan failed, and not that any finding is wrong. **Warning:** Do not read absence as failure on historical snapshots. Scorecard cells, worksheets and verification badges each appear only when that snapshot recorded the underlying data — a snapshot from before a given audit capability existed will show fewer signals, honestly. Compare trust signals only between snapshots of a similar vintage. ## Worked example: standing up a number The [Briefing](https://docs.regsn.app/using/briefing) claims a licensing figure you are about to quote to your board. 1. On the Briefing, tap the sentence's `[7]` marker — it names an ESMA page. Note the item it belongs to. 2. Open **More → Sources**. The ticker reads `CLAIMS CITED 41/44 · VERIFIED 19/24` — the audit ran and mostly verified. 3. Find the item under its jurisdiction. Chip: *Primary regulator source*. Badge: `✓ verified` — the exact URL is in the retrieved corpus. Open it and check the figure in the regulator's own text. 4. For belt and braces, expand **Citation matching** and confirm the item was attributed with a strong score. Now you can quote the figure with its provenance attached — regulator document, retrieved by this scan, attributed by the audit. ## A non-obvious tip The scorecard's **Tunnel substitutions** cell is a quiet quality signal worth reading. Each substitution means the scan found a claim via an aggregator but *upgraded* the citation to the primary regulator document. A handful of substitutions on a news-heavy topic is the system doing its job; if you see none on a topic dominated by commentary, expect more `Secondary commentary` chips below — and budget verification time accordingly. ## Where next - [Overview](https://docs.regsn.app/using/overview) — the confidence chips and claim counts resurface on every detail card. - [Briefing](https://docs.regsn.app/using/briefing) — where the citation markers live. - [Scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots) — how a scan is scoped and recorded. --- # Snapshots Source: https://docs.regsn.app/using/snapshots (markdown: https://docs.regsn.app/using/snapshots.md) > Reading the Snapshots tab — your archive of every scan, day-grouped with series folding, in-flight scan cards, and the load / rename / re-scan / delete actions. The Snapshots tab — *My Snapshots* — is your archive: every scan you have run, grouped by day, with scans still running maturing in place at the top. It is where you load past results back into the dashboard, rename them, re-run them, and — with care — delete them. It is also where the app's change-tracking story becomes visible as structure: re-runs of an identical scope fold into a **series** under their newest scan, and it is exactly those series that give the [Change Monitor](https://docs.regsn.app/using/overview#the-change-monitor--whats-changed) its baseline. The masthead shows the archive's range (`OLDEST 03-02-2026 · NEWEST 20-07-2026`), and on this tab the ticker strip counts the archive itself: `SNAPSHOTS · SERIES · IN FLIGHT · ● LAST SCAN`. ## In flight Scans that are still running appear as cards above the ledger: - **Live scans** show the scan's title and scope, a `Stage x of N` tracker with a descriptive phase, a percentage and progress bar, the start time, and a live cost meter. - **Batch scans** show a steady bar and the promise: *"Queued — running in the background, we'll email you when it's ready."* When a scan finishes, its card settles into the ledger below — and the green **Scan Ready** pill in the top chrome offers to load it from anywhere in the app. ## The ledger The archive is a day-grouped ledger (`TODAY — 20-07-2026`, `YESTERDAY — 19-07-2026`, then weekdays), with columns: **Snapshot · Engine · Mode · Cost · Time · Scan ID** Each row carries the snapshot's title, a **Loaded** pill when it is the one currently on the dashboard, a `⟳` chip when it was produced by a scheduled sweep, the engine it ran on, a `LIVE` or `BATCH` mode pill, its cost, its time, and its mono scan ID. Click a row to reveal the actions: | Action | What it does | |---|---| | **Load to Dashboard** | Makes this snapshot the loaded one — every reading tab now shows it | | **Rename** | Inline rename (double-clicking the title does the same) | | **↻ Re-Scan** | Re-runs this snapshot's exact configuration as a new scan | | **Delete** | Two-step: the button arms to **Confirm Delete** on first click | ## Series — re-runs of the same scope Snapshots that share an **identical scope — the same jurisdictions, topic areas and custom topics** — fold into one series under their newest scan. A `▸ 4 scans` hint under the head row expands the older runs, each prefixed with its DD-MM date. Engines and time horizons may differ within a series; scope is what defines it. Series are not cosmetic. The Change Monitor compares a scan against the previous scan *of the same series*; a scope with only one run has no baseline and nothing to compare. The habit that makes the product compound in value is therefore: settle a scope, then **↻ Re-Scan** it (or schedule it) rather than composing a fresh scan each time. The full model is at [Changes between scans](https://docs.regsn.app/concepts/changes). **Warning:** Two cautions. **Delete is permanent** — it removes the snapshot and there is no undo beyond the two-step confirm. And **editing scope forks the series**: re-running with one extra topic starts a new series with no baseline, so the next Change Monitor will report nothing to compare against. Rename freely — titles are labels and do not affect series identity — but change scope deliberately. ## Finding things Search-by-title is the tab's only narrowing tool; while active it shows `x of n` matched. Everything else is chronology — there are no facet filters here, because the archive is a ledger of scans, not a list of items. ## Worked example: standing up a weekly series You have settled on a scope — *Digital Assets / Crypto and Operational Resilience, EU + UK, 18 months*. 1. Run it once from the order form and rename the result to something durable: `EU/UK crypto & opres — weekly`. 2. The following Monday, open Snapshots, click the row, **↻ Re-Scan**. A live card appears at the top, matures, settles into today's group — and folds under the same series head with `▸ 2 scans`. 3. Load the new run. The Overview's Change Monitor now reads *"compared with your scan 7 days earlier"* and lists confirmed events with document links. 4. When the routine proves out, recreate it as a scheduled scan so the Monday run happens without you; snapshots born from the schedule arrive with the `⟳` chip and join the same series, provided the scope is identical. ## A non-obvious tip Every snapshot is directly addressable: `?snapshot=` on the app's URL loads that snapshot on arrival. Combined with the scan ID pill on each row, that gives you permanent references for filing and sharing — a compliance memo can cite the exact snapshot it was written from, and anyone with access can reopen precisely that state of the world. Snapshots are also first-class API objects — see the [Snapshots API](https://docs.regsn.app/api/snapshots). ## Where next - [Overview → Change Monitor](https://docs.regsn.app/using/overview#the-change-monitor--whats-changed) — what a series buys you. - [Changes between scans](https://docs.regsn.app/concepts/changes) — the comparison model. - [Scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots) — the underlying objects. - [Studio](https://docs.regsn.app/using/studio) — turn any archived snapshot into artefacts. --- # Studio Source: https://docs.regsn.app/using/studio (markdown: https://docs.regsn.app/using/studio.md) > Generate and download artefacts from a finished scan — slide decks, tearsheets, infographics, audio briefings, and video — and manage them in the archive. Studio is where a finished scan becomes something you can put in front of other people. It is a single generate-and-download surface for the loaded snapshot: pick an output product on the left, preview an example on the stage, press **Generate**, and collect the result from the archive below. Everything Studio makes is built from the scan you currently have open — the kicker at the top of the page restates exactly which scan that is (date, areas, jurisdictions). The workflow is always the same four moves: ```mermaid flowchart LR A["Pick an output
(left rail)"] --> B["Pick a sub-type
or style (strip)"] B --> C["Generate"] C --> D["Collect from
the archive"] ``` ## The five outputs The left-hand **Output** index lists five product families. Each line carries its file format and what varies within it: | Output | Format | Sub-types / styles | |---|---|---| | **Deck** | HTML / PPTX | Action-oriented · Narrative-led · Regulation-focused | | **Tearsheet** | PDF | Overview + Detailed · 12 styles | | **Infographic** | PNG | Consultant Blue + Custom · 21 styles | | **Audio** | MP3 | Briefing / Discussion / Debate | | **Video** | MP4 | Explainer, narrated | Selecting a product swaps the **stage** — the large panel on the right. The stage always shows an example render at size, labelled **"Preview — example"**: it demonstrates the format and style, not your data. Below the image, an order row spells out precisely what Generate will produce (for instance `PDF · TEARSHEET — OVERVIEW · 2PP · A4`), so the button acts on exactly what you can see described. ### Decks Three sub-types, chosen with the segmented control on the stage: - **Action-oriented** — an interactive, self-contained HTML briefing deck. Two visual presets: *Dark editorial* and *Light consulting*. Because it is a single HTML file, it opens in any browser with nothing to install. - **Narrative-led** — a generated narrative deck that walks the scan as a story. - **Regulation-focused** — an editable board pack in PPTX, dark theme. Use this one when the deck has to be edited in PowerPoint afterwards. ### Tearsheets Two sub-types: **Overview** (a clean two-page A4 PDF of the key takeaways) and **Detailed** (an illustrated deep dive in a style you pick). The style strip under the stage groups the choices into buckets — *Professional*, *Poster*, *Editorial* — and each style card carries a thumbnail; the stage updates to show the selected style at size. ### Infographics One-page visual summaries as portrait PNGs: **Consultant Blue** (the house consulting look) or **Custom**, with a 21-style gallery bucketed into *Professional*, *Poster*, and *Film and Art*. As with tearsheets, click a bucket chip to jump the strip, or scroll it with the ‹ › controls. For Detailed tearsheets and Custom infographics a **Provider** control on the stage chooses which image-generation service renders the artwork (the two options are labelled in the product). Your choice is remembered as a standing preference; the style thumbnails never change with it, only the renderer does. ### Audio Three variants, all MP3: - **Briefing** — a single-voice read of the scan. - **Discussion** — a scripted two-voice dialogue. - **Debate** — a two-voice debate. **English-only**, as the label says. Ready audio plays in the **audio dock** — a mini-player that pins to the bottom of the window with play/pause, a seekable waveform, a queue, and volume. Press **Play** on any ready audio tile in the archive to enqueue it; the dock appears whenever the queue is non-empty and follows you around the app. ### Video **Explainer** — a narrated MP4 walkthrough of the scan. Generate it like anything else and watch it from the archive with the **Watch** action. ## Generating Press **Generate →** on the stage. The job is queued; the button becomes a live counter ("1 generating — queue another") and you can immediately queue another artefact — of the same type or a different one — without waiting. Progress also shows on the corresponding archive tile, which appears at once in a *queued* then *generating* state, with a spinner in its hover preview until the real render exists. Some routes ask a question or two first, in a small popover on the Generate button — for example the Consultant Blue infographic's orientation and detail options, or a free-text **custom instructions** field on several generated routes (available where enabled on your account). Fill them in and confirm; the popover's Generate does the same thing as the stage button. **Language follows the dashboard.** If you are viewing the scan in a non-English language and a translated narrative exists, generated artefacts are produced in that language too. The one exception is the Debate podcast, which is English-only. ### Advanced and Expedite Every sub-type carries an **Advanced** disclosure in the same place beneath the order row. Inside you will find: - The **fixed production roles** for that route — shown for transparency; they are not configurable. - The **Expedite** toggle. By default, artefact generation runs through a slower batch lane. Expedite runs it in real time instead — the UI notes this costs roughly double. On routes with no batch lane the toggle shows as permanently on and greyed out, which is the honest state: there is nothing to flip. Where Expedite is live, it is a sticky preference — it stays set for future generations until you turn it off. ## The archive Beneath the stage, **Archive — Previously generated** holds every artefact you have made, grouped by scan with a dated rule between groups ("Scan 18-07-2026 · … · 3 artefacts") and a running artefact count in the header. **Scan filter.** Once the current scan has at least one artefact, filter chips appear: the **current scan** (the default), **All scans**, and a searchable **Choose scan** picker that filters your whole history by title, scan ID, or date. The filter only scopes the shelf — nothing is deleted by changing it. **Tile anatomy.** Each tile shows a friendly type label ("Deck — Action-oriented", "Tearsheet — Detailed", "Audio — Discussion"…), when it was made, and a status pill: *queued*, *generating*, *ready*, or *failed*. Hovering a ready tile floats a live preview by the cursor — for interactive decks this is the actual deck, scaled down and running. **Actions on a ready tile:** | Artefact | Primary | Secondary | |---|---|---| | Decks | **View** | **Download ▾** — HTML (recommended), PDF (when available), Slice JSON (advanced) | | Tearsheets, infographics, PDFs | **View** | **Download** | | Audio | **Play** (enqueues to the audio dock; shows *Queued* if already there) | **Download** | | Video | **Watch** | **Download** | **Failed tiles** show the error message with **Retry** and **Delete**. Retry resubmits the identical job; Delete removes the record. **Spend line.** When the current scan has accumulated any artefact spend, a footer states it plainly: *"Artefact spend on this scan — $x.xx"*. If you see no line, there is nothing to report. ## Worked example: the Monday pack Your weekly scan landed this morning and the team expects a tearsheet and a podcast by ten. 1. Open Studio; the kicker confirms the loaded scan is this morning's run. 2. Pick **Tearsheet**, sub-type **Overview**. The order row reads `PDF · TEARSHEET — OVERVIEW · 2PP · A4`. Press **Generate →**. 3. Without waiting, pick **Audio**, variant **Discussion** — the order row reads `MP3 · DISCUSSION · TWO-VOICE` — and generate that too. The button is now a counter, and two tiles sit in the archive working through *queued* and *generating*. 4. When the tearsheet turns *ready*, **View** it, then **Download** the PDF for the compliance channel. When the discussion is ready, **Play** sends it to the audio dock — it keeps playing while you write the covering note. Two artefacts, one scan, no waiting in between; the archive footer states what the pair cost. ## Send a scan to NotebookLM If the integration is configured for your workspace, a **Send scan to NotebookLM** card sits under the output index (and the same flow is available from the header's **Export & Import** menu). It pushes the scan's sources — and optionally its executive narrative — into a new NotebookLM notebook so you can question the underlying documents interactively. The dialog has two steps: 1. **Configure** — edit the notebook title (pre-filled from the scan title, jurisdictions, and date), choose whether to include the executive narrative, and set source filters (include unverified sources; exclude low-confidence items). A live counter shows how many unique sources will be sent. 2. **Progress** — each source reports its status as it is added, ending with an **Open in NotebookLM** link. ## Exporting scan data Artefacts are not the only way out. The header's **Export & Import** menu works on the scan data itself: - **Export JSON** — the full snapshot as structured data. - **Export CSV** — the item table, spreadsheet-ready. - **Import JSON** — load a previously exported snapshot back in. For programmatic and repeatable exports, the same artefact and data surfaces are available through the [`/v1` API](https://docs.regsn.app/api/exports). **Warning:** **Pitfalls** - **The stage is an example.** "Preview — example" means exactly that: the big image demonstrates the style, not your scan. Your data appears in the artefact itself and in the archive tile's hover preview once generation completes. - **Debate is English-only.** Viewing the dashboard in French will not translate the Debate podcast; use Briefing or Discussion for non-English audio. - **Greyed Generate.** If the button reads "Disabled by administrator", that output has been switched off for your workspace — the rest of Studio still works. - **Missing sub-types.** Administrators can hide individual sub-types; counts on the left rail ("3 sub-types") always reflect what is actually available to you. - **Expedite is sticky.** Where the toggle is live, it persists across sessions — worth checking before a batch of large generations. **Note:** **Tip** — queue in parallel. Generate does not block: fire the deck, then the tearsheet, then the podcast, and let the archive fill in. Each tile tracks its own job, and the audio dock keeps playing while you work. ## Where next - [Your first scan](https://docs.regsn.app/using/first-scan) — if Studio's shelf is still empty. - [Scheduled scans](https://docs.regsn.app/using/scheduled-scans) — keep fresh snapshots arriving for Studio to work on. - [`/v1` exports API](https://docs.regsn.app/api/exports) — the same artefacts, programmatically. --- # Scheduled scans Source: https://docs.regsn.app/using/scheduled-scans (markdown: https://docs.regsn.app/using/scheduled-scans.md) > Put scans on a recurring rota — the Planner calendar, the schedule builder, cadences, batch delivery, and email on completion. A scheduled scan is a scan configuration on a rota: it runs itself — every Monday at 09:00, weekdays at 06:00, the 1st of the month — and each run lands as a fresh snapshot, exactly as if you had pressed **Start scan** yourself. This is how Regulatory Snapshot goes from a tool you remember to open to a briefing that is there when you arrive. You reach it from **More ▸ Scheduled** in the navigation. The page is the **Planner** — a calendar-first view of everything on the rota — plus a builder for creating and editing schedules. ## The Planner at a glance | Zone | What it shows | |---|---| | **Month calendar** | Mon-first grid; each schedule projects colour-coded pills onto the days it will run. Past days are faded, today is ringed. Click a day to see exactly what ran, or will run, and when. | | **Next-run hero** | The single next thing due across all enabled schedules, with a relative countdown and a **Run now →** button. Shows "Nothing due." when the rota is empty or paused. | | **Schedule manager** | One row per schedule: an enable/pause toggle, its cadence and next-run line, last-successful-run date, and a kebab menu with **Edit**, **Run now**, and a two-step **Delete** ("Tap again to confirm" — there is no undo). A dashed **New recurring sweep** row starts the builder. | | **Recent activity** | A feed of past runs, newest first, including runs the scheduler made up after downtime (labelled as catch-up runs). | **Run now** is worth internalising: any schedule can be fired immediately, off-rota, without touching its cadence. It is the quickest way to test a new schedule end to end. ## Creating a schedule Open **New recurring sweep**. The builder has two columns — timing on the left, configuration and delivery on the right. ### Name, cadence, and time - **Name** it something you will recognise in a list ("EU Crypto & AML Weekly"). - **Cadence** presets cover the common rhythms: *Every day · Weekdays · Mon + Thu · M-W-F · Weekly (Mon) · Fortnightly · Monthly (1st) · Monthly (1st + 15th)*. Or ignore the presets and toggle the **day circles** (M T W T F S S) directly. - **Time** is local, 24-hour, with quick-pick chips for 06:00, 08:00, 12:00, and 17:00. A preview line keeps translating your choices into plain language ("Every Monday at 9:00 AM") with the concrete **next run** stamped beneath it — if the preview reads wrong, the schedule is wrong. ### Configuration source Every run needs a scan configuration. Two options: - **Current dashboard scan** — the schedule reuses whatever configuration produced the scan you currently have loaded. The card shows its areas and jurisdictions so you can confirm it is the one you mean. - **Custom configuration** — an inline mini order form: jurisdiction chips, entity types, regulatory areas, an engine selector, an analysis-model choice, a horizon (6/12/18/24 months), and — for engines that support it — a **Batch mode (≈50% off)** checkbox. Selecting Custom pre-fills from the current dashboard scan, so you usually only nudge one or two chips. Scheduled runs default to the batch lane where the engine allows it: unattended scans rarely need live progress, and batch costs roughly half. ### Delivery **Email when a run completes** — one toggle. Batch runs deliver by email on completion, so a Monday-morning schedule with this on means the briefing is in your inbox before you open the app. Either way, every run also appears in [My Snapshots](https://docs.regsn.app/using/snapshots) and in **Recent scans** on the order form. Press **Save schedule**. It appears in the manager, projects onto the calendar, and the next-run hero updates if it is now the soonest thing due. ## A concrete rota The classic setup for a compliance team watching EMEA: 1. On the order form, build and run the scan once — EMEA preset, your areas, 12-month horizon — and check the result reads right. 2. **More ▸ Scheduled ▸ New recurring sweep** — name it, preset **Weekly (Mon)**, time **08:00**, source **Current dashboard scan**, email on completion **on**. Save. 3. Press **Run now** once from the kebab to confirm the whole loop — run, snapshot, email — behaves before Monday does it unattended. **Warning:** **Pitfalls** - **Pausing is not deleting.** The row toggle pauses a schedule (its pills leave the calendar's future); Delete removes it permanently after the "Tap again to confirm" second tap. There is no undo on Delete. - **"Current dashboard scan" is captured, not live.** The schedule stores the configuration as it was when you saved. Changing your dashboard scan later does not silently retune the schedule — edit the schedule if you want it to follow. - **Times are local.** The time field follows your device's timezone. A schedule built at 08:00 in London runs at 08:00 London time, not UTC. - **Missed windows become catch-up runs.** If the service was down over a scheduled slot, the run may be made up afterwards and labelled as a catch-up in the activity feed — expect the odd off-schedule timestamp rather than a silent gap. **Note:** **Tip** — the order form's ticket has a one-tap **"Make this a weekly scan"** shortcut with a *fine-grained control → Scheduled scans* link. Start there when the scan you have just built is the one you want weekly; come here when you need any other cadence, custom configuration, or delivery control. ## Where next - [Your first scan](https://docs.regsn.app/using/first-scan) — build the configuration a schedule will reuse. - [My Snapshots](https://docs.regsn.app/using/snapshots) — where every scheduled run accumulates. - [`/v1` scans API](https://docs.regsn.app/api/scans) — trigger and fetch scans programmatically instead. --- # Settings Source: https://docs.regsn.app/using/settings (markdown: https://docs.regsn.app/using/settings.md) > Account, language, theme, and the standing preferences Regulatory Snapshot remembers between sessions. Regulatory Snapshot deliberately has no settings page. The handful of things you can configure live where you use them — the header chrome for account, language, and theme; the relevant panel for everything else — and the app remembers them per account. This page is the map of what is configurable, where it lives, and what persists. | Setting | Where | Persists | |---|---|---| | Account (profile, sign-out) | Header ▸ account button | Your account | | Interface & output language | Header ▸ language menu | Your account | | Light / dark theme | Header ▸ theme toggle | Your account | | Scan configuration | The order form | Carried forward from your last scan | | Expedite (artefact generation) | Studio ▸ Advanced | Your account | | Image-generation service | Studio ▸ Provider control | Your account | | Scan rota & run emails | Scheduled scans | Per schedule | ## Account The account button at the right of the header opens your account menu: manage your profile and sign-in details, and sign out. Your account is what ties everything together — snapshots, generated artefacts, schedules, and the standing preferences below follow you across devices. ## Language The language menu in the header switches the interface and dashboard between seven languages: **English, French, German, Spanish, Italian, Mandarin Chinese, Japanese**. Switching to a non-English language translates the loaded scan's narrative (a translation pass with a locked glossary keeps regulatory terms consistent), and [Studio](https://docs.regsn.app/using/studio) artefacts follow the dashboard language where the artefact supports it. The scan order form has its own **Output language** selector in section 05 — that one sets the language a *new* scan is produced in. The header menu is for reading; section 05 is for commissioning. ## Theme The theme toggle in the header flips between the light and dark guises. It is cosmetic only — nothing about scans or artefacts changes with it. Like the language, your choice is remembered with your account and follows you across devices. ## Scan defaults The order form itself is the memory for scan configuration: **every setting persists from your last scan** — entity types, jurisdictions, areas, horizon, engine, verification, language, run lane. The header of the form tells you which scan the configuration was carried from, and **Reset to defaults** clears the scan shape (who/where/what/when) back to an empty form without touching the engine choice. ## Studio standing preferences Two Studio controls are sticky preferences saved to your account: - **Expedite** — found under **Advanced** on each output. Where a route has a batch lane, Expedite flips generation to real time (the UI notes ~double the cost). Once on, it stays on for future generations until you turn it off. - **Image-generation service** — the **Provider** control shown for Detailed tearsheets and Custom infographics. Your pick becomes the standing renderer for those artefacts. ## Delivery emails Two places, two different emails: - **Batch scans** — the order form's batch lane offers an optional *"Email me when it's ready"* for that one run. - **Scheduled scans** — each schedule has its own *"Email when a run completes"* toggle; batch runs deliver by email on completion. See [Scheduled scans](https://docs.regsn.app/using/scheduled-scans). **Warning:** **Pitfall** — preferences belong to the account, not the snapshot. If a shared machine shows a different language, theme or pre-filled order form, a different account is signed in — check the account button before concluding the data changed. Two people can load the same snapshot and see it dressed quite differently while reading exactly the same content. **Note:** **Tip** — if an output or control seems to be missing in Studio, it may be administered off for your workspace ("Disabled by administrator"). Ask your workspace administrator rather than hunting for a hidden setting. The same goes for your account's budget cap: scans and artefacts draw on one spending pool set by your administrator — there is no self-service control for it here. ## Where next - [Your first scan](https://docs.regsn.app/using/first-scan) — the order form, section by section. - [Studio](https://docs.regsn.app/using/studio) — where the artefact preferences live. - [Scheduled scans](https://docs.regsn.app/using/scheduled-scans) — rota and delivery configuration. --- # FAQ Source: https://docs.regsn.app/using/faq (markdown: https://docs.regsn.app/using/faq.md) > Practical answers about running scans, costs and runtimes, languages, scheduling, artefacts, and exporting your data. Practical answers, grounded in how the product actually behaves. For workflows, start with [Your first scan](https://docs.regsn.app/using/first-scan); for the ideas behind the product, see the [concepts](https://docs.regsn.app/concepts) section. ## How long does a scan take? It depends on scope — cost and runtime scale roughly linearly with each jurisdiction you add — but an expedited scan typically finishes within a few minutes. The order ticket shows a live runtime estimate (`~…`) alongside the price before you commit, so you never run blind. In the **batch** lane, results typically arrive within a few hours instead, with an optional email when they are ready. ## What does a scan cost? The ticket shows a live dollar range for exactly the configuration you have built, recomputed as you change it, with a confidence note — and a footer that says what it is: *"Estimate, not a quote."* Two levers move it most: the number of jurisdictions (roughly linear) and the run lane — **Batch — later today** costs about 50% less than **Expedite — run now**. The Advanced accordion also shows a live per-engine cost so you can compare the three engines on your actual scan shape. ## Why is the Batch option greyed out? Not every analysis engine has a batch lane. The ticket says so explicitly when the selected engine can only run live; switch engines in the Advanced accordion or run Expedite. ## Can I rerun a previous scan? Yes — the **Recent scans** list at the foot of the order form covers your entire history, with a filter that searches titles, configuration, scan IDs, and dates. Each row has two actions: **Reload** fills the form with that scan's configuration so you can tweak it, and **Rerun** runs it again as-is. ## Can scans run themselves? Yes. [Scheduled scans](https://docs.regsn.app/using/scheduled-scans) puts a configuration on a rota — daily, weekdays, weekly, fortnightly, or monthly, at a time you choose — with an optional email each time a run completes. The quickest start is the *"Make this a weekly scan"* shortcut on the order ticket. ## Which jurisdictions and topics are covered? The order form's pill lists are a starting set, not the boundary. Built-in jurisdiction pills run from the US, EU and UK through to Brazil and India; built-in areas run from *Banking / Prudential* to *Research Bundling / Unbundling*. Both lists are open — **Add custom…** accepts any jurisdiction and **Add an area…** any topic, marked ★ in your selection and treated as first-class scan scope. The catalogue the platform tracks is published as data through the API — see [Discovery](https://docs.regsn.app/api/discovery). ## What languages are supported? Seven: English, French, German, Spanish, Italian, Mandarin Chinese, Japanese — for the interface, the scan output (section 05 of the order form), and, where supported, generated artefacts, which follow the dashboard language. One exception: the **Debate** podcast is English-only, as its label says. Non-English output runs through a translation pass with a locked glossary, so terms of art stay consistent. ## What is the Citation audit toggle? A verification stage: with it on, every claim in the narrative is checked against its source before the dashboard renders. It defaults on for the verified engines; on the classic engine it is opt-in. The toggle in section 05 and the matching station in the Advanced view are the same switch — flipping either updates both. ## Where do generated artefacts go? Every deck, tearsheet, infographic, podcast, and video lands in the [Studio archive](https://docs.regsn.app/using/studio#the-archive), grouped by the scan that produced it. The shelf defaults to the current scan; **All scans** and a searchable scan picker are one tap away. Ready artefacts stay on the shelf and remain downloadable; a failed tile can be retried or deleted. ## Can I generate more than one artefact at a time? Yes. Generate does not block — the button becomes a counter ("1 generating — queue another") and you can queue further artefacts immediately. Each archive tile tracks its own job through *queued → generating → ready*. ## What happens when a generation fails? The archive tile flips to *failed* and shows the error, with **Retry** (resubmits the identical job) and **Delete**. The archive footer keeps the cost picture visible — it states the current scan's artefact spend whenever there is any. ## Why does my artefact look different from the Studio preview? The stage is labelled **"Preview — example"** — it demonstrates the selected format and style with example content, not your data. Your scan's content appears in the generated artefact itself, and in the tile's hover preview once it is ready. ## Can I export the raw data? Yes, two ways. In the app, the header's **Export & Import** menu offers **Export JSON** (the full snapshot) and **Export CSV** (the item table), plus **Import JSON** to load an exported snapshot back in. Programmatically, the [`/v1` API](https://docs.regsn.app/api/quickstart) exposes [scans](https://docs.regsn.app/api/scans), [snapshots](https://docs.regsn.app/api/snapshots), and [exports](https://docs.regsn.app/api/exports). ## Do my settings follow me between devices? Account-level things do: snapshots, schedules, generated artefacts, language, the light/dark theme, and the Studio standing preferences (Expedite, image-generation service). The scan order form always carries forward your last scan's configuration. See [Settings](https://docs.regsn.app/using/settings) for the full map. --- # API overview Source: https://docs.regsn.app/api (markdown: https://docs.regsn.app/api.md) > Programmatic access to Regulatory Snapshot — scans, snapshots, exports, and usage over a small JSON-over-HTTPS surface at api.regsn.app/v1. The Regulatory Snapshot API gives you programmatic access to the same horizon-scanning engine that powers the [regsn.app dashboard](https://docs.regsn.app/using). Configure a set of jurisdictions and regulatory areas, run a [scan](https://docs.regsn.app/concepts/scans-and-snapshots), and get back a structured **snapshot** — items, trends, an executive summary and narrative, and (when a prior comparable snapshot exists) an overlay of [changes between snapshots](https://docs.regsn.app/concepts/changes). From any snapshot you can then generate exportable artefacts: PDFs, slide decks, infographics, audio briefings, and more. The API is a small JSON-over-HTTPS surface at `https://api.regsn.app/v1`. Bearer-key authentication, [idempotent retries](https://docs.regsn.app/api/idempotency), [rate limits](https://docs.regsn.app/api/rate-limits), RFC 9457 errors, and Server-Sent Events for long-running scans are all first-class. If you have used Stripe or Plaid, the shape will feel familiar. ## The lifecycle One scan produces one snapshot; one snapshot can feed many exports. Everything else is a read. ```mermaid sequenceDiagram participant You participant API as api.regsn.app participant Engine You->>API: POST /v1/scans API->>Engine: dispatch Engine-->>API: progress … Engine-->>API: snapshot ready API-->>You: 200 { scan_id, snapshot_id, snapshot } You->>API: POST /v1/exports { snapshot_id, provider, artifact_type } API-->>You: 202 { export_job_id, status_url } loop poll You->>API: GET /v1/exports/{id} API-->>You: 200 { status: queued | processing | completed } end You->>API: GET /v1/exports/{id}/download API-->>You: 200 artefact bytes ``` A sync scan (`POST /v1/scans`, the default mode) blocks for up to 120 seconds and returns the finished snapshot inline. Anything longer — and every export — is asynchronous: you get an id back, then poll or stream until it completes. ## Endpoint map | Method & path | What it does | Reference | |---|---|---| | `POST /v1/scans` | Run a scan (sync up to 120 s, or `?mode=async`) | [Scans](https://docs.regsn.app/api/scans) | | `POST /v1/scans/estimate` | Cost envelope for a scan config, without running it | [Scans](https://docs.regsn.app/api/scans#estimate-a-scan) | | `GET /v1/scans/{id}` | Poll scan status and progress | [Scans](https://docs.regsn.app/api/scans#poll-a-scan) | | `GET /v1/scans/{id}/stream` | Server-Sent Events progress stream | [Scans](https://docs.regsn.app/api/scans#stream-scan-progress-sse) | | `POST /v1/scans/{id}/cancel` | Cancel a running scan | [Scans](https://docs.regsn.app/api/scans#cancel-a-scan) | | `GET /v1/snapshots` | List snapshots with filters and paging | [Snapshots](https://docs.regsn.app/api/snapshots) | | `GET /v1/snapshots/{id}` | Full snapshot envelope | [Snapshots](https://docs.regsn.app/api/snapshots#retrieve-a-snapshot) | | `GET /v1/snapshots/{id}/items` | Items only | [Snapshots](https://docs.regsn.app/api/snapshots#sub-resources) | | `GET /v1/snapshots/{id}/trends` | Trends only | [Snapshots](https://docs.regsn.app/api/snapshots#sub-resources) | | `GET /v1/snapshots/{id}/executive-summary` | Executive summary block | [Snapshots](https://docs.regsn.app/api/snapshots#sub-resources) | | `GET /v1/snapshots/{id}/executive-narrative` | Narrative prose, with `?language=` | [Snapshots](https://docs.regsn.app/api/snapshots#executive-narrative) | | `GET /v1/snapshots/{id}/drift` | Changes overlay against a prior snapshot | [Snapshots](https://docs.regsn.app/api/snapshots#changes-overlay-drift) | | `POST /v1/exports` | Queue an export job against a snapshot | [Exports](https://docs.regsn.app/api/exports) | | `GET /v1/exports` | List your export jobs | [Exports](https://docs.regsn.app/api/exports#list-export-jobs) | | `GET /v1/exports/{id}` | Poll one export job | [Exports](https://docs.regsn.app/api/exports#poll-an-export-job) | | `GET /v1/exports/{id}/download` | Download the finished artefact | [Exports](https://docs.regsn.app/api/exports#download-the-artefact) | | `DELETE /v1/exports/{id}` | Delete a job and its artefact bytes | [Exports](https://docs.regsn.app/api/exports#delete-an-export-job) | | `GET /v1/meta/engines` | Supported engines and horizons | [Discovery](https://docs.regsn.app/api/discovery) | | `GET /v1/meta/models` | Model catalogue per provider | [Discovery](https://docs.regsn.app/api/discovery#models) | | `GET /v1/meta/jurisdictions` | Jurisdiction vocabulary, with regulators | [Discovery](https://docs.regsn.app/api/discovery#jurisdictions) | | `GET /v1/meta/areas` | Regulatory-area vocabulary | [Discovery](https://docs.regsn.app/api/discovery#areas) | | `GET /v1/meta/export-types` | Export catalogue incl. per-type option schemas | [Discovery](https://docs.regsn.app/api/discovery#export-types) | | `GET /v1/usage` | Request, scan, export, and cost telemetry | [Usage](https://docs.regsn.app/api/usage) | | `GET /v1/usage/budget` | Current budget, spend, and remaining | [Usage](https://docs.regsn.app/api/usage#budget) | | `POST /v1/keys` | Create an API key (dashboard session) | [Authentication](https://docs.regsn.app/api/authentication#create-a-key) | | `GET /v1/keys` | List keys, masked (dashboard session) | [Authentication](https://docs.regsn.app/api/authentication#list-keys) | | `POST /v1/keys/{id}/revoke` | Revoke a key (dashboard session) | [Authentication](https://docs.regsn.app/api/authentication#revoke-a-key) | ## Conventions - **Base URL** — `https://api.regsn.app`. All paths are prefixed `/v1`. - **Authentication** — `Authorization: Bearer regsn_live_…` on every call except the dashboard-session `/v1/keys/*` endpoints. See [Authentication](https://docs.regsn.app/api/authentication). - **Content type** — `application/json` requests and responses; errors use `application/problem+json`. Request bodies are capped at 2 MB. - **Request IDs** — every response carries an `X-Request-Id` header (`req_…`); quote it in support requests. The same value appears as `request_id` in error bodies. - **Idempotency** — `POST /v1/scans` and `POST /v1/exports` accept an `Idempotency-Key` header: same key + same body returns the cached response for 24 hours. See [Idempotency](https://docs.regsn.app/api/idempotency). - **Budget** — all scan and export work depletes the same budget pool the regsn.app UI consumes; there is no separate API meter. Check `GET /v1/usage/budget` before a large run. See [Usage & budget](https://docs.regsn.app/api/usage). - **Amounts** — every `*_cents` field is US cents, and may carry fractions of a cent. ## What you can build - **Compliance dashboards** — pull snapshots into your own UI and slice by jurisdiction or area. - **Briefing pipelines** — run scheduled scans, then export the snapshot as a PDF, deck, or audio briefing and route it to the people who need it. - **Change monitoring** — compare snapshots over time; `GET /v1/snapshots/{id}/drift` returns what shifted between snapshots, not just what each one said. - **Workflow integrations** — trigger a scan from a ticketing system, attach the tearsheet to the ticket, post the narrative to chat. ## SDKs | Language | Package | Requirements | |---|---|---| | JavaScript | [`@regsn/api`](https://docs.regsn.app/api/sdks/javascript) | Node 18+, ESM | | Python | [`regsn`](https://docs.regsn.app/api/sdks/python) | Python ≥ 3.8, stdlib only | Both SDKs cover the core scan → snapshot → export flow, retry on 429 and 5xx, and generate idempotency keys automatically. They are thin wrappers — anything they do not cover is a plain HTTPS call away. See each SDK page for current availability. ## See also - [Quickstart](https://docs.regsn.app/api/quickstart) — key → first scan → snapshot → download, start to finish. - [Errors](https://docs.regsn.app/api/errors) — the problem-details shape and every error code. - [Core concepts](https://docs.regsn.app/concepts) — the data model in product terms. - [Glossary](https://docs.regsn.app/glossary) — one-line definitions for every term used here. --- # Quickstart Source: https://docs.regsn.app/api/quickstart (markdown: https://docs.regsn.app/api/quickstart.md) > Create an API key, run your first scan, read the snapshot, and download a PDF — all with curl. In the next few minutes you will create an API key, run your first [scan](https://docs.regsn.app/concepts/scans-and-snapshots), read the resulting snapshot, and download a PDF built from it. Everything here is plain curl; the [SDKs](https://docs.regsn.app/api/sdks/javascript) wrap the same calls. The example scans **UK** and **EU** for **AML / KYC** over a 12-month horizon — substitute your own. `GET /v1/meta/jurisdictions` and `GET /v1/meta/areas` list the [vocabulary the product uses](https://docs.regsn.app/api/discovery). ### Create an API key Keys live in the developer dashboard at [api.regsn.app](https://api.regsn.app). Sign in, create a key, give it a name (for example `production-backend`), and copy the raw `regsn_live_…` string immediately. **Warning:** The raw key is shown **exactly once**. Afterwards only the masked prefix (`regsn_live_aBcD…`) is visible. If you lose it, revoke the key and create a new one — see [Authentication](https://docs.regsn.app/api/authentication). Put it in an environment variable for the rest of this guide: ```bash export REGSN_API_KEY="regsn_live_aBcD1234eFgH5678iJkL9012mNoP3456" ``` ### Run a scan By default `POST /v1/scans` runs synchronously: it blocks for up to 120 seconds and, if the scan finishes inside that window, returns the full snapshot inline. ```bash curl https://api.regsn.app/v1/scans \ -H "Authorization: Bearer $REGSN_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "jurisdictions": ["UK", "EU"], "areas": ["AML / KYC"], "horizon": 12 }' ``` A completed sync response: ```json { "scan_id": "8f3d…", "status": "completed", "snapshot": { "items": ["…"], "trends": ["…"], "executive_summary": { "bottom_line": "…", "priorities": ["…"] }, "executive_narrative": "Over the next twelve months…", "_meta": { "engine": "v4", "model": "…" } }, "snapshot_id": "a1b2…" } ``` If the scan exceeds the 120-second ceiling you get `202` instead, with `status: "running"`, a `status_url`, and a `stream_url`. That is not an error — the scan carries on in the background. Either way, capture the scan id for the next step: ```bash export SCAN_ID="…" # scan_id from the response ``` ### Poll until complete For a `202`, poll the scan until it reaches a terminal status (or subscribe to the [SSE stream](https://docs.regsn.app/api/scans#stream-scan-progress-sse)): ```bash curl https://api.regsn.app/v1/scans/$SCAN_ID \ -H "Authorization: Bearer $REGSN_API_KEY" ``` ```json { "id": "8f3d…", "status": "running", "progress": { "phase": "research", "percent": 62, "message": "…" }, "snapshot_id": null, "created_at": "2026-07-20T09:12:03.000Z", "completed_at": null, "error": null, "cost_cents": null } ``` When `status` is `completed`, `snapshot_id` is set — it also appears directly in a completed sync response, so if you skipped polling take it from there. Fetch the envelope: ```bash export SNAPSHOT_ID="…" # snapshot_id from the scan response or the poll ``` ```bash curl https://api.regsn.app/v1/snapshots/$SNAPSHOT_ID \ -H "Authorization: Bearer $REGSN_API_KEY" ``` The envelope lives under `data` — `data.items`, `data.trends`, `data.executive_summary`, `data.executive_narrative`. [Snapshots](https://docs.regsn.app/api/snapshots) documents the full shape and the lightweight sub-resources (`/items`, `/trends`, `/executive-summary`, `/executive-narrative`, `/drift`). **Note:** **Two envelope shapes.** A fast sync scan returns the envelope flat under `snapshot`; `GET /v1/snapshots/{id}` nests it under `data`. Re-fetching the snapshot by id always gives you the nested shape — that is what the rest of these docs use. ### Export and download a PDF Queue an export against the snapshot. Exports are always asynchronous: ```bash curl https://api.regsn.app/v1/exports \ -H "Authorization: Bearer $REGSN_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d "{ \"snapshot_id\": \"$SNAPSHOT_ID\", \"provider\": \"internal-pdf\", \"artifact_type\": \"pdf\" }" ``` ```json { "export_job_id": "c3d4…", "status": "queued", "status_url": "/v1/exports/c3d4…", "download_url": null } ``` Capture the job id, then poll `GET /v1/exports/{id}` until `status` is `completed`: ```bash export EXPORT_ID="…" # export_job_id from the response ``` ```bash curl https://api.regsn.app/v1/exports/$EXPORT_ID \ -H "Authorization: Bearer $REGSN_API_KEY" ``` Once it is, download — `-OJ` saves the file under its server-supplied name: ```bash curl -OJ https://api.regsn.app/v1/exports/$EXPORT_ID/download \ -H "Authorization: Bearer $REGSN_API_KEY" ``` The full export catalogue — decks, infographics, audio briefings, and their per-type options — is at [`GET /v1/meta/export-types`](https://docs.regsn.app/api/discovery#export-types) and documented in [Exports](https://docs.regsn.app/api/exports). ## Where next - [Scans](https://docs.regsn.app/api/scans) — sync vs async, cost estimates, streaming, cancellation. - [Snapshots](https://docs.regsn.app/api/snapshots) — the data model and every sub-resource. - [Exports](https://docs.regsn.app/api/exports) — all 16 export types and their options. - [Errors](https://docs.regsn.app/api/errors) — what to do when something goes wrong. **Note:** **Make retries safe.** Send `Idempotency-Key: ` on every `POST /v1/scans` and `POST /v1/exports`. If your request times out client-side, retrying with the same key returns the original response instead of running a duplicate scan. See [Idempotency](https://docs.regsn.app/api/idempotency). --- # Authentication Source: https://docs.regsn.app/api/authentication (markdown: https://docs.regsn.app/api/authentication.md) > Bearer keys (regsn_live_…), the key lifecycle at api.regsn.app, and the /v1/keys management endpoints. Every `/v1/*` endpoint requires a bearer key, except the [key-management endpoints](#key-management-endpoints) (which use a dashboard session) and the two [usage endpoints](https://docs.regsn.app/api/usage) (which accept either). ```bash curl https://api.regsn.app/v1/snapshots \ -H "Authorization: Bearer $REGSN_API_KEY" ``` ## Key format | Property | Value | |---|---| | Shape | `regsn_live_` + 32 base62 characters (`A–Z a–z 0–9`) | | Example | `regsn_live_aBcD1234eFgH5678iJkL9012mNoP3456` | | Header | `Authorization: Bearer regsn_live_…` | | Storage | SHA-256 hash only; the raw key is never stored | | Masked display | first 4 entropy characters, e.g. `regsn_live_aBcD…` | Keys are account-scoped: every scan, snapshot, and export a key touches belongs to the account that created it. A key never sees another account's data. **Warning:** **Never put a key in a URL.** Always use the `Authorization` header — keys in URLs end up in browser history, access logs, and referrers. Treat a key like a password: environment variables or a secrets manager, not source control. ## Where keys come from Keys are created and managed in the developer dashboard at [api.regsn.app](https://api.regsn.app) — sign in with your regsn.app account. The dashboard shows plan, usage, and every key with its masked prefix, creation date, and last-used time. - The raw key is returned **exactly once**, at creation. Copy it then. - You can hold up to **10 active keys** at a time. Revoke one to make room. - `last_used_at` updates as a key is used (at most once every 60 seconds), so you can spot dormant keys before revoking them. - Revocation takes effect immediately: revoked keys receive `401` with code `key_revoked`. **Rotation** is revoke-and-replace: create the new key, deploy it, then revoke the old one. Revocation is permanent — there is no un-revoke. ## Authentication errors All are `401` with an [RFC 9457 problem body](https://docs.regsn.app/api/errors): | `code` | Meaning | |---|---| | `authentication_required` | No `Authorization: Bearer …` header. | | `authentication_invalid` | Token malformed (not `regsn_live_` + 32 base62) or not recognised. | | `key_revoked` | The key matched but has been revoked. | ```json { "type": "https://api.regsn.app/problems/auth", "title": "Authentication failed", "status": 401, "detail": "This key has been revoked. Create a new key at api.regsn.app.", "instance": "/v1/snapshots", "code": "key_revoked", "request_id": "req_m3k9…", "errors": [] } ``` ## Key-management endpoints The dashboard drives these three endpoints. They authenticate with a **signed-in dashboard session** (a Clerk session token), never with a bearer key — a `regsn_live_…` key cannot create or revoke keys. They are rate-limited to 10 requests/minute per user. **Note:** For most integrations you never call these directly — use the dashboard. They are documented for completeness and for teams automating key issue from a session-holding context. ### Create a key `POST /v1/keys` | Body field | Type | Required | Constraints | |---|---|---|---| | `name` | string | yes | 1–64 characters: letters, digits, space, `- _ . ( )` | ```bash curl https://api.regsn.app/v1/keys \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "name": "production-backend" }' ``` `201`: ```json { "id": "3f2c…", "name": "production-backend", "key": "regsn_live_aBcD1234eFgH5678iJkL9012mNoP3456", "key_prefix": "regsn_live_aBcD…", "created_at": "2026-07-20T09:00:00.000Z", "last_used_at": null, "revoked_at": null, "project_id": null } ``` `key` is present **only** in this response. Errors: `422 validation_error` (bad name), `422 key_limit_exceeded` (already 10 active keys). ### List keys `GET /v1/keys` — returns every key for the account, newest first, masked: ```json { "data": [ { "id": "3f2c…", "name": "production-backend", "key_prefix": "regsn_live_aBcD…", "created_at": "2026-07-20T09:00:00.000Z", "last_used_at": "2026-07-20T11:41:00.000Z", "revoked_at": null, "project_id": null } ] } ``` ### Revoke a key `POST /v1/keys/{id}/revoke` — idempotent; revoking an already-revoked key returns the original `revoked_at`. ```json { "id": "3f2c…", "revoked_at": "2026-07-20T12:00:00.000Z" } ``` `404 not_found` if the key id does not exist on your account. ## Dual authentication on `/v1/usage` `GET /v1/usage` and `GET /v1/usage/budget` accept **either** a bearer key or a dashboard session, so the same endpoint serves SDK clients and the dashboard. Routing is by token shape: tokens starting `regsn_live_` take the bearer path; anything else is treated as a session token. ## See also - [Quickstart](https://docs.regsn.app/api/quickstart) — create a key and make your first call. - [Rate limits](https://docs.regsn.app/api/rate-limits) — per-key buckets. - [Errors](https://docs.regsn.app/api/errors) — the full error-code table. --- # Scans Source: https://docs.regsn.app/api/scans (markdown: https://docs.regsn.app/api/scans.md) > Create, estimate, poll, stream, and cancel scans — POST /v1/scans and friends. A scan is a run of the research engine over a set of jurisdictions and regulatory areas. It produces a [snapshot](https://docs.regsn.app/api/snapshots). See [scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots) for the product-side view. | Endpoint | Purpose | |---|---| | [`POST /v1/scans`](#create-a-scan) | Run a scan (sync by default, `?mode=async` to queue) | | [`POST /v1/scans/estimate`](#estimate-a-scan) | Cost envelope for a config, without running it | | [`GET /v1/scans/{id}`](#poll-a-scan) | Status and progress | | [`GET /v1/scans/{id}/stream`](#stream-scan-progress-sse) | Server-Sent Events progress stream | | [`POST /v1/scans/{id}/cancel`](#cancel-a-scan) | Best-effort cancellation | ## Create a scan `POST /v1/scans` — bearer auth; rate-limited to **6 scans per hour per key**; accepts [`Idempotency-Key`](https://docs.regsn.app/api/idempotency). ### Query parameters | Parameter | Values | Default | Effect | |---|---|---|---| | `mode` | `sync`, `async` | `sync` | `sync` blocks up to 120 seconds and returns the snapshot inline if the engine finishes in time; otherwise it returns `202` and the scan continues in the background. `async` returns `202` immediately. | ### Request body | Field | Type | Required | Constraints | |---|---|---|---| | `jurisdictions` | string[] | yes | 1–20 entries, each under 100 characters. Free text; [`GET /v1/meta/jurisdictions`](https://docs.regsn.app/api/discovery#jurisdictions) lists the vocabulary the product uses. | | `areas` | string[] | yes | 1–20 entries, each under 200 characters. Free text; vocabulary at [`GET /v1/meta/areas`](https://docs.regsn.app/api/discovery#areas). | | `horizon` | integer | yes | Months of forward horizon: one of `3, 6, 12, 18, 24, 36`. | | `engine` | string | no | `v4` (default), `v4.5-alpha`, or `v4.5-beta`. Retired ids (`v1`, `v2`, `v3`, `admiral`) return `422` with field code `engine_deprecated`. | | `model` | string | no | Model id from [`GET /v1/meta/models`](https://docs.regsn.app/api/discovery#models), or one of the shorthand ids `opus`, `opus48`, `sonnet`, `haiku`. `haiku` is rejected on verifier paths (see below). | | `searchModel` | string | no | Model for the search pass. Same vocabulary as `model`. | | `verificationMode` | string | no | Only value: `in-analyst`. Valid on any engine listed above. Setting it defaults `realist` and `auditor` to `true` if you left them unset. | | `realist` | boolean | no | Enables the realist verification pass. | | `auditor` | boolean | no | Enables the auditor verification pass. | | `auditorModel` | string | no | Only value: `sonnet`. | | `fetchProvider` | string | no | Page-fetch backend for `v4.5-beta` **only**: `firecrawl` (default) or `crw`. On any other engine returns `422` with field code `incompatible`. | | `translationLanguages` | string[] | no | Language codes to translate the snapshot's narrative content into: `fr`, `de`, `es`, `it`, `zh`, `ja`, `pt`. Not validated at request time — an unsupported code simply produces no translation. Translations surface via [`/executive-narrative?language=`](https://docs.regsn.app/api/snapshots#executive-narrative) and export `targetLanguage` options. | Constraint interactions, exactly as enforced: - `verificationMode`, `realist: true`, and `auditor: true` require an **explicit** `engine` of `v4`, `v4.5-alpha`, or `v4.5-beta` in the same body (field code `incompatible` otherwise). Omitting `engine` and relying on the `v4` default does not satisfy this check — set it explicitly when using verification flags. - `model: "haiku"` is rejected (field code `haiku_blocked_on_verifier`) when the config is verifier-aware: engine `v4.5-alpha` or `v4.5-beta`, or engine `v4` with `realist` or `auditor` set `true`. - Jurisdiction and area **names are not membership-checked** — only count and length. Unrecognised names still run; the meta lists are the vocabulary the product itself scans with. ### Example — sync ```bash curl https://api.regsn.app/v1/scans \ -H "Authorization: Bearer $REGSN_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "jurisdictions": ["UK", "EU"], "areas": ["AML / KYC", "Sanctions"], "horizon": 12 }' ``` `200` — completed within the 120-second ceiling: ```json { "scan_id": "8f3d…", "status": "completed", "snapshot": { "items": ["…"], "trends": ["…"], "executive_summary": {}, "_meta": {} }, "snapshot_id": "a1b2…" } ``` `202` — ceiling exceeded; the scan continues in the background: ```json { "scan_id": "8f3d…", "status": "running", "status_url": "/v1/scans/8f3d…", "stream_url": "/v1/scans/8f3d…/stream", "message": "Scan exceeded sync ceiling; poll or stream" } ``` ### Example — async with verification ```bash curl "https://api.regsn.app/v1/scans?mode=async" \ -H "Authorization: Bearer $REGSN_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "jurisdictions": ["US"], "areas": ["Capital Markets"], "horizon": 6, "engine": "v4.5-alpha", "model": "sonnet", "verificationMode": "in-analyst" }' ``` Returns `202` immediately with the same `status_url` / `stream_url` shape as above. ### Errors | Status · `code` | When | |---|---| | `402 budget_exhausted` | Account budget pool depleted. Check [`GET /v1/usage/budget`](https://docs.regsn.app/api/usage#budget) first. | | `409 idempotency_key_in_use` / `idempotency_in_progress` | Replayed `Idempotency-Key` with a different body / original still running. | | `422 validation_error` | Per-field reasons in `errors[]` (codes `required`, `invalid`, `incompatible`, `engine_deprecated`, `haiku_blocked_on_verifier`). | | `429 rate_limit_exceeded` | The scans bucket is exhausted (6/hour). Honour `Retry-After`. | | `503 engine_unavailable` | Selected engine not loaded in this deployment. | ## Estimate a scan `POST /v1/scans/estimate` — bearer auth; counts against the [reads bucket](https://docs.regsn.app/api/rate-limits) (60/min), **not** the scans bucket. Returns a cost envelope without queueing anything and without touching your budget. The estimator buckets on **counts** of jurisdictions and areas plus horizon and engine — the names themselves are not consulted, so stub strings give the same answer as real ones. ### Request body | Field | Type | Required | Notes | |---|---|---|---| | `jurisdictions` | string[] | yes | Non-empty. | | `areas` | string[] | yes | Non-empty. | | `horizon` | integer | no | If present, one of `3, 6, 12, 18, 24, 36`. (Unlike scan creation, optional here.) | | `engine` | string | no | Same vocabulary and deprecation rules as scan creation. | | `seekerProvider` / `analystProvider` / `translatorProvider` | string | no | Provider hints; keys as listed by [`GET /v1/meta/models`](https://docs.regsn.app/api/discovery#models). | ```bash curl https://api.regsn.app/v1/scans/estimate \ -H "Authorization: Bearer $REGSN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "jurisdictions": ["UK", "EU"], "areas": ["AML / KYC", "Sanctions"], "horizon": 12 }' ``` `200`: ```json { "low_cents": 38, "expected_cents": 55, "high_cents": 91, "confidence": "high", "tier": 1, "sample_size": 14, "fingerprint": { "scan_mode": "standard", "engine_version": "v4", "jurisdiction_bucket": "1-2", "area_bucket": "1-2", "enabled_exports_count": 0, "provider_mix_hash": "da39a3ee", "date_range_bucket": "medium" }, "estimator_version": "v2.0", "engine": "v4" } ``` | Field | Meaning | |---|---| | `low_cents` / `expected_cents` / `high_cents` | Cost envelope in US cents. All `null` on a cold start. | | `confidence` | `high`, `medium`, `low`, or `cold_start`. | | `tier` | `1` exact-match window, `2` relaxed one dimension, `3` global similarity-weighted mean; `null` on cold start. | | `sample_size` | Historical runs behind the estimate. | | `fingerprint` | Structured fingerprint of the config; stable across equivalent configs. Absent on cold start. | | `estimator_version`, `engine` | Estimator version and the engine the estimate assumed (`v4` if you omitted one). | Errors: `422 validation_error` (same field rules as above). ## Poll a scan `GET /v1/scans/{id}` — bearer auth; reads bucket (60/min). ```bash curl https://api.regsn.app/v1/scans/8f3d… \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200`: ```json { "id": "8f3d…", "status": "running", "progress": { "phase": "research", "percent": 62, "message": "…" }, "snapshot_id": null, "created_at": "2026-07-20T09:12:03.000Z", "completed_at": null, "error": null, "cost_cents": null } ``` | Field | Notes | |---|---| | `status` | `running`, `completed`, `failed`, or `cancelled`. | | `progress` | `{ phase, percent, message }`, updated as the scan advances. | | `snapshot_id` | Set once `status` is `completed` — fetch it via [`GET /v1/snapshots/{id}`](https://docs.regsn.app/api/snapshots#retrieve-a-snapshot). | | `error` | Failure message when `status` is `failed`; otherwise `null`. | | `cost_cents` | Actual cost once known, else the pre-scan estimate, else `null`. | `404 not_found` for an id that does not exist or belongs to another account. ## Stream scan progress (SSE) `GET /v1/scans/{id}/stream` — bearer auth; **not rate-limited**; `Content-Type: text/event-stream`. ```bash curl -N https://api.regsn.app/v1/scans/8f3d…/stream \ -H "Authorization: Bearer $REGSN_API_KEY" ``` Every message is a `data:` line carrying a JSON object whose `type` field discriminates it (the stream does not use named SSE `event:` fields — dispatch on `type` in `onmessage`): | `type` | Payload | Terminal | |---|---|---| | `progress` | `{ "type": "progress", "phase": "…", "percent": 62, "message": "…" }` | no | | `complete` | `{ "type": "complete", "data": , "snapshotId": "a1b2…" }` | yes | | `error` | `{ "type": "error", "error": "…" }` | yes | | `cancelled` | `{ "type": "cancelled" }` | yes | Behaviour: - On subscribe you immediately receive the current `progress` state, so late subscribers are never blind. - If the scan has already finished, the terminal event (`complete`, `error`, or the last stored progress) is emitted once and the connection closes. - A comment line `: heartbeat` is sent every 30 seconds to keep proxies from idling the connection out. ```text filename="wire format" data: {"type":"progress","phase":"research","percent":35,"message":"…"} : heartbeat data: {"type":"complete","data":{…},"snapshotId":"a1b2…"} ``` `404 not_found` for an id that does not exist or belongs to another account. ## Cancel a scan `POST /v1/scans/{id}/cancel` — bearer auth; mutations bucket (30/min). ```bash curl -X POST https://api.regsn.app/v1/scans/8f3d…/cancel \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200`: ```json { "id": "8f3d…", "status": "cancelled" } ``` Cancellation is **best-effort**: the job is marked `cancelled` and stream subscribers receive `{ "type": "cancelled" }`, but engine work already in flight runs to completion server-side — its result is discarded rather than written over the cancelled state. | Status · `code` | When | |---|---| | `404 not_found` | The id does not exist or belongs to another account. | | `409 invalid_state` | Scan already `completed`, `failed`, or `cancelled`. | **Note:** Scheduled, recurring scans are a product feature configured in the dashboard — see the [product guide](https://docs.regsn.app/using). The API runs one scan per request; schedule on your side with cron or an orchestrator, using an `Idempotency-Key` per tick. The app's discounted batch lane is likewise product-only — it is not exposed on `/v1`. --- # Snapshots Source: https://docs.regsn.app/api/snapshots (markdown: https://docs.regsn.app/api/snapshots.md) > The snapshot envelope, listing and filtering, and the five sub-resources — items, trends, executive summary, executive narrative, and the changes overlay. A snapshot is the structured output of one [scan](https://docs.regsn.app/api/scans): the items found, cross-item trends, an executive summary and narrative, and — when a prior comparable snapshot exists — an overlay of what changed. The product-side explanation is at [scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots). | Endpoint | Purpose | |---|---| | [`GET /v1/snapshots`](#list-snapshots) | List with filters and paging | | [`GET /v1/snapshots/{id}`](#retrieve-a-snapshot) | Full envelope | | [`GET /v1/snapshots/{id}/items`](#sub-resources) | Items only | | [`GET /v1/snapshots/{id}/trends`](#sub-resources) | Trends only | | [`GET /v1/snapshots/{id}/executive-summary`](#sub-resources) | Summary block only | | [`GET /v1/snapshots/{id}/executive-narrative`](#executive-narrative) | Narrative prose, with `?language=` | | [`GET /v1/snapshots/{id}/drift`](#changes-overlay-drift) | Changes overlay | | [`GET /v1/snapshots/{id}/briefing`](#the-briefing-sub-resource) | Sub-editor briefing block | All snapshot endpoints are bearer-authenticated reads (60/min bucket). An id that does not exist or belongs to another account returns `404 not_found`. ## The envelope The `data` object of a snapshot has this top-level shape: ```text items[] regulatory items — the core payload trends[] cross-item trends executive_summary { bottom_line, priorities[] } executive_narrative prose written for an executive reader (optional) _briefing sub-editor editorial block (optional; see below) driftOverlay changes vs a prior snapshot (optional; see below) translations { "": { executive_narrative, … } } (optional) _meta { engine, model, searches, estimatedCost, inputFingerprint, … } ``` Each item carries at minimum a `jurisdiction` and an `area`; typical items also have `title`, `source`, `impact` (`High` | `Medium` | `Low`), `likelihood` (`Confirmed` | `Likely` | `Possible`), `date`, and `summary`. Additional fields may appear over time — treat the envelope as open. ### The `_briefing` block `_briefing` is the sub-editor's output — the editorial furniture the product's Briefing tab renders around the narrative. Seven documented fields: | Field | Contents | |---|---| | `briefing_headline` | Editorial headline for the briefing, six words or fewer, in the register of a broadsheet analysis piece. | | `briefing_standfirst` | One orienting sentence standing under the headline: what the briefing covers and why it matters now. | | `priorities[]` | One entry per `executive_summary.priorities` entry, in the same order. Each is `{ short_label, tags }` — a 2–3-word contents-list label and a `"JURISDICTION · INSTRUMENT"` tag (e.g. `"EU · MiCA"`). | | `bottom_line_tight` | The briefing's "so what" in one or two sentences — a fresh closing line, not a truncation of `executive_summary.bottom_line`. | | `pull_quote` | A two-sentence executive pull quote (~40 words) sharpening one specific point from the narrative body, with one key number or date. | | `sentiment_label` | One-word posture label: `Tightening`, `Stable`, `Easing`, `Mixed`, or `Volatile`. | | `sentiment_rationale` | One sentence (30 words at most) explaining the sentiment label. | Fields are validated independently after generation: a field that fails validation is **absent**, not `null` — treat every field as optional, and the whole block as optional on older snapshots and engine paths that skip the sub-editor. ## List snapshots `GET /v1/snapshots` | Query parameter | Type | Default | Notes | |---|---|---|---| | `limit` | integer | `50` | 1–100. | | `offset` | integer | `0` | Offset paging; `pagination.total` gives the full count. | | `from` / `to` | ISO 8601 date-time | — | Filter on creation time. | | `jurisdiction` | string | — | Exact match against any item's `jurisdiction`. | | `area` | string | — | Exact match against any item's `area`. | Snapshot starring is retired: there is no `starred` filter, and sending one is rejected with `422` and code [`unknown_parameter`](https://docs.regsn.app/api/errors#error-codes) rather than silently returning the unfiltered list. ```bash curl "https://api.regsn.app/v1/snapshots?jurisdiction=UK&from=2026-06-01T00:00:00Z&limit=10" \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200`: ```json { "data": [ { "id": "a1b2…", "title": "UK · EU — AML / KYC (12m)", "created_at": "2026-07-20T09:14:11.000Z", "cost_cents": 55, "actual_cost_cents": 61.4, "item_count": 18, "trend_count": 4, "jurisdiction_count": 2 } ], "pagination": { "limit": 10, "offset": 0, "total": 37 } } ``` List rows are summaries — counts, not content. Fetch the id for the envelope. ## Retrieve a snapshot `GET /v1/snapshots/{id}` ```bash curl https://api.regsn.app/v1/snapshots/a1b2… \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200`: ```json { "id": "a1b2…", "title": "UK · EU — AML / KYC (12m)", "config": { "jurisdictions": ["UK", "EU"], "areas": ["AML / KYC"], "horizon": 12 }, "data": { "items": ["…"], "trends": ["…"], "executive_summary": { "bottom_line": "…", "priorities": ["…"] }, "executive_narrative": "Over the next twelve months…", "_meta": { "engine": "v4", "model": "…" } }, "cost_cents": 61.4, "created_at": "2026-07-20T09:14:11.000Z" } ``` | Field | Notes | |---|---| | `config` | The scan configuration that produced this snapshot. | | `data` | The envelope, verbatim. | | `cost_cents` | Actual cost where known, otherwise the pre-scan estimate. US cents; may carry fractions of a cent (`61.4`). | ## Sub-resources Three sub-resources project a single key out of the envelope, so you can fetch just what you need instead of the whole document: | Endpoint | Returns | |---|---| | `GET /v1/snapshots/{id}/items` | `{ "data": [ …items ] }` | | `GET /v1/snapshots/{id}/trends` | `{ "data": [ …trends ] }` | | `GET /v1/snapshots/{id}/executive-summary` | `{ "data": { "bottom_line": "…", "priorities": ["…"] } }` — `{ "data": null }` if the snapshot has none | ```bash curl https://api.regsn.app/v1/snapshots/a1b2…/items \ -H "Authorization: Bearer $REGSN_API_KEY" ``` ## Executive narrative `GET /v1/snapshots/{id}/executive-narrative` | Query parameter | Default | Notes | |---|---|---| | `language` | `en` | `en` returns the original narrative. Any other code (`fr`, `de`, `es`, `it`, `zh`, `ja`, `pt`) returns the matching translation **if the scan was configured with [`translationLanguages`](https://docs.regsn.app/api/scans#request-body)**. | ```bash curl "https://api.regsn.app/v1/snapshots/a1b2…/executive-narrative?language=fr" \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200`: ```json { "executive_narrative": "Au cours des douze prochains mois…", "language": "fr" } ``` | Status · `code` | When | |---|---| | `404 not_found` | The snapshot has no narrative (`language=en`), or the id does not exist. | | `404 translation_not_available` | No translation exists for the requested non-English language. | ## Changes overlay (`/drift`) `GET /v1/snapshots/{id}/drift` returns the snapshot's `driftOverlay` — the scan-time comparison recorded when the snapshot was created: what moved between this snapshot and the prior comparable one. The product's [Change Monitor](https://docs.regsn.app/concepts/changes) card is a richer, recomputed-on-read view of the same question. The field keeps its original name on the wire for stability. ```bash curl https://api.regsn.app/v1/snapshots/a1b2…/drift \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200` — the overlay object, verbatim. When the snapshot has no comparison (for example, the first scan of a given configuration): ```json { "available": false } ``` **Note:** The overlay is only present when an earlier snapshot with a comparable configuration existed at scan time. Treat `{ "available": false }` as the normal first-run case, not an error. ## The briefing sub-resource `GET /v1/snapshots/{id}/briefing` returns the [`_briefing` block](#the-_briefing-block) without fetching the whole envelope. ```bash curl https://api.regsn.app/v1/snapshots/a1b2…/briefing \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200` — `{ "available": true }` plus the briefing fields: ```json { "available": true, "briefing_headline": "The grace period is over", "pull_quote": "…", "sentiment_label": "Tightening", "sentiment_rationale": "…" } ``` Snapshots that predate the sub-editor, or whose pass produced no valid fields, return the same shape as `/drift`'s first-run case: ```json { "available": false } ``` **Note:** `{ "available": false }` is a routine state on older snapshots, not an error — 404 is reserved for the snapshot itself being missing. Individual fields are validated independently and may be absent even when `available` is `true`. ## See also - [Scans](https://docs.regsn.app/api/scans) — how snapshots get made. - [Exports](https://docs.regsn.app/api/exports) — turn a snapshot into a PDF, deck, infographic, or audio briefing. - [Changes between scans](https://docs.regsn.app/concepts/changes) — the product-side view of the overlay. --- # Exports Source: https://docs.regsn.app/api/exports (markdown: https://docs.regsn.app/api/exports.md) > Queue export jobs against a snapshot, poll them, download the artefact, and the full per-type options vocabulary. An export turns a [snapshot](https://docs.regsn.app/api/snapshots) into a deliverable artefact — a PDF, CSV, slide deck, infographic, podcast, or video. Exports always run asynchronously: you queue a job, poll it, then download the result. One snapshot can feed any number of exports. | Endpoint | Purpose | |---|---| | [`POST /v1/exports`](#create-an-export-job) | Queue a job | | [`GET /v1/exports`](#list-export-jobs) | List your jobs, with filters | | [`GET /v1/exports/{id}`](#poll-an-export-job) | Poll one job | | [`GET /v1/exports/{id}/download`](#download-the-artefact) | Stream the finished artefact | | [`DELETE /v1/exports/{id}`](#delete-an-export-job) | Delete a job and its artefact bytes | **The recipe:** 1. `GET /v1/meta/export-types` — every export type, as a `(provider, artifact_type)` pair with a machine-readable `options_schema`. See [Discovery](https://docs.regsn.app/api/discovery#export-types). 2. `POST /v1/exports` with `snapshot_id`, the pair, and any `options`. 3. Poll `GET /v1/exports/{id}` until `status` is `completed`, then fetch `download_url`. ## Create an export job `POST /v1/exports` — bearer auth; rate-limited to **30 exports per hour per key**; accepts [`Idempotency-Key`](https://docs.regsn.app/api/idempotency). ### Request body | Field | Type | Required | Notes | |---|---|---|---| | `snapshot_id` | string (uuid) | yes | A snapshot owned by you — from `POST /v1/scans` or `GET /v1/snapshots`. | | `provider` | string | yes | Provider key, e.g. `internal-pdf`, `notebooklm`. | | `artifact_type` | string | yes | Valid only paired with the matching provider — see [the catalogue](#export-types-and-options). Unknown pairs return `422`. | | `options` | object | no | Per-type string fields, validated against the registry. Unknown option names and out-of-vocabulary values return `422` with did-you-mean hints and the valid list. | ```bash curl https://api.regsn.app/v1/exports \ -H "Authorization: Bearer $REGSN_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "snapshot_id": "a1b2…", "provider": "internal-pptx", "artifact_type": "slide-deck", "options": { "theme": "light" } }' ``` `202`: ```json { "export_job_id": "c3d4…", "status": "queued", "status_url": "/v1/exports/c3d4…", "download_url": null } ``` More examples: ```bash filename="gemini-infographic, non-default style" curl https://api.regsn.app/v1/exports \ -H "Authorization: Bearer $REGSN_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "snapshot_id": "a1b2…", "provider": "gemini-infographic", "artifact_type": "infographic-custom", "options": { "styleSlug": "riso-tritone-gem", "planModel": "opus" } }' ``` ```bash filename="NotebookLM podcast, deep dive, long" curl https://api.regsn.app/v1/exports \ -H "Authorization: Bearer $REGSN_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{ "snapshot_id": "a1b2…", "provider": "notebooklm", "artifact_type": "audio", "options": { "audio_format": "DEEP_DIVE", "audio_length": "LONG", "instructions": "Focus on enforcement-action implications." } }' ``` ### Errors | Status · `code` | When | |---|---| | `404 not_found` | `snapshot_id` does not exist or belongs to another account. | | `409 idempotency_key_in_use` / `idempotency_in_progress` | See [Idempotency](https://docs.regsn.app/api/idempotency). | | `422 validation_error` | Missing field; unknown `provider:artifact_type` pair; invalid `options` — `errors[]` names each offending field (codes `unknown_option`, `invalid_value`, `invalid_type`, `too_long`) with the valid vocabulary. | | `429 rate_limit_exceeded` | The exports bucket is exhausted (30/hour). Honour `Retry-After`. | | `503 transient_error` | Service temporarily unavailable. Retry with the same `Idempotency-Key`. | ## Export types and options Sixteen `(provider, artifact_type)` pairs. All option values are **strings**. The authoritative, always-current schema is `options_schema` on [`GET /v1/meta/export-types`](https://docs.regsn.app/api/discovery#export-types); this table reflects it as of 20-07-2026. | `provider` | `artifact_type` | Options (defaults in bold) | |---|---|---| | `internal-pdf` | `pdf` | — | | `internal-csv` | `csv` | — | | `internal-tearsheet` | `tearsheet` | `targetLanguage`; `editorialModel` (deprecated — accepted but ignored) | | `internal-pptx` | `slide-deck` | `theme`: `light` \| **`dark`**; `targetLanguage`; `editorialModel` (deprecated — accepted but ignored) | | `frontend-slides` | `slide-web` | `styleSlug`: **`dark-editorial`** \| `light-consulting`; `targetLanguage` | | `gemini-infographic` | `tearsheet-detailed` | `styleSlug` (12 styles, default **`bloomberg-editorial-gem`**); `planModel`: **`sonnet5`** \| `sonnet` \| `opus` \| `opus48`; `targetLanguage` | | `gemini-infographic` | `infographic-custom` | `styleSlug` (21 styles, default **`bloomberg-editorial-gem`**); `planModel` (default **`opus`**); `targetLanguage` | | `openai-infographic` | `tearsheet-detailed` | `styleSlug` (12 styles, default **`bloomberg-editorial-oai`**); `targetLanguage` | | `openai-infographic` | `infographic-custom` | `styleSlug` (21 styles, default **`bloomberg-editorial-oai`**); `targetLanguage` | | `notebooklm` | `infographic` | `style` (10 styles, default **`PROFESSIONAL`** — full list under Field notes); `detail_level`: `CONCISE` \| **`STANDARD`** \| `DETAILED`; `orientation`: **`LANDSCAPE`** \| `PORTRAIT` \| `SQUARE`; `instructions`; `targetLanguage` | | `notebooklm` | `slide-detailed` | `slide_length`: `SHORT` \| **`DEFAULT`**; `instructions`; `targetLanguage` | | `notebooklm` | `audio` | `audio_format`: **`DEBATE`** \| `DEEP_DIVE` \| `BRIEF` \| `CRITIQUE`; `audio_length`: `SHORT` \| **`DEFAULT`** \| `LONG`; `instructions`; `targetLanguage` | | `notebooklm` | `video-explainer` | `instructions`; `targetLanguage` | | `notebooklm` | `video` | `video_format`: **`CINEMATIC`**; `instructions`; `targetLanguage` | | `elevenlabs-briefing` | `podcast-briefing` | `voiceId`; `modelId` (alias `model_id`); `targetLanguage` | | `elevenlabs-discussion` | `podcast-discussion` | `modelId` (alias `model_id`); `targetLanguage` | Field notes: - **`targetLanguage`** — a language code matching a translation present on the snapshot (e.g. `fr`, `de`; see [`translationLanguages`](https://docs.regsn.app/api/scans#request-body)). Omit for English. The podcast types fall back to English when the requested translation is missing — and the `notebooklm` `audio` type's default `DEBATE` format is English-only regardless of `targetLanguage`, as its product label says. - **`style`** — the `notebooklm` `infographic` visual style: `PROFESSIONAL` (default), `EDITORIAL`, `SCIENTIFIC`, `SKETCH_NOTE`, `BENTO_GRID`, `BRICKS`, `CLAY`, `INSTRUCTIONAL`, `KAWAII` or `ANIME`. - **`instructions`** — free text up to 2,000 characters steering the generator (NotebookLM types only). - **`styleSlug`** — visual style anchor for the infographic types. The full per-type catalogue, with slugs, lives in `options_schema` on [`GET /v1/meta/export-types`](https://docs.regsn.app/api/discovery#export-types) — do not hardcode it. - **`editorialModel`** — deprecated. Still accepted for backwards compatibility, but has no effect. - `notebooklm` types require the NotebookLM integration to be configured on your account (`requires_provider: "notebooklm"` in the catalogue); the `elevenlabs-*` podcast types likewise (`requires_provider: "elevenLabsPodcast"`). **Note:** Two account-level settings affect behaviour without appearing in the request. **Free-text customisation** — if it is disabled for your account, `instructions` values are replaced server-side with your account's defaults rather than rejected. **Expedite** — whether AI-generated exports run in the real-time lane or the slower batch lane is a stored account preference, not a request option; it applies to bearer-key jobs exactly as it does in the dashboard. ## List export jobs `GET /v1/exports` | Query parameter | Default | Notes | |---|---|---| | `snapshot_id` | — | Only jobs for this snapshot. | | `status` | — | Comma-separated subset of `queued`, `processing`, `completed`, `failed`, `cancelled`. Unknown values return `422`. | | `limit` | `50` | Max 100. Newest first. | ```bash curl "https://api.regsn.app/v1/exports?status=queued,processing&limit=20" \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200` — `{ "data": [ …job objects… ] }` in the shape below. ## Poll an export job `GET /v1/exports/{id}` ```bash curl https://api.regsn.app/v1/exports/c3d4… \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200`: ```json { "id": "c3d4…", "status": "completed", "artifact_type": "slide-deck", "provider": "internal-pptx", "snapshot_id": "a1b2…", "created_at": "2026-07-20T10:00:00.000Z", "completed_at": "2026-07-20T10:03:41.000Z", "cost_cents": 12, "error": null, "result_mime": "application/vnd.openxmlformats-officedocument.presentationml.presentation", "result_filename": "regulatory-snapshot.pptx", "result_size_bytes": 482133, "download_url": "/v1/exports/c3d4…/download" } ``` `status` is one of `queued`, `processing`, `completed`, `failed`, `cancelled`. `download_url` is populated only when `completed`; on `failed`, `error` carries the reason. `404 not_found` for an id that does not exist or belongs to another account. ## Download the artefact `GET /v1/exports/{id}/download` — streams the raw bytes. ```bash curl -OJ https://api.regsn.app/v1/exports/c3d4…/download \ -H "Authorization: Bearer $REGSN_API_KEY" ``` Semantics: - `Content-Type` is the job's `result_mime`; `Content-Disposition` supplies `result_filename` (`-OJ` saves under it). - Audio, video, PDF, and image types are served `inline` (so players and viewers can point at the URL); everything else is `attachment`. - **Audio and video support HTTP range requests** — `Accept-Ranges: bytes`, partial content as `206`. Other types ignore `Range`. | Status · `code` | When | |---|---| | `404 not_found` | The id does not exist or belongs to another account. | | `409 not_ready` | Job is not `completed` yet. | | `410 gone` | The job completed but the artefact bytes are no longer retained. Re-run the export. | | `416 range_not_satisfiable` | `Range` outside the resource (audio/video only). | ## Delete an export job `DELETE /v1/exports/{id}` — removes the job and its stored artefact bytes. Mutations bucket (30/min). ```bash curl -X DELETE https://api.regsn.app/v1/exports/c3d4… \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `204` on success; `404 not_found` if the id does not exist or belongs to another account. Deleting a job does not affect the snapshot it was built from. ## See also - [Discovery](https://docs.regsn.app/api/discovery#export-types) — the machine-readable export catalogue. - [Usage & budget](https://docs.regsn.app/api/usage) — export costs deplete the same pool as scans. - [Studio, in the product](https://docs.regsn.app/using/studio) — the dashboard surface over the same export engine. --- # Discovery (meta) Source: https://docs.regsn.app/api/discovery (markdown: https://docs.regsn.app/api/discovery.md) > The five /v1/meta endpoints — engines, models, jurisdictions, areas, and export types — for discovering valid configuration values at runtime. The `/v1/meta/*` endpoints list the platform's current vocabulary — engines, models, jurisdictions, regulatory areas, and export types — so clients can discover valid values at runtime instead of hardcoding them. All five are cheap bearer-authenticated reads (60/min bucket) with no parameters. | Endpoint | Feeds | |---|---| | [`GET /v1/meta/engines`](#engines) | `engine` and `horizon` on [`POST /v1/scans`](https://docs.regsn.app/api/scans) | | [`GET /v1/meta/models`](#models) | `model` / `searchModel` on `POST /v1/scans` | | [`GET /v1/meta/jurisdictions`](#jurisdictions) | `jurisdictions` on `POST /v1/scans` | | [`GET /v1/meta/areas`](#areas) | `areas` on `POST /v1/scans` | | [`GET /v1/meta/export-types`](#export-types) | The whole body of [`POST /v1/exports`](https://docs.regsn.app/api/exports) | ## Engines `GET /v1/meta/engines` ```bash curl https://api.regsn.app/v1/meta/engines \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200` — the current response, in full: ```json { "data": [ { "id": "v4", "label": "V4", "description": "V4 classic" }, { "id": "v4.5-alpha", "label": "V4.5α", "description": "Verifier-aware (Sonnet+Tools)" }, { "id": "v4.5-beta", "label": "V4.5β", "description": "Verifier-aware (SerpAPI/Firecrawl)" } ], "horizons": [3, 6, 12, 18, 24, 36] } ``` | Field | Notes | |---|---| | `data[].id` | The value to send as `engine` on `POST /v1/scans`. | | `data[].label` / `description` | Display strings, as shown in the product UI. | | `horizons` | Valid `horizon` values, in months. | ## Models `GET /v1/meta/models` — the model catalogue, grouped by provider. The catalogue is dynamic; always read it rather than assuming these ids. ```bash curl https://api.regsn.app/v1/meta/models \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200` (truncated example): ```json { "data": [ { "provider": "anthropic", "label": "Anthropic", "configured": true, "models": [ { "id": "sonnet", "label": "Sonnet 4.6", "role": "analyst", "tier": null, "model_id": "claude-sonnet-4-6" } ] } ] } ``` | Field | Notes | |---|---| | `data[].provider` | Provider key (`anthropic`, `openai`, `gemini`, `deepl`, `cohere`, `perplexity`). | | `data[].configured` | Whether the provider is usable on this deployment. Unconfigured providers are listed but their models will fail at scan time. | | `models[].id` | The value to send as `model` / `searchModel` on `POST /v1/scans`. | | `models[].role` | Which pipeline role the entry is offered for. | | `models[].tier` | Optional tier tag, or `null`. | | `models[].model_id` | The provider's own identifier for the model, where applicable. | | `models[].pro_variant` | Optional `{ id, label, model_id }` — a higher-capability variant selectable by its own `id`. | Note `model: "haiku"` is rejected on verifier-aware scan configs — see [Scans](https://docs.regsn.app/api/scans#request-body). ## Jurisdictions `GET /v1/meta/jurisdictions` — the jurisdiction vocabulary the product scans with, each with its principal regulators. ```bash curl https://api.regsn.app/v1/meta/jurisdictions \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200` (truncated): ```json { "data": [ { "id": "UK", "label": "UK", "regulators": ["FCA", "PRA", "BoE", "HMT", "PSR", "ICO"] }, { "id": "EU", "label": "EU", "regulators": ["EC", "ESMA", "EBA", "EIOPA", "ECB/SSM", "EDPB"] } ] } ``` Current ids: `US`, `EU`, `UK`, `Singapore`, `Hong Kong`, `Japan`, `Australia`, `Switzerland`, `Canada`, `Brazil`, `India`, `China`, `South Korea`. `POST /v1/scans` does not reject names outside this list (only count and length are validated) — but this list is what the product itself is tuned for. ## Areas `GET /v1/meta/areas` — the regulatory-area vocabulary. ```bash curl https://api.regsn.app/v1/meta/areas \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200`: ```json { "data": [ { "id": "Banking / Prudential", "label": "Banking / Prudential" }, { "id": "Capital Markets", "label": "Capital Markets" }, { "id": "Digital Assets / Crypto", "label": "Digital Assets / Crypto" }, { "id": "AML / KYC", "label": "AML / KYC" }, { "id": "Payments", "label": "Payments" }, { "id": "Data Privacy", "label": "Data Privacy" }, { "id": "Operational Resilience", "label": "Operational Resilience" }, { "id": "ESG / Sustainable Finance", "label": "ESG / Sustainable Finance" }, { "id": "Sanctions", "label": "Sanctions" }, { "id": "Research Bundling / Unbundling", "label": "Research Bundling / Unbundling" }, { "id": "Consumer Protection", "label": "Consumer Protection" } ] } ``` As with jurisdictions, free-text areas are accepted on `POST /v1/scans`; this is the recommended vocabulary. See also [jurisdictions and topics](https://docs.regsn.app/concepts/jurisdictions-and-topics) in the concepts guide. ## Export types `GET /v1/meta/export-types` — every `(provider, artifact_type)` pair accepted by [`POST /v1/exports`](https://docs.regsn.app/api/exports), each with a machine-readable options schema. ```bash curl https://api.regsn.app/v1/meta/export-types \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200` (one row shown): ```json { "data": [ { "key": "pptx", "label": "Regulation-focused", "provider": "internal-pptx", "artifact_type": "slide-deck", "group": "internal", "provider_label": "Internal", "requires_provider": null, "has_options": true, "options_schema": { "theme": { "type": "string", "enum": ["light", "dark"], "default": "dark", "description": "Deck visual theme." }, "editorialModel": { "type": "string", "enum": ["haiku", "sonnet", "opus"], "default": "sonnet", "description": "DEPRECATED — accepted for backwards compatibility but ignored. …" }, "targetLanguage": { "type": "string", "description": "…" } } } ] } ``` | Field | Notes | |---|---| | `key` / `label` / `group` / `provider_label` | Display metadata, as used in the product UI. | | `provider` + `artifact_type` | The pair to send on `POST /v1/exports`. | | `requires_provider` | Non-null when the type depends on an integration being configured for your account (`notebooklm`, `elevenLabsPodcast`). | | `has_options` | `true` when `options_schema` is non-empty. | | `options_schema` | Field name → `{ type, enum?, default?, description?, maxLength? }`. This is the validation vocabulary for the `options` object — unknown fields and out-of-enum values are rejected with `422`. | Build export UIs and pipelines from `options_schema` rather than hardcoding — style catalogues in particular change over time. A human-readable summary is on the [Exports](https://docs.regsn.app/api/exports#export-types-and-options) page. --- # Usage & budget Source: https://docs.regsn.app/api/usage (markdown: https://docs.regsn.app/api/usage.md) > GET /v1/usage for request, scan, export, and cost telemetry; GET /v1/usage/budget for the account budget pool. Two read endpoints cover accounting: `/v1/usage` aggregates your API activity and its cost; `/v1/usage/budget` reports the account budget pool so you can self-check before running work that would be refused. Both accept **either** a bearer key or a signed-in dashboard session ([details](https://docs.regsn.app/api/authentication#dual-authentication-on-v1usage)), and both count against the reads bucket (60/min). **Note:** **One pool.** Scans and exports run over the API deplete the same budget the regsn.app UI consumes — there is no separate API meter. All `*_cents` values are US cents. ## Usage `GET /v1/usage` | Query parameter | Default | Notes | |---|---|---| | `from` | 30 days ago | ISO 8601 date-time. | | `to` | now | ISO 8601 date-time. Must not be earlier than `from` (`422` otherwise). | | `group_by` | `day` | `day`, `endpoint`, or `key`. Unrecognised values fall back to `day`. | ```bash curl "https://api.regsn.app/v1/usage?group_by=endpoint&from=2026-07-01T00:00:00Z" \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200`: ```json { "totals": { "request_count": 412, "scan_count": 9, "export_count": 31, "error_count": 3, "total_cost_cents": 618, "avg_latency_ms": 184 }, "buckets": [ { "key": "POST /scans", "request_count": 9, "scan_count": 9, "export_count": 0, "error_count": 1, "cost_cents": 512, "avg_latency_ms": 2210 } ], "filters": { "from": "2026-07-01T00:00:00.000Z", "to": "2026-07-20T12:00:00.000Z", "group_by": "endpoint" } } ``` ### Semantics | Field | Meaning | |---|---| | `totals` | Aggregates over the whole window. `error_count` counts responses with status ≥ 400. `avg_latency_ms` is `null` when no latency data exists. | | `buckets[].key` | Depends on `group_by`: a `YYYY-MM-DD` day, a `METHOD /path` pair, or an API-key id. | | `buckets[].cost_cents` | Cost attributed to requests in the bucket — a scan's cost lands on the request that created it, an export's on the request that queued it. Reads cost nothing. | With `group_by=key`, each bucket is additionally decorated so you can attribute usage without a second lookup: ```json { "key": "3f2c…", "key_name": "production-backend", "key_prefix": "regsn_live_aBcD…", "key_revoked": false, "request_count": 388 } ``` Revoked keys are included — history keeps its attribution. Day buckets sort chronologically; endpoint and key buckets sort by cost, highest first. ### Errors | Status · `code` | When | |---|---| | `422 validation_error` | `from`/`to` not parseable as ISO 8601, or `from` after `to` (field code `invalid_range`). | ## Budget `GET /v1/usage/budget` — the same accounting that decides whether `POST /v1/scans` returns `402`. Call it before a batch run to avoid burning a scan-bucket slot on a request that will be refused. ```bash curl https://api.regsn.app/v1/usage/budget \ -H "Authorization: Bearer $REGSN_API_KEY" ``` `200`: ```json { "allowed": true, "budget_cents": 5000, "spent_cents": 3182, "remaining_cents": 1818, "role": "user", "message": "$18.18 remaining of $50.00" } ``` | Field | Meaning | |---|---| | `allowed` | Whether a new scan would currently be accepted on budget grounds. | | `budget_cents` | The account's budget cap. `null` means no cap. | | `spent_cents` | Spend against the pool. | | `remaining_cents` | `budget_cents − spent_cents`, floored at `0` when exhausted; `null` when uncapped. | | `role` | `user` or `admin`. | | `message` | Human-readable summary of the same numbers. | When the pool is exhausted, `allowed` is `false` and the next `POST /v1/scans` returns [`402 budget_exhausted`](https://docs.regsn.app/api/errors). Budgets are set at account level by your workspace administrator — raising a cap is a conversation with them, not an API call or a self-service setting. ## See also - [Rate limits](https://docs.regsn.app/api/rate-limits) — request-frequency limits, distinct from budget. - [Scans](https://docs.regsn.app/api/scans#estimate-a-scan) — estimate a scan's cost before running it. - [Authentication](https://docs.regsn.app/api/authentication) — key attribution and the dual-auth rule. --- # Idempotency Source: https://docs.regsn.app/api/idempotency (markdown: https://docs.regsn.app/api/idempotency.md) > The Idempotency-Key header — 24-hour replay window, body fingerprinting, and the conflict cases. `POST /v1/scans` and `POST /v1/exports` do real, billable work — a duplicated request is a duplicated scan or export. The `Idempotency-Key` header makes retries safe: the first request with a given key executes; any replay of the same key with the same body returns the original response instead of running again. ```bash curl https://api.regsn.app/v1/scans \ -H "Authorization: Bearer $REGSN_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: 5f2b7c1e-0a44-4c5b-9d3e-8a1f2b3c4d5e" \ -d '{ "jurisdictions": ["UK"], "areas": ["Payments"], "horizon": 6 }' ``` ## Rules | Property | Value | |---|---| | Header | `Idempotency-Key` | | Format | 1–255 printable ASCII characters (a UUID is the sensible choice) | | Endpoints | `POST /v1/scans`, `POST /v1/exports` (ignored elsewhere) | | Scope | Per API key **and** per endpoint — the same string used on `/v1/scans` and on `/v1/exports` names two unrelated records | | Window | 24 hours | | Cached | Successful (2xx) responses only | | Optional | Yes — omit the header and the request executes normally | The request **body** is fingerprinted (top-level key order does not matter). Replay behaviour depends on what matches: | Situation | Result | |---|---| | Same key, same body, original succeeded | Original response replayed, with header `Idempotency-Replayed: true` | | Same key, same body, original still running | `409` · `idempotency_in_progress` — wait and retry the same key | | Same key, **different body** | `409` · `idempotency_key_in_use` — use a fresh key for a new request | | Same key, original failed (non-2xx) | Not cached — the retry executes normally | | Malformed header | `422` · `invalid_idempotency_key` | **Note:** **Failures are not cached — by design.** If your scan hit `402 budget_exhausted` or a `503`, retrying with the same key re-executes rather than replaying the error. You only ever "lock in" a success. ## Replay in practice ```bash # First call: executes, returns 202 curl -s -D - https://api.regsn.app/v1/exports \ -H "Authorization: Bearer $REGSN_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: export-a1b2-pdf-v1" \ -d '{ "snapshot_id": "a1b2…", "provider": "internal-pdf", "artifact_type": "pdf" }' # Identical retry (e.g. after a client timeout): same 202 body, no new job # Response now includes: # Idempotency-Replayed: true ``` Check for the `Idempotency-Replayed: true` header when it matters whether work actually ran. ## Recommendations - **Generate one UUID per logical operation** and reuse it across retries of that operation — not per HTTP attempt. - Deterministic keys (e.g. `nightly-scan-2026-07-20`) are useful for cron-style jobs: a rerun of the same tick can never double-scan. Keep the 24-hour window in mind for schedules longer than a day. - Both [SDKs](https://docs.regsn.app/api/sdks/javascript) auto-generate a UUID key for every `POST` when you do not pass one, so their internal retries are always safe. Pass your own key when retries span process restarts. ## See also - [Errors](https://docs.regsn.app/api/errors) — the `409`/`422` codes above, in context. - [Rate limits](https://docs.regsn.app/api/rate-limits) — pair `Retry-After` waits with the same key. --- # Rate limits Source: https://docs.regsn.app/api/rate-limits (markdown: https://docs.regsn.app/api/rate-limits.md) > The five rate-limit buckets, the RateLimit response headers, and how to behave on 429. Requests are rate-limited per API key (key management, which uses a dashboard session, is limited per user). Limits protect the platform's shared capacity; they are independent of your [budget](https://docs.regsn.app/api/usage#budget), which limits spend rather than frequency. ## Buckets | Bucket | Limit | Window | Applies to | |---|---|---|---| | reads | 60 | 1 minute | Every `GET` except the SSE stream and `/v1/keys/*`, plus `POST /v1/scans/estimate` | | mutations | 30 | 1 minute | `POST /v1/scans/{id}/cancel`, `DELETE /v1/exports/{id}` | | scans | 6 | 1 hour | `POST /v1/scans` | | exports | 30 | 1 hour | `POST /v1/exports` | | key management | 10 | 1 minute | `/v1/keys/*` (per user, dashboard session) | `GET /v1/scans/{id}/stream` is not rate-limited — hold one long-lived stream per scan rather than polling tightly. **Note:** The scans bucket is deliberately small: **6 scan creations per hour per key**. `POST /v1/scans/estimate` costs nothing from it — estimate freely, scan deliberately. A `429` from this bucket can mean waiting up to an hour, so schedule batch work accordingly. ## Response headers Successful responses on limited endpoints carry the IETF draft-7 standard headers: ```text RateLimit-Policy: 60;w=60 RateLimit: limit=60, remaining=57, reset=42 ``` - `RateLimit-Policy` — the bucket's policy: limit and window (seconds). - `RateLimit` — your current state: `limit`, `remaining` requests, and seconds until `reset`. ## When you are limited A `429` returns a [problem-details body](https://docs.regsn.app/api/errors) plus a `Retry-After` header (in seconds): ```http HTTP/1.1 429 Too Many Requests Retry-After: 3600 Content-Type: application/problem+json; charset=utf-8 { "type": "https://api.regsn.app/problems/rate_limited", "title": "Rate limit exceeded", "status": 429, "detail": "Rate limit exceeded for scans bucket. Retry after 3600s.", "instance": "/v1/scans", "code": "rate_limit_exceeded", "request_id": "req_m3k9…", "errors": [] } ``` Client guidance: - **Honour `Retry-After`.** Both [SDKs](https://docs.regsn.app/api/sdks/javascript) do this automatically (capped at 60 seconds per wait, up to 3 retries). - **Watch `remaining`** on the `RateLimit` header and pace proactively instead of driving into the limit. - **Pair retries with idempotency.** A retried `POST /v1/scans` or `POST /v1/exports` with the same [`Idempotency-Key`](https://docs.regsn.app/api/idempotency) can never double-run work. - **Prefer streaming to polling** for scan progress — the stream is unmetered; polling spends the reads bucket. ## See also - [Errors](https://docs.regsn.app/api/errors) — the `429` body shape and every other code. - [Usage & budget](https://docs.regsn.app/api/usage) — spend limits, as opposed to frequency limits. --- # Errors Source: https://docs.regsn.app/api/errors (markdown: https://docs.regsn.app/api/errors.md) > RFC 9457 problem details, the X-Request-Id header, and the complete error-code table. Every error response from the API is an [RFC 9457](https://www.rfc-editor.org/rfc/rfc9457) problem-details document with `Content-Type: application/problem+json`, and every response — success or error — carries an `X-Request-Id` header. The one exception is malformed transport: a request rejected before it reaches the API layer (unparseable JSON, a body over the 2 MB cap) gets a plain `400`/`413` with neither a problem body nor a request id. ## The shape ```json { "type": "https://api.regsn.app/problems/validation", "title": "Validation error", "status": 422, "detail": "horizon must be one of 3, 6, 12, 18, 24, 36", "instance": "/v1/scans", "code": "validation_error", "request_id": "req_m3k9f2ab8xk2p91q", "errors": [ { "path": "horizon", "code": "invalid", "message": "horizon must be one of 3, 6, 12, 18, 24, 36" } ] } ``` | Field | Meaning | |---|---| | `type` | Stable problem URI: `https://api.regsn.app/problems/`. | | `title` | Human-readable category for the status. | | `status` | The HTTP status, repeated in the body. | | `detail` | What went wrong, specifically. Unexpected 5xx never leak internals — their `detail` is the generic `"Internal server error"`; deliberate 5xx (for example a `503` when the database is unavailable) keep a specific message. | | `instance` | The request path that produced the error. | | `code` | **Machine-readable error code — branch on this**, not on `detail` strings. | | `request_id` | Matches the `X-Request-Id` header. | | `errors` | Per-field problems on validation failures; empty otherwise. Each entry: `{ path, code, message }`. | **Note:** **Quote the request id.** `request_id` (`req_…`) correlates your request with server-side traces end-to-end. Include it in any support message — it is the fastest route to an answer. ## Error codes The top-level `code`, by status: | Status | `code` | Meaning | What to do | |---|---|---|---| | 400 | `invalid_request` | Malformed request. Note unparseable JSON is rejected before the API layer, with a plain body rather than a problem document. | Fix the request. | | 401 | `authentication_required` | No bearer token. | Send `Authorization: Bearer regsn_live_…`. | | 401 | `authentication_invalid` | Token malformed or unknown. | Check the key value; [create one](https://docs.regsn.app/api/authentication) if needed. | | 401 | `key_revoked` | Key exists but was revoked. | Switch to an active key. | | 402 | `budget_exhausted` | Account budget pool depleted. | Check [`GET /v1/usage/budget`](https://docs.regsn.app/api/usage#budget); contact your workspace administrator to raise the cap. | | 403 | `permission_denied` | Authenticated but not allowed. | Verify the resource belongs to your account. | | 404 | `not_found` | Resource missing, or owned by another account. | Check the id. | | 404 | `translation_not_available` | No translation for the requested `language` on [`/executive-narrative`](https://docs.regsn.app/api/snapshots#executive-narrative). | Request `en`, or re-scan with [`translationLanguages`](https://docs.regsn.app/api/scans#request-body). | | 409 | `conflict` | Generic state conflict. | Re-read the resource. | | 409 | `invalid_state` | Scan already terminal on [`/cancel`](https://docs.regsn.app/api/scans#cancel-a-scan). | Nothing — it is already finished. | | 409 | `not_ready` | Export not `completed` on [`/download`](https://docs.regsn.app/api/exports#download-the-artefact). | Keep polling, then download. | | 409 | `idempotency_key_in_use` | Same `Idempotency-Key`, different body. | Use a fresh key for a genuinely new request. See [Idempotency](https://docs.regsn.app/api/idempotency). | | 409 | `idempotency_in_progress` | Original request with this key still running. | Wait, then retry with the same key. | | 410 | `gone` | Export completed but artefact bytes no longer retained. | Re-run the export. | | 416 | `range_not_satisfiable` | `Range` header outside the resource. | Fix or drop the `Range`. | | 422 | `validation_error` | One or more fields invalid — see `errors[]`. | Fix each listed field. | | 422 | `unknown_parameter` | A removed or unrecognised query parameter — currently `starred` on [`GET /v1/snapshots`](https://docs.regsn.app/api/snapshots#list-snapshots) (snapshot starring is retired). | Drop the parameter. | | 422 | `key_limit_exceeded` | Already at 10 active API keys. | Revoke one first. | | 422 | `invalid_idempotency_key` | `Idempotency-Key` not 1–255 printable ASCII characters. | Fix the header value. | | 429 | `rate_limit_exceeded` | Bucket exhausted. | Honour `Retry-After`. See [Rate limits](https://docs.regsn.app/api/rate-limits). | | 500 | `internal_error` | Unexpected server error. | Retry with backoff; report the `request_id` if it persists. | | 503 | `transient_error` | Temporarily unavailable (e.g. database). | Retry with backoff. Safe with the same `Idempotency-Key`. | | 503 | `engine_unavailable` | Requested scan engine not loaded. | Use an engine from [`GET /v1/meta/engines`](https://docs.regsn.app/api/discovery#engines). | ### Field-level codes Inside `errors[]` on a `422`, `path` names the offending field (e.g. `horizon`, `options.styleSlug`) and `code` is one of: | `errors[].code` | Meaning | |---|---| | `required` / `missing` | Required field absent. | | `invalid` | Value outside the allowed shape or vocabulary. | | `invalid_range` | `from` after `to` on [`/v1/usage`](https://docs.regsn.app/api/usage). | | `incompatible` | Field valid only in combination with another setting (e.g. `fetchProvider` without `engine: "v4.5-beta"`). | | `engine_deprecated` | A retired engine id (`v1`, `v2`, `v3`, `admiral`). | | `haiku_blocked_on_verifier` | `model: "haiku"` on a verifier-aware config. | | `unknown` | Unknown value (e.g. an unregistered `provider:artifact_type` pair or export status filter). | | `unknown_option` | Export option name not in the type's schema — the message includes a did-you-mean hint and the valid list. | | `invalid_value` | Export option value outside the enum — message lists valid values. | | `invalid_type` | Export option value not a string. | | `too_long` | String over its `maxLength`. | ## Retry guidance - **Retry** on `429` (after `Retry-After`), `500`, and `503`, with exponential backoff. - **Do not retry** `4xx` other than `429` without changing the request — the outcome will not change. - **Always pair POST retries with an [`Idempotency-Key`](https://docs.regsn.app/api/idempotency)** so a retry can never duplicate a scan or export. Failed (non-2xx) attempts are not cached, so the same key retries cleanly. Both [SDKs](https://docs.regsn.app/api/sdks/javascript) implement exactly this policy and surface errors as a typed exception carrying `status`, `code`, `request_id`, and the full body. --- # JavaScript SDK Source: https://docs.regsn.app/api/sdks/javascript (markdown: https://docs.regsn.app/api/sdks/javascript.md) > @regsn/api — the JavaScript client for the Regulatory Snapshot API: setup, methods, retries, and errors. `@regsn/api` is a small, dependency-free JavaScript client for the API — one ESM module plus TypeScript type definitions. | Property | Value | |---|---| | Package | `@regsn/api`, version 0.2.0 | | Runtime | Node 18+ (uses the built-in `fetch`) | | Module format | ESM only (`import`) | | Dependencies | None | | Types | Bundled (`index.d.ts`) | **Warning:** **Availability.** `@regsn/api` is source-available; publication to the public npm registry is pending, so `npm install @regsn/api` does not work yet. Until it lands, call the HTTP API directly — every page in this reference carries copy-pasteable curl, and the surface is small. This page documents the SDK for teams who already have the source. ## Setup ```js import { RegSn } from '@regsn/api'; const client = new RegSn({ apiKey: 'regsn_live_…' }); ``` | Constructor option | Default | Notes | |---|---|---| | `apiKey` | `process.env.REGSN_API_KEY` | Required, one way or the other. | | `baseUrl` | `https://api.regsn.app` | Override for testing. | | `timeoutMs` | `180000` | Per-request timeout (aborts the request). | ## Methods The client exposes four resources mirroring the HTTP surface: | Method | Calls | Notes | |---|---|---| | `client.scans.create(config, opts?)` | `POST /v1/scans` | `opts`: `mode` (`'sync'` default), `idempotencyKey`, `pollUntilDone` (`true` default). If the API returns `202`, polls until terminal. | | `client.scans.createAsync(config, opts?)` | `POST /v1/scans?mode=async` | Returns the `202` body immediately — no polling. | | `client.scans.get(scanId)` | `GET /v1/scans/{id}` | | | `client.scans.wait(scanId, opts?)` | polls `GET /v1/scans/{id}` | `opts`: `pollMs` (5 000), `timeoutMs` (720 000). Resolves with `{ scan_id, status, snapshot_id, snapshot }` — `snapshot` is the full `GET /v1/snapshots/{id}` body. Throws on failure or timeout. | | `client.snapshots.list(filters?)` | `GET /v1/snapshots` | `filters` become query parameters (`from`, `to`, `jurisdiction`, `area`, `limit`, `offset`). | | `client.snapshots.get(id)` | `GET /v1/snapshots/{id}` | | | `client.snapshots.getItems(id)` / `getTrends(id)` / `getExecutiveSummary(id)` | sub-resources | | | `client.snapshots.getExecutiveNarrative(id, { language })` | `GET …/executive-narrative` | `language` defaults `'en'`. | | `client.snapshots.getDrift(id)` | `GET …/drift` | | | `client.exports.create({ snapshot_id, artifact_type, provider, options }, opts?)` | `POST /v1/exports` | `opts.idempotencyKey` optional. | | `client.exports.get(id)` | `GET /v1/exports/{id}` | | | `client.usage.get(filters?)` | `GET /v1/usage` | `from`, `to`, `group_by`. | 0.2.0 also wraps [`scans.estimate`](https://docs.regsn.app/api/scans#estimate-a-scan), [`scans.cancel`](https://docs.regsn.app/api/scans#cancel-a-scan), export [list](https://docs.regsn.app/api/exports#list-export-jobs)/[download](https://docs.regsn.app/api/exports#download-the-artefact)/[delete](https://docs.regsn.app/api/exports#delete-an-export-job) (`exports.list` / `exports.download` / `exports.delete`), [`usage.budget`](https://docs.regsn.app/api/usage#budget), and the five [`/v1/meta/*`](https://docs.regsn.app/api/discovery) reads (`meta.engines` / `models` / `jurisdictions` / `areas` / `exportTypes`). Still not wrapped: the [SSE stream](https://docs.regsn.app/api/scans#stream-scan-progress-sse) — use `EventSource` or any SSE client. [Key management](https://docs.regsn.app/api/authentication#key-management-endpoints) is excluded **by design**: keys are minted and revoked only in a signed-in dashboard session at api.regsn.app, never with an API key, so there is nothing for an SDK to wrap. ## End to end ```js filename="scan-and-read.mjs" import { RegSn } from '@regsn/api'; const client = new RegSn(); // reads REGSN_API_KEY const result = await client.scans.create({ jurisdictions: ['UK', 'EU'], areas: ['AML / KYC'], horizon: 12, }); // Deterministic envelope shape regardless of sync/async path: const snap = await client.snapshots.get(result.snapshot_id); console.log(snap.data.executive_narrative); const job = await client.exports.create({ snapshot_id: result.snapshot_id, provider: 'internal-pdf', artifact_type: 'pdf', }); console.log(job.status_url); ``` **Note:** **Envelope shapes.** A fast sync scan resolves with the envelope flat under `snapshot`; when `create` had to poll, `snapshot` is the full `GET /v1/snapshots/{id}` body (envelope nested under `data`). Re-fetching by `snapshot_id`, as above, always gives the nested shape. ## Retries, idempotency, timeouts - Every `POST` gets an auto-generated UUID `Idempotency-Key` unless you pass `idempotencyKey` — the SDK's own retries can never duplicate a scan or export. - Up to 3 retries on network errors, `5xx`, and `429`. `Retry-After` is honoured, capped at 60 seconds per wait, with exponential backoff and jitter otherwise. - Requests abort after `timeoutMs` (default 180 s) via `AbortController`. ## Errors Failures throw `RegSnError`: ```js import { RegSn, RegSnError } from '@regsn/api'; try { await client.scans.create({ jurisdictions: ['UK'], areas: ['Payments'], horizon: 6 }); } catch (err) { if (err instanceof RegSnError) { console.error(err.status); // e.g. 402 console.error(err.code); // e.g. 'budget_exhausted' console.error(err.requestId); // 'req_…' — quote this in support requests console.error(err.body); // full problem-details document } } ``` SDK-generated codes (no HTTP status): `network_error`, `retry_exceeded`, `scan_failed` (from `wait` when a scan ends `failed`), `wait_timeout`. Everything else is the API's own [`code`](https://docs.regsn.app/api/errors). ## See also - [Python SDK](https://docs.regsn.app/api/sdks/python) — the same surface in Python. - [Quickstart](https://docs.regsn.app/api/quickstart) — the same flow with raw curl. --- # Python SDK Source: https://docs.regsn.app/api/sdks/python (markdown: https://docs.regsn.app/api/sdks/python.md) > regsn — the Python client for the Regulatory Snapshot API: setup, methods, retries, and errors. `regsn` is a single-file, standard-library-only Python client for the API — no dependencies to vet. | Property | Value | |---|---| | Package | `regsn`, version 0.2.0 | | Python | ≥ 3.8 | | Dependencies | None (stdlib `urllib`) | **Warning:** **Availability.** The `regsn` package is source-available; publication to the public PyPI index is pending, so `pip install regsn` does not work yet. Until it lands, call the HTTP API directly — every page in this reference carries copy-pasteable curl. This page documents the SDK for teams who already have the source. ## Setup ```python from regsn import RegSn client = RegSn(api_key="regsn_live_…") ``` | Constructor argument | Default | Notes | |---|---|---| | `api_key` | env `REGSN_API_KEY` | Required, one way or the other. | | `base_url` | `https://api.regsn.app` | Override for testing. | | `timeout_s` | `180` | Per-request timeout in seconds. | ## Methods | Method | Calls | Notes | |---|---|---| | `client.scans.create(**config, mode="sync", idempotency_key=None, poll_until_done=True)` | `POST /v1/scans` | Scan config fields are keyword arguments. If the API returns `202`, polls until terminal. | | `client.scans.create_async(**config, idempotency_key=None)` | `POST /v1/scans?mode=async` | Returns the `202` body immediately. | | `client.scans.get(scan_id)` | `GET /v1/scans/{id}` | | | `client.scans.wait(scan_id, poll_s=5, timeout_s=720)` | polls `GET /v1/scans/{id}` | Returns `{"scan_id", "status", "snapshot_id", "snapshot"}` — `"snapshot"` is the full `GET /v1/snapshots/{id}` body. Raises on failure or timeout. | | `client.snapshots.list(**filters)` | `GET /v1/snapshots` | `from`/`to` (pass as `**{"from": …}`), `jurisdiction`, `area`, `limit`, `offset`. | | `client.snapshots.get(snapshot_id)` | `GET /v1/snapshots/{id}` | | | `client.snapshots.get_items(id)` / `get_trends(id)` / `get_executive_summary(id)` | sub-resources | | | `client.snapshots.get_executive_narrative(id, language="en")` | `GET …/executive-narrative` | | | `client.snapshots.get_drift(id)` | `GET …/drift` | | | `client.exports.create(snapshot_id=…, artifact_type=…, provider=…, options=None, idempotency_key=None)` | `POST /v1/exports` | | | `client.exports.get(export_id)` | `GET /v1/exports/{id}` | | | `client.usage.get(**filters)` | `GET /v1/usage` | `group_by`, `from`, `to`. | 0.2.0 also wraps [`scans.estimate`](https://docs.regsn.app/api/scans#estimate-a-scan), [`scans.cancel`](https://docs.regsn.app/api/scans#cancel-a-scan), export [list](https://docs.regsn.app/api/exports#list-export-jobs)/[download](https://docs.regsn.app/api/exports#download-the-artefact)/[delete](https://docs.regsn.app/api/exports#delete-an-export-job), [`usage.budget`](https://docs.regsn.app/api/usage#budget), and the five [`/v1/meta/*`](https://docs.regsn.app/api/discovery) reads. Still not wrapped: the [SSE stream](https://docs.regsn.app/api/scans#stream-scan-progress-sse) — use any SSE client. [Key management](https://docs.regsn.app/api/authentication#key-management-endpoints) is excluded **by design**: keys are minted and revoked only in a signed-in dashboard session at api.regsn.app, never with an API key, so there is nothing for an SDK to wrap. ## End to end ```python filename="scan_and_read.py" from regsn import RegSn client = RegSn() # reads REGSN_API_KEY result = client.scans.create( jurisdictions=["UK", "EU"], areas=["AML / KYC"], horizon=12, ) # Deterministic envelope shape regardless of sync/async path: snap = client.snapshots.get(result["snapshot_id"]) print(snap["data"]["executive_narrative"]) job = client.exports.create( snapshot_id=result["snapshot_id"], provider="internal-pdf", artifact_type="pdf", ) print(job["status_url"]) ``` **Note:** **Envelope shapes.** A fast sync scan returns the envelope flat under `"snapshot"`; when `create` had to poll, `"snapshot"` is the full `GET /v1/snapshots/{id}` body (envelope nested under `"data"`). Re-fetching by `snapshot_id`, as above, always gives the nested shape. ## Retries, idempotency, timeouts - Every `POST` gets an auto-generated UUID `Idempotency-Key` unless you pass `idempotency_key` — the SDK's own retries can never duplicate a scan or export. - Up to 3 retries on network errors, `5xx`, and `429`. `Retry-After` is honoured, capped at 60 seconds per wait, with exponential backoff and jitter otherwise. - Requests time out after `timeout_s` (default 180 s). ## Errors Failures raise `RegSnError`: ```python from regsn import RegSn, RegSnError client = RegSn() try: client.scans.create(jurisdictions=["UK"], areas=["Payments"], horizon=6) except RegSnError as err: print(err.status) # e.g. 402 print(err.code) # e.g. 'budget_exhausted' print(err.request_id) # 'req_…' — quote this in support requests print(err.body) # full problem-details document ``` SDK-generated codes (no HTTP status): `network_error`, `retry_exceeded`, `scan_failed` (from `wait` when a scan ends `failed`), `wait_timeout`. Everything else is the API's own [`code`](https://docs.regsn.app/api/errors). ## See also - [JavaScript SDK](https://docs.regsn.app/api/sdks/javascript) — the same surface in JavaScript. - [Quickstart](https://docs.regsn.app/api/quickstart) — the same flow with raw curl. --- # Core concepts Source: https://docs.regsn.app/concepts (markdown: https://docs.regsn.app/concepts.md) > The object model behind Regulatory Snapshot — scans produce snapshots, snapshots hold items, every dashboard tab is a reading of a snapshot, and change is computed between snapshots of the same scope. Regulatory Snapshot is one engine with two front doors: the web app at regsn.app, where compliance and regulatory-affairs teams configure scans and read the results, and the [`/v1` API](https://docs.regsn.app/api), where the same engine is driven programmatically. Both speak the same vocabulary, and that vocabulary rests on a small number of objects. This page installs the whole model in one sitting; the rest of the section takes each object in turn. ## The model in one paragraph You describe a slice of the regulatory world — which **jurisdictions**, which **topic areas**, how far ahead — and run a **scan** over it. A completed scan is saved as a **snapshot**: a fixed, dated record of what the analysis found, made up of **items** (individual regulatory developments), **trends** (cross-cutting patterns), and an **executive summary and narrative**. Everything else in the product is downstream of a snapshot: the dashboard tabs are *readings* of it, exports are *derivatives* of it, and the Change Monitor is a *comparison* between it and an earlier snapshot of the same scope. Re-run the same configuration — by hand or on a schedule — and the snapshots line up into a **series**, which is what makes "what's changed since last time?" answerable at all. ## The object model ```mermaid flowchart TB config["Scan configuration
jurisdictions × areas × horizon"] scan["Scan
queued → running → complete"] snap["Snapshot
fixed at its scan date"] items["Items"] trends["Trends"] exec["Executive summary
+ narrative"] readings["Readings
Overview · Briefing · Trends · Timeline"] artefacts["Exports / artefacts
documents · decks · images · audio · video"] changes["What's changed
(Change Monitor)"] series["Series
same scope, over time"] sched["Scheduled scan"] config -->|run| scan sched -.->|each run| scan scan -->|on completion| snap snap --> items snap --> trends snap --> exec snap ==>|read as| readings snap ==>|derive| artefacts snap --> series series -.->|latest vs earlier| changes ``` Five relationships carry all the weight: 1. **A scan produces exactly one snapshot.** The scan is the verb, the snapshot is the noun. Scans are asynchronous — you can queue several, watch their progress, cancel one mid-flight — but the only lasting output of a successful scan is its snapshot. See [Scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots). 2. **A snapshot holds items.** Items are the atoms: one regulatory development each, with a jurisdiction, regulator, area, status, likelihood, impact, dates, a summary, and its sourcing. See [Items, sources and citations](https://docs.regsn.app/concepts/items-and-citations). 3. **The dashboard tabs are readings, not separate data.** Overview (the pressure heatmap and executive panels), Analyst Briefing, Trends and Timeline all render the *same* snapshot from different angles — a severity grid, a prose briefing, a pattern digest, a calendar. Filtering by likelihood, impact or status narrows one shared set of items, so the readings computed from items — the heatmap, the Timeline — move together; the Briefing narrative and the Trends ledger are editorial output written at scan time and stay as written. The product walkthrough starts at [the Overview tab](https://docs.regsn.app/using/overview). 4. **Exports derive from a snapshot.** Every artefact you generate in [Studio](https://docs.regsn.app/using/studio) — PDF, tearsheet, slide deck, infographic, podcast, video — is rendered from one named snapshot, so an artefact can always be traced back to the exact scan it summarises. The API surface is [`POST /v1/exports`](https://docs.regsn.app/api/exports). 5. **Change is computed between snapshots.** The Change Monitor on the Overview tab compares the loaded snapshot with your previous scan of the *same scope* and reports confirmed regulator events, coverage movements and unverified assertions — each kept honestly apart. See [What "changed" means](https://docs.regsn.app/concepts/changes). ## Why a snapshot, and not a live view A reasonable question: why fix results in time at all, rather than keep one continuously updated dashboard? Because the product's users need to be able to say *"this is what the landscape looked like when we briefed the board on 09-03-2026"* — and have that statement stay true. A snapshot is a point-in-time record: it never updates itself, its title carries its scope, and its scan date is stamped on the dashboard whenever it is loaded. Freshness comes from re-running the scan, not from mutating the record — and that discipline is exactly what makes the Change Monitor trustworthy, since a comparison between two fixed records cannot be contaminated by either of them shifting underneath it. The one deliberate exception proves the rule: the [Feed](https://docs.regsn.app/using/feed) is a live wire of recent regulator announcements across all jurisdictions, independent of any scan. It answers "what happened this week?" while snapshots answer "what does my landscape look like, and what changed in it?". ## A worked example Suppose you run a scan on 02-06-2026 scoped to **EU** and **UK**, areas **Capital Markets** and **ESG / Sustainable Finance**, horizon **12 months**: - The scan completes and saves a snapshot titled after its scope. One of its items is an EU consultation on fund-liquidity rules — status **Consultation**, likelihood **Likely**, impact **High**, an expected date inside your window, and a summary carrying numbered citation markers back to the scan's own sources. - That item appears simultaneously in the Overview cell *Capital Markets × EU*, on the Timeline at its expected date, and among the Briefing's priorities — three readings of one record. - You generate a slide deck from the snapshot in Studio for Thursday's risk committee. The deck names the snapshot it came from. - Three weeks later a scheduled re-run of the same configuration adds a second snapshot to the series. Its Change Monitor headlines a confirmed **Consultation closed** event for that instrument, with the regulator's own dated document linked — and that, rather than a re-read of the whole dashboard, is your Monday briefing. ## In this section - [Scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots) — the lifecycle, what a snapshot fixes in time, and how series form. - [Jurisdictions and topics](https://docs.regsn.app/concepts/jurisdictions-and-topics) — the coordinate system a scan is scoped in. - [Items, sources and citations](https://docs.regsn.app/concepts/items-and-citations) — the anatomy of a finding, and how to read the trust signals. - [What "changed" means](https://docs.regsn.app/concepts/changes) — the Change Monitor's three strata and why they are kept apart. - [Glossary](https://docs.regsn.app/glossary) — every term above, A–Z. --- # Scans and snapshots Source: https://docs.regsn.app/concepts/scans-and-snapshots (markdown: https://docs.regsn.app/concepts/scans-and-snapshots.md) > The lifecycle that turns a scan configuration into a snapshot — the states a running scan moves through, what a snapshot fixes in time, and how identical-scope re-runs form a series. A **scan** is the verb; a **snapshot** is the noun. Every snapshot was produced by exactly one scan, and every successful scan produces exactly one snapshot. The lifecycle that connects them is the most useful piece of mental furniture in the product, because everything else — readings, exports, change tracking — hangs off its output. ## The lifecycle ```mermaid stateDiagram-v2 direction LR [*] --> Queued : start scan Queued --> Running Running --> Complete : snapshot saved Running --> Failed Running --> Cancelled : cancel Complete --> [*] Failed --> [*] Cancelled --> [*] ``` **Queued.** The scan has been accepted and is waiting to start. In the app this is visible on the scan toast — the floating progress card that appears when you press Start scan; you can queue several scans and keep working, because a running scan never blocks the dashboard. **Running.** The analysis is under way. The toast shows a named phase, a percentage, and a live message as the work advances; the same progress is available to API callers by polling [`GET /v1/scans/{id}`](https://docs.regsn.app/api/scans) or subscribing to the scan's event stream. A running scan can be cancelled from its toast (or via the API); cancellation is a terminal state — no snapshot is produced. **Complete.** The toast reports *Analysis complete* with headline counts — changes, trends, jurisdictions — and a **View** affordance that loads the new snapshot into the dashboard. In the API the scan's status becomes `completed` and carries the `snapshot_id`. **Failed.** No snapshot is produced. The scan's error is shown on the toast and returned by the API. Retrying is simply running the scan again. The two failure-adjacent points worth internalising: a scan that outlives the API's 120-second synchronous window is *not* a failure (it continues in the background and returns `202` with a `scan_id` to follow), and a cancelled scan leaves no partial snapshot behind — snapshots are all-or-nothing. ## What a snapshot fixes in time A snapshot is a complete, self-contained record of one scan's findings, stamped with its scan date. Concretely, it fixes: - **The configuration** — which jurisdictions, which areas (including custom ones), what horizon. The snapshot's title is derived from this configuration unless you name it yourself. - **The findings** — the [items](https://docs.regsn.app/concepts/items-and-citations), the typed [trends](https://docs.regsn.app/using/trends), the executive summary (a bottom line plus priorities) and the long-form executive narrative read on the [Briefing tab](https://docs.regsn.app/using/briefing). - **The sourcing** — the scan's own source index, each source classified by tier, plus the citation audit that ties editorial sentences back to sources. This is what the [Sources tab](https://docs.regsn.app/using/sources) renders. - **Any translations** — switch the dashboard into another language and the translated narrative is cached on the snapshot itself, so the next reader gets it instantly. What a snapshot deliberately does *not* do is update. Regulators keep publishing after your scan finishes; the snapshot keeps saying what was true on its scan date. The dashboard makes this legible rather than hiding it — the scan date is pinned in the chrome (rendered DD-MM-YYYY) on every tab. **Note:** **A snapshot is evidence, not a feed.** If you need "now", re-run the scan — or glance at the [Feed](https://docs.regsn.app/using/feed), which is the product's one always-live surface. If you need "what moved since my last look", that is the [Change Monitor](https://docs.regsn.app/concepts/changes), and it depends on snapshots staying fixed. ## One snapshot, many readings Loading a snapshot populates every dashboard tab at once. Overview, Analyst Briefing, Trends and Timeline are four projections of the same object — and the likelihood / impact / status filters narrow its items, recomputing every item-derived reading together (the Briefing narrative and Trends ledger are editorial output fixed at scan time and do not re-filter). Nothing on those tabs is fetched from anywhere else; if you can see it, it is in the snapshot. The same is true programmatically: [`GET /v1/snapshots/{id}`](https://docs.regsn.app/api/snapshots) returns the full envelope, and the per-part endpoints (items, trends, executive summary, narrative) are conveniences over the same record. Exports work the same way in the other direction: every artefact generated in [Studio](https://docs.regsn.app/using/studio) or via [`POST /v1/exports`](https://docs.regsn.app/api/exports) is derived from one named snapshot. One snapshot can spawn any number of artefacts — a tearsheet, a slide deck and a podcast are three independent export jobs hanging off the same record. ## Series: the same scan, over time Re-run an identical scope and the snapshots group into a **series**. My Snapshots collapses a series into a single ledger row — the newest scan heads the row, and earlier runs slide open beneath it — so ten weekly re-runs read as one tracked scope, not ten unrelated entries. The grouping is by *scope* alone: the same jurisdictions and the same areas (custom topics included) land in the same series. The engine — and even the horizon — may differ between runs: a 12-month and an 18-month view of the same ground extend one series, because the horizon changes how far you look, not what you are looking at. Series matter for two reasons: 1. **They are the unit of change tracking.** The Change Monitor compares the loaded snapshot against the previous scan in its series. A first-of-its-kind scope has no baseline, so its change card can only invite you to re-run it later. 2. **They are what scheduled scans produce.** A [scheduled scan](https://docs.regsn.app/using/scheduled-scans) is a saved configuration with a cadence and timezone (and optionally an email notification on completion). Each run lands as a new snapshot extending the series — the Snapshots ledger links a series to the schedule that feeds it. **Warning:** **Editing the scope starts a new series.** Add a jurisdiction or swap an area and the next run is the *first* scan of a new scope — with no change baseline. This is by design: a comparison across different scopes would attribute your edit to the regulators. (Lengthening the horizon is the one edit that does *not* fork the series — it widens the view of the same ground.) If you want continuity, keep the scope identical between runs and branch a separate scan for the experiment. ## Where to go next - [Jurisdictions and topics](https://docs.regsn.app/concepts/jurisdictions-and-topics) — how to think about the scope you are fixing. - [What "changed" means](https://docs.regsn.app/concepts/changes) — what a series buys you from the second run onward. - [Your first scan](https://docs.regsn.app/using/first-scan) — the order form walked end-to-end in the product. - [Scans](https://docs.regsn.app/api/scans) — request fields, execution modes and streaming for API callers. --- # Jurisdictions and topics Source: https://docs.regsn.app/concepts/jurisdictions-and-topics (markdown: https://docs.regsn.app/concepts/jurisdictions-and-topics.md) > The scan coordinate system — jurisdictions (where), regulatory areas and topics (what), the time horizon (when), and why every item lands in exactly one cell of it. Every scan is scoped in the same coordinate system: **jurisdictions** (the *where*), **regulatory areas** (the *what*), and a **time horizon** (the *when*), with an optional **entity type** hint (the *who*) to angle the analysis at your kind of firm. These coordinates are not just form fields — they are the axes every downstream reading is organised along. The Overview heatmap is literally areas × jurisdictions; the Timeline is the horizon drawn as a calendar; the Change Monitor only compares scans of the same scope — the same jurisdictions and areas. Understanding the axes is understanding the product's geometry. ## The mental model ```mermaid flowchart LR subgraph scope ["One scan's scope"] direction TB w["WHERE — jurisdictions
UK · EU · US · …"] t["WHAT — areas + topics
Capital Markets · AML / KYC · …"] h["WHEN — horizon
3 – 36 months forward"] end scope --> item["Every item lands in one cell:
jurisdiction × area, dated inside the horizon"] ``` Each item the analysis returns carries exactly one jurisdiction and one primary area, with its dates inside your window. That single-cell rule is what makes the readings composable: a heatmap cell, a timeline swimlane and a filtered detail list are all just different slices along the same axes. It is also why editing the *where* or the *what* resets change tracking — moving those axes changes the space itself, so comparisons across the edit would be geometrically meaningless (see [What "changed" means](https://docs.regsn.app/concepts/changes)). The horizon is the exception: it bounds the view rather than changing the ground, so re-running the same jurisdictions and areas with a longer horizon extends the same [series](https://docs.regsn.app/concepts/scans-and-snapshots#series-the-same-scan-over-time). ## Jurisdictions: the *where* A jurisdiction is a country, region or supranational regulator-cluster. Picking one is shorthand for a set of regulators — choosing **UK** directs coverage across FCA, PRA, Bank of England, HM Treasury, PSR and ICO output without you naming any of them. The full platform vocabulary, with the regulators associated with each, is served by [`GET /v1/meta/jurisdictions`](https://docs.regsn.app/api/discovery): | Jurisdiction | Associated regulators (illustrative) | | --- | --- | | **US** | SEC, CFTC, Fed, OCC, FDIC, FinCEN, CFPB | | **EU** | EC, ESMA, EBA, EIOPA, ECB/SSM, EDPB | | **UK** | FCA, PRA, BoE, HMT, PSR, ICO | | **Singapore** | MAS | | **Hong Kong** | SFC, HKMA, IA | | **Japan** | JFSA, BoJ | | **Australia** | ASIC, APRA, RBA | | **Switzerland** | FINMA | | **Canada** | CSA, OSFI | | **Brazil** | CVM, BCB | | **India** | SEBI, RBI | | **China** | CSRC, CBIRC, PBoC | | **South Korea** | FSC, FSS | All but two of these are one-click pills on the order form. **China** and **South Korea** are vocabulary without pills — they enter a scope through the APAC preset below, typed into **Add custom…**, or named directly in an API scan. The order form also offers **region presets** — one click selects a footprint rather than individual pills: | Preset | Members | | --- | --- | | **G7** | US, EU, UK, Canada, Japan | | **EMEA** | EU, UK, Switzerland (currently the same footprint as EU+) | | **APAC** | Singapore, Hong Kong, Japan, Australia, India, China, South Korea | | **Americas** | US, Canada, Brazil | | **EU+** | EU, UK, Switzerland | | **Global Major** | US, EU, UK, Singapore, Hong Kong, Japan, Australia | Anywhere not on the list — *South Africa, UAE, ASEAN, Cayman Islands* — can be added as a **custom jurisdiction**: type it in and it becomes a first-class axis value, visually distinguished on the order form so you can see which parts of your scope are off the beaten path. ## Areas and topics: the *what* An **area** is a broad policy domain — a category of regulation, not a specific rule. The built-in areas (authoritative list at [`GET /v1/meta/areas`](https://docs.regsn.app/api/discovery)): - **Banking / Prudential** — capital, liquidity, stress testing, recovery and resolution - **Capital Markets** — securities, market structure, investment management, conduct - **Digital Assets / Crypto** — MiCA-style regimes, stablecoins, custody, tokenisation - **AML / KYC** — anti-money-laundering, beneficial ownership, screening - **Payments** — payment-services regimes, open banking, system oversight - **Data Privacy** — GDPR and national equivalents, cross-border transfers - **Operational Resilience** — third-party risk, ICT incidents, DORA-style regimes - **ESG / Sustainable Finance** — disclosures, taxonomy, climate stress testing - **Sanctions** — designated-persons regimes, secondary sanctions - **Research Bundling / Unbundling** — research-payment regimes - **Consumer Protection** — retail conduct and consumer-duty regimes Ten of these are pills on the order form; **Consumer Protection** is in the API vocabulary but not a pill — add it as a custom area in the app, or name it directly in an API scan. A **topic** is finer-grained than an area: *AML / KYC* is an area; *beneficial-ownership transparency for trusts* is a topic. The product deliberately has no separate topic field — you inject a topic by typing it as a **custom area**, where it joins the axis as a first-class value the analysis treats as its own category. This is a design choice worth understanding: because topics live on the same axis as areas, a custom topic gets its own heatmap row, its own filterable item set, and its own line of change tracking — exactly as if it had been built in. The **entity type** hint (Global Asset Manager, Hedge Fund, Insurer, Payments / Fintech, Crypto / DeFi, and so on) does not change *what* is scanned — it angles the analysis's judgement of impact and priority towards firms like yours. ## Horizon: the *when* The horizon is the forward window the analysis scans: **3, 6, 12, 18, 24 or 36 months**. Items need dates inside the window, so the horizon is a genuine boundary, not a suggestion: | Horizon | Reads as | | --- | --- | | **3–6 months** | Imminent obligations — desk-level, operational cadence | | **12 months** | The default planning cycle; the most common pick | | **18–24 months** | Board-pack and roadmap territory | | **36 months** | Long-range: multi-year regimes and slow-moving global standards | A wider horizon does not mean more noise, but it does shift the mix: the further out the window reaches, the more of it is *Proposed*- and *Consultation*-stage material, which is by nature less certain. You will see that reflected in the likelihood mix of the items that come back. ## Why scope discipline pays Every axis you widen multiplies what the analysis must read and dilutes the editorial focus of what it writes. The product is at its best when scope is curated: a footprint of jurisdictions you actually operate in, two to four areas, one or two custom topics, a 12-month window. Two patterns follow naturally: - **Pin one configuration and re-run it on a cadence.** That produces a [series](https://docs.regsn.app/concepts/scans-and-snapshots#series-the-same-scan-over-time) with change tracking — the compounding payoff. - **Branch a copy for one-off questions.** Re-scan with one axis changed (a new topic, an extra jurisdiction) as a separate scan, leaving the pinned series untouched. **Warning:** Resist the everything-ticked scan. A maximal scope across all jurisdictions, all areas and 36 months will run, but slowly and expensively, and the resulting briefing reads like a census rather than an analysis. If you genuinely need breadth, split it into two or three scoped scans — each gets its own series and its own change baseline. ## Where to go next - [Your first scan](https://docs.regsn.app/using/first-scan) — the order form walk-through of setting these coordinates. - [Scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots) — what the coordinates fix in time. - [Meta endpoints](https://docs.regsn.app/api/discovery) — the authoritative live lists for API callers. --- # Items, sources and citations Source: https://docs.regsn.app/concepts/items-and-citations (markdown: https://docs.regsn.app/concepts/items-and-citations.md) > The anatomy of a regulatory item — status, likelihood, impact and dates — and the three separate trust signals that tell you how well it is sourced. An **item** is the atom of a snapshot: one regulatory development, placed at one jurisdiction × area coordinate, described and classified. Everything the dashboard shows you is built from items — a heatmap cell is a stack of them, a timeline entry is one of them with a date, a briefing priority is a claim about several of them. This page covers what an item carries, and then the part that deserves the most careful reading: how the product tells you *how well it knows* what it is telling you. ## The anatomy of an item Open any item — from a heatmap cell, the timeline, or the map — and the detail card shows the same fields: | Field | What it carries | | --- | --- | | **Title** | The development, named — usually the instrument or proposal itself | | **Jurisdiction · Regulator** | Where it comes from, and which authority owns it | | **Area** | The policy domain it is filed under (including your custom areas) | | **Status** | Where the measure is in its lifecycle — see below | | **Likelihood** | How firm the development is — see below | | **Impact** | How much it matters — **High · Medium · Low**, angled by your entity type | | **Expected date** | When it is expected to bite; items may also carry effective dates or compliance deadlines. Undated items show **TBD** rather than an invented date | | **Summary** | A short editorial account, carrying numbered citation markers | | **View source →** | The link to the underlying document, when the item carries one | Two of these fields are ladders worth internalising, because the filter bar treats them as the primary lenses on every reading: **Status** tracks a measure's lifecycle: **Proposed → Consultation → Final Rule → Implementation Phase → Effective**. It answers "how far along is this?" — a *Consultation* wants a response; an *Implementation Phase* rule wants a project plan; an *Effective* rule is a live obligation. **Likelihood** — **Confirmed · Likely · Possible** — answers a different question: "how certain is it that this lands as described?" A *Confirmed* item has a fixed footing (rules adopted, date set); a *Possible* item is direction-of-travel. Items for which no likelihood could be established are treated as **Uncertain** in the filters rather than being silently promoted. Status and likelihood are deliberately independent axes: a *Proposed* measure can be *Confirmed*-likely to proceed, and a *Final Rule* can still carry *Possible* timing. Impact and likelihood combine in one visible place: the Overview heatmap. Each cell prints a pressure score out of 10 that weighs impact *by* likelihood, so a confirmed high-impact item heats a cell far more than a speculative one. The grid is a severity-times-certainty reading, not a raw item count — the count survives in the cell's tooltip. ## Three trust signals, kept separate The product attaches three *independent* signals about sourcing to every scan, and it never blends them into a single score. The separation is the point: each signal answers a different question, fails in a different way, and is honestly absent when it was not produced (an older snapshot simply shows fewer signals — never a fabricated zero). ### 1. Sourcing confidence — *what kind of source is this?* Assessed while the analysis is generated, shown as a chip on the item: - **Primary regulator source** (high) — the item rests on a primary regulator document - **Supranational body** (medium) — a supranational standards body - **Secondary commentary** (low) — commentary about the regulation, not the regulator itself Where an aggregator link was silently upgraded to the primary regulator's own document — the product calls this *tunnelling* — the chip's tooltip says why. The Sources tab counts these substitutions in the Trust Scorecard. ### 2. Source cross-reference — *did the scan actually see this page?* After generation, each item's source URL is cross-referenced against the corpus of pages the scan actually retrieved, and badged: - **✓ verified** — the URL was found verbatim in the retrieved corpus - **≈ domain** — a page on the same domain was retrieved, but not this exact URL - **? unverified** — neither the URL nor its domain appears in the corpus This is a mechanical check, not a judgement — which is exactly why it is trustworthy as far as it goes, and why it is kept separate from the confidence chip. A *Primary regulator source* item with a **?** badge is telling you something specific: the claim type is strong, but the trail to this particular page is not. ### 3. Citation markers — *which source backs this sentence?* The numbered **[N]** markers on the executive narrative and summary are attached after generation by a dedicated audit pass, which selects supporting URLs from the scan's own source pool for each editorial sentence. In the product's own words: it is **an attributor, not a fact-checker** — it never verifies that a source is true, only which source backs the sentence. An unnumbered or dimmed marker means attribution was unavailable for that sentence. The audit itself reports its status. A complete audit is silent; anything less shows an amber chip — *Citation audit partial*, *failed*, or *timed out* — which means some markers may be missing or inactive. Amber is a statement about the *markers*, not the scan: it does not mean the scan failed, nor that any finding is incorrect. **Note:** The [Sources tab](https://docs.regsn.app/using/sources) is where all three signals are totalled: the **Trust Scorecard** shows editorial claim coverage (how many editorial claims carry citations), the sourcing-confidence mix, the cross-reference mix, the tier mix of surfaced sources — **Primary regulator · Supranational · Aggregator · Other source** — and the tunnelling count, alongside a methodology panel explaining each signal in situ. ## Reading one item end to end Take a concrete reading. An item titled after an EU fund-liquidity proposal shows *Consultation* status, *Likely*, *High* impact, expected 15-10-2026, a summary whose second sentence carries **[3]**, a **Primary regulator source** chip and a **✓ verified** badge. What you now know: the measure is mid-lifecycle with a response window; the analysis regards it as probably landing; the claim rests on the regulator's own document; the scan genuinely retrieved that document; and sentence-level attribution points at source 3 in this scan's pool, which the Sources tab will show you in full. What you still do not know — and what no signal claims — is that every statement in the summary is *true*. The verification machinery narrows the trust gap; it does not close it. **Warning:** The product ships with the same caution on every dashboard: **AI-assisted analysis — always verify findings against primary sources before acting.** The trust signals exist to make that verification fast — *View source* and the citation markers take you straight to the documents — not to substitute for it. ## Why items are built this way The design bets on a specific failure mode: in regulatory work, a wrong-but-confident summary is worse than a hedged one. Hence the separated signals (so one weak link never hides behind an average), the honest absences (TBD dates, unverified badges, dimmed markers), and the one-click path from any claim to its document. Items are also the substrate of change tracking — an item is bound to a tracked instrument, and it is instruments whose confirmed, dated events the [Change Monitor](https://docs.regsn.app/concepts/changes) reports between snapshots. Provenance discipline at the item level is what makes the change headline trustworthy one level up. ## Where to go next - [The Sources tab](https://docs.regsn.app/using/sources) — the trust surfaces in the product. - [What "changed" means](https://docs.regsn.app/concepts/changes) — how item provenance becomes change evidence. - [Snapshots](https://docs.regsn.app/api/snapshots) — the item fields on the wire for API callers. --- # What "changed" means Source: https://docs.regsn.app/concepts/changes (markdown: https://docs.regsn.app/concepts/changes.md) > How the Change Monitor compares snapshots of the same scope — confirmed regulator events, coverage movements, and unverified assertions, and why the three are never mixed. A regulatory landscape moves, and the most valuable thing Regulatory Snapshot does from your *second* scan onward is tell you what moved since you last looked. But "what changed?" is a treacherous question for any research product, because two very different things can change between runs: **the world** (a regulator published something) and **the report** (this run's analysis selected differently). Most tools blur the two. Regulatory Snapshot's Change Monitor is built around keeping them apart. ## Where you meet it The Change Monitor is the **What's changed** card on the [Overview tab](https://docs.regsn.app/using/overview). When the loaded snapshot has a predecessor — an earlier scan of the *identical* scope — the card compares the two and says so plainly: *compared with your scan 21 days earlier*. When it has no predecessor, it tells you that too: > No historic identical scan — nothing to compare against. Re-run this configuration to track change over time. That message is the whole story of baselines. Change is defined between snapshots in the same [series](https://docs.regsn.app/concepts/scans-and-snapshots#series-the-same-scan-over-time); the first scan of any scope has nothing to be compared against, and editing the scope — the jurisdictions or the areas — starts a new series with a fresh (empty) baseline. The horizon and the engine are not part of scope: change either and the series, and its baseline, continue. ## The three strata ```mermaid flowchart LR prev["Earlier snapshot
(same scope)"] --> cm{"Change Monitor"} curr["Loaded snapshot"] --> cm cm --> s1["1 · Confirmed regulator events
dated documents — may headline"] cm --> s2["2 · Coverage movements
composition — never headline"] cm --> s3["3 · Unverified assertions
flagged — never headline"] ``` ### 1. Confirmed regulator events The top stratum — and the only one allowed to headline the card — is regulator activity backed by a **dated document**. Each row names the kind of event, the instrument it concerns, and a provenance chip: the regulator, the publication date, and a link to the document itself. The event vocabulary is deliberately small: | Event | Meaning | | --- | --- | | **Consultation opened** | A consultation on the instrument began in your window. | | **Consultation closed** | A consultation ended. | | **Rules adopted** | Final rules were adopted. | | **Date set or moved** | A compliance or effective date was set, or shifted. | | **Guidance issued** | The regulator published guidance. | | **Enforcement** | Enforcement activity was published. | | **Regulator activity** | Something else the regulator published about the instrument. | If nothing confirmed happened in the window, the card does not manufacture a headline. Instead it shows an *affirmative null*: a quiet line of what the regulators in your scope actually published in the period (regulator and count), so "no confirmed change to your instruments" is distinguishable from "nobody looked". ### 2. Coverage movements Each scan is a fresh analytical pass, and a fresh pass makes fresh editorial selections. The second stratum reports how the *composition* of your report moved, without dressing it up as change in the world: - **Newly observed** — an instrument appears in this run that earlier runs did not surface. Every such row carries an honest sub-label: *in force before your window — newly shown, not new*, or *documented in this window — see confirmed events*, or *no dated document on record*. The first of those matters most: a rule from years ago surfacing for the first time is new *coverage*, not new *law*. - **Not shown this run** — an instrument earlier runs surfaced is absent from this one, annotated with how often it has appeared (*surfaced in 3 of 4 runs — likely selection*). Absence from a run is usually selection pressure in a bounded report, not repeal. A composition note keeps the arithmetic visible — *this scan surfaces N of M tracked instruments* — and the whole stratum lives collapsed under the card's detail view, because composition is context, not news. ### 3. Unverified assertions Sometimes a scan asserts regulator activity that cannot be tied to a verifiable source document. These claims are not discarded — you can read them under *unverified assertions from this scan*, each marked *source not verifiable* — but they can never reach the headline. The rule that organises all three strata is: **nothing headlines without a dated document**. **Warning:** The two misreadings the card is designed to prevent are still worth naming. **"Newly observed" does not mean newly enacted** — check the sub-label before escalating. And **"Not shown this run" does not mean withdrawn** — check the instrument's presence count, and its confirmed events, before deleting it from your tracker. ## Following one instrument Items in a snapshot are bound to **tracked instruments** — the named rules and regimes the Change Monitor reports on. From an item's detail card you can jump straight to the Change Monitor focused on that instrument: the card expands, announces *Showing activity for [instrument]*, and filters its lists to that instrument's events, with a small timeline of the window's activity. If there is nothing on record, it says exactly that — *no recorded activity in this window* — rather than leaving a blank. The comparison itself is recomputed each time you open it, so an older snapshot's change view quietly benefits from later improvements in event coverage rather than being frozen with whatever was known on scan day. ## The weekly loop The Change Monitor is why teams put their core scope on a [schedule](https://docs.regsn.app/using/scheduled-scans). The first scan is the expensive read — the full briefing, top to bottom. From the second run, the reading order inverts: open the change card, absorb the confirmed events (minutes, not an hour), skim the coverage movements for anything mislabelled as familiar, and only then decide whether the full dashboard needs a fresh read. Ten runs in, the series *is* your record of the period — each snapshot a fixed observation, each change card the certified delta between two of them. ## For API callers A changes overlay is exposed as a sub-resource of the snapshot at `GET /v1/snapshots/{id}/drift` — a legacy endpoint name retained for compatibility, glossed as changes between snapshots. One difference from the card is worth knowing: the overlay is recorded with the snapshot at scan time, whereas the card's view is recomputed on read. The response is the recorded overlay, or `{ "available": false }` when the snapshot had no baseline. See the [snapshots API reference](https://docs.regsn.app/api/snapshots). ## Where to go next - [Scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots) — series, and why identical scope is the price of a baseline. - [Items, sources and citations](https://docs.regsn.app/concepts/items-and-citations) — the provenance machinery the confirmed stratum is built on. - [Scheduled scans](https://docs.regsn.app/using/scheduled-scans) — putting the loop on a cadence. --- # Glossary Source: https://docs.regsn.app/glossary (markdown: https://docs.regsn.app/glossary.md) > A–Z definitions for the vocabulary used across the Regulatory Snapshot product and the developer API. Short definitions for the terms used across [Using Snapshot](https://docs.regsn.app/using), the [Core concepts](https://docs.regsn.app/concepts) section, and the [developer API](https://docs.regsn.app/api), using the product's own on-screen vocabulary. Entries tagged **(API)** are developer-facing. ## A | Term | Definition | | --- | --- | | **Affirmative null** | The Change Monitor's honest empty state: when no confirmed event touched your instruments, the card lists what the regulators in your scope *did* publish in the window instead of showing an empty box — so "no change" is evidence, not silence. See [What "changed" means](https://docs.regsn.app/concepts/changes). | | **Analyst Briefing** | The dashboard tab that renders a snapshot's executive narrative as readable prose, with numbered citation markers and an inline audio player. Present whenever the snapshot carries a narrative. See [Briefing](https://docs.regsn.app/using/briefing). | | **API key** *(API)* | The credential for the `/v1` API — a `regsn_live_…` string created and revoked from the dashboard, sent as a bearer token in the `Authorization` header. Shown in full exactly once at creation. See [Authentication](https://docs.regsn.app/api/authentication). | | **Area** | A broad policy domain (Capital Markets, AML / KYC, ESG / Sustainable Finance, …) — one of a scan's three coordinates, alongside jurisdiction and horizon. Anything not built in can be added as a custom area. See [Jurisdictions and topics](https://docs.regsn.app/concepts/jurisdictions-and-topics). | | **Artefact** | A generated output derived from a snapshot — document, slide deck, image, audio or video. Produced in [Studio](https://docs.regsn.app/using/studio) or via [`POST /v1/exports`](https://docs.regsn.app/api/exports); the API spells the field `artifact_type`. | | **Audio dock** | The mini-player that pins to the bottom of the window when audio artefacts are playing or queued — play/pause, a seekable waveform, a queue and volume — and follows you around the app. See [Studio](https://docs.regsn.app/using/studio). | ## B | Term | Definition | | --- | --- | | **Batch lane** | The deferred, cheaper way to run work. On the order form, **Batch — later today** costs roughly half the Expedite price, with results typically arriving within a few hours (optionally announced by email); scheduled scans default to it, and Studio generation uses a batch lane unless Expedite is on. Not every engine or export route has one. See [Your first scan](https://docs.regsn.app/using/first-scan). | | **Bottom line** | The one-line distillation of the scan — the thing to read if you read nothing else. Shown on the Overview hero and as the closing line of the [Briefing](https://docs.regsn.app/using/briefing), when the scan produced one. | | **Budget** | The account-level spending pool that all scans and exports draw on — the same pool whether the work is started from the app or the API. See [Usage](https://docs.regsn.app/api/usage). | ## C | Term | Definition | | --- | --- | | **Change Monitor** | The **What's changed** card on the Overview tab, comparing the loaded snapshot with your previous scan of the identical scope. Reports confirmed regulator events, coverage movements and unverified assertions as three separate strata, and recomputes on read — an older snapshot's change view improves as event coverage does. See [What "changed" means](https://docs.regsn.app/concepts/changes). | | **Citation audit** | The post-generation pass that attaches numbered citation markers to editorial sentences. Reports its own status — an amber *Citation audit partial / failed / timed out* chip means some markers may be missing, not that the scan failed. See [Items, sources and citations](https://docs.regsn.app/concepts/items-and-citations). | | **Citation marker** | A numbered **[N]** marker on the narrative or summary pointing at the source in this scan's pool that backs the sentence. An attributor, not a fact-checker. See [Items, sources and citations](https://docs.regsn.app/concepts/items-and-citations). | | **Confirmed event** | A Change Monitor entry backed by a dated regulator document — *Consultation opened*, *Consultation closed*, *Rules adopted*, *Date set or moved*, *Guidance issued*, *Enforcement*, or *Regulator activity*. The only stratum allowed to headline the card. See [What "changed" means](https://docs.regsn.app/concepts/changes). | | **Coverage movement** | A Change Monitor entry recording how the *composition* of the report moved between runs — **Newly observed** and **Not shown this run** — as distinct from change in the world. See [What "changed" means](https://docs.regsn.app/concepts/changes). | | **Custom area** | A free-text area (often a specific topic — *DORA Article 28*, *Pay-to-Play*) added on the order form when no built-in area fits. Treated as a first-class category by the analysis. See [Jurisdictions and topics](https://docs.regsn.app/concepts/jurisdictions-and-topics). | | **Custom jurisdiction** | A free-text jurisdiction (*South Africa*, *UAE*, *ASEAN*, …) added when no built-in fits. See [Jurisdictions and topics](https://docs.regsn.app/concepts/jurisdictions-and-topics). | ## D | Term | Definition | | --- | --- | | **Detail card** | One item's full record — fields, badges and trust chips — shown as a card inside the slide-in **Item Detail** panel that opens from a heatmap cell, a map country or a timeline entry. See [Overview](https://docs.regsn.app/using/overview). | ## E | Term | Definition | | --- | --- | | **Engine** | One of the product's analysis engines, compared — with a live cost figure for each — in the order form's Advanced section and shown on every ledger row in My Snapshots. Engines differ in verification support, batch availability and cost; the API lists their ids at [`GET /v1/meta/engines`](https://docs.regsn.app/api/discovery). | | **Entity type** | The *who* hint on a scan (Global Asset Manager, Hedge Fund, Payments / Fintech, …). Angles impact and priority judgements towards firms like yours without changing what is scanned. See [Jurisdictions and topics](https://docs.regsn.app/concepts/jurisdictions-and-topics). | | **Executive narrative** | The long-form prose briefing in a snapshot, read on the [Analyst Briefing](https://docs.regsn.app/using/briefing) tab. Distinct from the structured executive summary. | | **Executive summary** | The structured digest in a snapshot — a bottom line plus an ordered list of priorities. See [Core concepts](https://docs.regsn.app/concepts). | | **Expedite** | The full-price, real-time run lane. On the order form, **Expedite — run now** streams results into the dashboard as they arrive; in Studio, the Expedite toggle moves artefact generation from the batch lane to real time (at roughly double the cost) and persists as an account preference. See [Studio](https://docs.regsn.app/using/studio) and [Settings](https://docs.regsn.app/using/settings). | | **Export** | The act (and result) of deriving an artefact from a snapshot. Runs as an asynchronous job: **queued → processing → completed / failed / cancelled**. See [Studio](https://docs.regsn.app/using/studio) and [`POST /v1/exports`](https://docs.regsn.app/api/exports). | ## F | Term | Definition | | --- | --- | | **Feed** | The always-live wire of recent regulator announcements across all jurisdictions, independent of any scan — with a one-tap filter down to the loaded scan's scope. See [Feed](https://docs.regsn.app/using/feed). | | **Fingerprint** | Two distinct objects share the name. The *scope hash* — `_meta.inputFingerprint` to API callers — is derived from a scan's jurisdictions, areas and custom topics, deliberately blind to engine and horizon; snapshots with the same scope hash group into a series. The *cost-estimate fingerprint* returned by [`POST /v1/scans/estimate`](https://docs.regsn.app/api/scans#estimate-a-scan) is a separate, structured bucketing of the configuration that does include the engine and the date range. See [Scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots). | ## G | Term | Definition | | --- | --- | | **Graph** | The dashboard's relationship-graph reading of a snapshot, available under **More** when the loaded scan carries graph data. | ## H | Term | Definition | | --- | --- | | **Heatmap** | The Overview tab's grid — areas × jurisdictions, each cell printing a pressure score out of 10 that weighs impact by likelihood; the item count lives in the cell's tooltip. See [Overview](https://docs.regsn.app/using/overview). | | **Horizon** | The forward window a scan looks across — 3, 6, 12, 18, 24 or 36 months. Items need dates inside it. Not part of scope: lengthening the horizon extends a series rather than forking it. See [Jurisdictions and topics](https://docs.regsn.app/concepts/jurisdictions-and-topics). | ## I | Term | Definition | | --- | --- | | **Idempotency key** *(API)* | A client-supplied header on `POST /v1/scans` and `POST /v1/exports` making retries safe — the same key with the same body replays the original response for 24 hours. See [Idempotency](https://docs.regsn.app/api/idempotency). | | **Ident** | See **Scan ID (ident)**. | | **Impact** | The analysis's call on how much an item matters — **High · Medium · Low** — angled by your entity type. One of the two inputs to heatmap colour. See [Items, sources and citations](https://docs.regsn.app/concepts/items-and-citations). | | **Instrument** | A named rule or regime the product tracks across scans. Items bind to instruments, and it is instruments whose confirmed events the Change Monitor reports. See [What "changed" means](https://docs.regsn.app/concepts/changes). | | **Item** | One regulatory development inside a snapshot, at one jurisdiction × area coordinate, with status, likelihood, impact, dates, summary and sourcing. The atom of the data model. See [Items, sources and citations](https://docs.regsn.app/concepts/items-and-citations). | ## J | Term | Definition | | --- | --- | | **Jurisdiction** | A country, region or supranational regulator-cluster — the *where* axis of a scan. Picking one directs coverage across its associated regulators. See [Jurisdictions and topics](https://docs.regsn.app/concepts/jurisdictions-and-topics). | ## K | Term | Definition | | --- | --- | | **Kicker** | The short capitals label above a headline — the Briefing masthead's kicker reads *Analyst Briefing*; Studio's restates the loaded scan. See [Briefing](https://docs.regsn.app/using/briefing). | ## L | Term | Definition | | --- | --- | | **Likelihood** | How firm an item is — **Confirmed · Likely · Possible**; items with no stated likelihood are treated as **Uncertain** in filters. Independent of status. See [Items, sources and citations](https://docs.regsn.app/concepts/items-and-citations). | ## M | Term | Definition | | --- | --- | | **Map** | The dashboard's geographic reading of the snapshot — jurisdictions on a world map, coloured by activity. Always present under **More**. | | **Masthead** | The header block at the top of an article-styled tab — kicker, headline and standfirst on the Briefing; the scope and range lines on the Timeline and Snapshots tabs. See [Briefing](https://docs.regsn.app/using/briefing). | | **My Snapshots** | The ledger of your saved scans, day-grouped, with identical-scope re-runs collapsed into series rows and re-run affordances on each. See [Snapshots](https://docs.regsn.app/using/snapshots). | ## N | Term | Definition | | --- | --- | | **Newly observed** | A coverage movement: an instrument surfaced in this run that earlier runs did not show, sub-labelled honestly (e.g. *in force before your window — newly shown, not new*). See [What "changed" means](https://docs.regsn.app/concepts/changes). | | **Not shown this run** | A coverage movement: an instrument earlier runs surfaced is absent from this one — usually editorial selection, not repeal, and annotated with its presence count. See [What "changed" means](https://docs.regsn.app/concepts/changes). | ## O | Term | Definition | | --- | --- | | **Order form** | The scan configuration form, reached from **New Scan**: numbered sections 01–05 (who · where · what · when · output), an Advanced accordion for engine choice, and the live order ticket alongside. Every setting persists from your last scan. Sometimes called the scan wizard. See [Your first scan](https://docs.regsn.app/using/first-scan). | | **Order ticket** | The live summary rail beside the order form — it restates WHO / WHERE / WHAT / HORIZON, prices the scan as you build it (*"Estimate, not a quote."*), carries the Expedite / Batch choice, and holds the **Start scan** button. See [Your first scan](https://docs.regsn.app/using/first-scan). | | **Overview** | The dashboard's first tab: the heatmap, headline stats, and the What's changed card. The default reading of a loaded snapshot. See [Overview](https://docs.regsn.app/using/overview). | ## P | Term | Definition | | --- | --- | | **Planner** | The calendar-first view on the Scheduled tab: a month grid of upcoming runs, a next-run hero, the schedule manager and a recent-activity feed. See [Scheduled scans](https://docs.regsn.app/using/scheduled-scans). | | **Priority** | One entry in the executive summary's ordered list — the developments the analysis judges most worth your attention, walked in order by the Briefing. | | **Problem detail** *(API)* | The RFC 9457 error envelope on every non-2xx `/v1` response — `type`, `title`, `status`, `detail`, `code`, `request_id`, and per-field `errors`. See [Errors](https://docs.regsn.app/api/errors). | | **Provenance chip** | The compact *regulator · date · doc* chip on every confirmed event in the Change Monitor, linking to the dated document behind it. See [What "changed" means](https://docs.regsn.app/concepts/changes). | ## R | Term | Definition | | --- | --- | | **Rate limit** *(API)* | The per-key request budget on `/v1`, bucketed by operation category and signalled in response headers. See [Rate limits](https://docs.regsn.app/api/rate-limits). | | **Region preset** | A one-click jurisdiction bundle on the order form — G7, EMEA, APAC, Americas, EU+, Global Major. Presets replace the current pill selection (hand-added custom jurisdictions excepted). See [Jurisdictions and topics](https://docs.regsn.app/concepts/jurisdictions-and-topics). | | **Regulator** | The authority behind an item (FCA, ESMA, MAS, …). Shown on every item; jurisdictions are shorthand for sets of regulators. See [Jurisdictions and topics](https://docs.regsn.app/concepts/jurisdictions-and-topics). | | **Request ID** *(API)* | The `X-Request-Id` header on every API response, for support correlation. See [Errors](https://docs.regsn.app/api/errors). | ## S | Term | Definition | | --- | --- | | **Scan** | One run of the analysis over a configuration. Lifecycle: queued → running → complete (saving a snapshot), failed, or cancelled. See [Scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots). | | **Scan ID (ident)** | The short mono identifier stamped on a scan when it runs — shown on ledger rows in My Snapshots and in Studio's scan picker and artefact info cards, and appended to exported artefact filenames where present, so a file can be traced back to its scan. Unlike the fingerprint, a scan ID is unique to a single run. See [Snapshots](https://docs.regsn.app/using/snapshots). | | **Scan Ready** | The green pill that appears in the header chrome when a finished scan is waiting to be loaded — one click loads it; with several waiting, it opens a picker. See [The app at a glance](https://docs.regsn.app/using). | | **Scan toast** | The floating progress card shown while a scan runs — phase, percentage, cancel, and a **View** affordance on completion. Scans never block the dashboard. See [Scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots). | | **Scheduled scan** | A saved configuration with a cadence and timezone (and optional email notification) that runs itself, extending its series with each run. See [Scheduled scans](https://docs.regsn.app/using/scheduled-scans). | | **Scope** | The identity-defining part of a scan's configuration — its jurisdictions and areas (custom topics included). Identical scope is what groups snapshots into a series and enables change tracking; engine and horizon sit outside it and may differ between runs. See [Jurisdictions and topics](https://docs.regsn.app/concepts/jurisdictions-and-topics). | | **SDK** *(API)* | An official client library wrapping the `/v1` surface. See [Python SDK](https://docs.regsn.app/api/sdks/python) and [JavaScript SDK](https://docs.regsn.app/api/sdks/javascript). | | **Sentiment** | The scan's overall posture read (for example *Tightening.*), shown as an aside on the Overview hero and as the attribution on the Briefing's pull quote. Present only when the scan produced one. See [Overview](https://docs.regsn.app/using/overview). | | **Series** | The snapshots produced by re-running an identical scope, grouped into one ledger row in My Snapshots. The unit of change tracking. See [Scans and snapshots](https://docs.regsn.app/concepts/scans-and-snapshots). | | **Snapshot** | The fixed, dated record saved by one completed scan — items, trends, executive summary and narrative, sources and audit. The central object; everything else reads from or derives from it. See [Core concepts](https://docs.regsn.app/concepts). | | **Source cross-reference** | The mechanical badge on an item's source URL — **✓ verified** (URL found in the scan's retrieved corpus), **≈ domain** (same domain, different page), **? unverified** (neither). See [Items, sources and citations](https://docs.regsn.app/concepts/items-and-citations). | | **Source tier** | The classification of a surfaced source — **Primary regulator · Supranational · Aggregator · Other source** — totalled on the Sources tab. See [Sources](https://docs.regsn.app/using/sources). | | **Sourcing confidence** | The in-generation chip on an item — **Primary regulator source** (high), **Supranational body** (medium), **Secondary commentary** (low). See [Items, sources and citations](https://docs.regsn.app/concepts/items-and-citations). | | **SSE stream** *(API)* | The Server-Sent Events channel for a running scan at `GET /v1/scans/{id}/stream` — progress, completion (with the snapshot envelope), or error. See [Scans](https://docs.regsn.app/api/scans). | | **Standfirst** | The one-sentence framing under a headline (*"Three priorities for the quarter ahead — EU · UK."*) — newspaper vocabulary the Briefing masthead borrows. See [Briefing](https://docs.regsn.app/using/briefing). | | **Status** | An item's lifecycle stage — **Proposed · Consultation · Final Rule · Implementation Phase · Effective**. Independent of impact and likelihood. See [Items, sources and citations](https://docs.regsn.app/concepts/items-and-citations). | | **Studio** | The surface where a snapshot becomes artefacts — documents, decks, images, podcasts, video — with generation queue, gallery and inline players. See [Studio](https://docs.regsn.app/using/studio). | ## T | Term | Definition | | --- | --- | | **Tearsheet** | A two-page A4 PDF summarising a snapshot, generated in Studio in two variants — the clean Overview and the illustrated, style-led Detailed. See [Studio](https://docs.regsn.app/using/studio). | | **Ticker strip** | The mono readout under the tab bar — `ITEMS · JUR · HIGH-IMPACT · DEADLINES · ● SCAN` on most tabs — which re-tunes itself per tab: trust statistics on Sources, archive counts on Snapshots, the next run time on Scheduled. See [The app at a glance](https://docs.regsn.app/using). | | **Timeline** | The dashboard's calendar reading — dated items laid out by expected date with a Today marker, one swimlane per jurisdiction. See [Timeline](https://docs.regsn.app/using/timeline). | | **Topic** | A theme narrower than an area (*MiCA Title III*, *beneficial-ownership transparency*). Injected into a scan as a custom area, where it becomes a first-class axis value. See [Jurisdictions and topics](https://docs.regsn.app/concepts/jurisdictions-and-topics). | | **Translation** | An additional-language rendering of the snapshot's narrative and content, cached on the snapshot after first use. Covers the dashboard's seven reading languages; the API additionally accepts `pt`. See [Settings](https://docs.regsn.app/using/settings). | | **Trend** | A typed cross-item pattern in a snapshot — **Convergence** (jurisdictions moving towards a shared approach), **Acceleration** (pace increasing), **Interconnected** (obligations interlocking across regimes), **Divergence** (jurisdictions splitting), **Emerging** (early signals only). See [Trends](https://docs.regsn.app/using/trends). | | **Trust Scorecard** | The Sources-tab panel totalling the scan's trust signals: editorial claim coverage, sourcing-confidence mix, cross-reference mix, source-tier mix and tunnelling count. See [Sources](https://docs.regsn.app/using/sources). | | **Tunnelling** | The silent upgrade of an aggregator link to the primary regulator's own document, with the reason kept in the chip's tooltip and the count on the Trust Scorecard. See [Items, sources and citations](https://docs.regsn.app/concepts/items-and-citations). | ## U | Term | Definition | | --- | --- | | **Unverified assertion** | A Change Monitor entry the scan asserted but could not tie to a verifiable source document. Visible, marked *source not verifiable*, and never headline-grade. See [What "changed" means](https://docs.regsn.app/concepts/changes). | | **Usage** *(API)* | Request, scan, export and cost telemetry at `GET /v1/usage`, groupable by day, endpoint or key. See [Usage](https://docs.regsn.app/api/usage). | ## V | Term | Definition | | --- | --- | | **View source** | The link on an item's detail card to the document behind it — the fastest route from a claim to its evidence. See [Items, sources and citations](https://docs.regsn.app/concepts/items-and-citations). | ## W | Term | Definition | | --- | --- | | **What's changed** | The Change Monitor's card on the Overview tab, and the comparison behind it. API callers can fetch a changes overlay, recorded at scan time, as a snapshot sub-resource. See [What "changed" means](https://docs.regsn.app/concepts/changes) and [Snapshots](https://docs.regsn.app/api/snapshots). | | **Wizard** | An older name for the scan configuration form — see **Order form**. | --- # Docs for agents Source: https://docs.regsn.app/docs-for-agents (markdown: https://docs.regsn.app/docs-for-agents.md) > Machine-readable entry points to these docs and the API — markdown twins, llms.txt, the OpenAPI spec, an installable Agent Skill, and a base prompt. This page is for AI agents and for the people configuring them. Everything on this site, and the API it documents, is reachable in plain-text and machine-readable forms — no HTML scraping required. ## Markdown twins Every page on this site has a markdown twin. Append `.md` to any page URL: ```text https://docs.regsn.app/api/quickstart → the HTML page https://docs.regsn.app/api/quickstart.md → the same page as markdown ``` The site root is `https://docs.regsn.app/index.md`. Twins are regenerated on every deploy from the same sources as the HTML, so they never lag it. The **Copy page** menu on each page copies or links the twin directly. ## llms.txt Two index files, following the [llms.txt convention](https://llmstxt.org): | File | Contents | |---|---| | [`/llms.txt`](https://docs.regsn.app/llms.txt) | The documentation index — every page, one line each, linked to its markdown twin | | [`/llms-full.txt`](https://docs.regsn.app/llms-full.txt) | The entire documentation set concatenated in navigation order, with per-page source URLs | Point an agent at `llms.txt` when it should choose what to read; hand it `llms-full.txt` when it should read everything (roughly a hundred thousand tokens — check your context budget first). ## The OpenAPI spec The machine contract for the `/v1` API: | Resource | URL | |---|---| | OpenAPI 3 spec (JSON) | [`https://api.regsn.app/openapi.json`](https://api.regsn.app/openapi.json) | | OpenAPI 3 spec (YAML) | [`https://api.regsn.app/openapi.yaml`](https://api.regsn.app/openapi.yaml) | | Human-readable reference | [`https://api.regsn.app/reference`](https://api.regsn.app/reference) | The prose reference on this site ([API for developers](https://docs.regsn.app/api)) and the spec describe the same surface; when generating code, prefer the spec. ## The Agent Skill `regsn-api` is an installable [Agent Skill](https://agentskills.io) that teaches a coding agent the API: auth, the scan → snapshot → export object model, the canonical flows as curl, and the operational gotchas (rate buckets, polling cadence, error codes). Install it into any skills-aware agent: ```bash npx skills add https://docs.regsn.app ``` The skill is discovered via [`/.well-known/skills/index.json`](https://docs.regsn.app/.well-known/skills/index.json); the skill document itself is at [`/skill/regsn-api/SKILL.md`](https://docs.regsn.app/skill/regsn-api/SKILL.md) if you would rather read or vendor it directly. ## Base prompt For agents without skill support, paste this into the system or task prompt: ```text You are working with the Regulatory Snapshot API (https://api.regsn.app/v1). Read https://docs.regsn.app/llms.txt for the documentation index; any docs page is available as markdown by appending .md to its URL. The OpenAPI spec is at https://api.regsn.app/openapi.json. Auth: Bearer regsn_live_ API keys, minted in the dashboard at api.regsn.app. Scans are async and take minutes: POST /v1/scans with an Idempotency-Key, then poll GET /v1/scans/{id} every 5-10 seconds or stream the SSE endpoint. Estimate cost first with POST /v1/scans/estimate; check GET /v1/usage/budget. Errors are RFC 9457 problem+json with stable code values - branch on code. Rate buckets: reads 60/min, scans 6/hour, exports 30/hour. ``` ## See also - [API quickstart](https://docs.regsn.app/api/quickstart) — the same flow, written for people. - [Errors](https://docs.regsn.app/api/errors) — the full problem-details code table. - [Rate limits](https://docs.regsn.app/api/rate-limits) — all five buckets and the response headers.