Compliance Horizon Scanner

View saved version →

---
name: assess-materiality
description: Assess one named regulatory development in depth against a business's compliance profile — whether it binds them, which provisions engage, what would have to change operationally, and by when. Use when the user names or pastes a specific regulation, rule, directive, statutory instrument, bill, or consultation and asks whether it applies to them, what it means for them, or what they need to do about it. Complements horizon-scan, which finds developments; this one analyses a single development.
---

Read `../../references/runtime-safety.md` before using this workflow. Resolve relative paths from this skill directory. To use a sibling skill, read its `../<skill-name>/SKILL.md`; no special invocation tool is required.


Deep-dive one development. Where `horizon-scan` triages breadth, this goes to depth on a single
instrument the user cares about.

**Read `../../references/citation-discipline.md` first. It governs everything below.** The depth
here makes provenance more important, not less — a detailed operational analysis built on an
unsourced threshold is confidently wrong in a way a one-line finding never is.

---

## 1. Identify the instrument precisely

The user may give you a name, a number, a URL, a pasted extract, or a vague description. Pin it down
to a specific instrument with an identifier before analysing anything.

- **Resolve it to a primary source and fetch it.** Federal Register document number, CELEX,
  UK SI `year/number`, or a state instrument identified by state, type, session, and official
  number. For a named state instrument read `../../references/sources-us-states.md`; an
  explicit one-off assessment does not change saved recurring state selections. Use `../../references/sources-us-federal.md`, `sources-eu.md`, `sources-uk.md`.
- **If you cannot find it, say so.** Do not analyse an instrument you could not locate. A
  plausible-sounding name may be a misremembering, a proposal that was never adopted, a measure
  under a different number, or nothing at all. The correct response is:

  > I could not locate a primary source for that. Can you share a link or the official number? I
  > searched <sources> on <date> and found nothing matching.

  Never produce an analysis from recall to be helpful. This is the single most likely way this
  skill could cause harm.
- **If several instruments could match, ask which** rather than picking the most likely. Amending
  instruments, corrigenda, and consolidations often share most of a title.

## 2. Get the profile

Ask for the compliance profile. Without it there is no "material to whom," and the answer collapses
into a generic summary the user could get anywhere.

If they don't have one, you can still analyse the instrument, but say clearly that applicability is
unassessed and ask the specific facts that decide it — usually jurisdiction, headcount, data types,
and whether they are consumer-facing.

## 3. Read the instrument and extract, with quotes

- **Scope** — who it binds, in its own words. Quote the scope provision.
- **Lifecycle stage** — proposed, in consultation, adopted, in force, or applying from a date.
- **Every date** — comment deadline, entry into force, application, staged milestones, first
  reporting date. Each quoted separately from the provision that sets it.
- **Thresholds** — headcount, turnover, data volume, product class. Quoted.
- **Substantive obligations** — what must actually be done.
- **Penalties and liability**, including whether any is criminal or personal.
- **Exemptions and derogations** — often where the answer actually lives, and commonly missed.

Where the instrument amends another, **read the amended instrument too**. An amending act's text is
often unintelligible in isolation ("in Article 4, replace 'six' with 'twelve'"), and reporting the
amendment without the underlying provision tells the user nothing.

## 4. Assess applicability against the profile

Apply `../../references/materiality-rubric.md`. Name the profile field and the threshold that
decides it:

> `binds_us` — Article 2(1) applies to "an employer with 50 or more employees";
> `headcount_by_jurisdiction.UK = 120`.

Score `unassessed` and **name the missing facts** when scope cannot be assessed. Use
`likely` only when affirmative evidence supports probable applicability. Do not resolve
ambiguity toward the more interesting answer, in either direction — neither inflating applicability
to seem useful nor dismissing it to seem reassuring.

## 5. State what would have to change

This is the part the user cannot get from reading the instrument, and the reason to run this skill.
Be concrete and tie each item to the provision that requires it:

- **Policies and documents** — which ones, and what has to change in them
- **Systems and product** — engineering work, data flows, retention, consent, logging
- **Contracts** — customer terms, supplier terms, DPAs, flow-down clauses
- **Governance** — approvals, sign-off, board or committee reporting
- **Evidence** — what a regulator would ask to see, and what would have to exist to show it

