{"description":"Runs as a standalone per-release gate cycle — one workflow instance per new AI system or substantial modification. The schema has no native AI System item type, so the instance links (Item relationship) to the existing Control items it operates (UC-AI-04/05/06/07/09; framework eu-ai-act|iso-42001, domains ai_governance) and to the ai_governance Risk it mitigates, and all cycle evidence attaches to its steps. It consumes the AI system inventory profile and the enterprise responsible-AI objectives (Policy items) upstream; the release board then approves those objectives and the per-system requirements before build, governs training, validation, and test data with bias mitigation, executes the pre-deployment impact assessment and EU AI Act risk classification, applies the high-risk conformity obligations where they trigger, assembles Annex IV-grade technical documentation, and records verification-and-validation results and the deployment sign-off. Named deliverables: the risk-classification decision, the pre-deployment impact-assessment report, the Annex IV technical-documentation package, the verification-and-validation report, and the recorded sign-off. Retraining and substantial changes re-enter the same gate as a fresh instance (a self-loop, no downstream handoff).","edges":[{"id":"e-specify-responsible-ai-objectives-and-requirements-assess-and-classify-deployment-impact","source":"specify-responsible-ai-objectives-and-requirements","target":"assess-and-classify-deployment-impact"},{"id":"e-assess-and-classify-deployment-impact-apply-high-risk-conformity-requirements","label":"High-risk","source":"assess-and-classify-deployment-impact","target":"apply-high-risk-conformity-requirements","whenValue":"high_risk"},{"id":"e-assess-and-classify-deployment-impact-verify-and-validate-against-requirements","label":"Standard","source":"assess-and-classify-deployment-impact","target":"verify-and-validate-against-requirements","whenValue":"standard"},{"id":"e-verify-and-validate-against-requirements-deployment-signoff-decision","source":"verify-and-validate-against-requirements","target":"deployment-signoff-decision"},{"id":"e-apply-high-risk-conformity-requirements-deployment-signoff-decision","source":"apply-high-risk-conformity-requirements","target":"deployment-signoff-decision"},{"id":"e-apply-high-risk-conformity-requirements-verify-and-validate-against-requirements","source":"apply-high-risk-conformity-requirements","target":"verify-and-validate-against-requirements"},{"id":"e-deployment-signoff-decision-remediate-and-resubmit","label":"Hold","source":"deployment-signoff-decision","target":"remediate-and-resubmit","whenValue":"hold"},{"id":"e-deployment-signoff-decision-schedule-reassessment-and-change-triggers","label":"Signed off","source":"deployment-signoff-decision","target":"schedule-reassessment-and-change-triggers","whenValue":"sign_off"},{"id":"e-remediate-and-resubmit-schedule-reassessment-and-change-triggers","source":"remediate-and-resubmit","target":"schedule-reassessment-and-change-triggers"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-AI-05","UC-AI-04","UC-AI-09","UC-AI-06","UC-AI-07"],"department":"ai-governance","domains":["reg"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=reg-ai-system-development-data-deployment-gate","contentDigest":"sha256:5491251bf79dd811f94ee4d46bbb88850559c225c54b7beb93a0921b3b428275","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:5491251bf79dd811f94ee4d46bbb88850559c225c54b7beb93a0921b3b428275","schemaVersion":1,"sourceTemplateId":"workflow-library:reg-ai-system-development-data-deployment-gate"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"reg-ai-system-development-data-deployment-gate","source":"coworkcanvas-gallery","standards":["iso-42001","eu-ai-act","aiuc-1"],"teams":["ai-governance","it"]},"name":"AI System Development, Data & Deployment Gate","nodes":[{"data":{"description":"Agent drafts the responsible-AI objectives and the per-system requirement specification before build begins and stages them for design-stage approval; human confirms they are complete and approves the design to proceed to build.","instructions":"**Objective** — Fix, before any build starts, the responsible-AI objectives and the per-system requirement specification the rest of the gate verifies against — what is written here becomes the acceptance criteria at verification and the claims in the technical documentation.\n\n**Inputs**\n- The enterprise responsible-AI objective set — fairness, safety, security, transparency, accountability — and the documented design-and-development process this system will follow (ISO/IEC 42001 A.6.1.2, A.6.2.2). Both live as **Policy items** in the policy library (policy_type: policy/standard, framework: iso-42001|eu-ai-act, domains: ai_governance) with their governing documents attached; the instance links to the ai_governance **Control items** UC-AI-04/05/06/07/09 that carry the framework mapping.\n- The AI system's inventory profile — intended purpose, deployment context, lifecycle stage, trigger type (new build or change re-entry), and prior classification. There is no native AI System item type, so the profile is uploaded to this step as a PBC document; prior gate history is this system's earlier archived workflow instances. For a change re-entry, apply the substantial-modification test of EU AI Act Art. 3(23) to confirm the run's scope (full gate versus a scoped re-check within the pre-determined-change envelope of Art. 43(4)).\n- The sponsoring team's intended-purpose statement and candidate use cases — uploaded to this step (PBC from the sponsoring team).\n- Known regime constraints: the EU AI Act Art. 5 prohibited-practice list, sector rules, data-residency and retention limits (external regulation; the mapping frame is the linked Control items above).\n\n**Procedure**\n1. Screen against prohibitions before anything else: if a candidate use case touches an Art. 5 practice — social scoring, exploitative manipulation of vulnerabilities, untargeted facial-image scraping, emotion inference in workplaces or education outside medical or safety uses — it exits the pipeline here. No requirement engineering rescues a prohibited use.\n2. Instantiate each enterprise objective for this system with an evidence plan: not \"the system shall be fair\" but \"selection-rate ratio across the named attributes at or above 0.8 on the held-out test set, evidenced at verification\". Each objective states its metric, the lifecycle point where it is evidenced — design, data governance, verification, or post-deployment monitoring — and its owner; confirm the objectives are embedded in the documented design-and-development process rather than bolted on.\n3. Write the requirement specification: the intended purpose in one sentence a regulator could quote; use cases explicitly in scope and explicitly out of scope (the out-of-scope list is what makes the later foreseeable-misuse analysis concrete); performance criteria, each with metric, target threshold, and measurement dataset and conditions — accuracy, robustness, latency, or the domain metric that actually matters; and constraints — data constraints, regulatory constraints, prohibited uses, and deployment-context limits such as permitted populations, geographies, and integration points.\n4. Run the verifiability check: for every requirement, name the future evidence that will prove it. A requirement with no measurable test (\"the model should be interpretable\") is rewritten with its measurement or demoted to a design principle — requirements that cannot be evidenced at verification are the leading cause of sign-off holds.\n5. Check internal consistency: no constraint contradicts an in-scope use case; every performance criterion is measurable against the stated purpose; thresholds are plausible given the data constraints. If the team wants a pre-determined-change envelope — the retraining changes that will not count as substantial modification under Art. 43(4) — it must be specified now; it cannot be claimed retroactively.\n6. Compile the design-stage package — objectives with evidence plans, the requirement specification, and the design-process reference — and route it for the board's design-stage approval.\n\n**Record in AssureSwarm**\n- Record the design-stage requirements in the native step result and attach the objectives document and authored requirement specification; capture the board’s sign-off through native approval.\n- Link the workflow instance (Item relationship) to the AI system's governing Control items UC-AI-04/05/06/07/09 and to the ai_governance Risk it operates on, so the gate is visible from the control library.\n- Record the design-stage approval on the step — or the return to the sponsoring team naming the specific gap.\n\n**Exit criteria** — Art. 5 screen documented as clear; every objective carries a metric, an evidence point, and an owner; every requirement is measurable with its future evidence named; the out-of-scope use list exists; design-stage approval recorded before build or data preparation proceeds.","label":"Specify responsible-AI objectives and system requirements","performedBy":{"primitives":["coach-form-fill","coach-document-upload","coach-items-link"]}},"id":"specify-responsible-ai-objectives-and-requirements"},{"data":{"decisionField":"risk_classification","description":"Resolve this system's regulatory risk classification — the release board owns the call, chaired by the AI Governance Lead — because the classification determines whether the EU AI Act high-risk conformity obligations apply before verification or the cycle proceeds directly to verification and validation.","formData":{"fields":[{"key":"risk_classification","label":"Deployment risk classification","options":[{"label":"High-risk — meets an EU AI Act high-risk criterion or equivalent heightened-risk threshold","value":"high_risk"},{"label":"Standard — does not meet a high-risk criterion","value":"standard"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nResolve this system's regulatory risk classification — the release board owns the call, chaired by the AI Governance Lead — because the classification determines whether the EU AI Act high-risk conformity obligations apply before verification or the cycle proceeds directly to verification and validation.\n\n**Decision criteria**\nInputs and preparation before selecting the branch:\nThe requirement specification and intended purpose — Art. 10(3) judges quality \"in view of the intended purpose\", so quality scores mean nothing without it.\n- Dataset manifests from the engineering team: sources, acquisition dates, licensing or consent basis, row counts, and the split definition across training, validation, and test.\n- The data-governance and bias policy: quality thresholds, bias metrics and thresholds, and the protected-attribute list — a **Policy item** in the policy library (policy_type: standard/policy, domains: ai_governance) with its governing document attached.\n- ISO/IEC 42001 Annex A.7 data controls (provenance A.7.5, quality A.7.4, preparation A.7.6) as the control frame.\n\n*Agent retrieval, preparation and filing absorb “Govern training, validation, and test data”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Govern training, validation, and test data: Establish that the training, validation, and test datasets are governed to EU AI Act Art. 10 grade — provenance recorded, preparation documented, quality scored against the intended purpose, bias examined and mitigated — before the impact assessment or verification relies on them.\n\n2. Record provenance for every dataset: source, acquisition method, selection criteria, collection period, and the licensing or consent basis — for personal data, the original collection purpose, because repurposing consent-bound or scraped data is a legal determination, not an engineering one. An unlicensed or unconsented dataset stops here.\n3. Document preparation per Art. 10(2)(c): labelling methodology and labeller qualifications — where labels are judgment calls, measure inter-annotator agreement and relabel below the policy floor; cleaning rules; enrichment or synthetic augmentation with its generator documented; and the formulated assumptions the data is supposed to satisfy (Art. 10(2)(d)).\n4. Verify split integrity: no record overlap across the three sets (check at hash level, and near-duplicate level where records are documents or images); no temporal leakage on time-dependent tasks (test period strictly after training period); no leakage through derived features. Seal the test set here — identity and hash recorded — and require anyone who tuned against it to declare it, because a tuned-on test set voids verification independence.\n5. Score quality against the intended purpose per Art. 10(3): relevance of features and records to the deployment task; representativeness — compare dataset composition to the deployment population across the geographic, contextual, and behavioural settings Art. 10(4) requires, quantifying gaps as population share versus dataset share per segment; completeness and error levels — missingness per critical field and label error rate on a sampled recheck. Log every dataset that fails a policy threshold.\n6. Examine for bias per Art. 10(2)(f)–(g): skew across protected and sensitive attributes; a proxy screen for features materially correlated with protected attributes; and, on trained candidates, held-out slice behavior — selection-rate ratios (below 0.8 is the classic four-fifths flag) and TPR and FPR gaps across slices. Where special-category personal data is needed to detect or correct bias, apply the Art. 10(5) conditions and document strict necessity. Every finding above the policy threshold gets a mitigation — rebalancing, reweighting, relabelling, feature removal — or an explicitly justified, documented exception.\n7. Compile the data documentation package — provenance, preparation, split-integrity attestation, quality scores, and the bias examination with mitigations and exceptions — the evidence this cycle carries into the impact assessment and the Annex IV documentation.\n\n8. Assessment scope for Assess impact and classify deployment risk: Resolve this system's regulatory risk classification — the release board owns the call, chaired by the AI Governance Lead — because the classification determines whether the EU AI Act high-risk conformity obligations apply before verification or the cycle proceeds directly to verification and validation.\n\n\n\nGround the decision in the completed pre-deployment impact assessment (ISO/IEC 42001 6.1.4 and Annex A.5): consequences for individuals, for groups, and for society — fairness effects across the deployment populations quantified at the data step, safety effects under intended use and reasonably foreseeable misuse (built from the requirement specification's out-of-scope list), and fundamental-rights effects such as non-discrimination, privacy, due process, and access to essential services. The assessment also proposes the reassessment triggers — performance-drift threshold, deployment-context or population change, new use case — that the scheduling step will record.\n\n- **High-risk (`high_risk`)** — the system meets an EU AI Act high-risk criterion or an equivalent heightened threshold under another applicable regime. Art. 6(1): it is, or is a safety component of, a product covered by Annex I Union harmonisation legislation that requires third-party conformity assessment. Art. 6(2): it operates in an Annex III area — biometrics, critical infrastructure, education, employment and worker management, access to essential private or public services (including credit scoring and life and health insurance pricing), law enforcement, migration and border control, administration of justice and democratic processes. Profiling of natural persons is always high-risk regardless of the derogation tests. Equivalent regimes count too: a top model-risk tier under SR 11-7, an automated employment decision tool under NYC Local Law 144. When the honest answer is \"arguable\", classify high-risk — that error costs extra conformity work; the opposite error puts a non-conforming system on the market.\n- **Standard (`standard`)** — no Annex I or Annex III criterion is met; or an Annex III match qualifies for the Art. 6(3) derogation because the system performs a narrow procedural task, improves the result of a previously completed human activity, detects decision patterns without replacing human assessment, or performs a purely preparatory task — and does no profiling. A derogation is not a shrug: document the Art. 6(3) assessment before deployment and register the system under Art. 49(2) anyway. No other applicable regime's heightened tier is met.\n\n**Record in AssureSwarm**\nAttach the data documentation package to this step.\n- Record the per-dataset quality scores, the threshold failures with their dispositions, and the sealed test-set identity (hash) inside that data documentation package — there is no native AI System / gate-cycle item to hold these as fields, so the package document on this step is their system of record.\n\nSubmit the decision form: `risk_classification`; the step result citing the specific Annex and article criteria assessed — met and not met — and the documented Art. 6(3) assessment where the derogation carries the call; the step's approver record naming the accountable approver.\n- Attach the impact-assessment report: consequence analysis, classification rationale, and proposed reassessment triggers.\n- Where the assessment moves the register, update the linked ai_governance Risk item — `Risk.residual_rating` and, on an accepted residual, `Risk.treatment`.\n\n**Exit criteria**\nEvery dataset has provenance with a lawful basis; preparation and assumptions documented; split integrity verified and the test set sealed; quality failures dispositioned; every above-threshold bias finding carries a mitigation or a justified exception; the human reviewer has approved the package before impact assessment. Form submitted with a criteria-level rationale; impact-assessment report attached; proposed reassessment triggers on record for the scheduling step; the branch not taken is prunable. High-risk routes to the conformity-requirements step; standard proceeds directly to verification and validation, with the technical documentation assembled at the sign-off decision.","kind":"decision","label":"Assess impact and classify deployment risk","performedBy":{"note":"","primitives":["coach-query-data","coach-document-upload","coach-item-update"]}},"id":"assess-and-classify-deployment-impact"},{"data":{"description":"Agent applies the additional EU AI Act high-risk obligations triggered by the classification — human oversight design, accuracy/robustness/cybersecurity requirements, record-keeping, and the conformity assessment route; human confirms the obligations are addressed before verification and the board's sign-off decision.","instructions":"**Objective** — Address the obligations the high-risk classification just triggered — human oversight (Art. 14), accuracy, robustness and cybersecurity (Art. 15), record-keeping (Art. 12) — and fix the conformity-assessment route, so documentation and verification evidence them instead of discovering them.\n\n**Inputs**\n- The classification decision and impact-assessment report — the specific risks the oversight design must let a human catch.\n- The requirement specification (declared accuracy metrics) and the data documentation package.\n- The system's Annex III area, or the Annex I sectoral product legislation where that is the hook.\n\n**Procedure**\n1. Design human oversight to the Art. 14(4) capability tests — the measure is what the overseeing person can actually do, not the org chart: understand the system's capacities and limitations and monitor operation for anomalies; stay alert to automation bias, with the design stating how (for example, sampled blind review with the model score hidden); correctly interpret outputs using the interpretation tools provided; decide not to use, disregard, or override an output; and intervene or interrupt through a stop control that halts in a safe state. Name the assigned oversight role and verify the human-machine interface actually exposes what the design assumes. For biometric identification under Annex III point 1, plan the Art. 14(5) verification by at least two people.\n2. Verify Art. 15 with evidence, not intent: the declared accuracy levels and metrics appear in the instructions for use (Art. 15(3)); robustness is backed by redundancy or documented fail-safe behavior on malformed input, component failure, and environment shift — resilience to errors, faults, and attempts to manipulate inputs; feedback loops in continuously-learning systems have a mitigation (Art. 15(4)); and cybersecurity addresses the AI-specific attack classes — data poisoning, model poisoning, adversarial examples and model evasion, and model or data confidentiality attacks (Art. 15(5)) — proportionate to the deployment context.\n3. Confirm Art. 12 record-keeping: the system automatically logs events over its lifetime sufficient to identify situations that may present a risk or a substantial modification and to support post-market monitoring (Art. 72); retention is set — providers keep logs under their control at least six months (Art. 19), and deployer retention aligns (Art. 26(6)).\n4. Fix the conformity-assessment route per Art. 43: Annex III points 2–8 use internal control (Annex VI); Annex III point 1 biometrics may use internal control only where harmonised standards or common specifications were applied in full, otherwise a notified body (Annex VII); Annex I products follow their sectoral third-party procedure with the AI Act requirements folded in. Stage the administrative chain sign-off will need: the EU declaration of conformity (Art. 47), CE marking (Art. 48), and the Art. 49 EU-database registration package with the Annex VIII data — registration precedes placing on the market.\n5. Log every obligation that still has a gap as an owned, dated action — an unresolved Art. 14, 15, or 12 gap becomes a hold at sign-off.\n\n**Record in AssureSwarm**\n- For every article-level obligation that still carries a gap — oversight design, Art. 15 evidence, logging, route, registration — create an Issue (issue_type: observation, source: compliance_review, issue_owner, target_remediation_date) and link it (Item relationship) to the workflow's Control items UC-AI-04/05/06/07/09; obligations already in good standing are recorded in the conformity package, not as Issues.\n- Attach the oversight design, the Art. 15 evidence summary, and the staged registration package to this step.\n\n**Exit criteria** — Each Art. 14(4) capability is designed and role-assigned; Art. 15 evidence covers accuracy, robustness, and the named attack classes; logging confirmed with retention set; the conformity route recorded with its justification and the declaration, marking, and registration chain staged; remaining gaps carried as owned actions and the human has approved the conformity package feeding into verification and the documentation assembled at the sign-off decision.","label":"Apply high-risk conformity requirements","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"apply-high-risk-conformity-requirements"},{"data":{"description":"Agent executes the test plan against the requirement specification and responsible-AI objectives and compiles the results against the acceptance criteria; human reviews the results before the release board's sign-off decision.","instructions":"**Objective** — Execute the verification-and-validation plan against the requirement specification and the instantiated responsible-AI objectives, scoring every test against acceptance criteria committed before results existed, so the board decides sign-off on evidence rather than assurances.\n\n**Inputs**\n- The requirement specification with thresholds — these are the acceptance criteria, fixed at the design stage.\n- The sealed held-out test set and split-integrity attestation from the data-governance step.\n- The impact-assessment report: the populations for fairness testing and the foreseeable-misuse scenarios for safety testing.\n- The high-risk conformity package where applicable — the Art. 15 properties to demonstrate and the oversight controls to exercise.\n\n**Procedure**\n1. Confirm independence before producing any result: the test set is the sealed one, unseen in training and tuning, and the evaluation pipeline is versioned so a reviewer can re-run it exactly. Results on a leaked or substituted test set are void — return to data governance.\n2. Verify against specification: run each performance criterion's declared metric on the test set under the declared conditions, reporting point estimates with confidence intervals or run-to-run variance — a threshold met inside the noise band is a conditional, not a pass.\n3. Validate against purpose: fairness across the impact-assessment populations, reporting per-slice metrics with slice sizes and flagging slices too small for stable estimates rather than averaging them away; safety behavior under each foreseeable-misuse scenario and on boundary and malformed inputs; robustness under perturbation. For high-risk systems, demonstrate the Art. 15 properties — adversarial and poisoning resilience tests, not design claims — and exercise the human-oversight controls end to end: an override and a stop that have never been triggered are design fiction.\n4. Score every test pass, fail, or conditional against the acceptance criteria exactly as written. Changing a threshold after seeing results is outcome-shopping and voids the run — a threshold change goes back through the requirements step with board approval. A conditional pass states its compensating control and an expiry date.\n5. Draft a finding for every fail and conditional: the criterion, required versus achieved value, suspected cause, and remediation owner.\n6. Compile the verification-and-validation report — test plan, environment and versions, results scored against acceptance criteria, findings register — the evidence package for the board's sign-off decision.\n\n**Record in AssureSwarm**\n- Attach the verification-and-validation report and the raw results export to this step.\n- Record the pass, fail, and conditional counts and the open-findings register inside the verification-and-validation report on this step — there is no native cycle item; the report is the system of record, and each open finding becomes a remediation Issue at the remediate-and-resubmit step.\n\n**Exit criteria** — Every requirement-spec criterion and instantiated objective has a scored result from the sealed test set; fairness and safety coverage matches the impact assessment's populations and scenarios; every fail and conditional carries a documented finding; no acceptance threshold changed after results; the human reviewer has approved the report for the board.","label":"Verify and validate against requirements","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"verify-and-validate-against-requirements"},{"data":{"decisionField":"signoff_disposition","description":"Agent assembles the Annex IV-grade technical documentation from the evidence on file and compiles the full release package — requirements, data governance, impact assessment, documentation, and verification results — for the release board; human grants or holds the deployment sign-off.","formData":{"fields":[{"key":"signoff_disposition","label":"Deployment sign-off disposition","options":[{"label":"Sign off — approve deployment","value":"sign_off"},{"label":"Hold — release blocked pending remediation","value":"hold"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — The release board's terminal call for this cycle: assemble the technical documentation to Annex IV grade from the evidence the gate has already produced, then grant deployment sign-off or hold the release on the complete package, recorded by the accountable owner — sign-off activates the staged deployment plan; hold blocks release pending remediation.\n\n**Inputs**\n- The cycle's evidence set: requirement specification, data documentation package, impact-assessment report with the recorded classification, the high-risk conformity package where the classification requires it, and the verification-and-validation report.\n- The Annex IV template and the retention schedule; the prior version's documentation where this is a change re-entry.\n\n**Procedure**\n\n_Items 1–6 are agent-run (folded from the former \"Assemble and verify technical documentation\" step); the human moment is the board's decision below._\n\n1. Assemble the technical documentation by linking to controlled sources at their recorded versions, never by re-authoring or copying content — copies fork the truth, and at the next re-entry someone updates one copy and not the other.\n2. Cover, for every system regardless of classification: the general description — intended purpose, system version, hardware and software interactions, instructions for use; design and development — architecture, methods, and the key design choices with their rationale; data — the provenance, preparation, quality, and bias examination from the data step, carried as-is; performance achieved against each requirement-spec criterion; and known limitations — the populations and conditions where performance degrades and the foreseeable-misuse scenarios the impact assessment considered. Documented limitations are what make a later incident defensible; undocumented ones read as negligence.\n3. For high-risk systems, verify the Annex IV content item by item and cross-reference each element to its supporting evidence: general description; detailed description of development including data requirements and the human-oversight assessment; monitoring, functioning, and control information; the appropriateness of the performance metrics; the Art. 9 risk-management description; the lifecycle-change log; the harmonised standards applied or the alternative solutions adopted; a copy of the EU declaration of conformity; and the Art. 72 post-market monitoring plan. Include the pre-determined-change envelope claimed at requirements — it only shields future retraining if it is written here (Art. 43(4)).\n4. Run the currency check on re-entries: version identifiers throughout the documentation equal the version being gated, and the prior version is marked superseded with a pointer to this one — never deleted, because Art. 18 keeps documentation ten years after placing on the market.\n5. Apply the no-oral-explanation test: a competent assessor with only this package can determine what the system does, on what data, with what performance and limits, and how it is overseen. Anything answerable only by interviewing the team is a gap to close before the package reaches the board.\n6. Compile the release package for the board — approved objectives and requirements, data-governance and bias evidence, the impact assessment with its recorded classification, the high-risk conformity package where applicable, the assembled documentation with its Annex IV checklist result, and the verification-and-validation report — and stage the deployment plan: target environment, rollout approach, and the monitoring that begins at deployment.\n\n**Decision criteria**\n\nJudge the compiled release package. Three consistency checks catch most bad packages: the recorded classification matches the conformity route actually taken; the documentation carries the same system version verification tested; and every verification finding has a disposition.\n\n- **Sign off (`sign_off`)** — every requirement scored pass, or conditional with a compensating control and expiry the board explicitly accepts; no bias finding without an accepted mitigation or documented exception; the three consistency checks hold; the documentation is complete against Annex IV for high-risk systems or the baseline standard otherwise, with retention set — ten years for EU high-risk, the enterprise schedule otherwise; for high-risk systems, the Art. 14 oversight was demonstrated during verification, the Art. 15 evidence is complete, logging is live with retention set, the conformity assessment is concluded with the EU declaration of conformity drawn up (Art. 47), CE marking arranged (Art. 48), and the Art. 49 registration completed or staged to complete before placing on the market; and the deployment plan is staged. Sign-off routes to scheduling this system's reassessment triggers.\n- **Hold (`hold`)** — any failed requirement without an accepted disposition; a conditional lacking its compensating control or expiry; an unmet high-risk obligation — oversight not demonstrated, registration not achievable before market; documentation stale against the tested version or incomplete against Annex IV; or an unresolved bias finding. Name every gap specifically enough to remediate from: \"documentation incomplete\" is unusable; \"Annex IV monitoring section missing for the fallback model\" is a work order. A hold is a routine gate outcome — a board that never holds is rubber-stamping — and the hold rationale becomes the remediation step's direct input.\n\n**Record in AssureSwarm**\n- Upload the assembled documentation set and link (coach-document-link) each section to the versioned source evidence documents already attached to the earlier steps of this instance; record the documentation version, the Annex IV checklist result for high-risk systems, and the retention schedule inside the documentation package and as a note on this step — there is no native cycle item to hold them as fields.\n- Submit the decision form: `signoff_disposition`; the step result citing the specific evidence relied on and, for holds, the enumerated gaps; the step's approver record.\n- Attach the compiled release package and the staged deployment plan to this step.\n\n**Exit criteria** — Documentation complete against the applicable standard, every section cross-referenced to versioned evidence, version identifiers matching the gated system, the prior version superseded rather than lost, and retention set; form submitted with an evidence-cited rationale; release package and deployment plan attached; for holds, every gap named at work-order specificity; the branch not taken is prunable.","kind":"decision","label":"Record deployment sign-off decision","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"deployment-signoff-decision"},{"data":{"description":"Agent turns each hold gap into an owned remediation action and defines the resubmission trigger; human confirms the remediation plan before the cycle closes.","instructions":"**Objective** — Convert every gap the board cited in the hold into an owned, dated remediation action with an honest re-entry scope and a defined resubmission trigger, so the hold ends in a decision rather than a stall.\n\n**Inputs**\n- The hold rationale from the sign-off decision — the enumerated gaps.\n- The verification findings register and the conformity-obligation items behind those gaps.\n- The gate-cycle record and the system's gate history on its inventory entry.\n\n**Procedure**\n1. Cut one remediation action per gap — never bundle, because bundled actions hide the one that slips. Each action carries the gap text from the hold rationale, an owner with authority over the failing artifact — the engineering or model owner for test failures, data governance for dataset defects, legal or compliance for documentation and registration gaps, drawn from the release board roster or the sponsoring team — and a target date the owner commits to rather than receives.\n2. Scope the re-entry honestly: a test fix re-runs verification, refreshes the affected documentation sections, and returns to sign-off; a data change re-enters at the data-governance step because its quality and bias evidence is invalidated; a change to intended purpose, deployment context, or architecture is a substantial modification under Art. 3(23) and re-enters the full gate from the objectives-and-requirements step. Scoping a substantial modification as re-verify-only is the standard way a gate gets defeated — where the answer is arguable, the impact assessment re-runs.\n3. Define the resubmission trigger: all remediation actions closed and verified by their evidence — a re-run result, a corrected document version — not by the owner's say-so, checked against a defined resubmission date. Add the escalation rule: a hold aging past the policy window (60–90 days is typical) returns to the board with a continue-or-retire recommendation, because a system parked on indefinite hold accrues risk with no oversight.\n4. Log the held disposition, the gap list, and the remediation plan against the AI system's gate history, so the record shows why deployment did not proceed this cycle and exactly what must happen before it can.\n\n**Record in AssureSwarm**\n- Create an Issue per hold gap (issue_type: deficiency, source: compliance_review, issue_owner, target_remediation_date, remediation_plan) and link it (Item relationship) to the specific verification-finding or conformity-obligation Issue it resolves.\n- Record the resubmission trigger, the re-entry scope decision, and the escalation window as a note on this step — there is no native cycle item to hold them as fields.\n\n**Exit criteria** — Every hold gap maps to exactly one owned, dated action; the re-entry scope is decided with the substantial-modification reasoning recorded; resubmission trigger and escalation window set; the human has approved the plan before the cycle closes without deployment.","label":"Remediate and resubmit","performedBy":{"primitives":["coach-item-create","coach-items-link"]}},"id":"remediate-and-resubmit"},{"data":{"description":"Agent records the reassessment triggers that will bring this system back through the gate — drift thresholds, retraining, or significant modification — links them to the system's inventory record, then archives the complete gate record and routes systemic findings to the AI governance backlog; human confirms the triggers are genuinely monitored and that confirmation closes the cycle.","instructions":"**Objective** — Record the specific, monitored conditions that will bring this system back through the gate — a gate that fires only when someone remembers is not a control — link them to the system's inventory record, and close the cycle on that confirmation with a self-contained, retention-scheduled record.\n\n**Inputs**\n- For signed-off systems: the reassessment triggers proposed in the impact assessment.\n- For held systems arriving from remediation: the resubmission trigger from the remediation plan.\n- The pre-determined-change envelope from the technical documentation, where one was claimed, and the retention schedule fixed with that documentation.\n- The AI system's inventory entry.\n- The complete cycle evidence: scope note, approved objectives and requirements, data documentation package, impact assessment with its recorded classification, high-risk conformity package where applicable, technical documentation, verification-and-validation report, the sign-off or hold decision, and the remediation plan for held cycles.\n\n**Procedure**\n\n_Items 5–9 close the cycle (folded from the former \"Close and archive\" step); the confirmation recorded at item 4 — that every trigger is genuinely monitored — is the closure, and no separate closing step follows._\n\n1. Make every trigger measurable — type, metric, threshold, evaluation window. Working patterns: input drift with population-stability index above 0.2 on scored features over a rolling 30-day window (0.1–0.2 is a watch level); accuracy or the domain metric dropping beyond the agreed tolerance on a periodically labelled sample; any per-slice fairness metric breaching the threshold set at verification; a deployment-context change — new population, geography, integration, or upstream data source; any new use case; and retraining or model updates outside the pre-determined-change envelope — inside-envelope changes run the envelope's own checks, outside-envelope changes re-enter the gate as modifications (Art. 43(4)). Record whichever applies — the proposed reassessment triggers for signed-off systems, the resubmission trigger for held ones — as the system's active re-entry condition.\n2. Set the periodic backstop: a scheduled reassessment date — annual is the norm, shorter for high-risk systems and fast-drifting domains — so a system that never trips a threshold is still re-examined.\n3. Name a monitoring owner per trigger — the model owner for drift and performance, the deployment owner for context changes, governance for use-case additions — and verify each monitoring mechanism actually exists rather than relying on manual recall: an automated drift monitor that alerts, a release-pipeline check that blocks model deploys without a gate-cycle reference, a periodic attestation. \"The team will notice\" is not a mechanism. For high-risk systems, tie trigger monitoring into the Art. 72 post-market monitoring plan and the deployer's Art. 26(5) monitoring duty.\n4. Write the trigger summary for the inventory record — each trigger's type, threshold or condition, monitoring owner, and mechanism, plus the next scheduled reassessment date — and have the AI Governance Lead confirm the monitoring is real rather than aspirational. That confirmation closes the cycle; items 5–9 execute the closure.\n5. Assemble the cycle record in decision order and verify the chain is closed: every approval carries its approver and date; the sign-off or hold rationale cites evidence that is actually attached; the trigger record exists and is linked. A record that depends on the AI Governance Lead's memory fails this test.\n6. Compute the cycle metrics: new-build versus change re-entry; classification reached; verification pass, fail, and conditional counts; disposition granted or held and on what basis; elapsed days from cycle open to decision; and for holds, the gap categories. Cycle-time and hold-rate trends are how the board sees whether the gate is working or being gamed.\n7. Archive the record to the retention location under the schedule set at documentation — ten years after placing on the market for EU high-risk systems (Art. 18), the applicable enterprise schedule otherwise. Record the archive confirmation; post-archive corrections are new dated addenda, never edits to the archived record.\n8. Update the AI system inventory entry: outcome, the gated version, the classification, and the next trigger to watch.\n9. Route systemic findings — pattern findings, not this system's defects: a data-quality or bias defect recurring across systems, a conformity obligation that repeatedly causes holds, an objective that keeps proving impossible to evidence as specified — into the AI governance program backlog, each with a proposed owner.\n\n**Record in AssureSwarm**\n- Compile the trigger records — each trigger's type, threshold, evaluation window, monitoring owner, and mechanism — into the trigger-summary document on this step; there is no native AI System inventory item or Trigger type to hold them as fields, so this document (carried into the next cycle's history) is their system of record. Link the instance (Item relationship) to the ai_governance Risk item the triggers re-examine.\n- Record the next scheduled reassessment date on this step and add the system to the AI-governance watchlist dashboard so trigger breaches surface.\n- Export the full workflow record — the instance is the durable gate-cycle record — and attach the archive confirmation to this step.\n- Update the AI-governance gate-metrics dashboard with this cycle's figures; create an Issue per systemic finding (issue_type: observation, source: compliance_review, issue_owner: the proposed owner) and link each (Item relationship) to the gate's Control items UC-AI-04/05/06/07/09.\n\n**Exit criteria** — Every trigger has a metric, threshold, window, named monitoring owner, and a verified mechanism; the periodic backstop date is set; trigger records linked to the inventory entry; the monitoring confirmed real rather than aspirational; the cycle record complete and self-contained with its archive confirmation recorded under the correct retention schedule; the inventory updated with outcome and next trigger; systemic findings itemized with proposed owners.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles the cycle's documents and decisions into the archive-ready package with a cover index; `/coach-workflow-export` captures the full step-and-approval trail alongside it.","label":"Schedule reassessment and change triggers","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-dashboard-create","coach-workflow-export","coach-render-package"]}},"id":"schedule-reassessment-and-change-triggers"}],"sourceTemplateId":"workflow-library:reg-ai-system-development-data-deployment-gate"}