{"description":"Regulatory Horizon Scanning & Triage as a modular, decision-aware workflow. Each cycle runs on an Audit item created for the scan window — `audit_type` = compliance, titled \"Regulatory Horizon Scanning — <period>\", with `period_start`/`period_end` set to the detection window; the workflow instance attaches to that Audit and is archived against it at close. It can stand alone, but is designed to exchange handoff packages with related workflows instead of duplicating repeated work. In scope: detecting and summarizing regulator publications, routing them to the authority-source register, applicability screening against the compliance profile, entity profile, and activity inventory, owner assignment, and queueing. Out of scope: obligation mapping, gap and impact analysis, and implementation — those belong to the downstream Regulatory Impact Analysis & Obligation Mapping workflow, which consumes this workflow's named deliverables: the prioritized impact-analysis intake queue and the cycle evidence package. There is no upstream workflow and no prior handoff to consume; this is the sensing edge of the regulatory-change chain, and its standing inputs are the monitored feed list, the prior cycle's cursor, the authority-source register, and the Policy items that cite those authorities.","edges":[{"id":"e-screen-applicability-handoff-to-related-workflow","source":"screen-applicability","target":"handoff-to-related-workflow"},{"id":"e-screen-applicability-assign-impact-owner","source":"screen-applicability","target":"assign-impact-owner"},{"id":"e-assign-impact-owner-classify-disposition","source":"assign-impact-owner","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"action_required"},{"id":"e-classify-disposition-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","whenValue":"clear"},{"id":"e-create-action-plan-handoff-to-related-workflow","source":"create-action-plan","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-GOV-03","UC-RISK-11"],"department":"compliance-legal","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-horizon-scanning-triage","contentDigest":"sha256:6a8bf27bfdcd86939da101dae84bfe0394c1e12c5cda148d1d9fc22333700325","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:6a8bf27bfdcd86939da101dae84bfe0394c1e12c5cda148d1d9fc22333700325","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-horizon-scanning-triage"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"reg-horizon-scanning-triage","source":"coworkcanvas-gallery","standards":["gdpr","dora","nydfs-500","eu-ai-act","nis2","pci-dss","hipaa","ccpa"],"teams":["compliance-legal"]},"name":"Regulatory Horizon Scanning & Triage","nodes":[{"data":{"description":"Place every routed publication on the organization's regulatory coverage map — binding force, lifecycle stage, thematic domain, and coverage placement — so applicability screening starts from a classified change instead of raw regulator text.\n\nRule, with provision-level rationale, whether each classified change applies to the organization, so impact-analysis capacity goes only to genuine obligations and every \"not applicable\" ruling survives an examiner asking to see the reasoning.","instructions":"**Objective**\nPlace every routed publication on the organization's regulatory coverage map — binding force, lifecycle stage, thematic domain, and coverage placement — so applicability screening starts from a classified change instead of raw regulator text.\n\nRule, with provision-level rationale, whether each classified change applies to the organization, so impact-analysis capacity goes only to genuine obligations and every \"not applicable\" ruling survives an examiner asking to see the reasoning.\n\n**Inputs**\nThe batch of new publications since the last scan — each with regulator, title, source URL, and publication date — pulled per the sensor procedure below.\n- The monitored feed list with any per-feed authority-slug hints — a standing document attached to this step each cycle; there is no native Feed/Source item type, so the feed roster lives as that document.\n- The last-checked cursor carried forward from the previous pass — read from the prior cycle's closure record (the cursor bounds recorded on that cycle's handoff-and-close step), not re-derived.\n- The existing authority-source register — there is no native item type for a regulation, so the register lives as the per-authority routing records plus the publication documents attached on prior cycles' Ingest steps.\n- The Policy items that cite those authorities — matched through the policy-to-authority citation linkage — carrying their `framework` mapping, `policy_owner`, and obligation text (in `Policy.description`).\n\nThe routed batch from ingestion: the per-publication routing records with structured summaries, publication types, and their authority-source references.\n- The compliance profile — the frameworks the organization is subject to and the domains they cover. Supplied as a document on this step; the in-tenant signal for what is actually controlled is the `Control.framework` values on existing Control items.\n- The authority-source register (each authority's kind and status, and the count of Policy items citing it) — the routing records and publication documents from the Ingest step.\n- The entity profile — legal entities, licenses held, regulated sectors, and the headcount and revenue figures threshold tests use. Uploaded as a document on this step; there is no native Entity item type.\n- The activity inventory — the business- and IT-process footprint is existing Process items (`process_type` = business_process | it_general_control, `process_owner`); the personal-data processing, cardholder-data flows, AI systems and role-per-system, ICT services, and jurisdictions served have no native type and come as a document on this step.\n- The Policy items flagged at ingestion, with their obligation text (`Policy.description`) and authority citations.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Ingest publications”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Ingest publications: Ingest each new regulator publication surfaced by the horizon-scan feed sensor and route it to the correct authority record, so the authority-source register stays current and every affected policy is flagged for re-review.\n\n2. Pull the batch: poll each monitored regulator feed for items published after the last-checked cursor — prefer the feed's RSS/Atom endpoint, and fall back to fetching the regulator's publications page directly when no machine-readable feed exists. Collect title, regulator, source URL, and publication date per item, and map the feed's regulator name onto the register's controlled regulator values (the SELECT options on the authority record). Deduplicate by source URL against publications already routed in earlier passes — a re-run must never re-open or re-route an item already processed.\n3. Summarize each publication into structured fields — regulator, region, publication type (final rule, proposal, guidance, enforcement, or amendment), effective date, comment-period or close dates (if any), and the canonical source URL — plus a one-paragraph, plain-language summary of what changed.\n4. Route each publication. Search the existing authority-source register by regulator and title or slug for a likely parent; if a per-feed slug hint is supplied, prefer that match. When the match is fuzzy, have the accountable owner confirm it before attaching. There are two routes:\n   - Amendment to a known authority: attach the publication as supporting evidence on the matched authority-source record, link the amendment to that record, and advance the authority's rolling last-updated-by-publication date to the publication date (and its version label if the publication declares one). Do not create a duplicate authority.\n   - Materially-new authority: draft a new authority-source record with title, authority kind (regulation, standard, framework, guidance, or contractual), regulator, region, source URL, effective date (if known), a one-paragraph summary, and active status; attach the publication document once the draft is approved.\n   One boundary inside routing: a regulator exam or inquiry directed at the organization is not archive material on an authority — it opens as a regulatory audit engagement. Only regulator-published material (rules, proposals, guidance, enforcement actions on the market) attaches here.\n5. Attach with archive discipline: every document about a regulation hangs off the one authority-source item it belongs to — publications, amendments, enforcement letters, historical versions, regulator correspondence — with the file name annotated with document kind and publication date, so the item's document list reads as the regulation's timeline. There is no separate archive record type. For very large corpora (a full supervisory handbook with thousands of historical pages), link by URL to the regulator's official archive rather than uploading binaries. Bump last-updated-by-publication only for a publication or amendment that represents the regulation's newest state — enforcement letters, correspondence, and historical versions attach without a bump; the bump is what surfaces the change in the next period digest.\n6. Bulk historical back-archive (when onboarding a newly registered authority or backfilling history): attach the historical publications to the authority-source item in one pass, ordered by publication date, each annotated with kind and date. Do not bump last-updated-by-publication for superseded historical versions, and do not flag policies for re-review — a back-archive organizes the record of changes already absorbed into current text; it creates no triage work. Back-archive runs are out-of-band from the sensor and must not advance or disturb the last-checked cursor.\n7. Flag affected policies. For each routed authority, find the policy items that cite it (through the cites-authority-sources linkage) and surface each one — policy title, obligation excerpt, last-reviewed date — as needing re-review under this change. Never edit a policy's obligation text here; obligation reconciliation is a downstream step.\n8. Hold the human checkpoint: an accountable owner confirms every fuzzy publication-to-authority match and approves each new authority-source draft before it becomes the register's record of the change.\n9. Close the pass: advance the last-checked cursor only after every publication in the batch is summarized, routed, and its policy flags raised. A pass that fails midway leaves the cursor untouched, so the next run re-detects the unprocessed tail instead of losing it.\n\n10. Assessment scope for Classify and screen applicability: Place every routed publication on the organization's regulatory coverage map — binding force, lifecycle stage, thematic domain, and coverage placement — so applicability screening starts from a classified change instead of raw regulator text.\n\nRule, with provision-level rationale, whether each classified change applies to the organization, so impact-analysis capacity goes only to genuine obligations and every \"not applicable\" ruling survives an examiner asking to see the reasoning.\n\n11. Classify binding force. Distinguish: directly binding regulation or rule; directive requiring transposition (the obligation arrives through member-state law — NIS2 is the standing example — so the national transposition is what eventually binds and must be tracked separately); supervisory guidance and expectations (not law, but examiners test against it); consultation or proposal (no obligation yet — the decision it creates is whether to comment); enforcement action (no new text, but a signal of supervisory priorities worth weighting). Contractual regimes classify as contractual, not statutory — PCI DSS binds through acquirer and card-brand contracts.\n12. Classify lifecycle stage: proposal, adopted, in force, applicable — and record in-force and application dates separately when the instrument staggers them. DORA entered into force in January 2023 but applied from 17 January 2025, and the EU AI Act staggers application by risk class over several years; triage that treats \"in force\" as \"applicable\" queues work years early or, worse, late.\n13. Classify thematic domain(s): privacy and data protection (GDPR, CCPA, HIPAA privacy and security rules), ICT resilience and cybersecurity (DORA, NIS2, NYDFS Part 500), payments (PCI DSS), AI governance (EU AI Act). A single publication can hit several domains — classify all of them, not just the loudest; the domain set drives owner assignment later.\n14. Place each change on the coverage map: in-coverage (amends a framework already in the compliance profile); coverage-adjacent (a new instrument from a monitored regulator that the profile does not yet include — classify it and pass it to screening rather than dismissing it); or out-of-coverage (a regulator or domain outside the monitored set — record why it surfaced and whether the feed list needs correcting; recurring out-of-coverage detections mean the sensor is aimed wrong).\n15. Assign a severity pre-rating to order the screening queue: binding instruments with near application dates and enforcement signals on in-scope obligations rate highest; breadth — how many policies cite the authority — raises the rating. The pre-rating sequences the work; it is not the applicability ruling.\n16. Entity scope: is the organization (or any group entity) the kind of person the instrument binds? Worked tests: DORA binds financial entities and critical ICT third-party providers; NYDFS Part 500 binds entities operating under New York Banking, Insurance, or Financial Services Law — check the section 500.19 exemption tiers before concluding full applicability; HIPAA binds covered entities and their business associates; CCPA applies only above thresholds (annual revenue over $25M, or personal information of 100,000+ consumers or households, or 50%+ of revenue from selling or sharing personal information).\n17. Territorial scope: establishment is not the only hook. GDPR Article 3(2) reaches organizations with no EU establishment that offer goods or services to, or monitor the behavior of, people in the EU; the EU AI Act reaches providers placing systems on the EU market wherever established, and providers and deployers whose system output is used in the EU. Screen against where customers and data subjects are, not just where offices are.\n18. Activity scope: does the organization actually do the regulated thing — store, process, or transmit cardholder data (PCI DSS); operate or deploy AI systems in a regulated risk class (EU AI Act); provide services in an NIS2 sector annex? Tie the answer to the activity inventory, not to recollection.\n19. Material-change test for amendments to already-applicable authorities: does the amendment change what the organization must do — a new requirement, a changed threshold, a new deadline, an expanded scope — or is it editorial and consolidating? Compare the amendment against the flagged policies' obligation excerpts; an amendment that changes nothing those policies commit to is recorded as applicable with no action, with that comparison as evidence.\n20. Rule each change one of three ways: applicable — route to owner assignment; not applicable — write the rationale citing the specific scoping provisions relied on, plus a re-check trigger (re-screen if the organization enters the market, crosses the threshold, or the instrument's scope is amended); or monitor — proposals and consultations not yet binding get a watchlist entry carrying the adoption milestone or comment deadline that re-opens the ruling. When a ruling is genuinely uncertain, send it forward to impact analysis rather than dismissing it: a wrong \"not applicable\" is invisible until an examiner finds it.\n\n**Record in AssureSwarm**\nPer publication, a routing record on this step — the register has no native authority-source item type, so it is kept as these routing records plus the attached publication documents: the structured summary fields, the route taken (amendment vs. new authority), the target authority-source id (existing or proposed), and the attached publication file or URL link annotated with document kind and publication date (step document).\n- The affected policies flagged for re-review — matched to the Policy items that cite the routed authority (`policy_owner`, `framework`, `review_frequency`, `next_review_date`); the per-change re-review flag itself is carried on this step's routing record, since it has no native Policy field.\n- The closing cursor position for the pass, recorded on this step.\n\nThe classification on each publication's routing record on this step — the per-change triage record has no native Regulatory Change item type: binding force, lifecycle stage with both in-force and application date fields where staggered, domains, coverage placement, and severity pre-rating.\n- Corrections to a matched authority's fields (region, authority kind) recorded on that authority's routing record on the Ingest step, since the register has no native item form.\n- Out-of-coverage and coverage-gap observations logged on this step for the disposition decision.\n- The ruling, the provision-level rationale, and the re-check trigger on each change's routing record, cross-referenced to its authority-source routing record.\n- Watchlist entries for monitor-class items with their re-check dates, carried on this step's ruling log (no native watchlist type).\n- Rulings pending legal input noted as open constraints on this step.\n\n**Exit criteria**\nAll new publications are summarized and routed; every claim about a publication cites its source URL; each publication is matched to exactly one authority or a justified new draft; affected policies are flagged for re-review with no obligation text edited; the register reflects each amendment or new draft; the cursor is advanced past the processed batch — ready to hand to coverage classification. Do not perform the downstream obligation mapping or impact analysis here; that is a separate workflow. Every publication in the batch carries a complete classification; staggered in-force and application dates are recorded separately; coverage placement is explicit with out-of-coverage observations logged; the screening queue is ordered by severity pre-rating. Every classified change carries a ruling backed by the specific scoping provisions and the entity or activity facts relied on; every not-applicable and monitor ruling has a recorded re-check trigger; uncertain rulings are routed forward, not parked; the applicable set is ready for owner assignment.","label":"Classify and screen applicability","performedBy":{"agent":"reg-artist","note":"publication summarize + authority-routing engine","primitives":["coach-query-data","coach-item-update","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"screen-applicability"},{"data":{"description":"Assign one accountable owner with a due date to each applicable change, then queue it as a prioritized impact-analysis intake","instructions":"**Objective** — Put one named owner with a due date on every applicable change, so the downstream impact analysis starts with accountability rather than a shared mailbox nobody answers.\n\nConvert each accepted assignment into exactly one queued intake for Regulatory Impact Analysis & Obligation Mapping, batched and prioritized so downstream capacity lands on the most consequential changes first.\n\n**Inputs**\n- The applicable changes with rulings, severity pre-ratings, and flagged-Policy lists — from the screening step's ruling log.\n- The domain ownership map (which function owns which regulatory domain — privacy office or DPO; CISO or IT risk; payments; product and legal for AI; compliance for the rest) and the escalation contacts per function — supplied as a document on this step; there is no native ownership-map type.\n- Current owner load — the open impact analyses per owner, read from the open intake queue (in-tenant, the set of downstream Regulatory Impact Analysis workflow instances created at handoff) and surfaced on the coverage dashboard.\n- The open impact-analysis intake queue, for deduplication and load visibility.\n\n**Procedure**\n1. Map each change's domain to its owning function: privacy and data-protection changes to the privacy officer or DPO; ICT-resilience and cyber rules (DORA, NIS2, NYDFS Part 500) to the CISO or IT-risk owner; payments changes to the PCI steward; AI Act changes to the AI-governance owner — often product and legal jointly, but still name exactly one accountable owner and list the others as consulted. A change classified into several domains gets one accountable owner from the dominant domain and named contributors from the rest.\n2. Name an individual, never a team: the owner needs authority over the affected policies and controls, subject-matter competence, and capacity. Check load before assigning — more than about three concurrent impact analyses on one owner reliably predicts missed due dates; rebalance, or split the work through consulted-party support, before assigning a fourth.\n3. Set the due date by urgency, not a uniform cycle: an enforcement action or a binding rule applying inside 90 days — impact analysis due within 5 business days; a consultation the organization may respond to — due at least 10 business days before the comment deadline, or the comment option is forfeited by default; routine guidance — the standard cycle, commonly 30 days.\n4. Issue the assignment carrying the full intake context — structured summary, source URL, applicability rationale, flagged policies — and require explicit acceptance. Silence is not acceptance: no acknowledgment within 3 business days escalates to the function head; still unresolved, the cycle's accountable owner arbitrates, assigns, and records the arbitration decision.\n5. For due dates more than 30 days out, name a deputy so the assignment survives leave and turnover.\n6. Choose the batching unit. Default is one intake per authority change. Group multiple publications into a single intake only when they amend the same authority as one package — a final rule published together with its annexes and interpretive guidance is one change, and splitting it fragments the analysis and double-counts effort. Never batch across different authorities merely because they share a regulator.\n7. Deduplicate against the open queue: if an impact analysis is already open for the same authority, attach the new publication and its flags to that intake instead of opening a second — two open analyses on one authority guarantee divergent conclusions landing in the register.\n8. Prioritize with explicit bands: P1 — binding with an application date inside 90 days, an enforcement signal on an in-scope obligation, or breadth of five or more flagged policies; P2 — binding with a farther application date; P3 — monitor-adjacent or narrow guidance. P1 items are queued within 1 business day of triage; log the queue timestamp so the SLA is checkable.\n9. Build each intake package so the analyst starts without re-doing triage: the structured summary and canonical source URL, the authority-source link, the applicability ruling with its provision-level rationale, the flagged policies (title, obligation excerpt, last-reviewed date), the owner and accepted due date, and the priority band.\n10. Hold the boundary: do not start decomposing obligations, assessing gaps, or planning implementation here. Triage's statement to downstream is \"this applies, this person owns it, and these policies are touched\"; what must change is the downstream workflow's finding, not this step's.\n\n**Record in AssureSwarm**\n- Owner, consulted parties, due date, and deputy recorded on each change's routing record (no native change item — the triage record lives on the screening and assignment steps).\n- The assignment notice and the explicit acceptance — or the escalation trail and arbitration decision — recorded against that change record.\n- One intake per change (or per publication package) recorded as an intake entry on this step, cross-referenced to its authority-source routing record and to each flagged Policy item; there is no native intake item type, so the queue is carried here and materializes downstream as one Regulatory Impact Analysis workflow instance per intake at handoff.\n- Priority band, owner, due date, and the queue timestamp recorded on each intake entry.\n- The dedupe disposition recorded wherever a publication joined an existing intake instead of opening a new one.\n\n**Exit criteria** — Every applicable change has exactly one accountable owner with a due date scaled to urgency; each assignment carries an explicit acceptance or a recorded arbitration decision; deputies named where due dates run past 30 days. Every applicable change sits in exactly one intake with owner, priority, due date, and a complete intake package; no authority has two open intakes; P1 items show queue timestamps inside the 1-business-day SLA.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` issues the owner assignments and runs the acceptance chase — reminder, then function-head escalation — with a logged trail.","label":"Assign impact owner and queue for analysis","performedBy":{"primitives":["coach-item-update","coach-notify","coach-item-create","coach-items-link"]}},"id":"assign-impact-owner"},{"data":{"decisionField":"disposition_path","description":"Refresh the coverage dashboard, then classify the result of Regulatory Horizon Scanning & Triage so the agent keeps only the relevant closure path","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"Ready to close","value":"clear"},{"label":"Action required","value":"action_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Refresh the horizon-scanning coverage dashboard so sensor health, triage throughput, and coverage posture are visible, then decide on that record whether this triage cycle closes clean or needs an owned action plan first. The cycle's accountable owner makes the call, and the selection prunes the branch that does not apply.\n\n**Inputs**\n- This pass's counts: publications detected per feed, routed, ruled (applicable, not applicable, monitor), and queued.\n- The feed list with per-feed last-successful-poll timestamps and each feed's normal publication rhythm.\n- The intake queue state and the watchlist of monitor-class items.\n- Prior-period dashboard figures for comparison.\n\n**Procedure**\n_Items 1–6 are agent-run (folded from the former \"Update coverage dashboard\" step); the human moment is the branch call in item 7._\n1. Score sensor health per feed: last successful poll against the expected cadence, and detections against the feed's normal rhythm. A feed silent for two or more expected cycles is a sensor defect until proven otherwise — regulators rarely go quiet; feeds break silently. An empty batch from a broken feed must render as a red flag, not a clean pass.\n2. Show coverage posture: frameworks in the compliance profile versus feeds actually monitoring them, surfacing any in-profile framework with no live feed as a coverage gap, plus any out-of-coverage detections from classification that suggest the monitored set is aimed wrong.\n3. Compute throughput and aging per stage: publication date to routed; routed to ruled; ruled to owner-accepted; accepted to queued. Apply the breach thresholds: any publication unrouted more than 5 business days after publication, and any P1 change unqueued more than 1 business day after ruling. Render the breach list itself, not just averages — averages hide the one stuck item that matters.\n4. Show the mix: publications by regulator, type, and route (amendment vs. new authority); applicability outcomes; queue depth by priority band and by owner — owner overload is the leading indicator of missed due dates.\n5. Maintain the watchlist view: monitor-class items with re-check dates and comment deadlines; anything past its date renders as overdue with a named owner.\n6. Compare against the prior period and annotate anomalies where they need explanation — a spike in enforcement-type publications from one regulator is a supervisory-priority signal; record that observation as a comment on the affected authority-source records so it travels with the register, not just with this report.\n7. Verify four things on the refreshed record, then pick the branch below: every publication in the batch is routed with the register updated; every applicable change has an owner and sits in exactly one intake; every not-applicable and monitor ruling carries its re-check trigger or watchlist entry; and the dashboard shows each breach owned.\n\n**Decision criteria**\n- **Ready to close (`clear`)** — the pass processed completely and the scanning machinery itself is sound: no compliance-profile framework without a live feed, no silent or faulty feed, the cursor advanced cleanly with no skipped or duplicated detections, no publication aged past the routing threshold, no ruling stuck awaiting counsel, and no back-archive owed. Queued impact analyses do not block this branch — handing analysis to the downstream workflow is this workflow's success condition, not an open action.\n- **Action required (`action_required`)** — any defect in the scanning-and-triage machinery needs an owned fix before the cycle can stand as reliable: a profile framework with no feed monitoring it; a broken or silent feed, or a cursor fault that skipped or duplicated publications; an unrouted-publication backlog past the aging threshold; an applicability ruling blocked on legal input; a bulk back-archive owed on a newly registered authority; or an assignment that only landed by arbitration or still lacks a capable owner. Enumerate every such item in the rationale — the action plan executes from that list, and an item left out here is a gap nobody fixes.\n\n**Record in AssureSwarm**\n- The coverage dashboard refreshed across the six views above (feed health, coverage posture, aging with the breach list, mix, queue depth, watchlist) — a recurring Dashboard surface.\n- Watchlist entries whose re-check dates moved, updated on the screening step's watchlist log.\n- Each breach recorded with a named owner (breach-list snapshot on this step); supervisory-priority anomalies annotated on the affected authority-source routing records so they travel with the register.\n- Submit the decision form: `disposition_path` (the branch), the step result citing the register, queue, and dashboard evidence behind each of the four verification points — and, for action_required, the enumerated gap list — and the step's approver record.\n\n**Exit criteria** — Dashboard reflects this pass's data across all six views; every breach and overdue watchlist item carries a named owner; coverage gaps and sensor defects are visible in the record rather than buried in averages; form submitted with a rationale disposing all four verification points; unused branches are prunable because branch edge values match the selected form value.\n\n> **⚡ Audit Artist accelerator:** `/coach-dashboard-create` builds or refreshes the coverage dashboard tiles from the register, queue, and watchlist data.","kind":"decision","label":"Classify disposition","performedBy":{"primitives":["coach-query-data","coach-dashboard-create"]}},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Convert each gap enumerated at disposition into an owned, dated corrective action with interim mitigation in force, so defects in the scanning machinery close on evidence instead of persisting as known weaknesses.\n\n**Inputs**\n- The gap list from the disposition rationale.\n- The feed list and sensor run history; the dashboard breach list; the assignment escalation trail.\n- The compliance profile, for judging each gap's exposure.\n\n**Procedure**\n1. Classify each gap: coverage gap (a profile framework with no feed), sensor defect (silent feed, cursor fault, duplicate detections), triage backlog (aging breach), ruling blockage (awaiting counsel), assignment failure (no capable accepting owner), or archive debt (back-archive owed on a registered authority).\n2. State the root cause as a testable claim, not a category: \"the regulator moved its RSS endpoint in June\" can be verified; \"feed issues\" cannot. For backlogs, distinguish a capacity shortfall from an unclear ruling standard — they take different fixes.\n3. Set the corrective action, owner, and due date, scaled to exposure: a coverage gap on a binding, in-force framework is a days-not-weeks fix; a redundant secondary feed can wait for the next cycle.\n4. Put interim mitigation in force immediately, and log it so the exposure window is provably covered: for any silent or missing feed, a manual check of the regulator's publications page at least weekly, recorded each time it runs; for cursor faults, a bounded re-scan of the affected window with deduplication by source URL, so re-processing cannot re-open items already routed.\n5. Define the validation evidence before the fix lands — what will prove closure: two consecutive sensor passes on the repaired feed with detections matching the regulator's site and the cursor advancing; the routing-aging metric back under the 5-business-day threshold for a full cycle; the blocked ruling resolved with counsel's position attached.\n6. Set the reporting cadence and escalation: progress reviewed at each sensor pass; a corrective action past its due date escalates to the accountable owner and is named in the next period digest's decisions-needed list for the GRC-committee audience.\n\n**Record in AssureSwarm**\n- One Issue per gap (`issue_type`: deficiency, `source`: self_assessment) — the gap classification in `description`, the testable root cause in `root_cause`, the corrective action plus interim mitigation and validation-evidence definition in `remediation_plan`, the owner in `issue_owner`, and the due date in `target_remediation_date`.\n- Link each Issue to the anchor Audit (Issue ↔ Audit relationship), cross-referencing the affected feed, authority-source routing record, or intake it corrects.\n- The escalation threshold and reporting cadence recorded on this step.\n\n**Exit criteria** — Every gap from the disposition rationale has an owned, dated action item; interim mitigation is operating and being logged for every exposure that needs one; validation evidence is defined up front; nothing on the gap list is unowned.","label":"Create action plan","performedBy":{"primitives":["coach-item-create","coach-items-link"]}},"id":"create-action-plan"},{"data":{"description":"Hand the queued intakes and the cycle package to Regulatory Impact Analysis & Obligation Mapping so analysis starts from triage's evidenced conclusions instead of re-deriving them, and close the cycle on those receipts with the audit trail preserved and the next pass armed. Closure is per-cycle — the sensor keeps running.","instructions":"**Objective**\nHand the queued intakes and the cycle package to Regulatory Impact Analysis & Obligation Mapping so analysis starts from triage's evidenced conclusions instead of re-deriving them, and close the cycle on those receipts with the audit trail preserved and the next pass armed. Closure is per-cycle — the sensor keeps running.\n\n**Inputs**\nThe reporting window: a period (week, month, or quarter) and a period-end date; derive window_start and window_end from them. Quarterly windows are the typical input for a GRC committee meeting.\n- The audience: self (terse, structured, includes drafts and TODOs), grc-committee (status-by-region, emerging key risks, decisions needed), or board (one page, only material changes, no operational detail).\n- The instance or tenant being summarized — surface it in the opening so the reader knows which environment the digest covers.\n\nEverything upstream produced: the trigger, opening cursor position, and feed list with gaps recorded when the pass opened; the routing log and register updates with attached publication documents; classifications; applicability rulings with rationale; owner assignments with acceptances; intake queue entries; the dashboard snapshot; the period digest if one was generated; and action plans if that branch ran.\n\nThe signed-off final package, and the intake items with owners, priority bands, and due dates.\n- The flagged-policy lists per intake, and the open constraints (rulings pending counsel, monitor-class items).\n- Open action plans with their validation-evidence definitions; the watchlist with re-check dates; the closing cursor position.\n- The records-retention schedule — regulatory-change records are commonly retained six to seven years, or longer where a supervisor expects it.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Generate period regulatory digest”, “Prepare final package”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Generate period regulatory digest: Produce a period summary of regulatory activity for a non-day-to-day audience — the GRC committee, the audit committee, or the board — rolling up what changed this period and why it matters, with every claim clickable back to its source. Digest generation is read-only: it reports on existing records and never edits an authority source, policy, audit, or step.\n\n2. Amended authorities — find every authority-source record whose last-updated-by-publication date falls inside the window (the regulation was amended this period). For each, capture id, slug, title, regulator, region, authority kind, amendment date, version, source URL, one-paragraph summary, and status.\n3. New authorities — find every authority-source record created inside the window.\n4. Regulatory audits — find every Audit item whose `audit_type` is `regulatory_exam` (or `compliance`) that opened, advanced a step, or closed inside the window; capture id, slug, title, status, reporting period (`period_start`/`period_end`), and lead (`lead_auditor`).\n5. Completed attestations — walk the workflows attached to the in-scope regulatory audits and process items, and surface every step that flipped to complete inside the window.\n6. Downstream policy impact — for each amended authority, find the Policy items that cite it (their authority citations include this authority's id) and list each (policy title, obligation excerpt from `Policy.description`, `next_review_date`) so the reader sees what is downstream of each change.\n7. Synthesize with audience-specific framing: self = terse and structured with drafts and TODOs; grc-committee = group amendments by regulator, give status by region, name the emerging key risks and the decisions needed; board = one page, lead with the newly created authorities and the major amendments, no operational detail. For the board audience, if more than ten amendments landed in the window, group by regulator and surface only the top three by severity (the most material amendment per regulator).\n8. Render the digest to a markdown document, record it back on this step, and propose a distribution or notification path to the named committee or board recipients — do not send anything automatically; distribution is proposed for a human to trigger.\n9. Hold the human checkpoint: the compliance owner reviews the assembled digest — confirming each material change is captured, each claim carries a working source link, and the audience framing is right — before it is distributed to the committee or board.\n\nGround rules for digest generation: operate strictly read-only — do not modify any record. Cite every claim back to the source item's preview URL (the authority source, the audit, or the specific workflow step it came from); a reader must be able to click through to verify. There is no separate \"obligation\" record type — what used to be an \"obligation register\" is now the set of Policy items whose `description` (their obligation text) describes how the org meets the cited authorities, so this digest summarizes changes to the underlying authority sources, not the policy obligation prose. If the expected authority-source, policy, or audit schema is not present in the instance, halt and state that the shared core schema is not in place rather than guessing.\n\n10. Assessment scope for Prepare final package: Assemble the cycle's evidence into a self-contained package a reviewer can retrace from feed detection to disposition without leaving it, with a proposed conclusion ready for the accountable owner.\n\n11. Index the package in step order and run the re-performance test: pick two or three publications and walk each from detection through summary, route, ruling, owner, and intake; every hop must resolve inside the package (source URL, register link, form entries, acceptance record). The only sanctioned external reference is the canonical source URL on the regulator's site — every conclusion the organization drew must live in the package.\n12. Reconcile the counts before packaging: publications detected = publications routed = applicable + not applicable + monitor; applicable changes = intakes after accounting for package-batching and dedupe joins; policies flagged at ingestion = policies carried on intakes. An unexplained variance is a lost publication — find it now, not in an exam.\n13. Include the negative rulings deliberately: the not-applicable rationales with their scoping provisions, and the monitor watchlist entries, are the package's most examiner-sensitive content — they prove considered judgment rather than silence.\n14. State assumptions and unresolved constraints: rulings pending counsel, feeds under repair with their interim mitigation, and the entity or threshold facts the rulings relied on as of the ruling date.\n15. Draft the proposed conclusion: window and cursor bounds, volumes by stage, what was queued downstream and at what priority, and what remains open and where it is tracked — for the accountable owner to sign at closure.\n\n16. Assessment scope for Handoff to related workflow: Hand the queued intakes and the cycle package to Regulatory Impact Analysis & Obligation Mapping so analysis starts from triage's evidenced conclusions instead of re-deriving them, and close the cycle on those receipts with the audit trail preserved and the next pass armed. Closure is per-cycle — the sensor keeps running.\n\n17. Create or link one downstream workflow instance per intake — matching the batching decided at queueing — attach the intake package to its opening step, and link the instance to the authority-source record so the register shows analysis in flight on that authority.\n18. State explicitly what downstream must not repeat: re-summarizing publications, re-matching publications to authorities, and re-screening applicability are done and evidenced; the downstream workflow starts at obligation decomposition against the flagged policies. If impact analysis disagrees with an applicability ruling, it challenges the ruling back to this workflow's owner with reasons — it does not silently re-decide, because the register cannot carry two conflicting applicability positions on one authority.\n19. Pass the assumptions register with each intake: the scoping provisions and the entity or threshold facts the ruling relied on as of the ruling date (thresholds drift — a ruling made below a revenue threshold needs re-screening after a growth year), and any interim mitigations in force that bear on the analysis.\n20. Obtain receipt: the assigned owner confirms the intake is complete enough to start. An incomplete intake comes back here for repair — it does not sit in downstream limbo accruing apparent progress.\n21. Keep monitor-class items home: they do not hand off. They stay on this workflow's watchlist until their adoption milestone or comment deadline fires, and the handoff note says so, so downstream does not chase unripe changes.\n22. Confirm the cycle is closable: the batch is fully routed, every intake's receipt is confirmed (item 20), the disposition is recorded, and any action plans exist with owners and dates. Action plans need not be complete to close the cycle — they carry forward on their own dates; an unowned gap, by contrast, blocks closure.\n23. Record the cycle's cursor bounds — the opening and closing last-checked values — in the closure record. The pair proves the detection window had no gap and gives the next pass its exact starting point. The idempotency contract holds at closure: the next run starts after the closing cursor and must not re-open this cycle's routed items.\n24. Export the workflow record and archive it with the final package under the retention schedule; record the archive reference and verify retrievability by opening the archived copy, not by trusting the upload confirmation. Post-archive corrections are new dated addenda, never edits to the archived package.\n25. Create the carry-forward items, each with an owner and a date: open corrective actions and their validation checks; monitor-class watchlist items due at their adoption milestones or comment deadlines; not-applicable rulings due at their re-check triggers; and any question still with counsel.\n26. Confirm the recurring sensor cadence is intact — the next pass is scheduled and will open from the recorded closing cursor — and send the closure communication: the cycle summary to the accountable owner, and the queued-work summary to the impact-analysis owners.\n\n**Record in AssureSwarm**\nThe reporting window (window_start/window_end) and the audience, recorded on this step.\n- The amended authorities, new authorities, regulatory-exam Audit items, and completed attestations found in the window, and the downstream Policy items flagged per amendment — captured in the digest body (read-only; nothing on those records is modified).\n- The rendered digest document attached to this step (step document, markdown/PDF), plus the proposed distribution recipients recorded on the step.\n\nAttach the rendered package to this step (document upload) and link every source artifact to the step that produced it.\n- Record the count reconciliation and the proposed conclusion on this step.\n\nOne downstream Regulatory Impact Analysis & Obligation Mapping workflow instance created or linked per intake (Workflow instance), with the intake package attached to its opening step (Handoff package — step document); this workflow, each downstream instance, and each authority-source routing record linked to one another.\n- The do-not-repeat note and the assumptions register recorded on each intake package; each owner's receipt confirmation recorded on this step.\n- The monitor-class items retained on the watchlist with their re-check dates, noted on this step (they do not hand off).\n- The closure record with cursor bounds and the archive reference attached to this step (step document) and the exported workflow record; the workflow instance is archived under the retention schedule against the anchor Audit.\n- On the anchor Audit: `Audit.report_date` set to the closure date, and `Audit.period_start`/`Audit.period_end` set to the cycle's detection-window bounds.\n- Carry-forward items with owners and due dates: open corrective actions remain the Issue items on their own `target_remediation_date`; watchlist re-checks and not-applicable re-screen triggers have no native type and are enumerated in this closure record for the next cycle to consume.\n- The next pass's scheduled date and the closure communication noted on this step.\n\n**Exit criteria**\nThe period digest is rendered, recorded on this step, and ready to distribute to the GRC committee, audit committee, or board, with a proposed distribution path for a human to trigger. Quality holds throughout: every claim cites a clickable source preview URL; the window bounds are stated; no record was modified; board digests stay to one page and to top-three-per-regulator when amendments exceed ten. The package passes the re-performance walk with no unresolved external references; counts reconcile with variances explained; negative rulings and open constraints are included; the proposed conclusion is drafted for sign-off. Every intake has a linked downstream instance whose owner confirmed receipt; assumptions and do-not-repeat boundaries are recorded on each; monitor-class items remain on this workflow's watchlist rather than handed off; archive reference recorded with retrievability verified; cursor bounds recorded and the next pass scheduled from them; every open thread exists as a carry-forward item with owner and date; closure declared by the accountable owner.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` renders the indexed evidence package from the linked artifacts in one pass.","label":"Handoff to related workflow","performedBy":{"agent":"reg-artist","note":"read-only period regulatory-activity digest for committee or board","primitives":["coach-workflow-build","coach-items-link","coach-workflow-export","coach-document-upload","coach-item-create","coach-item-update","coach-query-data","coach-render-package"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:reg-horizon-scanning-triage"}