Separate **what the instrument requires** from **what would be prudent**. Both are useful; conflating
them misleads. Label the second as your assessment, not as obligation.

## 6. Output

```
## <Instrument name> · <official_id>
`<stage>` · <publisher> · retrieved <date>

**Bottom line.** <Two or three sentences: does it bind them, what is the hardest part, by when.>

**Scope** — <who it binds, quoted> [link]

**Applicability: `binds_us`** — <profile field and threshold, quoted>

**Key dates**
| What | Date | Source |
|---|---|---|
| Comment deadline | <date, or "none"> | "<verbatim quote>" [link] |
| Entry into force | <date> <if computed: "(derived: <arithmetic>)"> | "<verbatim quote>" [link] |
| Applies from | <date, or "not specified in the instrument"> | <quote, or "—"> |

**Obligations that engage** — <each with the provision and a quote>

**What would have to change** — <policies / systems / contracts / governance / evidence>

**Penalties** — <quoted, with whether any is criminal or personal>

**Exemptions worth checking** — <any that might apply, with provisions>

**Score** — impact `high` · effort `program_change` · timeline `30-90` · confidence `high`
**Flag** — <e.g. effort exceeds available lead time>

**Not established from the sources** — <anything you could not source, listed explicitly>

---
Regulatory intelligence, not legal advice. Verify against the cited primary sources before acting.
```

The **"Not established from the sources"** section is mandatory and must not be dropped when it
would be empty of interesting content — write "nothing material" rather than removing the heading.
It is where an unpublished effective date, an unresolved threshold, or an unreachable amended
instrument gets named. A detailed analysis that quietly omits what it could not establish reads as
more complete than it is, which is precisely the failure this heading prevents.

## 7. Self-check

Run the checklist in `citation-discipline.md`. Every date, threshold, and penalty in the output
traces to a verbatim quote from a document fetched this session, or it is moved to "Not established."
Then state the provenance tally.

---

## When the user pushes for a bottom line you cannot source

They will sometimes want a date, a number, or a yes/no that the sources do not give — often for a
real deadline of their own. Give the sourced part, name the gap, and say what would close it:

> The comment deadline is fixed and sourced: 11:59 p.m. Eastern Time on 30 September 2026 (quoted,
> linked). The instrument sets no effective date, and none is published — that comes with the final
> rule. I can't give you a date for it. If you need something to plan against, the comment deadline
> is the one that's certain; I'd re-scan this agency monthly for the final rule rather than plan to
> an assumed date.

That is a complete and useful answer. An invented effective date, however well hedged, is not.

View saved version →

---
name: compliance-calendar
description: Build a forward calendar of dated regulatory obligations from scan findings or a compliance profile — comment deadlines, entry-into-force dates, applies-from dates, staged transition milestones, and first reporting dates — each carrying the source link and the quote that establishes it. Use when the user asks what is coming up, what deadlines they face, what to diarise, or wants a compliance calendar or timeline for a quarter, year, or specific regulation.
---

Read `../../references/runtime-safety.md` before using this workflow. Resolve relative paths from this skill directory. To use a sibling skill, read its `../<skill-name>/SKILL.md`; no special invocation tool is required.


Turn findings into dates the user can diarise, each traceable to the provision that sets it.

**Read `../../references/citation-discipline.md` first.** This skill carries the highest fabrication
risk in the plugin: an unsourced date here gets entered in a diary, relied on, and either missed or
acted on early. **A date with no quotable source is omitted and listed as a gap — never estimated,
never interpolated, never carried over from a similar instrument.**

---

## 1. Get the input

Either the findings from a `horizon-scan` run, a specific instrument, or a compliance profile (in
which case run a scan first, or work from the domains in scope).

## 2. Extract every dated obligation

For each finding, pull out **every** date, not just the headline one. A single instrument commonly
carries several, and the one that matters to this user may not be the first:

- consultation or comment deadline
- adoption date
- entry into force
- applies-from / application date
- staged milestones — by obligation, entity class, or product category
- first reporting date, and the reporting period it covers
- transitional or grandfathering cut-offs
- review or sunset dates

**Each becomes its own calendar entry.** Do not collapse a staged regime into a single date — the
staging is usually the operationally important part, and a business may be in scope for one stage
and not another.

## 3. Source every date individually

