Data work may produce a decision aid, analysis, experiment, data product, or deployed model. Each requires different evidence and controls. Begin with the intended decision or user outcome—not a model or an unsupported industry “failure rate.” Stopping can be responsible when data is unsuitable, a simple rule works, expected value is low, or risk is unacceptable.

Write a decision-oriented charter

  • Outcome and owner: What changes, for whom, and who is accountable?
  • Baseline: What happens now, and what simple non-ML alternative must be beaten?
  • Success and harm: Define business, user, statistical, reliability, privacy, security, fairness, and operational measures.
  • Data: Record authority, provenance, representativeness, quality, access, retention, and deletion.
  • Evaluation: Prevent leakage, predefine slices and unacceptable failures, and assign launch approval.
  • Operations: Set latency, availability, cost, monitoring, override, incident, rollback, and retirement requirements.

Use the sample data-governance policy to structure data decisions.

Assign lifecycle accountability

Titles vary, but functions remain: accountable product owner, domain expertise, data stewardship, modeling, data and software engineering, privacy/legal/compliance, security, human factors where relevant, operations, and risk-proportionate independent review. Record decision rights for data approval, metrics, acceptance, release, incident response, rollback, and retirement.

Use reversible evidence gates

  1. Frame: approve users, baseline, constraints, harms, owner, and discovery budget.
  2. Assess data: validate permitted use, lineage, coverage, labels, leakage, and change cadence.
  3. Experiment: predefine hypotheses, evaluation sets, metrics, uncertainty, compute budget, and stopping rules.
  4. Review: reproduce results, challenge assumptions, assess security and risk, and decide proceed, pivot, pause, or stop.
  5. Release: test the complete system, human workflow, fallback, monitoring, incident response, and recovery.
  6. Operate and retire: monitor outcomes, harm, reliability, drift, and cost; remove traffic and access when operation is no longer justified.

Scrum, Kanban, CRISP-DM, stage-gate, and plan-driven methods organize work differently. None is universally best. Choose according to uncertainty, regulation, contract constraints, and evidence cadence.

Make experiments reproducible

Version code, configuration, tests, data snapshots or identifiers, schemas, lineage, environment, dependencies, seeds, metrics, and artifacts. Git is not generally a governance system for large or sensitive datasets. Register approved models with intended use, limitations, evaluation, approval, deployment state, and rollback compatibility.

Measure outcomes, not activity

Do not use universal targets such as AUC above 0.8, churn below 5%, or deployment within 14 days. Define measures from the decision and baseline. Separate model metrics from reliability, user outcomes, harm, cost, and value. Tool adoption, tickets closed, experiments run, and enthusiasm are activity—not proof of benefit.

Before release, follow AI-governance practices and MLOps practices. Monitor pipelines with data-pipeline monitoring.

Record every gate

Capture the question, artifact versions, design, baseline, results, uncertainty, slices, limitations, changed assumptions, decision, owner, reviewers, rationale, follow-up, and revisit date. A meeting is not evidence unless its inputs and consequences are recorded.

Reviewed and substantially updated September 4, 2026. Original publication date preserved.