23 — MLOps and Model Lifecycle Checklist#

Verify that AI/ML experiments, data, models, approvals, deployment configurations, and retirement decisions are traceable and managed across the system lifecycle. Registry entries and passing offline tests are inputs to a release decision, not proof of safe real-world operation.

Scope: Frontend-specific. This file is one part of the 23_MLOps_and_Model_Lifecycle.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

• Project / product:
• Release / version / environment:
• Scope and applicable jurisdictions / markets:
• Training, evaluation, registry, and serving owners:
• Dataset, feature, pipeline, and model artifact versions:
• Approval, deployment, rollback, and monitoring policy:
• Reviewer / owner:
• Review date:
• Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

1. Copy this shared checklist into project-specific records; keep all repository template boxes unchecked.
2. Verify each item using version-controlled code, immutable data and model manifests, experiment-tracking records, registry and deployment audits, pipeline tests, monitoring evidence, and authorized approval decisions. Document evidence, failures, justified N/A, and risk exceptions outside the shared template, keyed by MLOPS ID.
3. Tailor the controls to the deployment type: internally trained models, fine-tuned or adapter models, hosted third-party snapshots, batch prediction jobs, online endpoints, and generative AI workloads have different lifecycle and observability needs.
4. Review ## API Checks and ## Frontend Checks separately where those surfaces exist; document why items do not apply for headless or offline workflows.
5. Re-run appropriate lineage, evaluation, contract, security, and lifecycle checks after changes to data, model versions, features, prompts, providers, deployment platforms, tools, or user populations. Use the separate model-evaluation, drift-monitoring, fine-tuning, and governance templates for deeper requirements.
6. Follow current provider/runtime documentation for concrete implementation details. Do not assume that a registry alias, approval tag, or model stage automatically enforces your organization's security or release policy.

Frontend Checks#

• MLOPS-111 Confirm the interface accurately communicates AI capability, known limits, and changes in behavior resulting from a model release.
• MLOPS-112 Test essential user journeys on the candidate and approved baseline model with the same UI and authorized data.
• MLOPS-113 Verify frontend feature flags select only the server-approved model routing and cannot grant privileged model access.
• MLOPS-114 Show meaningful loading, timeout, refusal, fallback, and error states when a new model behaves differently.
• MLOPS-115 Confirm model changes do not break structured UI cards, generated markup, citations, or downstream field validation.
• MLOPS-116 Validate streaming partial responses, cancellations, and retry states across staged model deployments.
• MLOPS-117 Test accessibility of dynamic model outputs, status announcements, keyboard navigation, and error feedback.
• MLOPS-118 Include supported languages, scripts, devices, and assistive technologies in release-specific UI tests.
• MLOPS-119 Explain to users when tasks are unavailable because an incompatible or retired model capability was disabled.
• MLOPS-120 Ensure consequential tool actions still require appropriate user confirmation after model replacement.
• MLOPS-121 Check privacy notices and user consent text match the actual deployed model/provider data handling.
• MLOPS-122 Test a safe fallback experience for disabled AI features, provider outages, and rollback.
• MLOPS-123 Prevent cached conversations and generated artifacts from exposing prior users' protected content after account changes.
• MLOPS-124 Verify model-specific references, disclosures, and help content are updated when a release changes supported features.
• MLOPS-125 Check perceived latency and user-task completion time when model response length or inference speed changes.
• MLOPS-126 Confirm UI telemetry can associate errors and approved user feedback with the model release without logging unnecessary private prompts.
• MLOPS-127 Make it possible to report harmful or wrong outputs with traceable, privacy-safe incident identifiers.
• MLOPS-128 Check old browser tabs, cached bundles, and mobile clients against the new model's response schemas.
• MLOPS-129 Verify that frontend experiments or cohort routing do not misattribute model outputs or show incorrect completion status.
• MLOPS-130 Validate rollback does not strand unfinished workflows, saved drafts, or user-visible external actions.

Release gate#