Each entry carries the link and the verbatim quote from the provision that sets it. Different dates
in one instrument usually come from different provisions; cite each to its own.

**Derived dates.** Where a date must be computed — an EU act's "twentieth day following that of its
publication," a UK SI's "the day after the day on which these Regulations are made" — show the
arithmetic, quote the provision, and label it derived:

> **28 September 2026** — entry into force *(derived: 20th day after OJ publication 8 September
> 2026)* · "shall enter into force on the twentieth day following that of its publication in the
> *Official Journal of the European Union*" · [CELEX 32026R1975](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32026R1975)

**Undated obligations.** These are common and must be represented honestly, not dropped and not
guessed:

- A proposed US rule has no effective date — `effective_on` is `null`. The comment deadline is the
  one possible fixed date; hearing, registration, and other procedural dates may also be set.
- A UK SI may commence "on such day as the Secretary of State may by regulations appoint," which
  means **no date exists yet**.
- An EU directive's transposition deadline binds member states, not businesses; the business date
  comes from national law, which is outside v1 coverage.

Put all of these in an **Undated / pending** section with the reason and what will fix it. This
section is often the most useful part of the calendar, because it tells the user what to keep
watching rather than implying nothing is coming.

## 4. Flag lead-time mismatches

Compare each entry's `effort` score to the time available. Where effort exceeds lead time, flag it —
this is frequently the single most valuable output of the whole plugin:

> ⚠️ **Lead-time risk** — `program_change` due in 41 days. Cross-functional work with under six
> weeks of runway.

Rough guide, to be applied with judgement rather than mechanically: `program_change` needs quarters,
`policy_change` needs weeks, `documentation_only` needs days.

## 5. Output

Group by time bucket, soonest first, and make every date checkable:

```
## Compliance calendar · <profile_name>
Built <date> from a horizon scan covering <window>. Dates are as published; verify before diarising.

### Next 30 days
| Date | What | Instrument | Effort | Source |
|---|---|---|---|---|
| 2026-09-30 | Comment deadline | DOL proposed rule 2026-15717 | — | "<quote>" [link] |

### 30–90 days
### 90–365 days
### Beyond 12 months
### Undated / pending
| What | Why undated | What will fix it |
|---|---|---|
| Effective date, DOL 2026-15717 | Proposed rule; no effective date published | Final rule publication — re-scan `labor-department` monthly |

### Lead-time risks
<entries where effort exceeds available runway>

**Provenance:** N dated entries, N sourced to a quoted provision · N derived (arithmetic shown) ·
N undated and listed as pending · N coverage gaps

---
Regulatory intelligence, not legal advice. Verify each date against the cited source before relying
on it or entering it in a diary.
```

## 6. Self-check — strictly

Before returning, walk every entry:

- [ ] every date traces to a verbatim quote from a document fetched this session
- [ ] every derived date shows its arithmetic and the provision it rests on
- [ ] no date is inferred from a similar instrument, from a typical pattern, or from recall
- [ ] undated obligations appear in the pending section rather than being dropped or filled
- [ ] the provenance tally is stated

Then state the tally. If a date failed the check, it is not in the calendar — say so in the gaps
line rather than including it with a caveat. A caveated date in a table still gets diarised.

---

## Offering it as a file

Users usually want this in their own calendar or tracker. Offer a CSV they can import, with columns
`date,what,instrument,official_id,effort,source_url,supporting_quote`.

**Keep `source_url` and `supporting_quote` as columns in the export.** They are what make an entry
checkable six months later, when whoever reads the row has forgotten where it came from and is
deciding whether to act on it. Stripping them for tidiness defeats the purpose of the calendar.

View saved version →

---
name: compliance-profile
description: Build or update the compliance profile that scopes every horizon scan — the business's legal entities, operating jurisdictions, sector, headcount, data and AI exposure, supply chain, and materiality thresholds. Use when the user is setting up for the first time, has no profile yet, or needs to change one after a business change such as a new jurisdiction, product line, or headcount shift. Emits a portable YAML block the user saves and supplies to later scans.
---

Read `../../references/runtime-safety.md` before using this workflow. Resolve relative paths from this skill directory. To use a sibling skill, read its `../<skill-name>/SKILL.md`; no special invocation tool is required.


