{"description":"AI Service Data Policy & Quality Management Cycle as a modular, decision-aware workflow. Each annual instance — and each semiannual regulatory-compliance checkpoint — runs on the existing \"AI Service Data Policy & Quality Management\" Process item (process_type operational, process_owner = AI Product Owner) and enriches its standing records; it never recreates them. Run by the AI Governance Lead (second line) and owned by the AI Product Owner (first line), it refreshes the customer-facing input data policy and output data policy, collects customer acknowledgements where the changes are material, reviews the AI quality management system for effectiveness, and refreshes the regulatory compliance documentation and obligations register shared with customers. Consumes at launch: the cycle trigger and mode, the in-scope AI service list with each service's value-chain role (a step document — there is no AI System item type), both data policies and the quality manual and procedures as Policy items, and the obligations register as Control items. Deliverables: the published policy versions with their acknowledgement records, the quality management system review record, the refreshed compliance statement and obligations register, the corrective-action log, and an indexed cycle evidence pack. Out of scope: the AI services' own development, risk assessment, and control testing, and fulfilment of individual customer data requests. Terminal — the cycle closes to its own archived workflow record, linked back to the anchor Process item.","edges":[{"id":"e-assess-customer-notice-requirement-notify-customers-and-collect-acknowledgements","label":"Notice required","source":"assess-customer-notice-requirement","target":"notify-customers-and-collect-acknowledgements","whenValue":"notice_and_reacknowledgement_required"},{"id":"e-assess-customer-notice-requirement-assess-nonconformities","label":"No notice required","source":"assess-customer-notice-requirement","target":"assess-nonconformities","whenValue":"no_notice_required"},{"id":"e-notify-customers-and-collect-acknowledgements-assess-nonconformities","source":"notify-customers-and-collect-acknowledgements","target":"assess-nonconformities"},{"id":"e-assess-nonconformities-raise-and-track-corrective-actions","label":"Corrective action required","source":"assess-nonconformities","target":"raise-and-track-corrective-actions","whenValue":"corrective_action_required"},{"id":"e-assess-nonconformities-compile-cycle-report-and-evidence-pack","label":"No nonconformities","source":"assess-nonconformities","target":"compile-cycle-report-and-evidence-pack","whenValue":"no_corrective_action_required"},{"id":"e-raise-and-track-corrective-actions-compile-cycle-report-and-evidence-pack","source":"raise-and-track-corrective-actions","target":"compile-cycle-report-and-evidence-pack"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-AI-17","UC-AI-24","UC-AI-13"],"department":"ai-governance","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-ai-service-data-policy-quality-management-cycle","contentDigest":"sha256:578fedbe1717a4988fcc601d5f7881a77f1b6cc72e5f5e4f7e3f93d854941781","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:578fedbe1717a4988fcc601d5f7881a77f1b6cc72e5f5e4f7e3f93d854941781","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-ai-service-data-policy-quality-management-cycle"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"grc-ai-service-data-policy-quality-management-cycle","source":"coworkcanvas-gallery","standards":["aiuc-1","iso-42001","eu-ai-act"],"teams":["ai-governance","privacy"]},"name":"AI Service Data Policy & Quality Management Cycle","nodes":[{"data":{"controls":["UC-AI-17","UC-AI-13"],"decisionField":"customer_notice_required","description":"AI Product Owner after Legal and Privacy review: Approve coherent input/output commitments and decide the required contractual notice and re-acknowledgement before publication.","formData":{"fields":[{"key":"customer_notice_required","label":"Customer notice and re-acknowledgement","options":[{"label":"Notice and re-acknowledgement required","value":"notice_and_reacknowledgement_required"},{"label":"No customer notice required","value":"no_notice_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Approve the current scope and coherent input/output policy text, then determine which changes require customer notice and re-acknowledgement.\n\n**Decision criteria**\nInputs for preparation: - The anchor \"AI Service Data Policy & Quality Management\" Process item (process_type operational, process_owner = AI Product Owner) and its linked records.\n- The input data policy and the output data policy — the customer-facing data-use and output-rights policies — as Policy items (policy_type policy, framework iso-42001 + eu-ai-act, domains ai_governance, policy_owner = AI Product Owner).\n- The quality manual and its documented procedures (Policy items, policy_type standard and procedure) and the obligations register (Control items, framework eu-ai-act + iso-42001, `control_owner` = obligation owner).\n- The in-scope AI service list with each service's value-chain role, uploaded at this step (there is no AI System item type — it travels as a step document).\n- The current input data policy Policy item and its governed document, with `Policy.version`; the cycle scope note and reconciled service list from the scope preparation in this checkpoint.\n- The engineering facts per service: whether customer inputs are used for model training or fine-tuning, how inference-time inputs are processed and by which sub-processors, the retention period for inputs and prompts, and the deletion and opt-out mechanisms as built.\n- The privacy notice and data processing terms the policy must not contradict, and any regulatory change since the last cycle (EU AI Act transparency duties, data protection guidance).\n- The current output data policy Policy item and its governed document; the input data policy draft reviewed alongside this output policy, because the two policies must read as one coherent set.\n- The engineering facts per service: output retention period, whether outputs feed evaluation or retraining, output logging for abuse monitoring, and the deletion path when a customer requests it.\n- The commercial terms in force — ownership and licence clauses in the customer agreement and any enterprise addenda — and the rules on output disclosure and marking (EU AI Act Article 50 where AI-generated content reaches end users).\n\n*Autonomous preparation incorporates Confirm cycle scope and policy inventory; Review and redraft input data policy; Review and redraft output data policy; AI Product Owner after Legal and Privacy review reviews the combined evidence.*\n1. Confirm the trigger and mode. The annual review runs every step in full; the semiannual checkpoint (AIUC-1 E012, every 6 months) runs the policy and quality steps in confirm-only mode and does its substantive work in the compliance refresh.\n2. Reconcile the AI service list against the prior cycle: services launched, retired, or changed in what customer inputs they collect, how they generate outputs, or the organization's provider or deployer role.\n3. Confirm the current version of every policy, procedure, and obligation record is the one customers and regulators were last shown; an unpublished draft is not the baseline.\n4. Draft the cycle scope note: trigger, mode, in-scope services, baseline versions, and any service change that pre-commits a redraft.\n5. Walk the policy clause by clause against practice for every in-scope service: training use (opt-in or opt-out default, enterprise exclusions), inference processing (sub-processors, regions), retention (period, purpose, deletion trigger), and customer rights (access, deletion, opt-out, portability). Record each clause as consistent, inconsistent, or silent.\n6. Where a service changed since the last cycle, confirm the policy already covers the new behaviour; an unstated training use is a customer-transparency gap, not a wording issue.\n7. Draft the revision with a clause-level change log — old text, new text, driving fact — keeping substantive commitments visibly separate from wording clean-ups. On the semiannual checkpoint, or when every clause is consistent, record a reaffirmation with the same evidence.\n8. Route the draft to Legal and Privacy for a bounded review and resolve their comments before the AI Product Owner approves.\n9. Walk the policy clause by clause: output ownership and assignment, the organization's permitted uses of outputs (evaluation, safety review, retraining) and the customer's opt-in or opt-out for each, usage restrictions on the customer side, retention, and deletion on request. Disposition each clause as consistent, inconsistent, or silent against practice and against the customer agreement.\n10. Check the two data policies against each other: a retention period or opt-out mechanism stated differently in the input and output policies is a defect in both.\n11. Draft the revision with a clause-level change log, or a reaffirmation record where nothing changed, and route it to Legal for review of the ownership and licence language before the AI Product Owner approves.\n12. Resolve the authorized approver, use native step approvals, and capture each round’s edit requests in the result.\n\n- **Notice and re-acknowledgement required (`notice_and_reacknowledgement_required`)** — at least one change alters a commitment customers relied on: a new or expanded training use of inputs, a shorter retention period, a new sub-processor, a change to output ownership or the organization's permitted uses of outputs, a narrowed customer right, or a new opt-in or opt-out default. Anything the customer agreement or a regulator would treat as material lands here, as does a policy never acknowledged before.\n- **No customer notice required (`no_notice_required`)** — every change is a reaffirmation, a wording clean-up, a correction that expands customer rights, or a structural edit with no change of commitment. The standing notice and prior acknowledgements remain valid evidence.\n\n**Agent procedure**\n1. Classify every change-log entry from both policies as commitment-changing or wording-only, citing the clause and driving fact.\n2. Check each commitment-changing entry against the customer agreement's notice clause and enterprise addenda for the notice period and whether re-acknowledgement is contractually required.\n3. Draft the materiality memo (every entry, its class, the notice basis) and pre-fill the decision form for the AI Product Owner to confirm or override.\n\n**Record in AssureSwarm**\n- Attach the reconciled AI service list and the cycle scope note to this step (step documents).\n- Link each in-scope Policy and obligation Control item to the anchor Process item (Policy ↔ Process, Control ↔ Process relationships).\n- Attach the clause-by-clause comparison, the draft revision or reaffirmation record, and the change log to this step (step documents, DOCX/XLSX).\n- Record the approval through native step approvals; the Policy item is not re-versioned until the customer notice decision is made.\n- Attach the clause-by-clause comparison, the draft revision or reaffirmation record, and the change log to this step (step documents).\n- Record approval routing and each round’s decision through native approvals and results; the Policy item fields are published once the customer notice decision is taken.\nSubmit the decision form: `customer_notice_required` (the branch), a rationale naming every commitment-changing entry or stating why none exists, and the decision owner. Attach the materiality memo to this step (step document). On the no-notice branch, publish the reaffirmed or cleaned-up versions here: update `Policy.version`, `Policy.effective_date`, `Policy.approved_by`, and `Policy.next_review_date` on both Policy items, attach the published documents, and retain the superseded versions (item field update; item document).\n\n**Exit criteria**\nApprove coherent input/output commitments and decide the required contractual notice and re-acknowledgement before publication.\nTrigger and mode recorded; every in-scope service has a confirmed value-chain role; baseline versions of both data policies, the quality manual, and the obligations register identified and linked; the AI Product Owner uses the documented boundary when approving the combined policy and notice decision.\nEvery clause dispositioned against practice for every in-scope service; each edit traces to a driving fact; Legal and Privacy comments resolved; the AI Product Owner has approved the input data policy text or its reaffirmation.\nEvery output-rights clause dispositioned against practice and the customer agreement; the two data policies are mutually consistent; each edit traces to a driving fact; the AI Product Owner has approved the output data policy text or its reaffirmation.\nForm submitted with a rationale that dispositions every change-log entry; materiality memo attached; on the no-notice branch both Policy items published; the not-taken branch is prunable because the taken branch fully describes the remaining publication work.","kind":"decision","label":"Assess customer notice requirement","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-items-link","coach-form-create","coach-form-fill","coach-item-update"]}},"id":"assess-customer-notice-requirement"},{"data":{"controls":["UC-AI-17"],"description":"Automatically execute the authorized notice and collect outside customer decisions; apply the existing escalation rules to gaps.","formData":{"fields":[{"key":"acknowledgement","label":"Do you acknowledge the revised policies for your account?","options":[{"label":"Acknowledged","value":"acknowledged"},{"label":"Acknowledged, questions noted below","value":"acknowledged_with_questions"},{"label":"Objection - do not apply to my account","value":"objection"}],"required":true,"type":"select"},{"key":"training_use_election","label":"Election on use of your input data for model training","options":[{"label":"Opt in","value":"opt_in"},{"label":"Opt out","value":"opt_out"},{"label":"Keep current election","value":"no_change"}],"required":true,"type":"select"},{"key":"deletion_or_rights_request","label":"Deletion or other data-rights request you want actioned with this acknowledgement","required":false,"type":"textarea"},{"key":"questions_or_objections","label":"Questions or objections about the changed commitments","required":false,"type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Communicate the revised input and output data policies to every affected customer before they take effect, collect acknowledgements, and freeze a defensible acknowledgement record — the evidence that the data-use and output-rights policies were communicated and versioned, not merely posted.\n\n**Inputs**\n- The approved policy texts, change logs, and the materiality memo with the required notice period.\n- The affected customer population per service — account owners and named contract contacts — exported from the customer system and uploaded here as a CSV (the AssureSwarm copy is the evidence). New customers receive the policies at onboarding, before first use.\n- The customer agreement's notice mechanics, the acknowledgement threshold, and the escalation path.\n\n**Procedure**\n1. Publish both new versions with an effective date that honours the notice period, and retain the superseded versions read-only so the lineage is traceable.\n2. Issue the notice to every affected contact — what changed, why, the effective date, and how to exercise the choices the change introduces (opt-out of training use, deletion, objection) — together with this step's acknowledgement form.\n3. Track acknowledgements against the population, remind on the cadence, and escalate through account owners past the due date; correct the population for churned accounts and changed contacts rather than counting them as refusals. Never record an acknowledgement on a customer's behalf — an unanswered form is a non-response, not an acknowledgement.\n4. When the window closes, freeze the record: who acknowledged and when, who did not, the disposition of each non-response, and any customer who exercised an opt-out or deletion right in response.\n\n**Record in AssureSwarm**\n- Update both Policy items to the published state — `Policy.version`, `Policy.effective_date`, `Policy.approved_by`, `Policy.next_review_date` — attach the published documents, and retain the superseded versions as archived documents on the same items (item field update; item document).\n- The form on this step, answered by each affected customer's named contract contact, captures the acknowledgement or objection, training-use election, any deletion or data-rights request, and questions or objections. Bind each response to the exact version pair in the notice, the named contract contact and role in the authorized population, and the native submission timestamp — it is the acknowledgement evidence itself.\n- Attach the customer population, the notice log, and the frozen acknowledgement record consolidating the form responses (CSV or XLSX) to this step — there is no Acknowledgement item type, so the step record is the authoritative evidence.\n\n**Exit criteria** — Both versions published with notice-compliant effective dates; every affected customer notified through the contractual channel; the frozen acknowledgement record covers the whole population with non-responses dispositioned; exercised opt-outs and deletion requests handed to fulfilment; automatic completion follows the approved notice rules; unresolved cases remain escalated.\n\n**Form recipient** — each affected customer’s named contract contact, outside the AI Governance Lead, Product Owner, Legal/Privacy reviewers and corrective-action executors, supplies the account’s acknowledgement, election and rights requests. Send it with a form assignment; the owner's own work goes in the step result.","label":"Notify customers and collect acknowledgements","performedBy":{"primitives":["coach-item-update","coach-notify","coach-form-create","coach-query-data","coach-document-upload"]},"requiredApprovals":0},"id":"notify-customers-and-collect-acknowledgements"},{"data":{"controls":["UC-AI-24","UC-AI-13"],"decisionField":"nonconformity_disposition","description":"AI Product Owner with second-line AI Governance Lead: Judge quality-system effectiveness, obligation evidence and policy-communication failures and choose corrective action or evidenced closure.","formData":{"fields":[{"key":"nonconformity_disposition","label":"Nonconformity disposition","options":[{"label":"Corrective action required","value":"corrective_action_required"},{"label":"No corrective action required","value":"no_corrective_action_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Evaluate quality-system operation, current customer compliance claims and obligation evidence together, then disposition every candidate nonconformity.\n\n**Decision criteria**\nInputs for preparation: - The quality manual (Policy item, policy_type standard) and its documented procedures (Policy items, policy_type procedure): design, development, testing and release; change management; data management; issue tracking and corrective action; stakeholder and regulator communication; record keeping.\n- The period's operating evidence: release and change records, test and evaluation results, the issue log with corrective actions, incident and customer communications, and the prior cycle's open actions.\n- ISO/IEC 42001 Clauses 9.1 (monitoring and evaluation) and 10.1 (continual improvement) as the baseline.\n- The reconciled AI service list with value-chain roles, and the prior cycle's roles worksheet.\n- The obligations register — Control items (framework eu-ai-act + iso-42001, `control_owner` = obligation owner), one per obligation.\n- The prior compliance statement, the regulatory change log since it was issued, and the quality management system review record.\n\n*Autonomous preparation incorporates Review AI quality management system; Refresh compliance documentation and obligations register; AI Product Owner with second-line AI Governance Lead reviews the combined evidence.*\n1. Confirm each quality objective is measurable, owned, and measured for the period; an unmeasured objective is a finding.\n2. For each documented procedure, sample the period's records and test conformance: releases tested and approved as written, changes assessed for impact on customer-facing behaviour and the data policies, issues logged and closed with root cause and corrective action, affected customers and, where required, regulators informed on time.\n3. Check that the procedures still describe current practice after the period's changes — new model versions, sub-processors, evaluation methods — and flag any that drifted.\n4. Compile the review record: objective results, conformance per procedure, drifted procedures, corrective actions open past their date, and an effectiveness verdict with improvement actions.\n5. Re-confirm each service's role — provider, deployer, or both — under ISO/IEC 42001 A.10.2 and EU AI Act Article 25, recording any change and its cause.\n6. Walk every obligation of each confirmed role: provider duties — quality management system, technical documentation, conformity assessment, declaration of conformity, CE marking, registration, cooperation with authorities, authorised representative (EU AI Act Articles 16-17, 21-22, 43, 47-49) — and deployer duties — operation per the instructions for use, human-oversight assignment, log retention (Article 26). Confirm each traces to a named `control_owner` and to current evidence.\n7. Add obligations that new services or regulatory changes introduce, retire those of retired services or roles, and record every obligation that is unowned, unevidenced, or stale.\n8. Redraft the customer compliance statement: roles per service, obligations with status and evidence reference, open gaps with owners and dates, and the next checkpoint date. An obligation with an owner but no evidence is reported as open.\n\n- **Corrective action required (`corrective_action_required`)** — at least one of: a quality objective unmeasured or missed without an owned action; a documented procedure not followed in the sampled records, or drifted from practice; a corrective action from the prior cycle still open past its date; an obligation unowned, unevidenced, or carrying stale evidence; a compliance statement claim not backed by evidence; or a customer notice or acknowledgement gap left open from the policy steps. Each is named individually in the rationale — the corrective-action step works that list.\n- **No corrective action required (`no_corrective_action_required`)** — every candidate is dispositioned as conforming on re-check, as an observation carrying no obligation or objective failure, or as already closed with evidence attached during the cycle. The disposition record still names each candidate and its reason; an empty list is not a disposition.\n\n**Agent procedure**\n1. Consolidate the candidates from the quality system review record, the obligations walk-through, and the acknowledgement record into one worksheet, de-duplicating items that surfaced in more than one place.\n2. Classify each candidate — nonconformity, observation, or conforming on re-check — with the evidence reference that supports the class and the procedure, objective, obligation, or policy commitment it attaches to.\n3. Pre-fill the decision form with the classified list for the AI Product Owner to confirm or override.\n\n**Record in AssureSwarm**\n- Attach the review record and the sampled evidence index to this step (step documents).\n- Update `Policy.next_review_date` on the quality manual and each procedure reviewed, and note any procedure marked for revision (item field update).\n- Update each obligation Control item (`control_owner`, status, evidence) and create new ones for added obligations, each linked to the anchor Process item (item field update; item create; Control ↔ Process relationship).\n- Attach the roles worksheet, obligations walk-through, and redrafted compliance statement to this step and the anchor Process item (step documents; item document).\nSubmit the decision form: `nonconformity_disposition` (the branch), a rationale that lists every candidate with its class and evidence reference, and the decision owner. Attach the consolidated disposition worksheet to this step (step document).\n\n**Exit criteria**\nJudge quality-system effectiveness, obligation evidence and policy-communication failures and choose corrective action or evidenced closure.\nEvery quality objective measured and owned; every documented procedure tested against period records; drifted procedures and unmeasured objectives listed as candidate nonconformities for the disposition step; the effectiveness verdict is evaluated in the combined nonconformity decision.\nEvery service has a confirmed role; every obligation added, retired, or dispositioned against owner and evidence; the compliance statement reflects that walk exactly; gapped obligations listed as candidate nonconformities; the statement’s accuracy is evaluated in the combined nonconformity decision.\nForm submitted with a rationale that dispositions every candidate from both review steps; worksheet attached; the not-taken branch is prunable because the taken branch fully describes the remaining corrective-action work.","kind":"decision","label":"Assess nonconformities","performedBy":{"primitives":["coach-query-data","coach-workflow-scan","coach-document-upload","coach-item-update","coach-item-create","coach-items-link","coach-form-fill"]}},"id":"assess-nonconformities"},{"data":{"controls":["UC-AI-24","UC-AI-13"],"description":"Agent raises one tracked corrective action per nonconformity, routes it to an owner, and tracks it to closure or a dated carry-forward; AI Product Owner approves each closure once evidence is attached","instructions":"**Objective** — Convert every confirmed nonconformity into a corrective action with a named owner, root cause, and target date, tracked to closure with re-checked evidence, so the quality management system's corrective-action procedure is demonstrably operated and no obligation gap stays open without accountability.\n\n**Inputs**\n- The disposition worksheet and rationale: each nonconformity, its class, and the procedure, objective, obligation, or policy commitment it attaches to.\n- The corrective-action procedure from the quality manual (root cause, action, verification, closure authority) and the corrective-action log.\n- The record each nonconformity attaches to — a quality manual or procedure Policy item, an obligation Control item, or a data policy Policy item.\n\n**Procedure**\n1. Create one Issue per nonconformity — `issue_type: deficiency` for quality system and policy communication failures, `issue_type: exception` for obligation gaps — with `source: self_assessment`, `issue_owner`, `target_remediation_date`, root cause in `description`, and the corrective action in `remediation_plan`. One nonconformity, one Issue; batching hides misses.\n2. Link each Issue to the record it remediates and to the anchor Process item, so the open action shows on the procedure, obligation, or policy itself.\n3. Have each participating owner accept the action through native approval and record the committed date in the result; escalate non-acceptance through the AI Product Owner — an unaccepted action is still an open nonconformity.\n4. Track to closure: attach arriving evidence to the remediated record, re-perform the failed check, and only then close the Issue with its `actual_remediation_date`; anything still open at reporting carries a named owner and date.\n\n**Record in AssureSwarm**\n- Create one Issue per nonconformity linked to its Policy or Control item and to the anchor Process item (item create; Issue ↔ Policy, Issue ↔ Control, Issue ↔ Process relationships).\n- Record each owner’s acceptance through native approval and the committed date in the result; attach closure evidence to the remediated item and update each Issue through to closed (document upload; item update).\n- Append every action to the corrective-action log on this step (step document).\n\n**Exit criteria** — Every nonconformity exists as an accepted, dated Issue linked to its record and the anchor; closed Issues carry re-checked evidence; open Issues carry an owner and date; the AI Product Owner approves each closure; the corrective-action log is current.","label":"Raise and track corrective actions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-form-create","coach-notify","coach-item-update","coach-document-upload"]}},"id":"raise-and-track-corrective-actions"},{"data":{"description":"Automatically assemble the cycle report, archive its evidence and carry forward open items under the preceding decisions and closure approvals.","instructions":"**Objective** — Assemble a self-contained evidence pack and a cycle report the AI Product Owner and the AI governance body can act on — what changed in the customer data-use and output-rights policies, whether customers acknowledged them, how the quality management system performed, what the compliance statement now says, and who owns every open item — then archive the record and schedule the next run, so the prior policy and nonconformity decisions and corrective-action approvals authorize automatic closure.\n\n**Inputs**\n- Every artifact produced this cycle: the scope note; the policy comparisons, change logs, and approvals; the materiality memo and, where taken, the notice log and acknowledgement record; the quality system review record; the roles worksheet, obligations walk-through, and compliance statement; the disposition worksheet and corrective-action log.\n- The current state of the typed records — the data policy, quality manual, and procedure Policy items, the obligation Control items, and the corrective-action Issues (with their owners and dates), plus the customer opt-outs and deletion requests handed to fulfilment.\n- The prior cycle's report and dashboard, for trend comparison.\n- The records-retention schedule and archive location (ISO/IEC 42001 Clause 7.5; EU AI Act Article 18 where the organization is a provider), the annual cadence, and the semiannual AIUC-1 E012 checkpoint calendar.\n\n**Procedure**\n_Items 5–8 automatically record closure under the preceding authorized decisions; no additional approval is requested._\n1. Index the pack by evidence area — data policies and acknowledgements (AIUC-1 A001, A002), quality management system (E013), regulatory compliance documentation (E012), and corrective actions — so the report's structure is the evidence's structure.\n2. Test the pack against re-performance: could a reader holding only this pack reconstruct the policy changes, notice decision, acknowledgement rate, effectiveness verdict, obligations coverage, and each disposition? An external reference fails that bar — pull the artifact in.\n3. Build the cycle dashboard: policy versions in force, acknowledgement rate, quality objectives met, procedures conforming, obligations evidenced, and corrective actions open and overdue, each against the prior cycle.\n4. Draft the cycle report: what changed in each area, what remains open with its owner and date, and what the next semiannual checkpoint must pick up. Spot-check every figure against its source artifact.\n5. Confirm the cycle is closable: both data policies published and, where required, acknowledged; the quality system review verdict recorded; the compliance statement current; every nonconformity closed with evidence or open with an owner and date. An unowned open item does not close — it escalates.\n6. Export the full workflow record — every node's evidence, decisions, and rationales — and archive it with the pack, tagged with the cycle date, mode, and policy versions, and linked to the anchor Process item. Verify retrievability by opening the archived copy; later corrections are dated addenda, never edits.\n7. Carry forward every open corrective action and customer request as a named input to the next run, with owner and date.\n8. Schedule the next semiannual checkpoint and annual cycle, set `Policy.next_review_date` on both data policies and the quality manual, and notify the AI Product Owner, AI Governance Lead, and each obligation owner of the dates. The prior substantive decisions and corrective-action approvals remain linked to the automatic closure record.\n\n**Record in AssureSwarm**\n- Attach the indexed evidence pack to this step (step documents) and build the cycle dashboard (dashboard create).\n- Record the cycle report on the step with each open item's owner and due date, referencing the Policy, Control, and Issue items it reports on.\n- Export and archive the workflow record, linking the archived pack to the anchor Process item (workflow export; document upload; item relationship).\n- Carry each open action forward as an Issue linked to the anchor Process item (`issue_owner`, `target_remediation_date`) as a named input to the next run (item create; Issue ↔ Process relationship).\n- Set `Policy.next_review_date` on the data policies and quality manual (item field update); record the next dates on this step and send the schedule notice.\n\n**Exit criteria** — Pack passes the re-performance test with no external references and is verified retrievable from the archive; dashboard covers every area against the prior cycle; every figure traces to an attached artifact; every open thread exists as a carry-forward Issue with a named owner and date; next checkpoint and cycle scheduled with review dates set; the prior decisions and corrective-action approvals remain linked to the automatic closure record.","label":"Compile cycle report and evidence pack","performedBy":{"primitives":["coach-query-data","coach-dashboard-create","coach-document-upload","coach-workflow-export","coach-item-create","coach-items-link","coach-item-update","coach-notify"]},"requiredApprovals":0},"id":"compile-cycle-report-and-evidence-pack"}],"sourceTemplateId":"workflow-library:grc-ai-service-data-policy-quality-management-cycle"}