{"description":"Standing operator workflow for the hardware and system maintenance desk, anchored on the existing Process item \"Hardware & System Maintenance\" (process_type: it_general_control, process_owner: the maintenance coordinator, frequency: monthly): each monthly cycle runs as one workflow instance on that Process — enrich the standing Process, never create a duplicate desk. It schedules and approves maintenance, repair, and replacement, routes execution across on-site, off-site, and nonlocal (remote) sessions with the right tool, personnel, and connection controls, and verifies security controls after every completion. The governing requirements are the linked Control items UC-CONFIG-07 and UC-CONFIG-08 (framework nist-800-53, nist-csf-2; MA family). In scope: scheduling, approval, execution, and post-work verification of maintenance, repair, and replacement for in-scope hardware and systems across on-site, off-site, and nonlocal sessions, plus support/spare-parts tracking and end-of-life disposition. Out of scope: procurement of net-new assets and software patch/change management, which run in their own workflows. No upstream workflow feeds this desk; it consumes its own maintenance queue, open work requests, the asset/hardware register export (there is no native Asset item type — the register is uploaded at the first step), and manufacturer maintenance schedules, and it seeds its own next cycle at close. Named deliverables: an approved maintenance schedule (XLSX), per-mode execution-evidence logs, a post-maintenance security-control verification report, a support/spare-parts disposition status, a maintenance-desk health dashboard, and a closure record — with exceptions, control drift, and gaps promoted to Issue items and a corrective-action register. Downstream, end-of-life \"remove from service\" dispositions hand off to the equipment-disposal / media-destruction workflow, and any out-of-scope drift found during post-maintenance verification hands off to the incident or change-management workflow.","edges":[{"id":"e-route-maintenance-execution-mode-control-tools-and-personnel-onsite","label":"On-site","source":"route-maintenance-execution-mode","target":"control-tools-and-personnel-onsite","whenValue":"on_site"},{"id":"e-route-maintenance-execution-mode-sanitize-and-transfer-offsite","label":"Off-site","source":"route-maintenance-execution-mode","target":"sanitize-and-transfer-offsite","whenValue":"off_site"},{"id":"e-route-maintenance-execution-mode-control-nonlocal-maintenance-session","label":"Remote session","source":"route-maintenance-execution-mode","target":"control-nonlocal-maintenance-session","whenValue":"remote_session"},{"id":"e-control-tools-and-personnel-onsite-classify-queue-health","source":"control-tools-and-personnel-onsite","target":"classify-queue-health"},{"id":"e-sanitize-and-transfer-offsite-classify-queue-health","source":"sanitize-and-transfer-offsite","target":"classify-queue-health"},{"id":"e-control-nonlocal-maintenance-session-classify-queue-health","source":"control-nonlocal-maintenance-session","target":"classify-queue-health"},{"id":"e-classify-queue-health-log-corrective-actions","label":"Gaps","source":"classify-queue-health","target":"log-corrective-actions","whenValue":"gaps_identified"},{"id":"e-classify-queue-health-close-and-archive","label":"Healthy","source":"classify-queue-health","target":"close-and-archive","whenValue":"healthy"},{"id":"e-log-corrective-actions-close-and-archive","source":"log-corrective-actions","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-CONFIG-07","UC-CONFIG-08"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-controlled-hardware-system-maintenance","contentDigest":"sha256:4ab7949ada41be689fc596040ac532f7fecc93bb91772f5a347654ffd5afcf03","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:4ab7949ada41be689fc596040ac532f7fecc93bb91772f5a347654ffd5afcf03","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-controlled-hardware-system-maintenance"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-controlled-hardware-system-maintenance","source":"coworkcanvas-gallery","standards":["nist-800-53","nist-csf-2"],"teams":["it","facilities"]},"name":"Controlled Hardware & System Maintenance","nodes":[{"data":{"decisionField":"execution_mode","description":"Approve the maintenance schedule against manufacturer and organizational requirements and select the appropriate on-site, off-site or remote control set.","formData":{"fields":[{"key":"execution_mode","label":"Execution Mode","options":[{"label":"On-site, performed in place","value":"on_site"},{"label":"Off-site, hardware leaves the facility","value":"off_site"},{"label":"Nonlocal remote maintenance session","value":"remote_session"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Approve the maintenance schedule against manufacturer and organizational requirements and select the appropriate on-site, off-site or remote control set.\n\n**Inputs**\n- The maintenance queue, open work requests, and the asset/hardware register — this workflow's own initial inputs; there is no upstream workflow handoff to consume. The register is uploaded to this step as a CSV/XLSX export (PBC) — there is no native Asset item type, so asset condition, last-serviced, and EOS/EOL live as columns in that upload, not as items.\n- Manufacturer-specified maintenance intervals, warranty terms, and end-of-support dates for each in-scope asset — columns of the same register export, with manufacturer spec sheets attached to this step as needed.\n- The organization's maintenance Policy item (policy_type, policy_owner, review_frequency, next_review_date; the governing document attaches to the Policy) and the approved-vendor Vendor items (category: hardware_supplier / managed_services, tier, business_owner, monitoring_status, contract_end_date).\n- The prior cycle's carry-forward: the open corrective-action Issue items still linked to the anchor Process, plus the prior cycle's closure-record document on its close-and-archive step (upcoming scheduled maintenance and pending support/spare-parts renewals are listed there — no native item type).\n- The governing Control items UC-CONFIG-07 / UC-CONFIG-08 (framework nist-800-53, nist-csf-2; MA family) linked to the anchor Process.\n\n**Procedure**\n_This checkpoint absorbs “Compile and approve maintenance schedule”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Compile and approve maintenance schedule: Establish why the cycle is running: the routine monthly queue review, or a specific maintenance/repair/replacement event triggered by a fault, request, or manufacturer notice. Record the trigger on the operating record.\n2. Pull manufacturer intervals, warranty terms, and organizational requirements for each in-scope asset, and reconcile them against the current queue and each asset's condition and last-serviced date to compute what is due, overdue, or already in flight.\n3. For each item, draft the proposed action (maintenance / repair / replacement), the proposed date and window, the assigned maintenance person or vendor, and the intended execution mode (on-site in place, off-site transfer, or nonlocal remote session). Cite the manufacturer reference or organizational requirement each item satisfies.\n4. Capture each scheduled action as a row in the schedule document — asset, proposed action, date/window, assigned person or vendor, execution mode, and the driver it satisfies — so the schedule is traceable line by line. There is no native WorkOrder/Asset item type, so scheduled-maintenance lines are document rows, not items.\n5. Compile the proposed schedule into one document for approval; flag any item with no clear manufacturer/organizational driver for the coordinator to accept or drop.\n\n**Decision criteria**\n- **on_site** — Work is performed in place at the facility; hardware does not leave and no remote connection is opened. The governing controls are tool/media inspection and maintenance-personnel authorization/escort (NIST 800-53 MA-3, MA-5).\n- **off_site** — Hardware must physically leave the facility for service. Sanitization before removal and chain-of-custody control the risk that data leaves on the equipment (NIST 800-53 MA-2, MA-4).\n- **remote_session** — Maintenance is performed nonlocally by personnel over a network connection. Approved-connection, strong authentication, session recording, and termination controls apply (NIST 800-53 MA-4).\n- When a batch spans modes, pick the dominant mode for routing and split the minority items into their own case rather than forcing one control set onto all.\n\n**Record in AssureSwarm**\n- Compile the proposed schedule as an XLSX document and attach it to this step (coach-document-upload) — one row per action carrying the asset, proposed action, date/window, assigned person or vendor, execution mode, and the manufacturer/organizational driver it satisfies. Scheduled-maintenance lines have no native Asset or WorkOrder item type, so they live as rows in this document, not as items.\n- Read source data with coach-query-data: the prior cycle's open carry-forward Issue items and closure-record document on the anchor Process, the governing Control items UC-CONFIG-07 / UC-CONFIG-08, the maintenance Policy item (policy_owner, review_frequency, next_review_date), and the approved-vendor Vendor items (category, tier, monitoring_status, contract_end_date).\n- The asset/hardware register, manufacturer spec sheets, work-request queue, and policy/vendor extracts are uploaded to this step as PBC evidence (coach-document-upload) — the register has no native Asset item type.\n- Group the approved items by execution mode with coach-query-data and, for each group, compile the applicable control requirements listed above.\n- Scan open workflows (coach-workflow-scan) to confirm no duplicate maintenance case already covers an item.\n- Draft the routing recommendation with a reason per group and attach it (coach-document-upload) for the coordinator.\n- Submit the SELECT field `execution_mode` (on_site / off_site / remote_session) on this decision node's form.\n- Capture the decision rationale and evidence references in the step result, and the approver in the native approval record.\n\n**Exit criteria**\n- Every in-scope item has a scheduled-maintenance record citing its driver and execution mode; the maintenance coordinator has approved the schedule item by item (adjusting date, vendor, or mode as needed); no item is authorized to proceed without approval.\n- The `execution_mode` routing selector is submitted and the step result contains a rationale; the two unused branches are prunable; the batch is routed to exactly one control set.","kind":"decision","label":"Route maintenance execution mode","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-workflow-scan"]}},"id":"route-maintenance-execution-mode"},{"data":{"description":"Agent inspects maintenance tools and media and checks personnel against the approved list; human confirms controls are satisfied before on-site work starts","formData":{"fields":[{"key":"servicing_organization","label":"Servicing organization and dispatch reference","required":false,"type":"text"},{"key":"technician_names_and_identification","label":"Name and government-ID type of every technician attending","required":false,"type":"textarea"},{"key":"tools_and_media_manifest","label":"Every tool, medium and diagnostic device to be brought on site","required":false,"type":"textarea"},{"key":"diagnostic_network_connection","label":"Network connectivity the diagnostic equipment requires","options":[{"label":"No network connection","value":"no_connection"},{"label":"Direct connection to the maintained system only","value":"maintained_system_only"},{"label":"Connection to the wider corporate network","value":"corporate_network"},{"label":"Outbound or vendor remote access","value":"external_remote_access"}],"required":false,"type":"select"},{"key":"technician_screening_confirmed","label":"Every attending technician has passed the contracted background screening","required":false,"type":"checkbox"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Ensure on-site maintenance proceeds only under controlled conditions: every tool and medium brought in is approved and inspected, and every technician is either approved or escorted.\n\n**Inputs**\n- The approved schedule items routed to on-site execution (from the execution-mode decision).\n- The list of tools, media, and diagnostic equipment the maintenance personnel intend to bring on site, declared on this step's form by the servicing organization before the visit.\n- The current list of individuals approved to perform maintenance on the organization's systems, and the tool/media pre-approval list — both uploaded to this step as PBC evidence (no native item type for either list).\n\n**Missing-input gate** — Before any form request below, inspect the existing source records, reports and correspondence. Reuse every established fact and record its source. Send a form only when a listed fact remains genuinely unresolved and the named respondent is outside the complete roster of people executing or approving any checkpoint in this workflow. If the respondent is on that roster, record their contribution in native results and approvals. Ask only the unresolved fields; leave known, unasked or inapplicable fields optional and blank. Skip the form entirely when no missing facts remain. Attach evidence documents and record sign-off through native approval. References below to form answers or completion also accept the existing authoritative record or native participant contribution.\n\n**Procedure**\n1. Send this step's form to the servicing organization's dispatcher at least one working day before the visit and reconcile each declared tool, medium, and diagnostic device against the pre-approval list; hold anything not pre-approved for coordinator sign-off before it enters. An undeclared tool arriving on the day is treated as not pre-approved.\n2. Inspect each tool and medium for improper modification and for malicious code (NIST 800-53 MA-3(2)); log the inspection result and the inspector as a row in the inspection log.\n3. Check each maintenance person against the approved-personnel list (NIST 800-53 MA-5) and against the declared attendee list. For anyone not on the list, assign a technically qualified escort for the full duration of the visit and record the escort assignment as a row in the log.\n4. Where the declared diagnostic equipment needs corporate-network or vendor remote access, route it through the nonlocal-session controls rather than treating it as a plain on-site visit.\n5. Compile the tool-inspection and personnel-authorization log for review.\n\n**Record in AssureSwarm**\n- Attach the tool-inspection and personnel-authorization log to this step (coach-document-upload) — one row per tool/medium (inspection result, inspector) and per technician (on approved list? escort assigned?). There is no native inspection or escort item type, so these are rows in the log.\n- The form on this step, answered by the servicing organization’s dispatcher, captures only its dispatch reference, attending technician identities and identification, complete tools/media/diagnostic manifest, required network connectivity and contracted screening status. The approved schedule supplies the visit date and the trusted response supplies contact provenance — it is the declared baseline the inspection and personnel checks reconcile against.\n- Where a tool/medium fails inspection or an unauthorized person is found on site, create an Issue (coach-item-create — issue_type: exception, source: self_assessment, severity, identified_date, issue_owner) and link it (coach-items-link) to the anchor Process so the exception is tracked to remediation.\n- Read the approved-personnel list, the tool/media pre-approval list (both uploaded to this step), and the governing Control items with coach-query-data.\n\n**Exit criteria** — The complete manifest is evidenced before the visit; every tool and medium passed inspection or was rejected; every technician is on the approved list or has a recorded escort; the coordinator has authorized on-site work to begin.\n\n**Form recipient** — The servicing organization's dispatcher supplies only provider dispatch reference; attending technician identity and identification type; tools, media and diagnostic-device manifest; diagnostic network needs; contracted screening status only when this gate permits the assigned form. The workflow executor records their own analysis in the step result.","label":"Control tools and personnel on site","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"control-tools-and-personnel-onsite"},{"data":{"description":"Agent drives sanitization and chain-of-custody for hardware leaving the facility; human verifies sanitization before release","instructions":"**Objective** — Guarantee no organizational data leaves the facility on hardware sent out for service, by sanitizing each item to its classification and controlling the custody chain of everyone who removes it.\n\n**Inputs**\n- The approved schedule items routed to off-site execution (from the execution-mode decision).\n- Each item's data classification and the organization's sanitization method/standard for that classification (e.g., NIST SP 800-88 clear/purge/destroy).\n- The approved maintenance-personnel/courier list and any active legal hold or retention flags on the affected media — the classification extract, sanitization standard, and legal-hold flags are uploaded to this step as PBC evidence.\n\n**Procedure**\n1. Determine each item's data classification and the required sanitization method; confirm no legal hold or retention requirement blocks removal before touching the media.\n2. Drive sanitization per the method for the classification, and record a sanitization row capturing method, performer, timestamp, and verification result (NIST 800-53 MA-2). Where media cannot be sanitized (e.g., embedded, failed), record the exception and the compensating control (media removal/retention on site).\n3. Check the person or courier removing the equipment against the approved-personnel list; assign an escort if not approved. Record chain-of-custody — item, releasing party, recipient, destination vendor, and timestamp — as rows in the same log.\n4. Compile the sanitization and chain-of-custody log for review.\n\n**Record in AssureSwarm**\n- Attach the sanitization and chain-of-custody log to this step (coach-document-upload) — one row per item (method, performer, timestamp, verification result) and per custody transfer (releasing party, recipient, destination vendor, timestamp). Sanitization and custody records have no native item type, so they are rows in this log.\n- Where media cannot be sanitized, create an Issue (coach-item-create — issue_type: exception, source: self_assessment, severity, identified_date) documenting the exception and its compensating control, and link it (coach-items-link) to the anchor Process.\n- Read data classifications, the destination Vendor items (category: hardware_supplier), and legal-hold/retention flags with coach-query-data.\n\n**Exit criteria** — Each item is sanitized and verified clean (or has a recorded exception with a compensating control); chain-of-custody is complete end to end; the coordinator has approved release off site.","label":"Sanitize and transfer off-site","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"sanitize-and-transfer-offsite"},{"data":{"description":"Agent enforces approved-connection and strong-authentication requirements and records the session; human confirms scope and termination when work completes","instructions":"**Objective** — Ensure every nonlocal (remote) maintenance session runs over an approved, strongly authenticated, recorded connection and is terminated at completion, so remote diagnostic/administrative access is never left standing.\n\n**Inputs**\n- The approved schedule items routed to remote-session execution (from the execution-mode decision).\n- The approved-connection list (uploaded to this step) and the strong-authentication (MFA) requirement for maintenance accounts, which is carried by the governing Control item (UC-CONFIG-08; NIST 800-53 MA-4).\n- The vendor/technician identity (the servicing vendor is a Vendor item — category: managed_services / professional_services) and the specific systems and actions authorized for the session.\n\n**Procedure**\n1. Confirm the proposed remote-access path is on the approved-connection list and that strong authentication is enforced for the maintenance account before the session opens (coach-query-data). Reject any ad-hoc or unapproved path.\n2. Open a nonlocal-session row capturing vendor, technician identity, approved connection method, start time, and the systems to be accessed; start session recording.\n3. Monitor the live session for scope — confirm only authorized systems and actions are touched — and note any anomalous or out-of-scope activity for follow-up.\n4. Terminate the connection at completion, capture the end time and the session-recording reference, and confirm no standing access or persistent credential was left behind.\n\n**Record in AssureSwarm**\n- Attach the session log and recording reference to this step (coach-document-upload) — vendor, technician, approved connection, start/end times, systems accessed, and the recording pointer. The nonlocal-session record has no native item type, so it lives as rows/fields in this log.\n- Where activity is out of scope or anomalous, create an Issue (coach-item-create — issue_type: exception or finding, source: self_assessment, severity, identified_date) and link it (coach-items-link) to the anchor Process for follow-up.\n- Verify the approved connection and the servicing Vendor item with coach-query-data.\n\n**Exit criteria** — The session used an approved, strongly authenticated connection; it was fully recorded and stayed within authorized scope; it was terminated with no residual access; the coordinator has confirmed all four.","label":"Control nonlocal maintenance session","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"control-nonlocal-maintenance-session"},{"data":{"decisionField":"queue_health","description":"Judge return-to-service security controls, maintain/replace/remove support dispositions and the maintenance desk’s tolerance breaches from the completed work.","formData":{"fields":[{"key":"queue_health","label":"Queue Health","options":[{"label":"Healthy, within tolerance","value":"healthy"},{"label":"Gaps identified","value":"gaps_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge return-to-service security controls, maintain/replace/remove support dispositions and the maintenance desk’s tolerance breaches from the completed work.\n\n**Inputs**\n- The completed maintenance from whichever execution branch ran: the on-site tool/personnel record, the off-site sanitization/custody record, or the nonlocal-session record.\n- The pre-maintenance configuration and security-control baseline for each completed item, uploaded to this step as a PBC export — there is no native ConfigurationBaseline item type.\n- The expected firmware/patch level and hardening settings for each asset.\n- The completed maintenance from whichever execution branch ran (on-site, off-site, or nonlocal), giving this cycle's repair and failure history.\n- Vendor support contracts (the servicing Vendor items — contract_end_date, monitoring_status), spare-parts lead times, and end-of-support / end-of-life dates for in-scope hardware (EOS/EOL live as columns of the asset-register upload — no native Asset type).\n- The organization's defined support/spare-parts timeframe limits and each asset's risk rating.\n\n**Procedure**\n_This checkpoint absorbs “Verify post-maintenance security controls”, “Track support and spare parts”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Verify post-maintenance security controls: Pull the pre-maintenance baseline for each completed item and compare it against the post-maintenance state (coach-query-data): endpoint agents, logging, access controls, encryption, and required services.\n2. Flag any control that was disabled, reconfigured, or removed during the maintenance window and not explicitly restored, and any firmware, patch-level, or setting drift the work introduced (NIST 800-53 MA-2, NIST CSF 2.0 PR.PS-03).\n3. For each item, record a verification row documenting the comparison result (pass / drift found) against the execution branch that ran, so verification is traceable to the work that caused it.\n4. Compile the post-maintenance verification report, listing any unrestored control with the item it belongs to and the owner who must restore it.\n5. Track support and spare parts: Query support contracts, spare-parts lead times, and EOS/EOL dates for in-scope hardware (coach-query-data); flag any item whose support or spare-parts timeframe has lapsed or is approaching its defined limit (NIST 800-53 MA-6).\n6. Compile repair-frequency and failure history for items serviced this cycle to identify hardware degrading faster than its risk tolerance allows (e.g., a device requiring a third repair in the period).\n7. For each flagged item, draft a risk-based disposition — renew/obtain support, expedite spare parts, replace, or remove from service — as a row in the support/spare-parts status document (no native WorkOrder/Asset item type).\n8. Attach the support/spare-parts status and disposition recommendations for review.\n\n**Decision criteria**\n- **healthy** — Every metric is within tolerance: schedule adherence at target, no overdue/unscheduled items, no failed tool or personnel inspection, all post-maintenance controls verified restored, support/spare-parts timeframes within limits, and no unresolved risk disposition. Routes straight to close.\n- **gaps_identified** — Any breach exists in schedule adherence, tool/personnel inspection, post-maintenance control verification, support/spare-parts timeframe, or risk disposition. Routes through corrective-action logging before close.\n- A single control-verification failure with security impact is sufficient to select `gaps_identified`, regardless of other metrics.\n\n**Record in AssureSwarm**\n- Attach the post-maintenance verification report to this step (coach-document-upload) — one row per completed item (baseline vs post-maintenance comparison, pass/drift, owner). Verification records have no native item type, so they are rows in this report.\n- For each unrestored or drifted control, create an Issue (coach-item-create — issue_type: deficiency, source: self_assessment, severity, issue_owner, identified_date, target_remediation_date) and link it (coach-items-link) to the affected Control item and to the anchor Process.\n- Pull the pre-maintenance baselines (uploaded to this step — no native ConfigurationBaseline type) with coach-query-data.\n- Attach the support/spare-parts status document (coach-document-upload) — EOS/EOL dates, contract coverage, spare-parts lead times, repair/failure history, and a maintain/replace/remove disposition row per flagged asset. Dispositions have no native item type, so they live as rows here.\n- Where a support or spare-parts timeframe has lapsed and the coordinator formally accepts it, register the waiver as an Issue (coach-item-create — issue_type: policy_exception, exception_approver, exception_expiry_date) and link it (coach-items-link) to the governing Control item (UC-CONFIG-07 / UC-CONFIG-08, MA family) and the anchor Process.\n- Where a lapsed-support or repeat-failure exposure warrants it and a matching Risk item exists in the register, update that Risk (coach-item-update — residual_rating, and treatment: accept where the exposure is knowingly accepted).\n- Pull contract, EOS/EOL, and risk-rating data — and the servicing Vendor items — with coach-query-data.\n- Compute cycle metrics with coach-query-data: schedule adherence, overdue/unscheduled items, failed inspections, unverified post-maintenance controls, lapsed support/spare-parts timeframes, and unresolved dispositions — reading the verification report and the support/spare-parts status.\n- Build a maintenance-desk health dashboard (coach-dashboard-create) showing each metric against its threshold and the trend versus prior cycles.\n- List every breach with its owner and the evidence behind it, and attach the readiness summary (coach-document-upload).\n- Submit the SELECT field `queue_health` (healthy / gaps_identified).\n- Capture the decision rationale and evidence references in the step result, and the approver in the native approval record.\n\n**Exit criteria**\n- Every completed item has a verification record; all disabled or drifted controls are either restored or logged as an open gap with an owner; the coordinator has confirmed controls are effective before return to service.\n- Support and spare-parts timeframes are within defined limits or covered by a recorded policy_exception Issue; every flagged item has a maintain/replace/remove disposition confirmed commensurate with risk by the coordinator.\n- The `queue_health` form is submitted with rationale; the dashboard and readiness summary are attached; the unused branch is prunable.","kind":"decision","label":"Classify queue health","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-item-update","coach-dashboard-create"]}},"id":"classify-queue-health"},{"data":{"description":"Agent converts each identified gap into an owned corrective action; human confirms every gap is owned, dated, and escalated where required","instructions":"**Objective** — Convert every gap identified at the queue-health review into an owned, tracked corrective action, so nothing degrades the maintenance desk unaddressed.\n\n**Inputs**\n- The readiness summary and breach list from the queue-health classification (this node runs only on the gaps_identified branch).\n- The driving metric or maintenance/verification/disposition record behind each gap, and the roster of accountable owners.\n\n**Procedure**\n1. Parse the readiness summary to list each gap with its root cause and the metric or item that surfaced it.\n2. Create an Issue per gap capturing root cause, named owner, due date, and interim mitigation, and link it to the driving Control item or maintenance evidence.\n3. Raise desk-level improvement Issues for systemic gaps — a chronically late vendor, an unreliable spare-parts source, a recurring inspection failure — and escalate any control failure with security impact to the accountable owner.\n4. Compile the corrective-action register for confirmation.\n\n**Record in AssureSwarm**\n- Create an Issue per gap (coach-item-create — issue_type: finding or deficiency, source: self_assessment, severity, root_cause, issue_owner, identified_date, target_remediation_date, remediation_plan) and link it (coach-items-link) to the anchor Process and, where the gap is a control failure, to the affected Control item.\n- Attach the corrective-action register (XLSX) to this step (coach-document-upload).\n\n**Exit criteria** — Every gap has a named owner and due date; escalations are routed to the accountable owner; the coordinator has confirmed nothing is left untracked.","label":"Log corrective actions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"log-corrective-actions"},{"data":{"description":"Automatically archive the authorized cycle record and carry open actions into the next cycle.","instructions":"**Objective** — Automatically preserve the authorized cycle record and its carry-forward actions after the preceding decision.\n\n**Inputs**\n- The healthy path (direct from the queue-health decision) or the completed corrective-action register (from the corrective-actions node) — whichever path reached this sink.\n- The full cycle operating record: schedule, execution logs, verification report, support/spare-parts status, and any corrective actions.\n- The designated evidence repository, its retention controls, and the control execution log.\n\n**Procedure**\n1. Export the full operating record (coach-workflow-export) and archive it in the designated evidence repository under retention controls; record the archive location and reference.\n2. Carry forward open items to the next cycle: leave the corrective-action Issues OPEN on the anchor Process (they are not re-created — the next cycle reads them as input), and list upcoming scheduled maintenance and pending spare-parts/support renewals as rows in the closure record, since neither has a native item type.\n3. Update the control execution log with the cycle result and key metrics, and confirm the next monthly queue review is scheduled.\n4. Attach the closure record summarizing outcome, archive reference, and carry-forward list.\n\n**Record in AssureSwarm**\n- The completed workflow instance is the cycle's audit trail; export the full operating record (coach-workflow-export) and attach the export to this step (coach-document-upload), recording the external evidence-repository archive location and retention reference in the closure record.\n- Carry-forward: the open corrective-action Issue items remain on the anchor Process (no re-create); upcoming maintenance and pending renewals are rows in the closure record (no native item type).\n- Attach the closure record (PDF/DOCX) summarizing outcome, archive reference, and carry-forward list (coach-document-upload).\n\n**Exit criteria** — The archived record is immutable and retrievable; the next review is scheduled; nothing remains open without a tracked owner; the authorized cycle record is complete.","label":"Close and archive","performedBy":{"primitives":["coach-workflow-export","coach-item-create","coach-items-link","coach-document-upload"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:controls-controlled-hardware-system-maintenance"}