The profile is the plugin's only memory. It scopes the scan to one business and carries the scan
state that makes later runs incremental. Getting it right is what separates a relevant scan from a
generic one.

Read `../../references/profile-schema.md` for the full field reference and vocabulary.

---

## 1. Establish whether this is new or an update

Ask for an existing profile block first. If there is one, go to §5.

## 2. Interview — ask only what you cannot infer

Work through the schema, but do not read it out as a form. Ask in the order below, group related
questions, and infer what you reasonably can from what the user has already said — then state your
inference so they can correct it.

**Identity and footprint** (needed)
- Legal entities and where each is incorporated
- Where the business actually operates — use the `operating_jurisdictions` vocabulary
- For US coverage, offer federal-only (default) or federal plus selected states. Ask which
  states matter, accept names or postal codes, and save them in `coverage.us_states` using
  the schema. Explain state research is bounded by reachable official sources. Ask only
  if the preference is not already clear; never enable every state automatically.
- Sector, in the user's own words; add NAICS/SIC if they know them
- Headcount per jurisdiction, roughly
- Public company? If so, listing venues
- Revenue band, roughly

**Exposure** (this is what makes the scan specific — worth the time)
- What personal data: customer, employee, health, biometric, children, financial, location
- AI anywhere: in the product, in hiring, in credit decisions, internal only
- Consumer-facing? Payments?
- Regulated products
- Export-controlled items; any touchpoints with sanctioned jurisdictions
- Physical sites, and how far the supply chain is mapped
- Unionised workforce

**Thresholds**
- Report at `medium` and above (default), or a different cut
- Anything to always surface regardless of score — default is criminal liability, personal
  liability for directors and officers, and licence conditions

### How to ask well

**Don't ask what you can infer, but do confirm it.** If they say "we're a UK SaaS business selling
to consumers in Europe," set `consumer_facing: true`, `sector` to software, and propose `UK` and
`EU` — then say what you assumed and let them correct it.

**Headcount matters more than it looks.** Several employment and reporting obligations turn on
thresholds, so an approximate number per jurisdiction is worth pressing for gently. "Roughly how
many people in the UK — under 50, under 250, or more?" gets there without an interrogation.

**Push a little on the exposure flags, and only there.** These are where a wrong value produces
confidently irrelevant results. `biometric` and `children` in particular pull in materially
different regimes, and users often don't volunteer them — face unlock, age-gated sign-up, or a
photo feature all count. Ask directly.

**Don't guess an exposure flag to be safe.** Setting `biometric: true` on a hunch floods every
later scan with irrelevant high-impact findings and trains the user to ignore the output. If you
don't know, ask; if the user doesn't know, record it as unknown and say the next scan may miss or
over-report in that area.

## 3. Set the scan-state fields

- `last_scan_date` → **90 days before today**, and say so
- `reported_ledger` → empty
- `profile_version: 1`, and a `profile_name` the user will recognise

## 4. Emit the block and explain what to do with it

Output the complete YAML block, then, in two or three sentences:

- **Save it** — in a project file or notes. Supply it at the start of each scan.
- **Each scan returns an updated block. Save that one too.** This is how "what's new since last
  time" works; skip it and every scan re-reports the same items.
- Echo selected states (or “state coverage off”). Name unselected profile states, local law,
  and EU member-state implementation as exclusions. Use the pending baseline rules when
  adding or removing states; preserve the existing global scan date and ledger.

Then offer to run the first scan, noting it will be a 90-day baseline rather than a delta.

## 5. Updating an existing profile

Accept a partial change without re-interviewing. Keep `last_scan_date` and `reported_ledger`
exactly as they are — an update is not a reset, and clearing the ledger would re-report everything.

Change only what the user asked for, then re-emit the whole block so they have one current artifact
to save.

For scope-expanding changes, also create `coverage.pending_scope_baselines` entries under the
schema rules. Explain that the next scan checks earlier developments and standing obligations
relevant to the change, not only publications since the last scan. Preserve pending work and all
saved rule snapshots. Do not promise coverage of unsupported countries or silently select states.

**Say when a change alters what will be in scope.** Adding `biometric` to `personal_data`, crossing
a headcount threshold, or adding a jurisdiction changes what the next scan surfaces, and the user
should hear that from you rather than be surprised by a scan that suddenly looks different:

