{"description":"Regulatory Impact Analysis & Obligation Mapping runs on a compliance Audit engagement record — an Audit item created per triggering instrument (audit_type=compliance) whose scope holds the locked scope statement and to which every gap Issue, risk acceptance, and the workflow instance attach. It consumes two upstream inputs: the triage handoff package from Regulatory Horizon Scanning & Triage (instrument, canonical citation, publication and effective dates, triage disposition) and the canonical instrument text itself — the Official Journal or regulator-register version, the authoritative source the whole analysis cites. It parses that instrument into obligations, maps them to the existing Policy and Control library, classifies and rates gaps, and reconciles the obligation register. Named deliverables: the cited regulatory impact note, the obligation inventory, the authority-to-policy crosswalk, the classified and rated gap Issues, the versioned obligation register, and the final evidence and decision package. In scope: obligation analysis, crosswalk, gap classification, exposure rating, and register reconciliation for the in-scope entities, products, and jurisdictions. Out of scope: remediation build-out (handed off to Regulatory Obligation Implementation) and re-prioritizing the instrument (owned by Regulatory Horizon Scanning & Triage). Confirmed gaps and their action plans hand off to Regulatory Obligation Implementation.","edges":[{"id":"e-lock-executable-workplan-analyze-impact","source":"lock-executable-workplan","target":"analyze-impact"},{"id":"e-analyze-impact-crosswalk-policies-and-controls","source":"analyze-impact","target":"crosswalk-policies-and-controls"},{"id":"e-crosswalk-policies-and-controls-identify-gaps","source":"crosswalk-policies-and-controls","target":"identify-gaps"},{"id":"e-identify-gaps-rate-exposure-and-assign-owners","source":"identify-gaps","target":"rate-exposure-and-assign-owners"},{"id":"e-rate-exposure-and-assign-owners-classify-disposition","source":"rate-exposure-and-assign-owners","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"gaps"},{"id":"e-classify-disposition-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","whenValue":"complete"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"monitor"},{"id":"e-create-action-plan-handoff-to-related-workflow","source":"create-action-plan","target":"handoff-to-related-workflow"},{"id":"e-escalate-or-accept-risk-handoff-to-related-workflow","source":"escalate-or-accept-risk","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-GOV-03","UC-AUDIT-24","UC-RISK-11","UC-RISK-14"],"department":"compliance-legal","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-impact-analysis-obligation-mapping","contentDigest":"sha256:552a35d2fabdfd04f46b566e106b4bccaca279a4e3155caf4d281b04b8db71b4","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:552a35d2fabdfd04f46b566e106b4bccaca279a4e3155caf4d281b04b8db71b4","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-impact-analysis-obligation-mapping"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"reg-impact-analysis-obligation-mapping","source":"coworkcanvas-gallery","standards":["gdpr","dora","nydfs-500","eu-ai-act","nis2","pci-dss","hipaa","ccpa"],"teams":["compliance-legal"]},"name":"Regulatory Impact Analysis & Obligation Mapping","nodes":[{"data":{"description":"Lock the executable workplan","instructions":"**Objective** — Freeze scope, owners, milestone dates, and evidence expectations so the parse-through-register steps execute without renegotiating basics mid-run.\n\n**Inputs**\n- The scope statement and owner assignments: in-scope and excluded entities, products, and jurisdictions, plus named owners for analysis, interpretation, and sign-off.\n- The triggering change record — consumes the handoff package from Regulatory Horizon Scanning & Triage: instrument, canonical citation, publication and effective/transition dates, and triage disposition.\n- Binding regulatory dates; register conventions (ID scheme, gap-rating scale); the compliance charter's review expectations.\n\n**Procedure**\n1. Backschedule from the earliest binding date: the register must be updated and gaps dispositioned early enough for Regulatory Obligation Implementation to deliver. Planning norms: a control build takes one to two quarters; a policy-only fix two to six weeks; a contract remediation a full vendor negotiation cycle. If backscheduling yields a start date already in the past, flag it now — that is an escalation fact for the disposition, not a planning footnote.\n2. Set the milestone chain, each with a date and owner: obligation inventory complete → impact note reviewed → crosswalk confirmed → gaps classified and signed off → exposure rated and owned → register updated → disposition.\n3. Fix evidence expectations per milestone: pinpoint citations on every obligation, before-and-after diffs for any obligation-text change, named sign-off identity on gap classification and disposition.\n4. Fix review expectations: the compliance officer reviews the impact note; accountable compliance owners confirm crosswalk proposals; the officer signs the disposition.\n5. Lock the plan. Later scope changes are dated change notes with reason and date impact — never silent edits.\n\n**Record in AssureSwarm**\n- Create the anchor **Audit** item for this run — `Audit.audit_type: compliance`, `Audit.scope` = the locked scope statement, `Audit.lead_auditor` = the named analysis owner; every gap Issue, risk acceptance, and the workflow instance link back to it.\n- Milestone dates and owners on the **workflow instance**; the evidence and review expectations, the rating scale, and the DoA/escalation thresholds as the **workplan note** (step document) — they have no native field home.\n- The lock date as a **step note**; subsequent scope changes accrue as dated change notes on the step, never silent edits.\n\n**Exit criteria** — A milestone chain with owners and dates exists, backscheduled from the earliest binding date; evidence and review expectations are stated; the lock is recorded and any already-past start date is flagged for escalation.","label":"Lock executable workplan"},"id":"lock-executable-workplan"},{"data":{"description":"Translate the confirmed regulatory publication into a structured, fully cited impact note that maps what changed onto the organization's obligation register and proposes sequenced next steps. This step is read-only analysis: it drafts the assessment for humans and the downstream steps to act on — it never edits an obligation record.","instructions":"**Objective**\nTranslate the confirmed regulatory publication into a structured, fully cited impact note that maps what changed onto the organization's obligation register and proposes sequenced next steps. This step is read-only analysis: it drafts the assessment for humans and the downstream steps to act on — it never edits an obligation record.\n\n**Inputs**\nThe canonical instrument text (Official Journal or regulator-register version — never a summary or alert): the authoritative source, uploaded as an evidence copy on this step (external/PBC upload).\n- The locked scope from the anchor Audit (`Audit.scope`), to filter which provisions bind which entities.\n- The existing obligation register — no native Obligation item type, so it lives as the controlled XLSX register document carried on the prior run's Classify disposition step, where the register is committed and reconciled; query it for obligations already citing this instrument (duplicate prevention), keyed on the register's ID scheme.\n\nThe resolved publication: there is no native authority-source item type, so read it from the uploaded instrument copy and the triage package — canonical source URL, regulator, title, and publication date.\n- The obligation register (the controlled XLSX carried from the prior run) and the **Policy** library — `Policy` items whose `description` carries the obligation text and whose `framework` lists the authorities each one cites.\n- The applicable entities, products, and regions in scope (`Audit.scope`).\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Parse obligations”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Parse obligations: Decompose the instrument's in-scope text into atomic, uniquely identified obligations with pinpoint citations — the unit of record that crosswalk, gap analysis, and the register all key on.\n\n2. Work provision by provision through the in-scope articles or sections, extracting atomic obligations: one actor, one modal requirement, one trigger or deadline per obligation. Split compound provisions — GDPR Art. 33 alone yields at least four: notify the supervisory authority within 72 hours (33(1)); processor notifies the controller without undue delay (33(2)); notification content minimums (33(3)); document every breach regardless of notification (33(5)). Each is separately testable and separately mappable.\n3. Apply modal analysis: \"shall\" and \"must\" are binding; \"should\" is an expectation — record the chosen treatment per regulator practice (EBA and ESMA guidelines operate comply-or-explain); \"may\" is a permission, recorded only where the organization relies on it; prohibitions (\"shall not\") are obligations too.\n4. Capture per obligation: pinpoint citation (article, paragraph, point), the requirement text verbatim or near-verbatim, the obligated actor in the organization's terms (controller versus processor; financial entity versus ICT third-party provider under DORA), trigger conditions, deadline or frequency (72-hour notices under GDPR Art. 33(1) and NYDFS 500.17(a); DORA incident-reporting windows; annual certifications such as NYDFS 500.17(b)), and the artifact a regulator could demand (the DORA Art. 28(3) register of information, breach documentation under GDPR Art. 33(5)).\n5. Mark applicability per obligation against the locked scope — an in-scope instrument does not make every provision in scope; a provision addressed only to critical ICT third-party providers may not bind the organization at all.\n6. De-duplicate against the register query: where an existing obligation covers the same citation, mark it \"exists — check for amendment\" instead of drafting a duplicate; the register-update step reconciles.\n7. Assign draft IDs per the register scheme and compile the obligation inventory with counts: parsed, applicable, existing-in-register, new.\n\n8. Assessment scope for Analyze impact: Translate the confirmed regulatory publication into a structured, fully cited impact note that maps what changed onto the organization's obligation register and proposes sequenced next steps. This step is read-only analysis: it drafts the assessment for humans and the downstream steps to act on — it never edits an obligation record.\n\n9. Read the publication content from its canonical source. If only a URL is available, retrieve and read the source text. When the source is a PDF or the text cannot be fully extracted, state that limitation explicitly as an open question rather than guessing at the content.\n10. Identify what changed: new requirements introduced, existing requirements amended (and exactly what changed), requirements rescinded, effective dates, and any comment-period or close dates. Record the publication type — final rule, proposed rule, guidance, enforcement action, or amendment.\n11. Map the change onto the obligation register, keeping two separate lists. High-confidence affected: policies that already cite this authority source, each captured with the policy id and the specific obligation excerpt now at risk. Possibly affected: policies under the same regulator and region as a sibling authority, flagged for compliance-team review as a softer signal. Do not merge the two lists — the confidence separation is the audit signal.\n12. Propose sequenced next actions: which obligation records need updating and re-crosswalking, which confirmed gaps should be handed to Regulatory Obligation Implementation, and whether a validation audit should be scheduled. For a proposed rule that is not yet final, mark the whole assessment preliminary and recommend re-running it once the final rule publishes.\n13. Compose the impact note with these sections: Summary; Source (URL plus publication and effective dates); What Changed; Affected Obligations (the high-confidence and possibly-affected lists); Proposed Actions; Open Questions; Citations.\n14. Apply the never-invent rule throughout: every claim about what the regulation requires cites its specific source URL (and paragraph where possible). Do not paraphrase a requirement without a citation — the note's whole value is traceability back to the authority text.\n15. Flag cross-jurisdictional reach and preliminary status: EU rules reaching US subsidiaries (for example DORA) or US rules with extraterritorial reach (for example SOX, FCPA) are flagged for human review in Open Questions even when the analysis looks complete; proposed rules are always marked preliminary.\n16. Hold the read-only guardrail: never edit a policy's obligation text and never auto-apply a change to the register. Obligation reconciliation and register updates happen in the dedicated downstream steps — here you only draft and cite.\n17. Human checkpoint: route the drafted impact note to the compliance officer, who reviews the what-changed reading, the affected-obligation lists, and the proposed actions before any obligation record is updated or any gap is handed downstream.\n\n**Record in AssureSwarm**\nAttach the **obligation inventory** as a **step document** (XLSX upload) with its counts summary (parsed, applicable, existing-in-register, new) — obligations have no native item type, so this inventory is the register-grade artifact this step produces.\n- The modal-treatment decisions (especially \"should\"-level items) and the per-obligation applicability marks as **step notes**.\n\nAttach the **cited regulatory impact note** as a **step document** (DOCX/PDF); the publication summary fields, publication type, and source URL as **step notes** — the authority/instrument record has no native item type.\n- The what-changed list with citations and the high-confidence and possibly-affected policy lists (`Policy` item id plus obligation excerpt for each) inside the note; keep the two confidence lists separate.\n- Proposed sequenced actions with owners; open questions including any text-extraction or cross-jurisdictional caveats — as step notes.\n\n**Exit criteria**\nEvery in-scope provision is decomposed into obligations or marked non-binding with a reason; each obligation carries a pinpoint citation, actor, trigger or deadline, and applicability mark; the inventory is attached with counts; duplicates are flagged against the register rather than re-created. A fully cited impact note exists with all sections populated; every requirement claim traces to a cited source URL; affected obligations are separated by confidence and never merged; no obligation text was edited; proposed rules and cross-jurisdictional reach are flagged for human review; next actions are sequenced with owners and open constraints documented — ready for the crosswalk and gap-identification steps.","label":"Analyze impact","performedBy":{"agent":"reg-artist","note":"drafts the cited regulatory impact note","primitives":["coach-query-data","coach-document-upload"]}},"id":"analyze-impact"},{"data":{"description":"Complete Crosswalk policies and controls","instructions":"**Objective** — Crosswalk the in-scope regulatory obligations to the existing policies and controls that already address them, building the authority-to-policy citation linkage and surfacing where a policy's obligation text needs a refresh under an amendment. Nothing is auto-mapped or auto-edited: every change is proposed to the accountable compliance owner and applied only on confirmation.\n\n**Inputs**\n- The authority source under review (regulator, region, authority kind, summary text, version, publication or amendment date, source URL) — read from the uploaded instrument copy and the impact note; there is no native authority-source item type, so its linkage to policies is recorded in the crosswalk workbook.\n- The current **Policy** library — `Policy` items whose `description` carries the obligation text (how the organization meets the authority) and whose `framework` lists the standards each one already cites.\n- The reviewed impact note from Analyze impact and the obligation inventory from Parse obligations. Reconcile them here: the impact note's high-confidence and possibly-affected lists and the inventory's applicability marks are the same obligations viewed two ways — merge them into one candidate set rather than carrying two, so nothing is crosswalked twice or dropped.\n\n**Procedure**\n1. Build two candidate sets of potentially affected policies. Already-citing: policies that already cite this authority source — these must have their obligation text re-reviewed under any amendment. Keyword-overlap: extract 3–5 keywords from the authority summary, full-text search the policy library for matches, and drop any already in the citing set — these are policies that may need to start citing the authority. Also surface, as a softer relevance signal, policies that cite a sibling authority (another authority source from the same regulator and region).\n2. Score each candidate: topic exact match +3; topic semantic match +2; process linkage to the same area +1; a recent passing test result on the linked controls +1; already cites a sibling authority +1.\n3. Decide one proposal per candidate: add-citation when the policy scores at or above the linkage threshold (about 3) and does not yet cite this authority; revise-obligation when the policy already cites the authority, scores at or above the revision threshold (about 5), and was last reviewed before the amendment date; otherwise no-action.\n4. For a revise-obligation proposal, draft the refreshed obligation text by reading the amendment summary against the current obligation, preserving any customer-specific commitments.\n5. Present each candidate to the accountable compliance owner as a proposed change — an add-citation link or an obligation-text revision — with the before-and-after diff visible (use suggested changes so the diff and the confirmation sit on the record). Never auto-map, never auto-edit; apply only the changes the owner confirms. Cite the authority source URL in every rationale.\n6. If no candidate reaches the linkage threshold, record \"no strong candidates\" and route the obligation to control design and obligation implementation rather than forcing a mapping. Do not modify control or process items in this step.\n\n**Record in AssureSwarm**\n- Confirmed citations recorded on the **Policy** item — `Policy.framework` gains the standard the obligation derives from (e.g. `gdpr`, `dora`, `nydfs-500`); where the policy maps to an enforcing control, an **Item relationship** links `Policy ↔ Control`. The authority-to-policy crosswalk itself is captured in the **crosswalk workbook** (step document, XLSX) with each scored rationale citing the source URL, since the authority source has no native item to link.\n- Confirmed obligation-text revisions applied as **Item field updates** to `Policy.description` from owner-approved suggested changes, or their deferral notes; no-action decisions with scores as step notes.\n- Obligations with no strong candidate flagged for the gap step; owner identities and confirmation dates as step notes.\n\n**Exit criteria** — Confirmed citation links recorded; obligation-text revisions confirmed or deferred; unmapped obligations flagged for control design; every proposed linkage and revision is traceable to the authority source text and confirmed by the accountable owner; the authority-to-policy relationship is treated as one-to-many — one authority typically maps to several policies, and a policy may cite several authorities, unordered.","label":"Crosswalk policies and controls","performedBy":{"agent":"reg-artist","note":"proposes authority-to-policy citation links and obligation-text revisions for the compliance owner to confirm; never auto-edits","primitives":["coach-query-data","coach-item-update","coach-items-link","coach-document-upload"]}},"id":"crosswalk-policies-and-controls"},{"data":{"description":"Complete Identify gaps","instructions":"**Objective** — Establish, for every in-scope obligation, whether existing policies and controls actually satisfy it, and classify the shortfalls into typed, evidenced gap records. The agent drafts the classification; the compliance officer signs off before anything is rated or planned.\n\n**Inputs**\n- The obligation inventory with pinpoint citations, and the confirmed crosswalk results: citation links, revised obligation text, and \"no strong candidates\" flags.\n- The `Control` items linked to the mapped policies, with their latest test results — the Control-hosted SOX testing workflows and their Test-step conclusions evidence operation; a control that failed its last test does not cover an obligation. For third-party-held obligations, the `Vendor` items (`Vendor.tier`, `Vendor.business_owner`, `Vendor.risk_owner`, `Vendor.data_classification`); specific contract-clause text, where the schema has no field for it, is uploaded as a step document.\n- The impact note's open questions (extraction limits, cross-jurisdictional flags) — unresolved ones constrain what may be called covered.\n\n**Procedure**\n1. Assess each obligation on four dimensions: policy (a governing policy states the commitment), control (a designed control enforces it), operation (recent test or monitoring evidence shows it operating — a control that failed its last test does not cover an obligation), and evidence (the organization could produce the artifact the regulator can demand, within its deadline — the DORA Art. 28(3) register of information on request, breach documentation under GDPR Art. 33(5), the basis for an NYDFS 500.17(b) certification).\n2. Classify each obligation: covered — all four dimensions satisfied, with references attached; partial — a policy exists but the control is missing, scope-limited (covers some in-scope entities or systems, not all), or too slow for the obligation's deadline (a manual process cannot reliably meet a 72-hour notification); gap — no policy or control addresses the obligation, including every \"no strong candidates\" flag from the crosswalk; superseded — a rescinded requirement whose register record will be retired at the register step.\n3. Type each gap so remediation lands with the right builder: policy gap (drafting), control-design gap (build), operating-evidence gap (fix or re-perform), technology gap (tooling), contractual gap (vendor terms — GDPR Art. 28 processor clauses, DORA ICT contract provisions).\n4. Write each gap record as: obligation ID plus citation, current state with evidence references, required state quoting or pinpoint-citing the source text, gap type, and a draft severity signal for the rating step. Never assert a current state without a reference — unevidenced \"covered\" calls are how registers rot.\n5. Respect the confidence separation carried from the impact note: a possibly-affected policy that was not confirmed in the crosswalk cannot be the basis for a covered call.\n6. Route the draft classification to the compliance officer for sign-off; capture the officer's identity, date, and any reclassifications with reasons.\n\n**Record in AssureSwarm**\n- One **Issue** per confirmed gap (an **Item create**): `issue_type: deficiency`, `source: compliance_review`, `description` = current-vs-required state with the obligation ID and pinpoint citation, `root_cause` = the gap-type framing (policy / control-design / operating-evidence / technology / contractual gap), `identified_date`. Relate each gap `Issue ↔` the anchor `Audit` and `Issue ↔` the affected `Control` (**Item relationships**).\n- Coverage marks (covered / partial / superseded) with evidence references recorded as **step notes** against the obligation inventory — obligations have no native item, so only the shortfalls become Issues.\n- The sign-off — officer identity, date, and any reclassification notes — as a step note.\n\n**Exit criteria** — Every in-scope obligation carries a classification (covered, partial, gap, or superseded) with evidence references; every gap is typed with current and required state cited to source text; the compliance officer's sign-off is recorded.","label":"Identify gaps","performedBy":{"agent":"reg-artist","note":"drafts the gap classification and exposure rating for human compliance-officer sign-off","primitives":["coach-query-data","coach-item-create","coach-items-link"]}},"id":"identify-gaps"},{"data":{"description":"Complete Rate exposure and assign owners","instructions":"**Objective** — Rate each confirmed gap's exposure on defined, re-derivable factors and put one acknowledged, accountable owner and a deadline on it, so prioritization survives contact with competing work.\n\n**Inputs**\n- The signed-off gap records with types and citations.\n- Sanction and enforcement context for the instrument; the organization's rating scale and the compliance charter's escalation thresholds; remediation lead-time norms per gap type.\n\n**Procedure**\n1. Rate exposure per gap on four factors, recording the value of each. (a) Sanction severity — what the instrument allows: GDPR up to 4% of worldwide annual turnover or EUR 20M, whichever is higher; HIPAA tiered civil penalties per violation category; NYDFS penalties assessed per violation; PCI DSS consequences arriving as card-brand fines and loss of processing ability. (b) Enforcement likelihood — the regulator's actual posture: active enforcement history under the provision, examination cycles, complaint-driven versus proactive supervision, and whether the obligation is examiner-visible (certifications, notifications) or surfaces only on incident. (c) Time pressure — compliance deadline minus realistic remediation lead time; a negative buffer is automatically high. (d) Business exposure — which products and revenue depend on the regulated activity, and whether the gap blocks an attestation (the annual NYDFS 500.17(b) certification cannot be signed over a known material gap without qualification).\n2. Combine the factors into the organization's high, medium, or low scale — and record the factor values, not just the result, so the rating is re-derivable at review.\n3. Assign exactly one accountable owner per gap: the first-line owner of the process or system. Compliance advises; legal owns interpretation questions attached to the gap. Two owners is zero owners.\n4. Set the remediation deadline backscheduled from the binding date using the lead-time norm for the gap type. Where the computed start date is already past, mark the gap for escalation at the disposition decision.\n5. Confirm each owner has actually accepted the assignment — an acknowledgment, not silent tagging. Unacknowledged assignments go on a chase list.\n\n**Record in AssureSwarm**\n- On each gap **Issue** (an **Item field update**): `severity` = the combined rating, `issue_owner` = the acknowledged accountable owner, `target_remediation_date` = the deadline backscheduled from the binding date; the four factor values and their derivation captured in `Issue.description` so the rating is re-derivable at review.\n- The chase list of unacknowledged assignments and the escalation flags on negative-buffer gaps as **step notes**.\n\n**Exit criteria** — Every gap carries a re-derivable rating with factor values recorded, one acknowledged accountable owner, and a deadline backscheduled from the binding date; negative-buffer gaps are flagged for the disposition decision.","label":"Rate exposure and assign owners","performedBy":{"primitives":["coach-item-update"]}},"id":"rate-exposure-and-assign-owners"},{"data":{"decisionField":"disposition_path","description":"Commit and reconcile the obligation register, then classify the result of Regulatory Impact Analysis & Obligation Mapping so the agent keeps only the relevant closure path","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"Complete","value":"complete"},{"label":"Gaps require action","value":"gaps"},{"label":"Monitor without immediate action","value":"monitor"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Commit the run's results to the obligation register — new obligations created, amended ones versioned, rescinded ones superseded — and on that reconciled register classify the analysis outcome so closure follows the right path: clean completion, gap remediation, or a deliberate monitor-without-action call carrying an escalation or risk-acceptance decision. The compliance officer who signed the gap classification owns the call.\n\n**Inputs**\n- The parsed obligation inventory with its new, exists, and amended marks.\n- Confirmed crosswalk links and obligation-text revisions; gap classifications and ratings with owners.\n- Register conventions: ID scheme, required fields, status values.\n\n**Procedure**\n_Items 1–5 are agent-run (folded from the former \"Update obligation register\" step); the human moment is the disposition call in item 6._\n1. Create one register item per new applicable obligation: ID per the scheme, pinpoint citation, requirement text verbatim or near-verbatim, obligated actor, trigger and deadline or frequency, applicability (entities, jurisdictions), accountable owner, status, and links to the authority source and the crosswalked policies and controls.\n2. For amended obligations, update the existing item — never a silent overwrite. Record a dated amendment note stating what changed, the amending instrument with citation, and the effective date, and quote the prior text in the note so the delta reads in place. Later corrections are new dated notes, not edits that erase history.\n3. Mark rescinded obligations superseded — a status change plus a note citing the rescinding provision. Do not delete: retired obligations are part of the compliance narrative and of past attestations.\n4. Carry the gap linkage: obligations with confirmed gaps link their gap records, so a register reader sees coverage state, rating, owner, and deadline without leaving the item.\n5. Run register hygiene checks: no two items share a pinpoint citation and applicability slice; every touched item has an owner and a status; every new item links its authority source; and the counts reconcile — new created plus amended updated plus superseded marked equals the inventory's marks.\n6. Classify the disposition against the criteria below, reading the gap state off the reconciled register.\n\n**Decision criteria**\n- Select `complete` when every in-scope obligation is covered or superseded with evidence references, the register is updated and reconciled, obligation-text revisions are confirmed, and no gap records remain open. The run produced nothing for Regulatory Obligation Implementation to build.\n- Select `gaps` when one or more confirmed gaps require remediation and the intent is to act now: owners exist and deadlines will be fixed in the action plan ahead of the binding date. Always select this when any negative-buffer gap exists — a gap whose remediation lead time already overruns its deadline cannot sit in monitoring.\n- Select `monitor` when no immediate remediation will be launched despite known exposure or unresolved uncertainty: the instrument is a proposed rule marked preliminary; guidance with no current enforcement posture; or a low-rated gap deliberately deferred to a scheduled program. This is a risk decision, not a null result — the monitor branch routes through escalate-or-accept-risk so the deferral is owned at the right authority level, time-boxed, and watched.\n\n**Record in AssureSwarm**\n- The updated **obligation register** as a new **versioned step document** (XLSX) — there is no native Obligation item type, so the register itself lives as this controlled document per run: new obligations added with full fields and links, amendments versioned with dated notes and the prior text quoted in place, rescissions marked superseded (never deleted). Cross-link the native records the register touches — the gap `Issue`s, the crosswalked `Policy`/`Control` items, and the anchor `Audit`.\n- A **reconciliation note** on the step: counts by category (new created + amended updated + superseded marked = the inventory's marks) tying back to the obligation inventory.\n- Submit the `disposition_path` selection. The rationale cites the register's gap state — counts by rating, deadline buffers — and, for `monitor`, the specific uncertainty or deferral reason with its planned re-review trigger. Name the decision owner in the owner field.\n\n**Exit criteria** — The register reflects the instrument's current state: new obligations created with full fields and links, amendments versioned with dated notes, rescissions superseded rather than deleted; hygiene checks pass and counts reconcile to the parsed inventory; form submitted with a rationale consistent with the register's recorded gap state; unused branches are prunable because edge whenValues match the submitted value.\n\n> **⚡ Audit Artist accelerator:** `/coach-item-create` creates the new obligation register items from the parsed inventory with citations, owners, and source links; `/coach-item-update` applies the versioned amendment notes and supersession status changes.","kind":"decision","label":"Classify disposition","performedBy":{"primitives":["coach-item-create","coach-item-update"]}},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Turn each confirmed gap into an executable, owned remediation plan that Regulatory Obligation Implementation can run without re-analyzing anything.\n\n**Inputs**\n- The rated gap records with owners, deadlines, and types, and the obligation register items they link to.\n- Remediation lead-time norms per gap type; the available interim-mitigation options (compensating controls, manual procedures, scope restrictions).\n\n**Procedure**\n1. State each gap's root cause in one honest sentence — the requirement is new, versus a control was descoped, versus evidence was never retained. The fix differs for each, and \"new requirement\" plans that quietly patch old control debt hide the real cost.\n2. Define the remediation action against the required-state citation: what will exist when done, quoting the obligation's pinpoint citation as the acceptance test.\n3. Set interim mitigation for any gap whose permanent fix lands after the binding date: the compensating measure, its coverage limits, and its expiry — an interim measure without an expiry becomes the permanent control by neglect. A gap whose binding date has already passed needs the interim measure effective now and the residual exposure noted for the final package.\n4. Fix the per-plan logistics: the owner from the rating step, the due date, milestones for multi-quarter builds, and the validation evidence that will close the plan — defined now, not at closure (which artifact, produced by whom, reviewed by whom).\n5. Set the reporting cadence proportional to rating: high — biweekly to the compliance officer; medium — monthly; low — quarterly at the register review. Route status through the workflow so the trail is inspectable.\n\n**Record in AssureSwarm**\n- The action plan written onto each gap **Issue** (an **Item field update**): `remediation_plan` = root cause, the action with its cited acceptance test, interim mitigation with expiry, milestones, the validation-evidence definition, and the reporting cadence; `recommendation` = the target end state; `target_remediation_date` confirmed from the rating step. The plan lives on the gap Issue itself — there is no separate action-plan item type.\n- Escalation flags carried forward as **step notes** where deadlines or buffers are breached.\n\n**Exit criteria** — Every open gap has a linked plan with root cause, cited acceptance test, owner, dated milestones, defined validation evidence, and a reporting cadence; interim mitigations carry expiry dates; breached-buffer items are flagged for the final package.","label":"Create action plan","performedBy":{"primitives":["coach-item-update"]}},"id":"create-action-plan"},{"data":{"description":"Escalate to compliance officer, legal owner, obligation owner, or governance delegate or document risk acceptance","instructions":"**Objective** — Put the monitor-without-action call in front of the right authority as a decision memo, and land it as either an escalated redirect to remediation or a formally accepted, time-boxed risk — never an unowned deferral.\n\n**Inputs**\n- The gap records or uncertainty driving the monitor disposition, with ratings and factor values.\n- The delegation-of-authority thresholds (who may accept what exposure level) and the escalation contacts: compliance officer, legal owner, obligation owner, governance delegate.\n\n**Procedure**\n1. Draft the decision memo: the obligations and citations at issue; the exposure quantified (sanction range, enforcement posture, deadline facts); the options considered — remediate now, interim mitigation, or defer with monitoring; and the recommendation with its basis.\n2. Route to the authority the thresholds require. An obligation owner cannot accept exposure on their own gap above the charter's threshold; high-rated exposure goes to the compliance officer or governance delegate. Record who decided — not merely that a decision happened.\n3. If the decision escalates to action: record the redirect — which gaps move to remediation, with owner and due date — and carry those plan essentials into the final package alongside the memo.\n4. If risk is accepted: capture the conditions that must remain true, the expiry (acceptance is time-boxed — a review date at or before the next binding event or twelve months, whichever is sooner), the trigger that reopens it early (an enforcement action under the instrument, final-rule publication, a threshold crossing), and the named follow-up owner.\n5. Make the re-review live: a watchlist entry on the authority-source or obligation record plus a scheduled follow-up in the monitoring plan. An acceptance nobody watches is a finding waiting to be written.\n\n**Record in AssureSwarm**\n- Attach the **escalation / risk-acceptance memo** as a **step document**; decider identity, date, and outcome (escalated or accepted) as step notes.\n- For an accepted risk: create (or update) a **Risk** item — `Risk.category: compliance_regulatory`, `Risk.treatment: accept`, `Risk.residual_rating` = the exposure level, `Risk.risk_owner` = the named follow-up owner, with the acceptance conditions, expiry, and reopen trigger in `Risk.description`; relate `Risk ↔` the gap `Issue`. The expiry and reopen trigger also sit on the gap Issue as step notes — there is no native watchlist/scheduler, so the recurring-run convention carries the re-review.\n- For an escalation to action: the recorded redirect (which gaps move to remediation, with owner and due date) as step notes carried into the final package.\n\n**Exit criteria** — Memo attached; the decision is made at the authority level the thresholds require and recorded with identity and date; acceptances carry conditions, an expiry, an active watch trigger, and a follow-up owner; escalated items carry their recorded redirect with owner and due date.","label":"Escalate or accept risk","performedBy":{"primitives":["coach-item-create","coach-item-update","coach-items-link","coach-document-upload"]}},"id":"escalate-or-accept-risk"},{"data":{"description":"Hand the confirmed gaps and their plans to Regulatory Obligation Implementation with everything it needs to build and an explicit list of what it must not re-do, and close the analysis on that acceptance with a preserved, reconstructable audit trail and the monitoring that outlives the run.","instructions":"**Objective**\nHand the confirmed gaps and their plans to Regulatory Obligation Implementation with everything it needs to build and an explicit list of what it must not re-do, and close the analysis on that acceptance with a preserved, reconstructable audit trail and the monitoring that outlives the run.\n\n**Inputs**\nThe impact note, obligation inventory, and confirmed crosswalk results.\n- Gap records with ratings and sign-off; action plans or the escalation and risk-acceptance memo, whichever the disposition produced; all decision-form rationales.\n\nThe final package; the action-plan records with owners and deadlines; the register items and gap records they link.\n- The escalation or acceptance memo, where the monitor path produced one.\n- Open acceptances with expiries; the watch triggers created during the run.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Prepare final package”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Prepare final package: Compile the complete, self-supporting record of the analysis — what changed, what it obligates, how coverage stands, and what was decided — so reviewers, auditors, and the downstream implementation team work from one package.\n\n2. Assemble in reading order: an executive summary (instrument, disposition, counts — obligations parsed, new, amended, superseded; gaps by rating); the impact note; crosswalk outcomes; the gap classification with sign-off; plans or the acceptance memo; the register reconciliation; open questions and assumptions.\n3. Verify internal consistency — the classic package failures: summary counts tie to the register reconciliation; every gap in the classification appears in exactly one of the plans or the acceptance memo; every preliminary or cross-jurisdictional flag from the impact note is either resolved or carried as an open item with an owner.\n4. Check citation integrity: spot-check that pinpoint citations in the note and the register resolve against the canonical source version confirmed for this analysis.\n5. State unresolved constraints plainly on page one — pending transpositions, proposed-rule status, unacknowledged owners — each with who carries it forward.\n6. Write the proposed conclusion for sign-off: the disposition, the exposure position, and what the downstream workflow is being asked to deliver by when.\n\n7. Assessment scope for Handoff to related workflow: Hand the confirmed gaps and their plans to Regulatory Obligation Implementation with everything it needs to build and an explicit list of what it must not re-do, and close the analysis on that acceptance with a preserved, reconstructable audit trail and the monitoring that outlives the run.\n\n8. Create or link the Regulatory Obligation Implementation workflow — one run, or one per accountable owner or domain when plans land with different builders. Split by owner, not by convenience.\n9. Pass the handoff package: the final package, the action-plan records, obligation register references (IDs plus citations), owners, deadlines, interim mitigations with expiries, and the validation-evidence definitions.\n10. State the do-not-repeat list explicitly: applicability analysis, obligation parsing, and the owner-confirmed crosswalk are settled — implementation builds to the required-state citations and does not re-interpret the instrument. Interpretation questions discovered downstream come back to legal through this workflow's record, not ad hoc.\n11. State the assumptions and open items transferring with the work — pending transposition, preliminary flags, any unacknowledged owner — and who carries each.\n12. Get an acceptance signal from the receiving owner and record the date — a handoff without acknowledgment is still this workflow's liability. If the disposition was complete with no open gaps, record the handoff as not-required with a reference to the disposition rationale instead of creating an empty downstream run.\n13. Verify closure preconditions: the disposition is recorded; every gap is dispositioned exactly once (plan handed off per item 12, or risk accepted with expiry); the register reconciliation is clean.\n14. Archive the final package and the decision-form trail with the workflow, and record the archive confirmation (who, when). Post-archive corrections are new dated addenda — never edits to the archived record.\n15. Update linked records to their end state: the authority-source record marked analyzed with this run linked; obligation register items carrying final status, owners, and gap links; watchlist entries active for every acceptance expiry and every preliminary-rule re-run.\n16. Schedule the monitoring that outlives the run: re-analysis on final-rule publication for anything marked preliminary; acceptance re-reviews at expiry; downstream plan checkpoints at the recorded cadence. Each schedule entry names an owner — an unowned reminder fires into a void.\n17. Communicate the outcome to the named stakeholders — compliance officer, obligation owners, the downstream implementation owner: the disposition, headline counts, the deadlines now running, and where the package lives.\n\n**Record in AssureSwarm**\nAttach the compiled **final evidence and decision package** as a **step document** (PDF/ZIP); link every component so the package is navigable — the impact note and register documents, the gap `Issue`s, any accepted `Risk` items, the anchor `Audit`, and the decision form.\n- Record the consistency-check results and any corrections made as **step notes**.\n\nLink the downstream **Regulatory Obligation Implementation** workflow run(s) and attach the **handoff note** as a step document — package contents, the do-not-repeat list (applicability, obligation parsing, owner-confirmed crosswalk), and transferred open items with who carries each.\n- The receiving owner's acceptance with date — or the not-required note referencing the disposition rationale on a complete disposition — as step notes.\n- Archive the run as the **workflow instance** audit trail (archive confirmation with identity and date); end-state **Item field updates** on the anchor `Audit` (`Audit.rating`, `Audit.report_date`) and final status on the gap `Issue`s; the register and package documents carried on their steps.\n- Scheduled re-reviews (preliminary-rule re-run, acceptance expiry, plan checkpoints) as **step notes** with named owners — there is no native watchlist/scheduler, so these ride the recurring-run convention.\n- The closure communication noted with recipients and date as a step note.\n\n**Exit criteria**\nPackage attached with all components linked; counts reconcile across summary, register, and plans; every gap is dispositioned exactly once; open constraints carry owners; the proposed conclusion is ready for handoff and close. Downstream runs are linked and owner-accepted (or the handoff is recorded as not-required on a clean disposition); the handoff note lists package contents, do-not-repeat boundaries, and transferred open items; no gap with an action plan is left unassigned to a downstream run; closure preconditions verified and the package archived with confirmation recorded; linked records at end state; every future trigger — preliminary re-run, acceptance expiry, plan checkpoint — exists on a watchlist or schedule with an owner; stakeholders notified. Post-archive changes arrive only as new dated addenda.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` compiles the linked impact note, register extract, gap records, and plans into the reviewer-ready package with consistent counts and citations.","label":"Handoff to related workflow","performedBy":{"note":"","primitives":["coach-workflow-attach","coach-document-upload","coach-item-update","coach-notify","coach-render-package"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:reg-impact-analysis-obligation-mapping"}