• Critical model training and tuning runs are traceable to reviewed code, data, environment, configuration, evaluation, and identifiable accountable owners.
• The approved model artifact or provider snapshot has verifiable identity, provenance, integrity, permissioned registry metadata, and documented intended use and limitations.
• Quality, safety, privacy, performance, compatibility, and resource/cost thresholds have been evaluated against representative conditions and a known-good baseline.
• Authorized promotion gates validate the specific model and associated feature, schema, prompt, tool, and serving configurations; unapproved versions cannot be deployed.
• Production-equivalent deployment, staged rollout, mixed-version compatibility, endpoint health, and rollback or safe-disablement tests pass.
• Ongoing monitoring, incident escalation, user feedback, drift investigation, retraining approvals, and retention/decommissioning procedures have named owners.
• Relevant API and frontend behaviors remain safe and comprehensible across model changes, fallback, and retired capabilities.
• Residual material risks and unresolved failures are documented and approved by appropriately qualified humans for the exact release.

Domain-specific approval rule: Block sign-off when a production model cannot be traced to approved data and code, integrity or access controls permit unreviewed artifacts to be deployed, severe evaluation or privacy findings are unresolved, or rollback/emergency disablement is required but untested. Automatic retraining does not confer automatic deployment authorization.

Trusted references and scope#

These primary specifications, project documentation, and authoritative risk-management resources support the lifecycle checks. They describe different architectures and are not interchangeable certification requirements.

• Google Cloud Architecture Center — MLOps CI/CD/CT — automation, testing, metadata, continuous training, and serving lifecycle; emphasis on predictive ML.
• MLflow — Experiment Tracking — experiment run metadata, datasets, artifacts, metrics, parameters, and run comparison.
• MLflow — Model Registry — model versioning, registry ownership, aliases, lineage, and approval metadata.
• MLflow — Model Registry Workflows — promotion workflows and migration away from deprecated fixed model stages.
• Kubeflow Pipelines — ML Metadata — pipeline executions, artifact lineage, metadata, and operational migration considerations.
• Kubeflow Pipelines — ML Artifacts — typed datasets, model artifacts, provenance, and pipeline artifact lifecycle.
• TensorFlow Extended — ML Metadata — tracking relationships among data, training runs, model artifacts, and software dependencies.
• Amazon SageMaker AI — Model Registry — model package approvals, lineage, metadata, and controlled deployment.
• Amazon SageMaker AI — Pipelines Overview — processing, training, evaluation, condition gates, and model registration workflows.
• NIST AI RMF Playbook — Manage — human risk decisions, continual monitoring, recovery, vendor oversight, and decommissioning.
• SLSA v1.2 — Provenance — verifiable artifact build/source provenance relevant to model packaging and serving supply chains.
• OpenTelemetry — Generative AI semantic conventions — model, operation, token, and response observability with sensitivity safeguards.

Applicability: Google Cloud's MLOps architecture article principally covers predictive machine learning; generative AI may use provider-managed models rather than locally trained artifacts. MLflow fixed Staging/Production/Archived model stages are deprecated in favor of model aliases, tags, and suitable environment access control; a mutable alias must never replace an immutable release identity. Kubeflow, TensorFlow ML Metadata, and SageMaker capabilities depend on the deployed version and provider configuration. SLSA is supply-chain provenance guidance, not proof of permission to use training data. OpenTelemetry's GenAI conventions and implementation support may evolve; avoid logging protected prompt or response content without an approved policy. NIST AI RMF is voluntary and not a certification.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

• Test focus: lineage, promotion gates, artifacts, deployment, and rollback; include browser and client behavior where applicable.
• Cross-stack: DVC + MLflow.
• Python: Evidently + pytest; for pytest-based suites, run python -m pytest -q.
• TypeScript: Testcontainers + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
• JavaScript: Testcontainers + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
• Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

• ml-pipeline-workflow — Review training/deployment lifecycle controls (wshobson/agents, 42,437 repo stars).
• checkpoint-promotion — Check model approval and rollback gates (wshobson/agents, 42,437 repo stars).
• agent-platform-model-registry — Check registry provenance where Google Agent Platform is used (google/skills, 24,012 repo stars).

How to check: In a project-specific copy, have the agent audit the frontend scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.