AI Governance & Ethics

21 MIN READ

AI Model Governance and Lifecycle Management

97% of breached orgs lacked AI access controls. Governance and lifecycle management for models that stay reliable long after launch, not just during testing.

Most organizations deploying AI models discover a painful truth too late: the model that performed brilliantly in testing degrades silently in production, and nobody notices until the damage is done. IBM’s 2025 Cost of a Data Breach Report found that 13% of organizations reported breaches of AI models or applications, with 97% of those lacking proper AI access controls (IBM). Among breached organizations, 63% either had no AI governance policy or were still developing one. The gap between building a model and governing it across its full lifecycle is where organizations face their greatest exposure.

What Is AI Model Governance? Definition and Core Principles

AI Model Governance is far more than another compliance checkbox added to an already long list. It is the end-to-end set of policies, roles, and controls that ensure AI and analytical models are built, validated, deployed, monitored, and retired responsibly throughout their entire lifecycle (Alation). Understanding what model governance actually entails, and how it differs from broader AI governance, is the first step toward building effective oversight.

The Distinction Between AI Governance and Model Governance

Where broader AI governance addresses organizational strategy around artificial intelligence, including workforce implications, ethical principles, and strategic investment decisions, AI Model Governance zeroes in on the specific controls that apply to individual models at every stage of their existence. Think of AI governance as the constitutional framework and model governance as the operating procedures that make constitutional principles enforceable at the model level.

This distinction matters practically. An organization might have excellent AI governance principles but still deploy models without proper validation, monitoring, or retirement planning. Responsible AI requires both the strategic framework and the operational controls that model governance provides.

Core Principles in Practice

In my experience, organizations that treat governance principles as abstract values rather than operational controls tend to struggle when those principles face production pressure. The principles that actually hold up are accountability, Transparency and Explainability, Ethics and Fairness, safety, and robustness. Each one translates into concrete governance activities.

Accountability means every model has a clear owner, and that ownership does not evaporate at deployment. It means someone specific answers when a model produces unexpected results. Transparency and Explainability require that stakeholders can understand how a model reaches its decisions, not just what decisions it makes. This becomes critical during regulatory audits and when affected individuals exercise their right to explanation.

Ethics and Fairness demand systematic checks for bias throughout training and deployment, not just a one-time review before launch. Safety means models fail gracefully when they encounter unexpected inputs, rather than producing confident but wildly incorrect outputs. Robustness ensures models maintain performance across the range of real-world conditions they will actually face, including edge cases and adversarial inputs.

Governance Across the Full Lifecycle

What often gets overlooked is that AI Lifecycle Governance spans the full AI Model Lifecycle, not just the deployment phase. In my experience, organizations that only govern production models miss the upstream decisions in data selection and training that create the downstream risks. Bias introduced during data collection compounds through every subsequent stage.

An Adaptive Risk-Based Governance approach applies tiered oversight proportional to model impact: high-risk models serving critical decisions in healthcare, finance, or criminal justice receive comprehensive oversight, while lower-risk models like recommendation engines follow streamlined processes. This prevents governance from becoming a bottleneck while ensuring controls concentrate where they matter most.

Risk Management in model governance also means recognizing that different regulatory environments impose different requirements. The EU AI Act classifies AI systems by risk level and mandates specific governance controls for each tier. The NIST AI Risk Management Framework (AI RMF) provides a voluntary but comprehensive approach to identifying and managing AI risks. ISO/IEC 42001 establishes requirements for AI management systems. Effective model governance maps internal controls to all applicable frameworks.

What Is The AI Model Lifecycle: Stages from Development to Retirement?

Understanding the AI Model Lifecycle matters because governance requirements differ fundamentally at each stage. The thing nobody tells you is that the lifecycle is not a linear progression from development to deployment. It is an iterative process where models routinely revisit earlier stages for retraining and recalibration (GSA). Treating it as a waterfall process creates governance blind spots at every feedback loop.

The Six Core Stages

Models move through six core stages, each presenting different governance needs and different risks when governance is absent (IBL):

Development: Data selection, feature engineering, and initial model design. Governance focuses on data quality assessments, bias evaluation in training data, documentation of design decisions, and ethical review of intended use cases. This is where governance has the most leverage per unit of effort, because decisions here cascade through every subsequent stage.

