{"description":"Assess a single AI system end to end under ISO/IEC 42001 (AIMS) and the NIST AI RMF: govern and register the system, map context and risks, measure risks and impacts, manage treatment, produce transparency artifacts, and authorize deployment with monitoring. The instance attaches to an Audit item created for this assessment cycle (audit_type compliance, or advisory for a pre-deployment review); because Studio has no native AI System type, the system under assessment is named in that Audit's scope and its lifecycle/EU-AI-Act detail lives in the scoping memo and step documents. In scope: one named AI system or use case and its lifecycle risk posture. Out of scope: enterprise-wide AI policy authoring and detailed EU AI Act legal obligation mapping, which are consumed as an input handoff package from the EU AI Act Obligation Impact Analysis workflow. The named deliverable is the approved AI assessment package (executive summary plus recommended governance decision), backed by the AI risk register (Risk items, category ai_governance), the model/system card and AI impact-assessment record, and a deployment authorization with live drift/fairness monitoring; approved outputs hand off to Quarterly Board & Audit-Committee GRC Reporting.","edges":[{"id":"e-govern-and-register-ai-system-measure-risks-and-impacts","source":"govern-and-register-ai-system","target":"measure-risks-and-impacts"},{"id":"e-measure-risks-and-impacts-manage-treatment","source":"measure-risks-and-impacts","target":"manage-treatment"},{"id":"e-manage-treatment-deploy-with-monitoring","source":"manage-treatment","target":"deploy-with-monitoring"},{"id":"e-deploy-with-monitoring-classify-disposition","source":"deploy-with-monitoring","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Remediate","source":"classify-disposition","target":"create-action-plan","whenValue":"remediate"},{"id":"e-classify-disposition-approve-or-revise-package","label":"Clean","source":"classify-disposition","target":"approve-or-revise-package","whenValue":"clean"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"escalate"},{"id":"e-create-action-plan-approve-or-revise-package","source":"create-action-plan","target":"approve-or-revise-package"},{"id":"e-escalate-or-accept-risk-approve-or-revise-package","source":"escalate-or-accept-risk","target":"approve-or-revise-package"},{"id":"e-approve-or-revise-package-record-approval-decision","label":"Approved","source":"approve-or-revise-package","target":"record-approval-decision","whenValue":"approved"},{"id":"e-approve-or-revise-package-resolve-approval-conditions","label":"Revise","source":"approve-or-revise-package","target":"resolve-approval-conditions","whenValue":"revise"},{"id":"e-resolve-approval-conditions-record-approval-decision","source":"resolve-approval-conditions","target":"record-approval-decision"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-AI-01","UC-AI-03","UC-AI-04","UC-AI-07","UC-AI-08","UC-AI-10","UC-AI-02","UC-AI-05","UC-AI-06","UC-AI-09","UC-AI-11","UC-AI-12","UC-AI-14","UC-AI-15","UC-AI-16"],"department":"ai-governance","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-ai-governance-aims-assessment","contentDigest":"sha256:f13547ad64a1e7ed0822c6ec471aea724ebac5e7e5bcc6629ee6c8c40aca16dc","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:f13547ad64a1e7ed0822c6ec471aea724ebac5e7e5bcc6629ee6c8c40aca16dc","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-ai-governance-aims-assessment"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"grc-ai-governance-aims-assessment","source":"coworkcanvas-gallery","standards":["nist-ai-tevv-athlon","iso-42001","nist-800-53","aiuc-1"],"teams":["ai-governance"]},"name":"AI Governance & Risk/Impact Assessment","nodes":[{"data":{"description":"AI governance lead: Set the internal risk tier, intended-use boundary and accountable roles that determine assessment depth.","instructions":"**Objective** — Determine the AI system scope, accountable roles and internal risk tier from the workplan, inventory and applicable policy.\n\n**Inputs**\n- The named AI system or use case under assessment: its business purpose, lifecycle stage (design / build / pre-deployment / in-production), and sponsoring business unit.\n- The EU AI Act Obligation Impact Analysis handoff package for this system, where one exists — it carries the legal risk classification (prohibited / high-risk / limited / minimal) and the obligation list this workflow consumes rather than re-deriving. If no upstream package exists, note that and set the EU AI Act tier to \"not yet assessed\".\n- Organizational AI policy and the ISO/IEC 42001 AIMS scope statement — Policy items (policy_type: policy / standard / charter, framework: iso-42001, domains: ai_governance) where they are registered, otherwise uploaded as documents on this step. The applicable ISO 42001 controls are existing Control items (framework: iso-42001, domains: ai_governance).\n- The AI risk appetite / tolerance thresholds set by the AI governance body — uploaded as a document on this step; appetite thresholds have no native structured field.\n- The AI system inventory record (kept as a register document — Studio has no AI System item type) and any prior assessment of this system (the previous cycle's Audit item and its archived workflow instance, linked to this new Audit).\n- The locked workplan and scope from scope preparation within GOVERN (the anchor Audit — its scope carries the boundary, lifecycle stage, EU AI Act tier, and the owners already assigned there).\n- Organizational AI policy and the ISO/IEC 42001 AIMS scope — Policy items or the documents uploaded during scope preparation within GOVERN; the RACI / roles matrix uploaded as a document on this step.\n- The EU AI Act tier carried in the upstream package.\n- The existing AI system inventory register (a document — no AI System type) and vendor due-diligence records: for externally sourced models the vendor register is Vendor items (category, tier, data_classification, business_owner, risk_owner) with due-diligence reports attached, otherwise uploaded as documents on this step.\n\n**Procedure**\n*Autonomous preparation incorporates Lock executable workplan; AI governance lead reviews the combined evidence.*\n1. Confirm the trigger and lifecycle stage — new system, material change, periodic re-review, or incident-driven — because it sets the depth of MEASURE and MANAGE.\n2. Set the boundary: list the specific model(s), datasets, integrations, and user populations that are in scope, and explicitly list what is out of scope (e.g., adjacent systems, upstream legal obligation mapping already covered by the EU AI Act analysis).\n3. Pull the EU AI Act classification from the upstream package and record the tier; if the use is flagged prohibited or high-risk, mark it for priority treatment in MEASURE and MANAGE.\n4. Assign accountable owners: the accountable executive, the AI risk owner, and the model/product owner, keeping independent review segregated from build.\n5. Define evidence requirements per function and the two decision gates this workflow enforces — disposition classification and final approval — with the authority for each.\n6. Set due dates, the review cadence, and the re-review trigger, then have the AI governance lead confirm the plan.\n7. Register or confirm the AI system record: for a net-new system, add it to the inventory register (unique ID, name, purpose, owner, lifecycle stage, build-vs-buy, foundation-model dependency); for a periodic re-review, confirm the existing register entry is current.\n8. Confirm and inherit accountability from the locked workplan — the accountable executive, the AI risk owner, and the model/product owner are already fixed there; re-assign only where GOVERN surfaces a change, and confirm independent review is segregated from build/operate.\n9. Determine the internal risk tier by combining the EU AI Act classification with internal impact criteria (safety, fundamental rights, financial, reputational); the tier sets how deep MEASURE and MANAGE go.\n10. Map applicable requirements: the ISO 42001 Annex A controls and internal AI policy clauses that apply at this tier.\n11. Verify prerequisite governance artifacts exist: approved intended use, data-governance sign-off, and third-party/vendor due diligence for externally sourced models.\n\n**Record in AssureSwarm**\nItem create: the anchor Audit item for this assessment cycle (audit_type: compliance, or advisory for a pre-deployment review; scope: the AI system name, boundary, lifecycle stage, and EU AI Act tier; description; lead_auditor; period_start / period_end). Step document: the scoping memo and the EU AI Act handoff package attached on this step — the system's lifecycle stage and EU-AI-Act tier have no native field, so they live in Audit.scope and the memo. Item relationship: link the prior-cycle Audit and the upstream EU AI Act workflow instance to this Audit.\nItem field update: the anchor Audit — refine scope to carry the internal risk tier, accountable executive, AI risk owner, and model/product owner (no native tier/executive field — recorded in Audit.scope), set lead_auditor, confirm audit_type. Item create/update: Vendor items for externally sourced models (category, tier, data_classification, business_owner, risk_owner, last_assessment_date, monitoring_status) with the due-diligence report attached. Item relationship: link the applicable Policy items (AI policy / AIMS scope), the ISO 42001 Control items, the Vendor items, and the upstream package document to the anchor Audit. Step document: the governance register entry / AI system inventory record attached on this step (no AI System type — it lives as a document).\n\n**Exit criteria**\nSet the internal risk tier, intended-use boundary and accountable roles that determine assessment depth.\nScope boundary documented with explicit in/out lists; owners assigned; EU AI Act tier recorded or marked not-yet-assessed; evidence requirements and both gates defined; workplan confirmed by the AI governance lead.\nSystem registered with a unique ID; accountable owners named; internal risk tier set and justified against EU AI Act and impact criteria; applicable Annex A controls and policy clauses listed.","label":"GOVERN and register AI system"},"id":"govern-and-register-ai-system"},{"data":{"description":"Independent AI assessor: Judge harm scenarios, affected populations, measurement reliability and residual exposure against appetite.","instructions":"**Objective** — Evaluate the mapped AI harm scenarios with documented system facts, quantitative tests and an impact assessment, including measurement limitations.\n\n**Inputs**\n- The registered AI system and internal risk tier from GOVERN (carried in the anchor Audit's scope).\n- System/design documentation, data sheets, and the intended-use statement — provided from the accountable model/product owner’s authorized design records and attached source documents.\n- The stakeholder list and incident history / known failure modes for comparable systems — documents on this step.\n- The inherent-risk register (the Risk items created during context mapping in this checkpoint) and the context document.\n- Test/evaluation datasets, model performance metrics, and fairness/bias tooling — these live in external ML evaluation tooling; the AssureSwarm copy is the evaluation-result evidence uploaded as documents on this step.\n- The AI risk appetite / tolerance thresholds (the appetite document from scope preparation within GOVERN).\n\n**Procedure**\n*Autonomous preparation incorporates MAP context and risks; Independent AI assessor reviews the combined evidence.*\n1. Read the accountable model/product owner’s documentation for intended use, data provenance, sensitive attributes, limitations and the oversight model. Record unresolved factual gaps for that participating owner to resolve in the native result or source documents; do not infer their answers.\n2. Document context: intended purpose, deployment setting, users and affected non-users, the decisions the system informs or automates, and the human-oversight model.\n3. Characterize data and model: training and inference data sources, provenance, sensitive attributes, model type, and known limitations.\n4. Identify risks across categories using a structured taxonomy (NIST AI RMF MAP plus ISO 42001 impact criteria): bias/fairness, privacy, security/adversarial, safety, robustness/drift, explainability, and third-party/supply-chain.\n5. For each risk, capture the harm scenario, the affected group, and an inherent likelihood/impact rating before controls.\n6. Flag any use the upstream EU AI Act package marks prohibited or high-risk so MEASURE prioritizes it.\n7. Select metrics and methods per risk: accuracy/error rates, fairness metrics (e.g., demographic parity, equalized odds) across protected groups, robustness/adversarial tests, drift and stability, privacy leakage, and explainability quality.\n8. Execute tests or gather existing evaluation evidence; for each, record the method, dataset, date, and result, and note any IPE dependency where a metric is system-generated.\n9. Conduct the AI impact assessment: rate severity and likelihood of each harm scenario on affected individuals/groups and the organization, and document affected rights and mitigating context.\n10. Compute residual risk after existing controls and compare each to appetite; mark every risk that sits above tolerance.\n11. Assess measurement reliability itself — coverage gaps, unrepresentative test data, unmeasured risks — and record the limitations.\n\n**Record in AssureSwarm**\nItem create: one Risk item per identified AI risk (category: ai_governance; taxonomies: ai_governance; domains: ai_governance; description: the harm scenario and affected group; likelihood; impact; inherent_rating; risk_owner). Item relationship: link each Risk to the anchor Audit. Step document: the context and impact-mapping document attached on this step. The native result and source documents record the intended-use statement, affected populations, data sources and provenance, sensitive-attribute usage, model type and known limitations, the human-oversight model, incident history, and the uploaded design documentation — the assessor's own risk analysis goes in the step result.\nStep document: the per-risk evaluation evidence (method, dataset, date, result) and the AI impact-assessment record attached on this step. Item field update: set residual_rating on each Risk item (after existing controls). Over-appetite risks have no native flag field — call them out in the impact-assessment record and by residual_rating versus the appetite thresholds.\n\nRecord in the native step result or attached source documents: Intended purpose, deployment setting, and the decisions this system informs or automates (intended_use_statement); Users and affected non-users, including any vulnerable or protected groups (affected_populations); Training and inference data sources, provenance, and retention (data_sources_and_provenance); Are sensitive or protected attributes used, inferred, or correlated in the data or features? (sensitive_attributes_used); Model type, foundation-model or vendor dependencies, and known limitations or failure modes (model_type_and_limitations); How a human reviews, overrides, or halts the system's output in production (human_oversight_model); Incidents, complaints, or near-misses recorded for this system or a comparable one (incident_history); Design documentation, data sheets, or evaluation reports (system_documentation). Use native approvals for sign-off.\n\n**Exit criteria**\nJudge harm scenarios, affected populations, measurement reliability and residual exposure against appetite.\nOwner-sourced facts and documentation are recorded; context and intended use documented; a categorized inherent-risk register created and linked; high-priority risks flagged for measurement.\nEach material risk has evaluation evidence and a residual rating versus appetite; the impact assessment is complete; measurement limitations are documented.","label":"MEASURE risks and impacts"},"id":"measure-risks-and-impacts"},{"data":{"description":"Complete MANAGE treatment","instructions":"**Objective** — Execute the MANAGE function: decide and document the treatment for each risk above appetite and confirm mitigations and human-oversight controls are in place.\n\n**Inputs**\n- Residual-risk ratings (the Risk items) and the impact-assessment record from the combined MAP/MEASURE assessment.\n- The existing control inventory (Control items) and the AI risk appetite document.\n- The owner list (carried in the anchor Audit's scope from GOVERN).\n\n**Procedure**\n1. Prioritize risks by residual severity and by whether they exceed appetite.\n2. For each, select a treatment: mitigate (add/strengthen controls — guardrails, human-in-the-loop, input/output filtering, monitoring), transfer (contractual/insurance), avoid (restrict or drop the use), or accept (with documented rationale, only within appetite).\n3. Specify each mitigating control: owner, design, operating frequency, and how effectiveness will be evidenced.\n4. Confirm human-oversight and fallback / kill-switch mechanisms for high-tier systems.\n5. Recompute post-treatment residual risk and confirm it lands within appetite, or route the remaining exception forward for acceptance or escalation.\n\n**Record in AssureSwarm** — Item field update: on each over-appetite Risk set treatment (mitigate / transfer / avoid / accept) and the post-treatment residual_rating. Item create/update: Control items for each mitigating control (control_type, control_category, automation, frequency, control_owner, framework incl. iso-42001, domains: ai_governance). Item relationship: link Control ↔ Risk for each mitigating control. Controls not yet implemented are carried forward as gaps to the action-plan step (created there as Issue items) — do not double-create here.\n\n**Exit criteria** — Every over-appetite risk has a treatment decision with an owner; controls are linked; post-treatment residual is recorded; remaining exceptions are flagged.","label":"MANAGE treatment"},"id":"manage-treatment"},{"data":{"description":"Agent compiles the model/system card, impact record, and user-facing disclosures and configures drift and fairness monitoring; the authorizer confirms preconditions and records the deployment authorization and residual-risk acceptance","instructions":"**Objective** — Produce the transparency and documentation artifacts ISO 42001 and the NIST AI RMF require, stand up post-deployment monitoring, and record the deployment authorization that lets the AI system go live inside its assessed risk envelope.\n\n**Inputs**\n- The treatment record, mitigating controls, and post-treatment residual risk from MANAGE, plus the MAP context document and the MEASURE evaluation evidence and impact assessment.\n- Disclosure/notice requirements from the EU AI Act upstream package for this system's tier, and the organization's documentation templates.\n- Monitoring tooling, the incident-response process, and the escalation matrix.\n\n**Procedure**\n_Items 1–5 are agent-run (folded from the former \"Document transparency artifacts\" step); the human moment is the authorization in item 10._\n1. Compile the model/system card: purpose, data, performance and fairness metrics, limitations, and intended and prohibited uses.\n2. Finalize the AI impact-assessment record: harms, affected groups, mitigations, residual risk, and human-oversight design.\n3. Draft the user-facing transparency notices/disclosures required for the system's tier (e.g., AI-interaction disclosure, automated-decision notice).\n4. Document data provenance and, for generative systems, content provenance/labeling of outputs.\n5. Verify each artifact against its policy/standard checklist and have the artifact owner confirm the statements made about their system.\n6. Verify deployment preconditions: all high/critical treatments implemented and tested, transparency artifacts published, and human-oversight configured.\n7. Define monitoring metrics and thresholds: performance/accuracy drift, fairness drift, data drift, volume/error anomalies, and safety triggers — each with an alert threshold and an owner.\n8. Configure the monitoring dashboard and alerting; define who responds and the escalation path on a threshold breach.\n9. Set the re-review trigger and cadence — periodic and event-driven (material change, incident, regulatory change).\n10. Record the deployment authorization decision, or the conditions of a staged/limited release, together with the residual-risk acceptance. Publishing the disclosures to users is part of this authorization — the authorizer owns both.\n\n**Record in AssureSwarm** — Step document: attach the model/system card (DOCX/PDF), the AI impact-assessment record, the user-facing disclosure notices, the data/content-provenance documentation, and the deployment authorization record (with the residual-risk acceptance and any staged/limited-release conditions) on this step. Item relationship: link each artifact document to the anchor Audit and to the relevant Risk and Control items. Dashboard: a drift/fairness monitoring Dashboard (metrics vs thresholds; the thresholds live in the Dashboard and external tooling — no native field). Item create: the next-cycle re-review Audit item (status PLANNED, audit_type: compliance, period_start = the re-review date) as the tracked re-review trigger, linked to this Audit. Documentation-status has no native field (no AI System type) — track it in Audit.scope and the artifact checklist.\n\n**Exit criteria** — Model/system card, impact record, and required disclosures complete, checklist-verified, owner-confirmed, and attached; preconditions verified; monitoring metrics/thresholds and alert owners configured; re-review trigger set; deployment authorization recorded.\n\n> **⚡ Audit Artist accelerator:** `/coach-dashboard-create` stands up the drift and fairness monitoring dashboard, and `/coach-workflow-scan` watches the thresholds and fires the re-review trigger on breach.","label":"Deploy with monitoring","performedBy":{"agent":"grc-artist","primitives":["coach-dashboard-create","coach-workflow-scan"]}},"id":"deploy-with-monitoring"},{"data":{"decisionField":"disposition_path","description":"Classify the result of AI Governance & Risk/Impact Assessment so the agent keeps only the relevant closure path","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"No reportable gap","value":"clean"},{"label":"Remediation required","value":"remediate"},{"label":"Escalate significant issue","value":"escalate"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Classify the overall result of the AI system assessment so the workflow keeps only the relevant closure path. Owned by the AI risk owner / GRC lead.\n\n**Decision criteria**\n- `clean` (No reportable gap): the system meets policy and ISO 42001 / AI RMF expectations — residual AI risk is within appetite, all high/critical risks have effective mitigations, transparency artifacts are complete, and monitoring is live. No action plan is needed.\n- `remediate` (Remediation required): one or more control or documentation gaps keep residual risk above appetite but below board level — e.g., a missing bias evaluation, an incomplete model card, or monitoring thresholds not yet configured. Route to an owned action plan.\n- `escalate` (Escalate significant issue): a significant or critical issue — a prohibited use, an unmitigated high-risk harm, or residual risk materially above appetite — that requires a formal accept/decline decision above the risk owner. Route to escalation.\n\n**Record in AssureSwarm** — Submit the `disposition_path` SELECT; record the step result with evidence references (risk IDs, residual scores versus appetite) and the step's approver record.\n\n**Exit criteria** — The form is submitted and the two unchosen branches are prunable because each branch edge value matches the selected value.","kind":"decision","label":"Classify disposition"},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Turn each identified gap into an owned, dated remediation action so residual AI risk is driven back within appetite.\n\n**Inputs**\n- The over-appetite Risk items and unimplemented controls from MANAGE.\n- The disposition decision set to remediate, with its rationale (the classify-disposition form).\n- The owner list (carried in the anchor Audit's scope from GOVERN).\n\n**Procedure**\n1. For each gap, state the root cause and the specific control or artifact to be added or fixed.\n2. Assign a single accountable owner and a due date proportionate to the risk severity.\n3. Define an interim mitigation to hold the risk while the fix is in flight.\n4. Define the validation evidence that will prove the action closed the gap, and the reporting cadence.\n\n**Record in AssureSwarm** — Item create: one Issue per gap (issue_type: deficiency or observation; source: compliance_review; severity; issue_owner; identified_date; target_remediation_date; remediation_plan carrying the interim mitigation and the fix; recommendation carrying the validation evidence). Item relationship: link each Issue to its related Risk, its related Control, and the anchor Audit.\n\n**Exit criteria** — Every remediate-path gap has an owned, dated action with an interim mitigation and a defined validation test.","label":"Create action plan"},"id":"create-action-plan"},{"data":{"description":"Escalate to risk owner, GRC lead, executive sponsor, or board delegate or document risk acceptance","instructions":"**Objective** — Prepare the decision memo for a significant AI issue so the accountable authority can formally accept, condition, or decline the risk.\n\n**Inputs**\n- The significant issue and residual exposure from the disposition decision set to escalate.\n- The impact quantification from the combined MAP/MEASURE assessment.\n- The risk appetite and the escalation matrix.\n\n**Procedure**\n1. State the issue, the specific over-appetite or prohibited exposure, and the affected groups or obligations.\n2. Quantify impact (financial, rights, safety, reputational) and likelihood; compare to appetite and the escalation threshold to name the right authority — risk owner, GRC lead, executive sponsor, or board delegate.\n3. Lay out the options: remediate-and-defer, accept-with-conditions, or avoid/withdraw the use, with the consequences of each.\n4. Capture the decision, any conditions, and follow-up ownership; if the risk is accepted, document the formal risk acceptance and its expiry/review date.\n\n**Record in AssureSwarm** — Step document: the escalation / decision memo attached on this step. Item create (on a risk acceptance): an Issue with issue_type: policy_exception, source: compliance_review, severity, exception_approver (the accountable authority), exception_expiry_date (the acceptance review/expiry date), issue_owner (the follow-up owner), and remediation_plan carrying the conditions. Item field update: set treatment: accept on the affected Risk. Item relationship: link the exception Issue to the affected Risk and to the anchor Audit.\n\n**Exit criteria** — Decision memo prepared with quantified impact and options; the accountable authority identified; the decision, conditions, and follow-up recorded.","label":"Escalate or accept risk"},"id":"escalate-or-accept-risk"},{"data":{"decisionField":"approval_path","description":"Accountable AI assessment approver: Challenge traceability, conclusions and unresolved constraints and approve the identified package or require corrections.","formData":{"fields":[{"key":"approval_path","label":"Approve or revise package","options":[{"label":"Approved","value":"approved"},{"label":"Revision required","value":"revise"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Review the assembled AI assessment package and choose approval or revision against evidence, ownership and appetite criteria.\n\n**Decision criteria**\nInputs for preparation: - The disposition outcome: a clean conclusion, the action plan (from the action-plan step), or the escalation/acceptance memo (from the escalate-or-accept-risk step).\n- The GOVERN-through-MANAGE evidence, the transparency artifacts, and the monitoring/re-review setup.\n\n*Autonomous preparation incorporates Prepare final package; Accountable AI assessment approver reviews the combined evidence.*\n1. Assemble the record: system registration and tier, the inherent/residual risk register, measurement evidence and the impact assessment, treatment decisions and controls, transparency artifacts, and the monitoring/re-review plan.\n2. Attach the disposition outcome — the clean conclusion, the action plan, or the escalation/acceptance memo.\n3. Write the executive summary: assessment conclusion, residual risk versus appetite, key issues, and the recommended governance decision.\n4. Run a completeness/traceability check: every conclusion traces to evidence, every gap to an owned action, every decision to an owner.\n5. List unresolved constraints and assumptions for the approver.\n\n- `approved`: evidence is complete and traceable, conclusions are supported, action plans have owners and dates, and the residual-risk position is within appetite or carries a documented acceptance — the approver signs off.\n- `revise`: the package has gaps — missing evidence, an unsupported conclusion, an action plan without an owner or date, or an unresolved reviewer condition — that must be fixed before sign-off.\n\n**Record in AssureSwarm**\nStep document: the compiled approved AI assessment package (PDF/DOCX with a traceability index) attached on this step. Item relationship: link the package and its constituent Risk, Control, and Issue items to the anchor Audit. Package-status is tracked via the workflow instance and the anchor Audit — there is no native package field.\nSubmit the `approval_path` SELECT; record the step result (what was reviewed and any conditions) and the step's approver record.\n\n**Exit criteria**\nChallenge traceability, conclusions and unresolved constraints and approve the identified package or require corrections.\nPackage assembled and traceability-checked; executive summary and recommended decision written; open items listed; ready for approval.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` compiles the assessment evidence, analysis, and decisions into one review-ready package with a traceability index.\nThe form is submitted and the unused branch is prunable because each branch edge value matches the selected value.","kind":"decision","label":"Approve or revise package","performedBy":{"agent":"grc-artist","primitives":["coach-render-package"]}},"id":"approve-or-revise-package"},{"data":{"description":"Resolve reviewer comments or approval conditions","instructions":"**Objective** — Clear the reviewer's comments or approval conditions on the package so a final decision can be recorded.\n\n**Inputs**\n- The approver's comments/conditions from the approve-or-revise decision set to revise.\n- The final assessment package.\n- Owners for each open item.\n\n**Procedure**\n1. Log each comment or condition as a discrete item with an owner.\n2. Address each: supply missing evidence, revise a conclusion, or tighten an action plan, documenting exactly what changed and why.\n3. Re-run the traceability check on every changed section.\n4. Summarize the changes for the approver so the decision can be recorded without a full re-review.\n\n**Record in AssureSwarm** — Step document: the revised package sections and a change-log note listing each reviewer condition and its resolution, attached on this step.\n\n**Exit criteria** — Every reviewer condition is resolved with a documented change; the package is updated; a change summary is ready for the approver.","label":"Resolve approval conditions"},"id":"resolve-approval-conditions"},{"data":{"description":"Final assessment approver: Authorize the final version after any corrections, record conditions and release its board-reporting handoff and closure.","instructions":"**Objective** — Record the authoritative final assessment decision, including approval after revisions where needed, then hand off the approved package and archive the cycle.\n\n**Inputs**\n- The approved package (approve-or-revise set to approved) or the resolved package (from the resolve-conditions step).\n- The approver's identity and any conditions of approval.\n- The recorded approval decision and the final package.\n- The downstream workflow's expected inputs (assessment conclusion, residual risk position, significant issues, open actions).\n- The monitoring and re-review commitments set at deployment.\n\n**Procedure**\n*Autonomous preparation incorporates Handoff to related workflow; Final assessment approver reviews the combined evidence.*\n1. Capture the approver name and role, the decision, the date, and the exact package version approved.\n2. Record any conditions of approval with their follow-up owners and due dates.\n3. Confirm residual-risk acceptance is documented wherever risk was accepted rather than eliminated.\n4. Set the re-review and monitoring commitments as tracked items.\n5. Create or locate the Quarterly Board & Audit-Committee GRC Reporting instance.\n6. Pass the final package: the assessment conclusion, the residual AI risk position versus appetite, significant issues and escalations, and open actions.\n7. Note the assumptions and state what the downstream workflow should not repeat (e.g., re-testing already-evidenced metrics).\n8. Confirm the downstream owner acknowledges receipt.\n9. Verify the package, the approval record, and the handoff are complete and linked.\n10. Archive the final package and set the assessment status to closed on the anchor Audit.\n11. Confirm post-deployment monitoring is live and the re-review date/trigger is scheduled as a tracked item.\n12. Communicate the final decision and residual-risk position to stakeholders and owners.\n\n**Record in AssureSwarm**\nItem field update: the anchor Audit — set rating (satisfactory / needs_improvement / unsatisfactory) and report_date; capture the approver name/role, decision, and conditions in Audit.scope and the sign-off memo (there is no native approver field). Item create: an Issue per condition of approval (issue_type: observation, source: compliance_review, issue_owner, target_remediation_date). Step document: the pinned approved package version attached on this step.\nStep document: the handoff package (assessment conclusion, residual AI risk position versus appetite, significant issues and escalations, and open actions) and the closure communication attached on this step. Item relationship: link the downstream Quarterly Board & Audit-Committee GRC Reporting workflow instance to the anchor Audit, and confirm the next-cycle PLANNED re-review Audit item exists and is linked. Workflow instance: archive the run on the anchor Audit as the immutable audit trail and set the Audit status to closed/complete. Handoff-status is tracked via the workflow instance.\n\n**Exit criteria**\nAuthorize the final version after any corrections, record conditions and release its board-reporting handoff and closure.\nApprover, date, decision, and conditions recorded; conditional follow-ups created; the approved version is pinned.\nDownstream instance linked, package delivered, reuse boundaries noted, and receipt acknowledged; package archived and Audit status closed; monitoring live and re-review scheduled; closure communicated to stakeholders.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` sends the handoff and the closure communication with the residual-risk summary to the downstream owner, stakeholders, and action owners.","label":"Record approval decision","performedBy":{"agent":"grc-artist","primitives":["coach-notify"]}},"id":"record-approval-decision"}],"sourceTemplateId":"workflow-library:grc-ai-governance-aims-assessment"}