> Added `biometric`. That engages special-category data rules and, with `in_product` AI, high-risk
> AI classification — your next scan will likely surface materially more in `privacy_ai`.

**Never silently correct a field the user set.** If something looks wrong — headcount inconsistent
with revenue band, a jurisdiction with no entity or staff — raise it as a question. The profile is
their artifact and counsel may have set a value deliberately.

View saved version →

---
name: horizon-scan
description: Scan US federal, optionally selected US states, EU, and UK primary regulatory sources for new and upcoming changes since the user's last scan, scoped to their saved compliance profile, and return each finding with a source citation and a materiality score. Use when the user asks what regulatory or compliance changes affect their business, what is new since their last scan, what is coming up, or which consultations are open. Requires a compliance profile; if the user has none, run the compliance-profile skill first.
---

Read `../../references/runtime-safety.md` before using this workflow. Resolve relative paths from this skill directory. To use a sibling skill, read its `../<skill-name>/SKILL.md`; no special invocation tool is required.


Produce a deduplicated, source-cited list of regulatory developments relevant to one specific
business, with a materiality score on each.

**Read `../../references/citation-discipline.md` before producing any output. It governs everything
below, and where anything here appears to conflict with it, it wins.** The short version: every
claim needs a link fetched in this session, a verbatim supporting quote, and per-claim sourcing for
dates, deadlines, thresholds, and penalties. No link, no claim.

---

## 1. Get the profile

Ask the user for their saved compliance profile block. If they don't have one, run
`compliance-profile` first — do not scan against guesses about their business, because a scan scoped
to the wrong business is worse than no scan.

Read `../../references/profile-schema.md` to interpret it. Extract:

- `last_scan_date` → the start of the scan window. Today is the end.
- `operating_jurisdictions` → which source registry files to use
- `coverage.us_states` → optional selected states; absent means none
- `coverage.pending_state_baselines` → first/re-enabled state windows from the schema
- `coverage.pending_scope_baselines` → historical and standing-law checks for scope changes
- `domains_in_scope` → which domain sections apply
- `exposure_flags` → the applicability triggers
- `materiality_thresholds` → the reporting cut
- `reported_ledger` → what to suppress
- `watch_keywords` / `exclude_keywords` → extra searches and noise suppression

State the window and scope back to the user in one line before scanning, so a wrong profile is
caught before the work rather than after:

> Scanning 2026-07-11 → 2026-09-09 · US-Federal, EU, UK · privacy_ai, employment, esg,
> trade_sanctions, consumer_protection · reporting at medium and above.

## 2. Announce uncovered jurisdictions — before scanning, not after

Announce selected states (or “state coverage off”), their scan windows, and any profile
states not selected. Identify EU member-state implementation, local law, and unsupported
jurisdictions as excluded. For example:

> State research enabled: California and New York. Not searched: Texas (not selected),
> city/county law, and EU national implementation. Source coverage will be reported by state.

This goes first, not in a footnote. A user who believes a jurisdiction was searched when it was not
is the worst outcome this skill can produce.

## 3. Select sources

Load only the registry files you need:

- `US-Federal` → `../../references/sources-us-federal.md`
- Nonempty `coverage.us_states` → `../../references/sources-us-states.md`
- `EU` → `../../references/sources-eu.md`
- `UK` → `../../references/sources-uk.md`

Then read `../../references/cross-industry-domains.md` for the domains in scope, to get the
applicability triggers and the agency slugs and feeds to watch per domain.

## 4. Query primary sources first

Before ordinary delta queries, process pending scope baselines under `profile-schema.md`.
Announce their affected scope and historical window separately. Search older developments and
current standing obligations, including older rules with ongoing duties or transitions; do not
constrain that standing-law review by publication date. Use the relevant baseline start instead
of last_scan_date in historical queries below. Preserve pending entries on incomplete research.

Work the registry in tier order — `primary`, then `regulator`. Start from the official registers when available; use official-domain search as a
fallback to find primary documents, and disclose incomplete enumeration. Do not rely on commentary; the registers are structured, complete for their scope, and citable.

**US federal.** Query the Federal Register API once per relevant agency slug, plus once per
`watch_keyword` using `conditions[term]`. Always set
`conditions[publication_date][gte]=<last_scan_date>` and `[lte]=<today>`. Follow all result
pages, or report the unprocessed range as a coverage gap. Request the full field list from the registry
file. Check `count` before paging; a wide window across many agencies can return thousands.