Training Operationalization: Standardizing how models are trained for repeatability and consistency. Model Validation gates ensure training produces reliable, reproducible results. Environment configuration, hyperparameter documentation, and training data versioning all fall under governance at this stage.

Model Deployment: Moving validated models into production environments. This stage requires validation gates that function as hard stops before promotion, ensuring no model reaches users without passing all required checks. Governance controls include approval workflows, security reviews, and deployment documentation.

Prediction Serving: The model actively generates outputs for business processes. Governance here monitors for unexpected behavior patterns, enforces access controls, and tracks prediction volumes and latency to detect anomalies.

Monitoring: Continuous observation of model performance against established baselines, tracking for Data Drift or Model Drift that signals degradation. Performance and Monitoring dashboards surface early warning signs before model degradation affects business outcomes.

Retirement: Planned decommissioning when models reach end-of-life, with records retention, successor validation, and knowledge transfer. Governance Requirements by Stage ensure this final phase receives the same rigor as deployment.

MLOps as the Operational Backbone

MLOps serves as the operational framework that makes repeatable, governed AI development possible. It provides the infrastructure for Continuous Training, automated testing, and consistent deployment practices. Without MLOps discipline, governance becomes a manual process that teams inevitably skip under delivery pressure because it creates friction without visible tools supporting it.

AI Management Systems (AIMS), as defined by standards like ISO/IEC 42001, provide the organizational framework that connects these technical stages to business accountability. They establish who is responsible for governance decisions at each stage and how those decisions get documented, reviewed, and audited.

Stage-specific risks compound when governance is absent. A Risk Assessment during development might reveal biased training data, but without that gate, the bias propagates through every subsequent stage, amplifying impact with each deployment. The iterative nature of the lifecycle means models revisit earlier stages for retraining. Each cycle through the lifecycle requires renewed governance attention because the data landscape, regulatory environment, and business context may have shifted since the previous iteration.

What Is Model Inventory and Registry: Tracking AI Assets Across the Organization?

You cannot govern what you do not know exists. An AI Asset Inventory is the foundation of any serious governance program, yet organizations commonly discover models running in production that nobody in the governance team knew about. IBM’s research found that one in five organizations reported breaches due to shadow AI, while only 37% had policies to manage or detect it (IBM).

What a Model Registry Provides

A Model Registry provides a centralized repository that manages the lifecycle of machine learning models from development through deployment to retirement. It functions as version control for models, tracking every artifact, parameter, training data reference, performance metric, and owner (Introl).

What to track goes beyond just the model binary itself. A comprehensive registry captures model artifacts, hyperparameters, training data references, performance metrics at validation and in production, deployment status across environments, ownership assignments, and compliance certifications. Think of it as your AI-BOM, a living registry that answers critical questions: What AI assets do we have? Where are they running? Who owns them? What data did they train on? (Pillar Security).

Dynamic vs. Static Inventories

The distinction between dynamic and static inventories has real governance consequences. A static inventory is a snapshot, already outdated by the time it is published. Models retrain, data pipelines change, and new deployments happen continuously. Dynamic inventories update automatically as models change, retrain, or deploy to new environments. Without dynamic tracking, AI System Inventory Coverage drops rapidly as model portfolios grow, and governance teams lose visibility into the actual state of production AI.

Tooling and Integration

ModelOp provides a dynamic, searchable registry of every AI solution across an organization, including ML models, generative AI, agents and agentic systems, vendor tools, and embedded AI in SaaS platforms (ModelOp). Platforms like IBM watsonx.governance, Collibra, and Alation offer similar capabilities with different strengths. IBM’s platform integrates AI Factsheets that track lineage events and facilitate efficient governance across model operations (IBM).

The registry also serves as a governance control point, not just a passive catalog. When a model’s status changes in the registry, it can trigger governance workflows: reviews, approvals, compliance checks, and audit entries. Data Lineage tracking through the registry ensures that every model’s provenance is traceable, which becomes critical during incident investigations or regulatory audits. Organizations should also track Vendor Coverage with due diligence for third-party models integrated into their systems, since vendor models often receive less governance scrutiny than internally developed ones.

What Is Model Validation and Testing Protocols for Production AI?

