Prepare and test your skills
Prepare and test your skills
Model Artifact Registration and Version Lineage Tracking is the practice of recording every base, fine-tuned, and custom agent model as a distinct, reproducible version with its artifacts and history. Model Registry (opens in a new tab) is the central repository for model versions and metadata, while Artifact Registry is the immutable store for the underlying files and containers. Together they link each training pipeline run, its source datasets, and its provenance metadata to a servable version to support auditability and scalable agent deployment.
Model Registry creates the single source of truth for model versions by tracking each version, its metadata, and its link to underlying model artifacts. Registration applies to base foundation models, fine-tuned derivatives, and custom agent models, with each iteration stored as a new version rather than overwriting a prior version. Only models that pass the validation step are registered for production deployment, so the registry enforces a gate between continuous training and serving.
| Registry | Stores | Provides for lineage |
|---|---|---|
| Model Registry | Model versions and metadata | Link from version to underlying artifacts, training parameters, evaluation metrics, dataset version |
| Artifact Registry | Model files, pretrained weights, serving container images | Versioning and tagging of binary artifacts referenced by Model Registry |
| Cloud Storage | Validated, versioned configuration files and validation artifacts | Durable audit trail for pipeline reproducibility |
The registry therefore depends on upstream validation outputs and downstream deployment pulls to maintain a reproducible chain from training to serving.
Exam tip: Model Registry tracks versions and metadata, while Artifact Registry stores the model files, weights, and serving container images.
Artifact storage in Artifact Registry preserves the exact binaries needed to reproduce serving, including model files, pretrained weights, and serving container images with versioning and tagging. Each Model Registry version points to these tagged artifacts plus its explicit runtime dependencies, container specification, and input-output schemas. Before promotion, the artifact must be staged in a sandboxed version of the serving environment to verify that the model can be loaded and invoked and that required operations and binaries are present. This verification prevents failures where training succeeds but serving fails due to missing dependencies, mismatched container images, or incompatible schemas.
A versioning scheme gives every model iteration a distinct, comparable identity within Model Registry. A clear scheme such as semantic versioning is used so champion and challenger versions can be tracked, compared, and rolled back without ambiguity. For each model version, comprehensive provenance metadata is attached to explain how the version was produced and how it performed:
This metadata flows from the training and validation pipeline into the registered version, so an auditor can move from a deployed endpoint back to the exact data, code, and parameters that produced it.
Pipeline run and dataset lineage tracking connects source code, execution, data, and outputs across continuous-training workflows. Lineage starts at the raw source and processed dataset, moves through deployed pipelines, pipeline components, and pipeline runs, and ends at the produced model artifacts and evaluation reports. Validated, versioned configuration files for YAML or JSON and command-line arguments are stored in Cloud Storage or Artifact Registry to ensure that each run can be reproduced and audited. Key inputs and outputs of each pipeline step are retained, including dataset statistics, anomalies, transformed data and schemas, checkpoints, and evaluation results, with observability on conditional steps to record whether they ran, were skipped, or failed.
Programmatic control and access governance make registration enforceable and automatable within CI/CD for agent deployment. The Agent Platform SDK or API is used to programmatically register versions, manage metadata, and integrate registration into automated build and deployment pipelines that pull from Artifact Registry. Stringent access-control policies are defined separately for Model Registry and Artifact Registry to meet security and governance requirements, separating who can register or modify a version from who can download or deploy the underlying binaries. Because registration, storage, and deployment are linked through the SDK, a validated version registered once can be consistently staged, tested for satisficing metrics like size and latency, and promoted to production without manual handoffs.
Version aliasing, lifecycle promotion, and deployment routing together decouple what model is served from how clients call it. The Gemini Enterprise Agent Platform Model Registry stores each foundational or fine-tuned model as an immutable version, a serving Endpoint routes live agent traffic to one or more deployed versions, and mutable aliases bridge the two so promotion and rollback do not require client changes.
Semantic version aliasing in the Model Registry is the practice of attaching a movable pointer name to an immutable model version. Each registered version gets a fixed ID such as v3 that never changes and preserves its artifacts, training metadata, evaluation results, and lineage for reproducibility, while an alias such as dev, staging, production, champion, or challenger can be reassigned from one version to another. Agent code and pipelines reference the alias rather than the fixed ID, so resolving production returns whichever version currently holds that alias. Aliases manage lifecycle stages without modifying downstream endpoint URIs because the endpoint configuration resolves the alias at deployment time. When staging moves from v4 to v5, the staging endpoint continues to use the same URI and authentication policy, and only the registry mapping behind it changes.
Lifecycle promotion across environments is the ordered reassignment of aliases as a model version gains confidence from development to staging to production. A version remains development while it is being fine-tuned and functionally tested, becomes staging when it serves production-like agent traffic for integration, safety, and latency validation, and becomes production only after it meets release criteria for quality, policy, and cost. Promotion follows an explicit sequence that preserves reproducibility:
dev alias for experimentation.staging alias to the candidate version and deploy that alias to the staging endpoint, leaving the production alias untouched.production alias to the validated version and update the production endpoint to serve it, retaining the prior production version in the registry for rollback.Only after staging validation succeeds should the production alias move, because skipping staging breaks isolation between experimental agent behavior and live users.
Deployment routing on serving endpoints is how an endpoint distributes live agent requests across one or more deployed model versions. An endpoint has a stable URI and owns a traffic-split map that sends a percentage of requests from the endpoint to each deployed model, so traffic flows from the agent client to the endpoint URI to the selected deployed model. Deploying multiple versions behind one endpoint enables controlled exposure without creating new URIs or redeploying clients.
| Pattern | How traffic is routed | Choose when |
|---|---|---|
| Canary rollout | Most traffic stays on the stable version, such as 95% to v4 and 5% to v5 as challenger | Validating a new agent version on live traffic with limited blast radius |
| Traffic splitting | Traffic is divided for comparison, such as 50% to v4 and 50% to v5 | Running A/B evaluation of quality, latency, tool-use accuracy, or cost |
| Seamless rollback | Traffic is shifted back to the prior version, such as 100% back to v4 | Recovering from regression, safety violation, or latency spike in v5 |
Canary rollouts reduce release risk but require monitoring of task success, grounding, policy violations, and tail latency before increasing the challenger share. Traffic splitting provides direct comparison but doubles operational load because both versions need sufficient compute and observability. Rollback is fast because the prior version remains deployed and registered; the operation is to re-point the production alias and reset the traffic split to 100% on the known-good version, then undeploy the faulty version only after recovery is confirmed.
Exam tip: Move the alias to promote or roll back; change the endpoint traffic split to canary or compare. The endpoint URI stays stable in both cases.
Evaluation metadata association, governance, and access control in the Gemini Enterprise Agent Platform Model Registry (opens in a new tab) is the practice of linking every registered model version to its evidence of readiness and then protecting that record with enterprise controls. Model Registry acts as the central repository and single source of truth from raw data to prediction, while Artifact Registry stores the large artifacts and Knowledge Catalog stores the data inventory that the version points back to. Only versions whose attached metrics and safety scores pass operational thresholds move forward to deployment, and only authorized identities can read or promote them.
Evaluation metadata attached to a registered version is the complete evidence package that makes a model version reproducible and auditable. Each version in Model Registry links to its underlying artifacts in Cloud Storage or Artifact Registry and carries metadata that travels with the version through its lifecycle. Automated MLOps pipelines register and update this record on creation or modification, so traceability does not depend on manual entry.
A registered version links to the following peer metadata:
For generative AI and foundation models, the catalog record must also track the specific foundation model used and the safety evaluation results for generated output. Before import into Model Registry, model files and pretrained weights are stored in Cloud Storage and custom training or serving container images are stored in Artifact Registry with versioning and tagging. This separation lets Model Registry govern the version identity and its metadata while Artifact Registry governs the immutable bytes.
Readiness validation is the gate that decides whether a candidate version can be registered for production deployment. A model validation step runs before the registration step, and only models that pass predefined quality thresholds are registered for production. Final evaluation uses a separate test split that was not used for training or hyperparameter tuning, which prevents optimistic scores from leaking tuning choices into the release decision.
The Agent Platform model evaluation service and Experiments on Gemini Enterprise Agent Platform provide the measurement plane for this gate. Experiments compares a candidate challenger model against the current champion model on the same test split, while model evaluation computes optimizing metrics and satisficing metrics such as minimum accuracy, maximum error rate, minimum F1-score, latency, and model size. For generative AI, the Gen AI evaluation service assesses toxicity, coherence, factual accuracy, and adherence to safety guidelines aligned to the use case and its risks. Evaluation also tests important data slices, such as users by country or movies by genre, and validates against fairness indicators to detect implicit bias from insufficient training diversity.
| Model class | Readiness dimensions | Evaluation tooling |
|---|---|---|
| Traditional ML | Accuracy, precision, recall, F1-score, AUC-ROC, log loss, plus latency and size satisficing metrics | Agent Platform model evaluation with threshold gates and champion-versus-challenger comparison in Experiments |
| Generative AI and fine-tuned foundation models | Response quality, factual accuracy, grounding, toxicity, coherence, safety-guideline adherence, instruction following, style and verbosity | Gen AI evaluation service with use-case-specific safety benchmarks, plus Cloud Logging and Cloud Monitoring alerts for output-quality shifts |
When monitoring detects data drift, prediction drift, or a shift in generative output quality, alerts trigger rollback procedures that use Model Registry lineage to revert endpoint traffic to the most recent stable version.
Exam tip: Final readiness must be scored on a separate test split never used for training or tuning, with the challenger compared directly against the champion on that same split.
Identity and Access Management (IAM) for registry governance is the set of granular permissions that controls who and what can register, read, and promote models and artifacts. Permissions are defined for users, groups, and service accounts and applied consistently across Model Registry, Artifact Registry, and all related resources. The principle of least privilege governs every grant, so each identity receives only the minimum permissions needed for its task.
IAM policies apply consistently across the following resource boundaries:
Model governance adds human accountability on top of these technical controls through a responsibility assignment matrix for each model by task. A training service account, for example, needs read access to training data and write access for model artifacts, but it does not need write access to production serving endpoints. This same separation applies in centralized and cross-project architectures where a central registry project hosts the governed versions and workload projects consume them through explicit grants.
Audit logging, tagging, and traceability in Model Registry provide the continuous record that proves which data and code produced which version and who touched it. Cloud Audit Logs are enabled for all Google Cloud services used by the AI system and capture API calls, data-access events, and configuration changes to registry, storage, and serving resources. Teams monitor those logs for suspicious activity, unauthorized access attempts, and unexpected modifications to critical data or model assets. Tagging connects the registry version outward to business context. Datasets are tagged and annotated with business metadata, ownership information, sensitivity levels, and lineage details that link a processed dataset to its raw source and to the pipeline that created it. Validation results and metrics are stored in BigQuery for analysis and historical tracking, while validation artifacts are archived in Cloud Storage, so the evidence behind each version remains queryable long after promotion.
Model Registry is the central repository for model versions and metadata that links each version to its underlying artifacts, training parameters, evaluation metrics, and dataset version. Artifact Registry is the immutable store for the underlying files including model files, pretrained weights, and serving container images with versioning and tagging.
Each registered version has a fixed immutable ID such as v3 while mutable aliases such as dev, staging, production, champion, and challenger can be reassigned from one version to another. Agent code and pipelines reference the alias rather than the fixed ID, so moving the production alias to a new version or back to a prior version changes what is served while the endpoint URI and authentication policy stay stable.
Use canary rollout such as 95 percent to v4 and 5 percent to v5 to validate a new agent version on live traffic with limited blast radius. Use traffic splitting such as 50 percent to each version for A and B evaluation of quality, latency, tool-use accuracy, or cost, and use seamless rollback shifting traffic back to 100 percent on the prior version to recover from regression, safety violation, or latency spike.
A model validation step runs before registration and only models that pass predefined quality, safety, latency, and size thresholds are registered for production. Final evaluation must use a separate test split never used for training or hyperparameter tuning, with the challenger compared directly against the champion on that same split.
Last updated