**Selected US states.** Follow `sources-us-states.md` for each selected state and its
baseline window: discover official legislature, register/code, and relevant regulator
sources, search the profile domains, and record actual coverage for every source family.
Do not treat federal sources as state coverage. Keep state identifiers namespaced in the
ledger and return partial/deferred states explicitly.

**EU.** The OJ L feed covers only the last few days. For any window longer than that, also use
EUR-Lex search or the SPARQL endpoint. **If you cover only part of the window, the EU result is
partial and must be labelled as such** — a feed-only result presented as a full-window EU scan is
the most likely way this skill produces a false "nothing new."

**UK.** Use the dated `/new/uk/<date>` endpoints across the window, or the year feeds filtered by
`ukm:CreationDate`. Separate `UnitedKingdomDraftStatutoryInstrument` (stage `proposed`) from
`UnitedKingdomStatutoryInstrument` (made, but check commencement).

## 5. Filter

In this order:

1. **Ledger comparison.** Follow `profile-schema.md`: re-fetch pending/future ledgered
   instruments as well as new candidates. Suppress only after checking stage and material
   changes. Re-report verified changes as updates. Legacy string IDs have unknown prior
   stages; do not fabricate history or suppress a possible update without checking.
2. **Exclude keywords.** Drop title/summary matches on `exclude_keywords` — unless the item matches
   an `always_report` tag, which overrides exclusion.
3. **Applicability.** Apply the domain triggers against `exposure_flags`. Drop confirmed `not_applicable` items even when a liability keyword matches.
   Keep `unassessed` items separate as applicability questions, not confirmed duties.

## 6. Open the sources and score

For each surviving candidate, **fetch the actual document.** Feed metadata and API abstracts are
triage only — they are not sources for a finding. This is the step that costs time and the step
that makes the output trustworthy, so do not skip it to cover more items. Fewer fully sourced
findings beat more thinly sourced ones.

From the document, extract and quote:

- lifecycle stage, from the document's own words
- every date: comment deadline, entry into force, applies-from, staged milestones, first reporting
- any scope threshold that decides whether it binds this business
- penalty and liability exposure

Then score against `../../references/materiality-rubric.md` on all five axes, naming the profile
field that drove applicability.

**Where a date must be computed** — an EU act's "twentieth day following publication," say — show
the arithmetic, quote the provision it rests on, and label the result as derived rather than
presenting it as a date the instrument states.

**Where no date is published**, the value is `undated`. Never estimate. A proposed US rule has
`effective_on: null`; that is a fact to report, not a gap to fill.

## 7. Run the provenance self-check

Walk every finding against the checklist in `citation-discipline.md`:
`source_url` fetched this session and pointing at the document; `official_id` present;
`supporting_quote` verbatim; every date, deadline, threshold, and penalty traced to a quote;
lifecycle stage matching the source; nothing secondary-tier presented as a finding.

Move every failure to **Coverage gaps** or **Unverified leads**. Do not repair a weak finding by
softening its language — an unsourced claim hedged with "reportedly" is still an unsourced claim.

## 8. Output

```
## Horizon scan · <profile_name>
Window 2026-07-11 → 2026-09-09 · US-Federal, EU, UK · threshold: medium

**Not covered:** <uncovered jurisdictions, or "none">
**Provenance:** N findings, N fully sourced · N coverage gaps · N unverified leads

### Needs attention now
<always_report matches and items where effort exceeds lead time>

### Findings — <jurisdiction>
<ordered per the rubric: always_report, then impact, then timeline, then applicability>

Each finding:
**<Title>** · `<stage>` · <official_id>
<One line on what it does.>
- applicability: `binds_us` — <profile field and threshold, with quote>
- impact: `high` · effort: `policy_change` · timeline: `30-90` (to <which date>) · confidence: `high`
- <each date with its own quote and link>
- source: <link> (<publisher>, <tier>, retrieved <date>)

### Open consultations — you can still influence these
<items with a live comment deadline, soonest first, with the deadline quoted and the link to respond>

### State source coverage
<each selected state, source families/URLs, domains, window, and completeness; or “off”>

### Coverage gaps
<each failed source, what it would have covered, and the date attempted>

### Unverified leads
<secondary-tier signals with no primary source reached — explicitly not findings>

### Updated profile — save this
<the full profile block with new last_scan_date and extended reported_ledger>

---
Regulatory intelligence, not legal advice. Verify against the cited primary sources before acting.
```