The thing nobody tells you about Model Validation is that it needs to be uncomfortable. If your validation process always confirms that the model is working, it is not rigorous enough. Validation exists to find problems before production does, and the organizations that embed this mindset into their validation protocols catch issues that others discover only through customer complaints or regulatory findings.

Statistical Validation Techniques

Cross-Validation techniques like k-fold validation and holdout validation establish statistical reliability. Methods such as cross-validation, k-fold validation, and holdout validation ensure robust evaluation of model performance across different data subsets (BigID). These techniques help teams understand not just how well a model performs on average, but how much performance varies across different data partitions. This variance is where production surprises hide, because a model that performs well overall may fail catastrophically on specific subpopulations or edge cases.

Adversarial and Red-Team Testing

Adversarial Testing and Red-Teaming go beyond standard validation by deliberately probing model boundaries. These approaches utilize perturbation techniques and targeted attacks to identify inputs that cause instability or unsafe responses, and deploy models in shadow or canary mode to observe real traffic behavior under low risk before full release (Nimbleway). The goal is to discover failure modes before users do. Red-Teaming, in particular, brings an attacker’s mindset to validation, asking not whether the model works, but how it can be made to fail.

one question · 10 seconds

Honestly, right now, which of these is closest to true for your models?

Bias Prevention is not an optional validation step. It is a mandatory gate that blocks deployment until issues are resolved. Organizations should integrate fairness checks using frameworks that systematically evaluate model outputs across protected groups. Adversarial testing should specifically include fairness checks to validate Robustness and minimize bias across demographic groups (Fiddler).

Pre-Production Deployment Strategies

Shadow Mode Deployment and Canary Deployment offer low-risk strategies for validating models against real traffic. In shadow mode, the new model processes live requests in parallel without serving results to users, allowing teams to compare its outputs against the current production model. Canary Deployment routes a small percentage of traffic to the new model while monitoring for anomalies, gradually increasing traffic as confidence builds.

Release gates make validation a hard stop before production promotion. The process involves turning validation into release gates that are hard to bypass, while maintaining Model Cards and documentation so stakeholders understand the scope, limits, and known risks (TestingXperts). Embedding validation into the development lifecycle helps teams catch issues earlier, reduce rework, and move models to production more efficiently (Domino).

The AI Validation Specialist role is essential here. Validators should be independent from the developers who built the model, ensuring that testing is genuinely adversarial rather than confirmatory. This separation of duties is a governance control that ensures accountability and prevents the natural human tendency to confirm that one’s own work is correct.

What Is MLOps and Governance Integration: Operationalizing AI Oversight?

The gap between governance policy and governance practice is where most organizations fail. What we have found is that written policies sitting in a document repository do not prevent governance failures. MLOps bridges that gap by embedding governance controls directly into the operational pipeline, making compliance automatic rather than aspirational.

Six MLOps Processes and Their Governance Controls

A Google framework divides MLOps into six integrated and iterative processes: ML Development, Training Operationalization, Continuous Training, Model Deployment, Prediction Serving, and Continuous Monitoring (ml-ops.org). Each process has natural integration points for governance controls. The key is mapping those integration points to specific governance requirements rather than bolting governance on as a separate workflow.

During ML Development, governance controls include data quality checks, bias assessment, and documentation of design decisions. Training Operationalization adds reproducibility requirements and experiment tracking. Continuous Training requires automated validation of retrained models before they replace production versions. Model Deployment enforces approval workflows and security scans. Prediction Serving adds access controls and usage monitoring. Continuous Monitoring tracks performance degradation, drift, and anomalies.

ModelOps and Policy Enforcement

ModelOps extends MLOps with explicit governance awareness. Where MLOps focuses on the operational mechanics of model development and deployment, ModelOps adds the governance layer: Policy Enforcement, compliance tracking, and risk assessment across the full AI Lifecycle Governance scope (EY). ModelOps treats governance as a first-class operational concern rather than an afterthought.

Automation and Regulatory Alignment

Automation in Governance transforms compliance from a periodic review into a continuous process. Governance workflows that trigger automatically on model changes or drift detection eliminate the human bottleneck that causes governance gaps. When a model retrains, automated checks validate that the new version meets all policy requirements before it can deploy.

Multi-account MLOps architectures with governance controls, such as those built on SageMaker, separate development, staging, and production environments while maintaining centralized policy enforcement through shared service catalogs and model registries (AWS).

