{"description":"AI Governance Framework, Roles & Obligations Review as a modular, decision-aware workflow. Each quarterly instance runs on the existing \"AI Governance Program\" Process item (process_type operational, quarterly, process_owner = AI Governance Officer) and enriches its standing registers — it never recreates them. It keeps the AI policy current and republished, refreshes the RACI and competency records, maintains each AI system's resource and dependency inventory, and walks the value-chain obligations register so every provider and deployer duty traces to an owner and evidence. Consumes at launch: the cycle trigger (interval, folded-in annual re-approval, or a regulatory/technology change) and prior-cycle registers — the AI policy as a Policy item (framework iso-42001 + eu-ai-act, domains ai_governance), the obligations register as EU AI Act / ISO 42001 Control items (control_owner = obligation owner), plus the in-scope AI system list, the RACI and competency register, and the per-system resource inventory, which have no native item type and travel as versioned step documents. Deliverables: the republished AI policy version, the refreshed RACI and competency register, the current resource and dependency inventory, the walked obligations register, and a four-area cycle evidence package. In scope: those four governance registers for the AI systems in boundary this quarter; out of scope: the AI systems' own development, risk assessment, and control testing. Terminal — no downstream workflow consumes the output; the cycle closes to its own archived workflow record, linked back to the anchor Process item.","edges":[{"id":"e-review-ai-policy-against-schedule-revise-and-approve-policy-updates","label":"Revision required","source":"review-ai-policy-against-schedule","target":"revise-and-approve-policy-updates","whenValue":"revise_required"},{"id":"e-review-ai-policy-against-schedule-compile-cycle-evidence-and-report","label":"Reaffirm","source":"review-ai-policy-against-schedule","target":"compile-cycle-evidence-and-report","whenValue":"reaffirm_current_version"},{"id":"e-revise-and-approve-policy-updates-compile-cycle-evidence-and-report","source":"revise-and-approve-policy-updates","target":"compile-cycle-evidence-and-report"},{"id":"e-refresh-raci-and-competency-register-action-competency-gaps","label":"Gaps require action","source":"refresh-raci-and-competency-register","target":"action-competency-gaps","whenValue":"gaps_require_action"},{"id":"e-refresh-raci-and-competency-register-compile-cycle-evidence-and-report","label":"Competencies current","source":"refresh-raci-and-competency-register","target":"compile-cycle-evidence-and-report","whenValue":"competencies_current"},{"id":"e-action-competency-gaps-compile-cycle-evidence-and-report","source":"action-competency-gaps","target":"compile-cycle-evidence-and-report"},{"id":"e-confirm-roles-and-walk-obligations-register-remediate-obligation-gaps","label":"Gaps require remediation","source":"confirm-roles-and-walk-obligations-register","target":"remediate-obligation-gaps","whenValue":"gaps_require_remediation"},{"id":"e-confirm-roles-and-walk-obligations-register-compile-cycle-evidence-and-report","label":"Fully evidenced","source":"confirm-roles-and-walk-obligations-register","target":"compile-cycle-evidence-and-report","whenValue":"obligations_fully_evidenced"},{"id":"e-remediate-obligation-gaps-compile-cycle-evidence-and-report","source":"remediate-obligation-gaps","target":"compile-cycle-evidence-and-report"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-AI-01","UC-AI-02","UC-AI-03","UC-AI-13"],"department":"ai-governance","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-ai-governance-framework-roles-obligations-review","contentDigest":"sha256:aab1bde82a904f5eba9b2ae83229f011b64af87ef752b3180189fa1124799384","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:aab1bde82a904f5eba9b2ae83229f011b64af87ef752b3180189fa1124799384","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-ai-governance-framework-roles-obligations-review"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"grc-ai-governance-framework-roles-obligations-review","source":"coworkcanvas-gallery","standards":["iso-42001","eu-ai-act","aiuc-1"],"teams":["ai-governance","executive"]},"name":"AI Governance Framework, Roles & Obligations Review","nodes":[{"data":{"decisionField":"policy_review_outcome","description":"Agent compares the current AI policy against its review schedule and related security, privacy, and ethics policies; AI Governance Officer decides whether it can be reaffirmed or must be revised","formData":{"fields":[{"key":"policy_review_outcome","label":"AI policy review outcome","options":[{"label":"Reaffirm current version","value":"reaffirm_current_version"},{"label":"Revision required","value":"revise_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve whether the current AI policy can be reaffirmed as-is this cycle or must be revised, and route the cycle down the matching branch. The AI Governance Officer owns the call on the review record.\n\n**Decision criteria**\n\nBuild the review record before selecting. The AI policy is the Policy item (policy_type policy, framework iso-42001 + eu-ai-act, domains ai_governance, policy_owner = AI Governance Officer) with the governed document attached; its last review date and planned interval come from Policy.next_review_date and Policy.review_frequency. Retrieve those and confirm which trigger is in play — the scheduled interval, the folded-in annual re-approval, or an unscheduled regulatory or technology change. Pull the in-scope AI system list uploaded at this step (there is no AI System item type — the list is a document input to the run) and the comparison copies of the security, privacy, and ethics policies (their own Policy items in the policy library). Check the AI policy's stated principles and requirements for developing and using AI clause by clause against those policies, using ISO/IEC 42001 A.2.2 (the AI policy), A.2.3 (alignment with other organizational policies), and A.2.4 (review of the AI policy) as the baseline. Cross-reference against the trigger: for a regulatory change, confirm the policy still reflects current obligations (e.g., EU AI Act duties now in force); for a technology change, confirm every new AI use case or system type is in scope.\n\n- **Reaffirm current version (`reaffirm_current_version`)** — the policy stays consistent with the security, privacy, and ethics policies, covers every current use case and system type, reflects all in-force obligations, and needs no substantive change. A clean scheduled review with zero clause-level inconsistencies is the typical case. Reaffirmation still produces a dated review record — silence is not evidence of review.\n- **Revision required (`revise_required`)** — at least one clause-level inconsistency or gap exists, or the regulatory or technology trigger introduces an obligation, use case, or system type the current text does not cover. Name each inconsistency and its driving finding in the rationale; the revise step works from that list and does not reopen clauses that passed.\n\n**Record in AssureSwarm** — Submit the decision form: `policy_review_outcome` (the branch), the step result citing every inconsistency found and where the review evidence lives, and the step's approver record. Attach the review record — review date, reviewer, scope compared, inconsistencies, recommended outcome — to this step (step document, DOCX/PDF), and reference the AI policy Policy item it dispositions.\n\n**Exit criteria** — Form submitted with a rationale that dispositions the clause-by-clause comparison; review record attached; the not-taken branch is prunable because the taken branch fully describes the remaining policy work.","kind":"decision","label":"Review AI policy against schedule","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"review-ai-policy-against-schedule"},{"data":{"description":"Agent drafts the policy revisions and routes them for management approval; AI Governance Officer confirms the approved text is ready to publish","instructions":"**Objective** — Turn the review record's findings into an approved AI policy revision, with every edit traceable to the finding that drove it and signed off by the accountable governance body.\n\n**Inputs**\n- the step result and review record (document) from the decision step: the inconsistencies, gaps, and trigger-driven requirements to close.\n- The prior approved AI policy — the Policy item with its governed document attached and its version history (Policy.version, Policy.approved_by, Policy.effective_date).\n- The approval authority: the accountable AI governance body or its delegate (ISO/IEC 42001 A.3.2; Clause 5.3 organizational roles and responsibilities).\n\n**Procedure**\n1. Translate each finding into a specific, testable edit to the policy text, and tag every edit with the finding it closes. An edit with no source finding is scope creep; a finding with no edit is an unclosed gap.\n2. Apply the edits to a draft revision and produce a clause-by-clause change log against the prior approved version — old text, new text, driving finding. Keep principle-level changes (e.g., a new human-oversight or fairness commitment) visibly distinct from wording clean-ups so the approver sees what is substantive.\n3. Confirm the revision still aligns with the security, privacy, and ethics policies (A.2.3): a change made to close one gap must not open an inconsistency elsewhere.\n4. Resolve the required management approver and route the draft revision and change log through native step approvals. Re-circulate until accepted, capturing each round's decision and edit requests so the approval trail shows what changed between versions.\n\n**Record in AssureSwarm**\n- Attach the draft revision (DOCX) and the clause-by-clause change log (XLSX) to this step (step documents) — the Policy item itself is not re-versioned until the publish step.\n- Record the named approver and each round’s native approval; retain edit requests and version references in the step result.\n\n**Exit criteria** — Every finding in the review record maps to an applied edit; the change log is complete and accurate against the prior version; the accountable body or delegate has signed off; the approved text is ready to publish as the Policy item's current version.","label":"Revise and approve policy updates","performedBy":{"primitives":["coach-document-upload","coach-form-create"]}},"id":"revise-and-approve-policy-updates"},{"data":{"decisionField":"competency_status","description":"Agent refreshes the AI governance RACI and the competency records against this cycle's system, personnel, and obligation changes; AI Governance Officer decides whether any competence gap needs action","formData":{"fields":[{"key":"competency_status","label":"RACI and competency status","options":[{"label":"Competencies current, no action needed","value":"competencies_current"},{"label":"Gaps require action","value":"gaps_require_action"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether the refreshed AI governance RACI and competency records are current with no unresolved gap, or whether at least one role, assignment, or competence gap needs a remediation action. The AI Governance Officer owns the call on the refresh summary.\n\n**Decision criteria**\n\nWork the refresh before selecting. Retrieve the current RACI (or equivalent) covering AI governance roles across every life-cycle stage — design, data governance, development, deployment, and operation and monitoring — with the personnel documented against each role. Reconcile it against what changed since the last cycle: AI systems added, retired, or materially changed; personnel who joined, left, or changed role; and obligations newly added by the value-chain and obligations register. Use ISO/IEC 42001 A.3.2 (AI roles and responsibilities) for the assignments and A.4.6 (competences of personnel) for the competency records. For every role, confirm the holder's documented competences still meet the role's requirements.\n\n- **Competencies current (`competencies_current`)** — every governance role and life-cycle stage has a named, current holder; every holder's competence record has been reviewed this cycle and matches the role's requirements; and no obligation change has left a role uncovered. No unresolved gap remains to action.\n- **Gaps require action (`gaps_require_action`)** — at least one of: a role is unassigned; a role is held by someone who left or changed role; a competence record has not been reviewed since the prior cycle; or a holder's competences fall short of the role's requirements. State each gap and its type in the rationale; the action step works that list.\n\n**Record in AssureSwarm** — Submit the decision form: `competency_status` (the branch), the step result listing each gap with its type and evidence reference, and the step's approver record. Attach the refreshed RACI and competency register with its refresh summary — RACI changes applied, competence records updated, gaps found with proposed remediation — as a versioned XLSX/DOCX on this step (step document); there is no Role or Competency item type, so the register travels as a step document rather than typed items.\n\n**Exit criteria** — Form submitted with a rationale that dispositions every role and competence record; refresh summary recorded; the not-taken branch is prunable because the taken branch fully describes the remaining competency work.","kind":"decision","label":"Refresh RACI and competency register","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-document-upload"]}},"id":"refresh-raci-and-competency-register"},{"data":{"description":"The remediation owner chooses a corrective approach and accepts the commitment in native results and approvals; the governance officer escalates unowned gaps.","instructions":"**Objective** — Convert every competency gap flagged at the refresh into a tracked remediation with an accepted owner and a target date, so no role or competence shortfall stays open without accountability.\n\n**Inputs**\n- the step result and refresh summary: each gap with its type — unassigned role, lapsed competence review, or competence shortfall.\n- The RACI entries and competency records the gaps attach to (ISO/IEC 42001 A.3.2, A.4.6).\n- The candidate holders for reassignment and the training or external-expertise options for shortfalls.\n\n**Procedure**\n1. Create one Issue item per flagged gap (`issue_type: deficiency`, `source: self_assessment`, `issue_owner`, `target_remediation_date`), naming the affected role in `description` and the remediation that fits the type in `remediation_plan`: fill or reassign the role for an unassigned or vacated role; schedule a competence review for a lapsed record; and schedule training or bring in additional expertise for a shortfall (A.4.6). One gap, one traceable Issue — batching hides misses.\n2. Link each Issue to the anchor \"AI Governance Program\" Process item (the RACI and competency register has no item type to link to), and name the specific RACI entry or competency record it remediates in the Issue description, so the program shows the open action against the affected role rather than in a side list.\n3. Have each participating action owner record their chosen remediation approach and target date in the native result and accept the assignment through native approval. The owner's acceptance is what makes the remediation real; an unaccepted assignment is still an open gap, and an acceptance filled in on the owner's behalf is not one.\n4. Chase to completion: track acceptances, escalate non-responders, and compile the list of any action still unowned after routing for the AI Governance Officer.\n\n**Record in AssureSwarm**\n- Create one Issue per gap (`Issue` — `issue_type: deficiency`, `source: self_assessment`, `issue_owner`, `target_remediation_date`, `remediation_plan`) and link each to the anchor Process item (item create; Issue ↔ Process relationship).\n- The action owner’s native result and approval capture their acceptance, the remediation approach, the committed target date, the planned actions, interim coverage of the role, the completion evidence they will attach, and any conditions or blockers; copy the accepted owner and committed date onto the matching Issue (`issue_owner`, `target_remediation_date`).\n- Record which Issues remain unowned after routing.\n\nRecord in the native step result or attached source documents: Do you accept ownership of this competency remediation? (assignment_accepted); How will the gap be closed? (remediation_approach); Committed completion date (committed_target_date); Specific actions you will take and their sequence (planned_actions); Who covers this role or competence until the gap closes (interim_coverage); Evidence you will attach to demonstrate the gap is closed (completion_evidence); Conditions, dependencies, or blockers the governance office must resolve (conditions_or_blockers). Use native approvals for sign-off.\n\n**Exit criteria** — Every flagged gap exists as a tracked Issue linked to the anchor Process item and naming its affected role, with an accepted owner and a target date; unowned Issues escalated to the AI Governance Officer; the RACI and competency register is not treated as current for this cycle until this holds.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` issues the acceptance assignments to each action owner, sends reminders, and keeps a logged chase trail through to acceptance.\n\n","label":"Action competency gaps","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-form-create","coach-notify"]}},"id":"action-competency-gaps"},{"data":{"decisionField":"obligations_status","description":"AI Governance Officer: Judge provider/deployer responsibilities and whether each obligation has an owner and current evidence, using the refreshed dependency inventory.","formData":{"fields":[{"key":"obligations_status","label":"Obligations register status","options":[{"label":"Obligations fully evidenced","value":"obligations_fully_evidenced"},{"label":"Gaps require remediation","value":"gaps_require_remediation"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Use the refreshed AI resource inventory to confirm value-chain responsibilities and decide whether every applicable obligation is owned and evidenced.\n\n**Decision criteria**\nInputs for preparation: - The current resource inventory per in-scope AI system — the prior cycle's versioned XLSX inventory document on this step (there is no Asset/Resource item type; entries are spreadsheet rows): data resources, tooling (frameworks, libraries, pre-trained and fine-tuned models), and system and computing resources — each with a recorded owner and location.\n- The AI system change-process log extract since the last cycle, uploaded at this step from the change-management tool: the source of record for what actually changed.\n- ISO/IEC 42001 A.4.2 (resource documentation), A.4.3 (data resources), A.4.4 (tooling resources), A.4.5 (system and computing resources).\n\n*Autonomous preparation incorporates Update AI resource and dependency inventory; AI Governance Officer reviews the combined evidence.*\n1. Pull the current inventory for every in-scope system and confirm each entry still carries an owner and a location; an entry with neither cannot support accountability and is itself a finding.\n2. Scan the change process log since the last cycle for every AI-system change: new or retired data sources, model or library version changes (a model version bump is a resource change, not a footnote), new tooling, and infrastructure or compute changes.\n3. Update the affected entries — add new resources, retire superseded ones, correct any owner or location that changed — mapping each update to the change-log entry that drove it. Record provenance and licensing for data resources (A.4.3), version and source for tooling (A.4.4), and environment and location for compute (A.4.5).\n4. Test each entry against its purpose: would this detail let someone assess the impact of changing the resource, reproduce the system's behaviour, or hold a supplier accountable? Detail that fails that test is too coarse — deepen it.\n5. Draft the inventory refresh summary listing every entry added, changed, or retired this cycle, and any entry still missing an owner or location.\n\nWork the walk-through before selecting. For every in-scope system, re-confirm and document the organization's role in the value chain — provider or deployer, or both where it plays different roles for different systems — using ISO/IEC 42001 A.10.2 (allocating responsibilities across the AI value chain), and re-allocate life-cycle responsibilities among the organization, partners, suppliers, and customers wherever a role has changed. Then retrieve the obligations register — the Control items (framework eu-ai-act + iso-42001, domains ai_governance, `control_owner` = obligation owner), one per obligation — and walk every obligation attached to each confirmed role. For provider duties on high-risk systems: quality management system (EU AI Act Art. 17), technical documentation (Art. 11), conformity assessment (Art. 43), CE marking (Art. 48), and EU database registration (Art. 49) — the Article 16 provider duty set. For deployer duties: use in line with the instructions for use, assignment of competent human oversight (Art. 14), and retention of automatically generated logs (Art. 26(6), at least six months) — the Article 26 deployer duty set. For each obligation, check it traces to a named owner (`Control.control_owner`) and to current evidence.\n\n- **Obligations fully evidenced (`obligations_fully_evidenced`)** — every obligation across every in-scope system, for every confirmed role, traces to a named owner and to evidence current within this cycle's tolerance. No unowned or unevidenced obligation remains.\n- **Gaps require remediation (`gaps_require_remediation`)** — at least one obligation is unowned, has no evidence, or carries evidence older than the cycle's tolerance. Name each gapped obligation, its system, its role (provider or deployer), and the missing element in the rationale; the remediation step works that list.\n\n**Record in AssureSwarm**\n- Attach the updated per-system inventory (entries added, changed, retired) with the change-log-to-entry mapping and the refresh summary as a versioned XLSX/DOCX on this step (step document) — there is no Asset/Resource item type, so the inventory travels as a step document, not typed items.\n- For any entry still missing an owner or location, create one Issue (`Issue` — `issue_type: observation`, `source: self_assessment`, `issue_owner`, `target_remediation_date`) and link it to the anchor Process item (item create; Issue ↔ Process relationship).\nSubmit the decision form: `obligations_status` (the branch), the step result listing each role confirmed or changed and each gapped obligation with its owner and evidence status, and the step's approver record. Link each in-scope obligation Control item to the anchor \"AI Governance Program\" Process item so the program shows current in-scope ownership (Control ↔ Process relationship). The per-system provider/deployer role attribution has no AI System item type — capture it in the walk-through worksheet attached to this step (step document).\n\n**Exit criteria**\nJudge provider/deployer responsibilities and whether each obligation has an owner and current evidence, using the refreshed dependency inventory.\nInventory reflects every relevant change-process entry since the last cycle; every resource has a named owner and location; entry detail would support an impact assessment or reproducibility request; refresh summary recorded before the cycle moves to value-chain roles.\nForm submitted with a rationale that dispositions every role and obligation; roles re-confirmed and re-allocated where changed; the not-taken branch is prunable because the taken branch fully describes the remaining obligations work.","kind":"decision","label":"Confirm roles and walk obligations register","performedBy":{"primitives":["coach-query-data","coach-workflow-scan","coach-item-create","coach-item-update","coach-document-upload","coach-items-link"]}},"id":"confirm-roles-and-walk-obligations-register"},{"data":{"description":"Agent creates a remediation ticket for every unowned or unevidenced obligation and tracks it to closure; AI Governance Officer approves closure once evidence is attached","instructions":"**Objective** — Convert every unowned or unevidenced obligation into a closed remediation with a named owner and attached, re-checked evidence, so every provider and deployer duty traces to accountability before the cycle reports.\n\n**Inputs**\n- the step result from the decision: each gapped obligation with its system, role, specific duty, and missing element.\n- The obligations register entries the gaps attach to — the Control items (framework eu-ai-act + iso-42001, `control_owner`).\n- The duty definitions to remediate against: EU AI Act Article 16 provider duties (quality management, technical documentation, conformity assessment under Art. 43, CE marking under Art. 48, registration under Art. 49) and Article 26 deployer duties (instruction-compliant use, human oversight under Art. 14, log retention under Art. 26(6)).\n\n**Procedure**\n1. Create one Issue per gapped obligation (`issue_type: exception`, `source: compliance_review`, `issue_owner`, `target_remediation_date`), naming the specific duty — e.g., conformity assessment, CE marking, EU database registration, human-oversight assignment, or log retention — and the missing element (owner, evidence, or both). One obligation, one Issue.\n2. Where the obligation Control has no owner, set `Control.control_owner` on it, and set a due date for the evidence to be produced or located. An obligation with a duty but no owner is where enforcement exposure lives.\n3. Track each Issue to closure. As evidence arrives, attach it to the obligation Control item and link the Issue to that Control so the register entry itself carries the evidence, not a pointer to somewhere else.\n4. Re-run the obligations check on every remediated Control — confirm it now traces to a named `control_owner` and to current evidence — before moving the Issue to closed and setting its `actual_remediation_date`. A closed ticket is a claim; the re-checked register entry is the evidence.\n\n**Record in AssureSwarm**\n- Create one Issue per gapped obligation (`Issue` — `issue_type: exception`, `source: compliance_review`, `issue_owner`, `target_remediation_date`) and set `Control.control_owner` on any obligation Control lacking an owner (item create; item field update).\n- Attach the arriving evidence to the obligation Control item and link the Issue to it (document upload; Issue ↔ Control relationship); update each Issue through to closed with its `actual_remediation_date` (item update).\n- Record any obligation that remains open with its named owner and due date.\n\n**Exit criteria** — Every flagged obligation is either closed with an owner and attached, re-checked evidence, or still open with a named owner and a due date; the AI Governance Officer approves each closure once evidence is attached and verified; no obligation remains open without accountability.","label":"Remediate obligation gaps","performedBy":{"primitives":["coach-item-create","coach-document-upload","coach-item-update","coach-items-link"]}},"id":"remediate-obligation-gaps"},{"data":{"description":"Automatically publish the already-authorized policy and compile, retain and report the joined cycle record after the prior decisions and remediation approvals.","instructions":"**Objective** — Publish the authorized current policy, preserve its lineage and assemble the four-area cycle record after the policy, competency and obligations paths converge.\n\n**Inputs**\n- The current version to publish: the reaffirmed policy with its review record, or the newly approved revision with its change log and approval sign-off.\n- The prior approved version and its version history (the superseded document and Policy.version).\n- The AI policy Policy item — the register of record — and the organization's policy distribution channel with its recipient groups (ISO/IEC 42001 A.8.5, information for interested parties).\n- Every artifact produced this cycle: the policy review record with publication and retention evidence; the RACI and competency refresh summary with any gap actions; the resource and dependency inventory refresh summary; and the value-chain and obligations walk-through with any remediations.\n- The current state of all four registers, for the extracts: the AI policy Policy item and the obligation Control items (exportable typed items), plus the document-based RACI and competency register and the resource and dependency inventory (step documents).\n- The prior cycle's report and dashboard, for trend comparison.\n- The governance records-retention schedule and the archive location (ISO/IEC 42001 Clause 7.5 documented information; EU AI Act documentation and log-retention periods where applicable).\n- The still-open competency and obligation remediation items with their owners and due dates, and the quarterly cadence plus the annual policy re-approval calendar.\n\n**Procedure**\n*The agent incorporates Publish and archive policy version after the preceding authorized decisions, without an additional approval.*\n1. Package the current version with its effective date, version number, and the evidence behind it — the review record for a reaffirmation, or the change log plus approval sign-off for a revision.\n2. Publish to all relevant personnel through the distribution channel and capture acknowledgment or receipt evidence per recipient group. For a substantive revision, a fresh re-acknowledgment is what demonstrates the change was communicated, not merely posted.\n3. Retain the prior version, superseded as of this date, in the policy archive with its own version history intact rather than overwritten, and link it to the new version so the lineage is traceable end to end. The retained version is fixed as of supersession; any later correction is a new dated version, never an edit to the archived one.\n4. Update the AI policy Policy item to the published state: `version`, `effective_date`, `approved_by`, and `next_review_date` (A.2.4), and re-attach the governed document as the new current version. The per-group distribution evidence has no native Policy field — it stays as a step document.\n5. Collect the evidence across all four register areas and index the package by area, so the report's structure is the evidence's structure. Test it against re-performance: could a reader holding only this package reconstruct the policy decision, the competency refresh, the inventory changes, and the obligations coverage? An external reference fails that bar — pull the artifact in.\n6. Build the cycle dashboard: policy status, open competency actions, inventory entries updated, and obligations coverage rate, each compared against the prior cycle so trend direction is visible.\n7. Export the consolidated register extracts so the package carries the current state of all four registers — not only this cycle's deltas — which is what an auditor samples against.\n8. Draft the cycle report to the AI governance body: what changed in each area, what remains open, and the named owner and due date for every in-progress item. Spot-check every figure against its source artifact before publishing.\n9. Confirm the cycle is actually closable: the policy version is published, the RACI and competency register is current or its gaps are owned actions, the inventory is refreshed, and every obligation is evidenced or a tracked remediation. A cycle with an unowned open item does not close — it escalates.\n10. Export the full workflow record — every node's evidence, decisions, and rationales — and archive it with the package to the retention location, tagged with the cycle date, trigger, and version references, and linked back to the anchor \"AI Governance Program\" Process item so it is retrievable as a single self-contained record. Verify retrievability by opening the archived copy, not by trusting the upload confirmation. The archived record is fixed as of this date; any later correction is a new dated addendum, never an edit to the archived copy.\n11. Carry forward every still-open competency or obligation remediation item as a named input to the next cycle, each with its owner and due date, rather than letting it lapse between cycles.\n12. Schedule the next quarterly cycle, noting whether the next occurrence also carries the annual policy re-approval, and notify the AI Governance Officer and the named register owners of the schedule. The prior policy, competency and obligations decisions and remediation approvals authorize this automatic cycle record.\n\n**Record in AssureSwarm**\n- Update the Policy item fields — `Policy.version`, `Policy.effective_date`, `Policy.approved_by`, `Policy.next_review_date` — and attach the published current version to it (item field update; item document).\n- Attach the per-group acknowledgment evidence to this step (step document) — acknowledgment has no native Policy field.\n- Link the superseded prior version to the new current version so the lineage is traceable (document link).\n- Assemble and index the four-area evidence package (document upload) and build the cycle dashboard (dashboard create).\n- Export the Policy item and obligation Control items as consolidated register extracts, and fold in the document-based RACI/competency and inventory registers, into the package (item export; document upload).\n- Record the cycle report with each open item's owner and due date.\n- Export the workflow record and archive it, linking the archived package back to the anchor Process item (workflow export; document link).\n- Carry each still-open remediation forward as an Issue linked to the anchor Process item (`Issue` — `issue_owner`, `target_remediation_date`), so it becomes a named input to the next cycle (item create; Issue ↔ Process relationship).\n- Record the next cycle's scheduled date and whether it carries the annual policy re-approval on this step.\n\n**Exit criteria**\nAutomatically publish the already-authorized policy and compile, retain and report the joined cycle record after the prior decisions and remediation approvals.\nCurrent version published and acknowledged across all recipient groups; prior version retained with intact history and linked to the new version; the Policy item updated with version, effective date, approver, and next review date; Distribution and retention evidence is attached; failed delivery or archive verification remains an open action.\nPackage passes the re-performance test with no external references and evidences all four areas — policy review, RACI and competency refresh, resource inventory update, obligations walk-through — without outside explanation; dashboard reflects the four areas against the prior cycle; every reported figure traces to an attached artifact; every open thread exists as a carry-forward item with a named owner and due date; the archived record is verified retrievable; the next cycle is scheduled; the prior decisions and remediation approvals remain linked to the automatic closure record.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles and renders the indexed four-area evidence package — policy, RACI and competency, resource inventory, and obligations — into a single reviewable cycle record.","label":"Compile cycle evidence and report","performedBy":{"primitives":["coach-document-upload","coach-item-update","coach-dashboard-create","coach-export-package","coach-render-package","coach-workflow-export","coach-item-create","coach-items-link"]},"requiredApprovals":0},"id":"compile-cycle-evidence-and-report"}],"sourceTemplateId":"workflow-library:grc-ai-governance-framework-roles-obligations-review"}