Lead with **open consultations** in your summary remarks when any deadline is close. The chance to
shape a rule before it binds is often worth more to the user than notice after it has.

## 9. Emit the updated profile

For each verified finding, append the structured deadline and rule-detail snapshot required by
the schema. Include an explicit previous → current comparison for verified changes, retaining
prior sources. Separate newly relevant older rules from actual legal amendments. Unknown previous
values are labeled baseline unavailable. Clear completed scope baselines only after standing-law
and historical checks succeed; retain partial entries and explain their outstanding work.

Follow `profile-schema.md` for ledger records, legacy IDs, and pruning. Set `last_scan_date`
to today only after a complete scan of the profile's supported scope. On source failures,
partial paging, a narrowed request, or an interrupted scan, retain the previous boundary
and explain that the next scan must retry it. Save sourced findings in the ledger either way.
Change no business fields without the user's request.

Tell the user plainly that the scan is only incremental if they save this block. That is the whole
delta mechanism, and it fails silently if they don't.

---

## Notes on judgement

**A first scan is a baseline, not a delta.** With `last_scan_date` bootstrapped 90 days back across
five domains and three jurisdictions, expect a long list. Say so, and offer to narrow the window or
raise the threshold instead of returning something unmanageable.

**"Nothing new" is a legitimate result** — but only say it when the sources actually returned
nothing, and never when a source failed. A failed source produces a coverage gap, and the honest
sentence is "no changes found in the sources that responded, with N gaps," not "nothing new."

**Volume is not value.** The registers carry a great deal of sector-specific matter irrelevant to any
one business. A scan returning six things that matter is more useful than one returning sixty, and
padding a scan with `monitor_only` items to look thorough works directly against the user.

**Don't let a big-name regulation crowd out a small binding one.** A minor SI that actually binds
this business outranks a landmark regulation that doesn't. Score against the profile, not against
how much the instrument has been in the news.

View saved version →

---
name: regulatory-change-brief
description: Render horizon scan findings into a finished deliverable — an in-house executive or board memo, a law-firm client alert, obligation register rows for a compliance tracker, or a short email or Slack digest — with citations carried through to the reader. Use when the user asks to write up, summarise, or circulate regulatory findings, or asks for a memo, alert, briefing, digest, or register entries from a scan.
---

Read `../../references/runtime-safety.md` before using this workflow. Resolve relative paths from this skill directory. To use a sibling skill, read its `../<skill-name>/SKILL.md`; no special invocation tool is required.


Turn findings into something the user can send. The analysis is already done by `horizon-scan` or
`assess-materiality`; this skill is about audience and format.

**Read `../../references/citation-discipline.md` first.** Then the rule that governs this skill
specifically: **citations travel to the reader.** A brief is where sourcing is most tempting to
strip for readability and where stripping it does the most damage — the recipient is further from
the source than the user is, and often acts on it.

Templates: `../../references/output-templates.md`.

---

## 1. Ask which format, if not obvious

| Format | Audience | Shape |
|---|---|---|
| `exec-memo` | In-house: GC, exec team, board | What changed, what it means for us, what we're doing, what we need |
| `client-alert` | Law firm: clients or a client group | What changed, who it affects, what to do, how we can help |
| `register` | Compliance tracker / obligation register | Structured rows, CSV-ready |
| `digest` | Email or Slack, internal circulation | Short, scannable, links out |

Infer from context where you can — "write this up for our board" is an `exec-memo`, "send to
clients" is a `client-alert`. Ask only when genuinely ambiguous.

Also ask, or infer, **who the reader is and what decision they face**. A board paper for an
approval decision is a different document from an FYI to the same board.

## 2. Filter to what this audience needs