MLOps provides a structured framework for ensuring compliance with regulatory frameworks like the EU AI Act, NIST AI RMF, and ISO/IEC 42001 (CognitiveView). The practical approach is mapping specific regulatory requirements to specific pipeline stages: data documentation requirements during training, bias testing before deployment, Continuous Monitoring after release. Platforms like Credo AI specialize in this regulatory alignment, providing automated Policy Enforcement against specific regulatory standards.

What Are Model Monitoring and Drift Detection in Production Environments?

In my experience, the most dangerous period for an AI model is not its first day in production. It is three months later, when the world has shifted and nobody has noticed that the model’s assumptions no longer hold. Production monitoring is the governance control that catches what all the upstream controls missed.

Understanding the Three Types of Drift

Data Drift occurs when the distribution of input data shifts from what the model was trained on. A fraud detection model trained on pre-pandemic transaction patterns may see dramatically different input distributions as consumer behavior evolves. Concept Drift is more insidious: the relationship between inputs and outputs changes, meaning the model’s learned patterns no longer apply even if the inputs look similar. You can detect concept drift by monitoring production model quality drops or through proxy metrics like Prediction Drift, which manifests as shifts in the distribution of model outputs (Evidently AI).

Data Drift, also known as Model Drift, represents a fundamental challenge for production AI because models are inherently backward-looking. They learn from historical data and assume the future will resemble the past. When that assumption breaks, model performance degrades, sometimes gradually and sometimes catastrophically (IBM).

Detection and Automated Response

Threshold-based detection involves setting drift thresholds that trigger governance responses. When statistical measures of distribution change exceed predefined limits, the system flags the model for review or automatically initiates remediation. Mean Time to Detect (MTTD) and Mean Time to Resolve (MTTR) are the key operational metrics for monitoring effectiveness. Organizations that track these metrics consistently tend to reduce both over time as their monitoring matures.

Automated Retraining Pipelines initiate model retraining automatically when drift exceeds thresholds. The framework autonomously initiates retraining while enforcing Data Lineage and quality controls (ResearchGate). This automation ensures that drift response is timely and consistent rather than dependent on someone noticing a dashboard alert.

Anomaly Detection goes beyond drift to identify individual predictions or input patterns that fall outside expected bounds. This catches sudden changes that threshold-based drift detection might miss because they affect specific segments rather than overall distributions.

Governance Integration for Monitoring

Monitoring tools like Evidently AI, Arize, and Fiddler provide specialized platforms for production model observability. These tools integrate with governance workflows, generating audit trail entries for drift events that require review and sign-off. Every drift event, retraining decision, and performance threshold breach should be recorded as a governance event, creating the continuous audit trail that regulators and internal risk teams require. Data Lineage tracking in the monitoring pipeline ensures that production inputs maintain the same quality and provenance standards as training data.

What Are Model Versioning, Reproducibility, and Audit Trails?

When a regulator asks why a model made a specific decision six months ago, you need to recreate that exact model version, not just describe it. This is where Model Versioning and Reproducibility become non-negotiable governance requirements, and where many organizations discover their documentation practices fall short.

Version Control and Experiment Tracking

Model Versioning goes beyond simply saving model files. It requires tracking every artifact, parameter, and training run through tools like Git-Based Versioning for code and specialized Experiment Tracking platforms for model-specific artifacts. A model registry provides centralized management, functioning as version control that tracks every artifact and parameter across the lifecycle (Introl). Every change to a model, whether in code, configuration, data, or hyperparameters, creates a new version that can be independently verified and recreated.

Reproducibility means any Data Scientist or ML Engineer can recreate any model version given the same inputs, code, and environment configuration. This capability is essential for three distinct governance needs: regulatory audits that require demonstrating how decisions were made, incident investigation that requires understanding what went wrong, and rollback when a new model version underperforms its predecessor.

Documentation Standards

Audit Trails capture who changed what, when, and why. Not just the current state of a model, but its complete history of changes, approvals, validations, and deployments. Under the EU AI Act and ISO/IEC 42001, maintaining versioned audit trails is a regulatory requirement for high-risk AI systems, not a best practice or optional enhancement.

Model Cards serve as standardized documentation for each model version, covering performance characteristics, known limitations, intended use cases, and ethical considerations. They make the model’s capabilities and constraints transparent to stakeholders who may not have technical expertise. Datasheets for Datasets complement model cards by documenting training data: its provenance, composition, collection methodology, and known biases. Together, these artifacts create the Data Lineage transparency that governance frameworks require and that regulatory compliance demands.

The practical challenge is making audit trails sustainable. Teams that treat documentation as a separate activity from development inevitably fall behind. What we have found is that effective governance integrates audit trail generation into the development workflow itself, automatically capturing experiment metadata, validation results, and deployment decisions as they happen rather than asking teams to retrospectively document their work.

What Is Roles and Responsibilities in AI Model Governance?

Governance fails when everyone assumes someone else is responsible. The organizations that get this right are the ones that make accountability explicit and granular, not just at the executive level but through every governance activity at every lifecycle stage.

Key Governance Roles

Governance is a shared responsibility spanning C-suite leadership, technical teams, compliance, legal, and Business Owner stakeholders. The core roles that effective governance programs establish include:

Chief AI Ethics Officer: Sets the ethical direction for AI use, establishes governance principles, and serves as the escalation point for high-impact decisions. This role bridges executive strategy and operational ethics.
AI Governance Manager: Operationalizes governance policies, coordinates across teams, and ensures day-to-day compliance activities happen. This role owns the governance process itself.
Chief Risk Officer (CRO): Integrates AI risk into enterprise risk management, ensuring model-specific risks roll up into organizational risk frameworks and receive appropriate executive attention.
AI Validation Specialist: Conducts independent validation testing, separate from the development team, providing objective assessment of model readiness for production.
Data Scientist / ML Engineer: Builds models within governance constraints, documents decisions, and participates in validation processes as subject matter experts.
Data Protection Officer: Ensures privacy requirements are met throughout the model lifecycle, particularly relevant under GDPR and similar data protection regulations.
Procurement Specialist: Manages due diligence for third-party AI systems, ensuring vendor models receive the same governance scrutiny as internally developed ones.

Structuring Accountability with RACI

A RACI Matrix clarifies who is Responsible, Accountable, Consulted, and Informed for each governance activity. For model deployment, the model developer is typically Responsible for completing deployment tasks, the Business Owner is Accountable for the model’s business impact, the AI Validation Specialist is Consulted for technical readiness assessment, and the AI Ethics Board / Ethics Review Board is Informed of deployment decisions.

The AI Ethics Board functions as a cross-functional review body for high-impact or high-risk AI models. It brings together technical, legal, ethical, and business perspectives to evaluate models that could significantly affect people or organizational reputation. These review boards typically convene for models classified as high-risk under internal tiering or regulatory frameworks.

The distinction between model owner and model developer is critical and often blurred. Developers build the model. Owners are accountable for its behavior in production. This accountability handoff at deployment must be explicit and documented, because production issues cannot simply be redirected back to the development team that has already moved to the next project. Separation of duties between validators and developers is a governance control that ensures testing remains genuinely adversarial.

What Is Model Retirement and Decommissioning: When and How to Sunset AI Models?

Organizations tend to focus heavily on building and deploying models but rarely plan for their end of life. Model Retirement is as much a governance activity as deployment, and gaps in decommissioning processes create risks that persist long after a model stops serving predictions.

Triggers for Retirement

Decommissioning Criteria include sustained Model Accuracy degradation that retraining cannot correct, regulatory non-compliance that cannot be remediated within required timelines, replacement by a superior successor model, or the end of the business use case the model serves. Data Drift that persists despite multiple retraining cycles often signals that the model’s fundamental assumptions no longer match reality, and a new architecture or approach is needed rather than incremental updates.

The Decommissioning Process

A structured decommissioning process follows a deliberate sequence: validate the successor model thoroughly, stage traffic migration gradually with monitoring at each step, observe system behavior during the transition period, and execute final shutdown only after confirming the successor performs as expected across all relevant dimensions.

Fail-Safe Plans must be in place throughout the transition, providing fallback mechanisms if the replacement model fails during migration. This includes automated rollback triggers, manual override procedures, and clear escalation paths. Rollback Strategy requires keeping the retired model available for rapid reinstatement during a defined window after decommissioning. This means maintaining the model artifacts, configuration, and deployment scripts in a state that allows rapid redeployment without rebuilding the entire pipeline.

Records Retention and Regulatory Obligations