For a client alert, first obtain the client's saved business profile, or run `compliance-profile`
for that client before discovery. Never substitute the law firm's own profile. For a client group,
agree an explicit representative profile and disclose its limits; keep materially different clients
in separate profiles and ledgers. If findings came from another profile, run `horizon-scan` against
the client profile before drafting: filtering a firm-scoped scan cannot recover missed rules.
Existing findings may be reused only when their scope matches and sources are reverified.
Start the alert with a concise summary of the client business, jurisdictions, activities and
unresolved applicability facts that scoped the research.

A brief is not a scan with a header on it. Cut hard, and cut by relevance to the reader:

- **exec-memo / digest** — `binds_us` and `likely` only, at the profile threshold or above.
  `monitor_only` items belong in an appendix or nowhere. Put `unassessed` items in a
  separate questions section when material to the decision; never present them as duties.
- **client-alert** — items discovered against the client or agreed client-group profile.
  Be explicit about that audience and individual applicability limits.
- **register** — everything reportable, since a register is a system of record rather than a read.

## 3. Carry the citations through

Non-negotiable, per format:

- **exec-memo / client-alert** — inline linked references at each claim, plus a closing sources
  list with `official_id`, publisher, and `retrieved_on` for each item.
- **register** — mandatory `source_url` and `official_id` columns. A row without them is not
  written.
- **digest** — every item links to its primary source. A digest is the format most likely to be
  forwarded onward with no further context, which makes the link matter more, not less.

**If an item's provenance cannot be rendered in the chosen format, the item does not go in the
brief.** Do not include it unlinked. Say which items you left out and why.

**Never summarise away a date's source.** In prose, keep the link on the sentence carrying the date:

> Comments must be received or postmarked by 11:59 p.m. Eastern Time on
> [30 September 2026](https://www.federalregister.gov/documents/2026/08/03/2026-15717/ventilation-plan-approval-criteria).

Note the time and time zone survived into the prose. Compressing that to "closes 30 September" loses
eleven hours on a filing deadline, which is the kind of tidying that costs someone a submission.

## 4. Carry the gaps through too

Every brief reproduces the coverage-gap list from the scan. This is not optional and not a
formality.

A reader who receives a brief with no gap list will read it as a complete picture of the regulatory
horizon. If US state law was not searched, or the EU window was only partly covered, or a source
failed, the recipient needs to know — they are the one who will act on it, and they cannot see the
scan behind it.

Keep it short and plain:

> **Not covered by this scan:** states not selected, local law, and any selected state source
> families marked partial or failed. EU coverage for 11 July – 2 September relied on the
> OJ feed only and may be incomplete.

## 5. Write for the audience

**exec-memo.** Lead with the decision or the ask, not the chronology. An executive reader wants to
know what they must decide and by when. Put "what we need from you" high, not at the end.

**client-alert.** State up front who is affected and who is not — clients reading an alert that
doesn't apply to them stop reading the next one. Be careful with the line between information and
advice; describe the position and the general steps, and be explicit that specific advice depends
on the client's circumstances.

**register.** Consistency beats prose. Same vocabulary, same date format, one obligation per row.

**digest.** Ruthless. One line per item, the date, the link. If it runs past a screen, it won't be
read, and a digest nobody reads is worse than none.

## 6. Standard elements on every format

- **Disclaimer**, on every brief: regulatory intelligence, not legal advice; verify against cited
  sources before acting.
- **Provenance tally**: `N items, N fully sourced, N coverage gaps`.
- **Scan window and date**, so the reader knows how current it is. A brief read three months later
  with no window on it is actively misleading.

## 7. Self-check

- [ ] every claim in the brief traces to a link that reaches the reader
- [ ] every date carries its source
- [ ] no item was included without renderable provenance
- [ ] the coverage-gap list is present
- [ ] the disclaimer, window, and tally are present
- [ ] nothing from `Unverified leads` made it in — by rule, they never enter a brief

---

## On tone

Both audiences are professional readers who will lose confidence in an overstated brief faster than
in a dull one. Two habits to avoid:

**Don't manufacture urgency.** If nothing is urgent, say the horizon is quiet. A brief that makes a
`medium` item sound `critical` gets discounted, and then the real `critical` item gets discounted
too.

**Don't hedge to cover thin sourcing.** "May potentially require consideration of possible changes"
is not caution, it is an unsourced claim in a raincoat. Either the instrument requires something —
quoted and linked — or you say what is not yet established. Certainty should come from the source,
and uncertainty should be stated as a specific unknown rather than diffused through the prose.