Records retention is a regulatory obligation, not just a best practice. Regulatory Compliance Score tracking determines what to preserve from retired models: model artifacts, Audit Trails, performance records, decision logs, and training data references. Under GDPR and EU AI Act requirements, organizations must balance data deletion obligations against model archival requirements, which sometimes create conflicting demands.

Knowledge Transfer from retiring model teams to successor model teams ensures that institutional knowledge about model behavior, known edge cases, and operational quirks does not disappear with the old model. Successor Model Validation must demonstrate that the replacement model meets or exceeds the retired model’s performance across all relevant dimensions before the transition begins, including performance on edge cases that the retiring team discovered through operational experience.

How Do You Build a Model Governance Framework: Implementation Roadmap?

The organizations that succeed with model governance are the ones that start with assessment rather than prescription. Before defining policies, you need to identify where your current AI portfolio stands and where the highest-impact governance gaps exist. This is where the assess, identify, and prioritize sequence matters most.

Five-Step Implementation Roadmap

Assess current state: Inventory all AI models, document existing controls, and identify gaps. This assessment reveals which models operate without governance oversight and where the highest risks concentrate. Organizations commonly discover models in production that governance teams never knew about.

Define principles and policies: Establish the governance principles that align with your organization’s risk appetite and regulatory obligations. Map these to specific regulatory frameworks: the NIST AI Risk Management Framework (AI RMF) for risk-based governance, ISO/IEC 42001 for management system structure, and the EU AI Act for compliance requirements. The AI Governance Framework approach emphasizes connecting organizational principles to operational controls.

Establish roles using a RACI Matrix: Assign governance responsibilities explicitly across technical, business, legal, and compliance teams through a Cross-Functional Governance Team. Every governance activity should have a clear owner, not just a general policy.

Build tooling and registries: Deploy model registries, monitoring platforms, and automated governance workflows that embed controls into existing development processes. The tooling should reduce governance friction, not increase it.

Implement continuous improvement: Use the Plan-Do-Check-Act (PDCA) cycle to evolve governance practices based on operational experience, incident lessons, and regulatory changes. Governance frameworks that remain static become governance frameworks that become irrelevant.

Risk Tiering and Framework Alignment

Adaptive Risk-Based Governance ensures that high-risk models receive comprehensive oversight while low-risk models follow streamlined processes. A one-size-fits-all approach either over-governs low-risk models, creating unnecessary friction, or under-governs high-risk models, creating unacceptable exposure. The High-Risk Systems Under Governance percentage is a critical metric for tracking whether tiered governance is actually reaching the models that need it most.

Governance metrics that indicate program health include AI System Inventory Coverage, High-Risk Systems Under Governance percentage, and Risk Assessments Complete percentage. A Policy and Legal Specialist ensures that governance policies stay current with evolving regulatory requirements, which shift regularly as legislators and regulators respond to AI’s expanding role.

Measuring Governance ROI

Measuring Governance ROI makes the business case sustainable over time. Track cost avoidance from prevented incidents, compliance savings from streamlined audit processes, and project acceleration from clear governance gates that eliminate ambiguity. A Governance Maturity Model helps organizations benchmark their progress against industry peers and identify the next level of capability to target. What we have found is that organizations that can demonstrate governance ROI in financial terms maintain executive support for governance investment through budget cycles and leadership changes.

Summary

AI Model Governance and Lifecycle Management is not a single initiative but an ongoing operational discipline that touches every stage from model development through retirement. The organizations that treat governance as infrastructure rather than overhead gain measurable advantages: fewer incidents, faster regulatory compliance, and greater confidence in scaling AI across the enterprise.

The path forward starts with assessing where your models stand today, identifying which governance gaps create the most risk, and prioritizing the controls that close those gaps first. Model registries provide visibility. Validation gates provide quality assurance. Monitoring provides early warning. Versioning and audit trails provide accountability. Clear roles provide ownership. And a structured retirement process ensures models do not outlive their usefulness.

What we have found consistently is that governance frameworks succeed when they are embedded into existing workflows rather than layered on top as a separate compliance burden. MLOps and ModelOps provide the operational backbone for making governance automatic. Standards like NIST AI RMF, ISO/IEC 42001, and the EU AI Act provide the compliance blueprint. The work is in connecting the two into a coherent system that teams can actually follow day to day.

agility at scale