MLOps / Prediction and evidence foundations / Lesson 1

Task ownership and lifecycle contracts

Define the prediction, decision, accountable roles, and evidence that must survive the model lifecycle.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Separate a model calculation from the decision process it supports.
Name task, ownership, fallback, and acceptance contracts.
Explain lifecycle states without confusing a label with evidence.

MLOps operates a changing prediction process

A learned model depends on code, data, configuration, and statistical assumptions that can change independently. MLOps organizes how that complete prediction process is built, assessed, delivered, observed, and revised. A weight file is only one artifact within it. Begin with the decision someone will make, the prediction unit and time, target horizon, permitted inputs, and consequences of error. A workshop attendance forecast two days before an event has different information available from a retrospective attendance explanation. Operational reliability cannot rescue a model answering the wrong question, so the task contract precedes pipeline automation.

Ownership includes decisions and fallback behavior

Name who defines the target, maintains input meaning, evaluates model evidence, owns delivery, and responds to failures. One person may hold several roles, but each responsibility should be explicit. Specify a fallback when inputs are unsupported, labels are delayed, or a candidate fails acceptance. A fallback can be a reviewed rule, an earlier compatible artifact, deferred processing, or human handling under the task’s conditions. It should have its own limits and evidence. A document saying owner exists is not enough if no one can explain what action that owner must take for a concrete failure.

Make the task declaration reviewable

The first fixture checks that a tiny synthetic task contains several required fields and a positive horizon. This is an executable completeness check for the stated schema, not a validation of organizational authority or real-world usefulness. Add domain-specific requirements only when they follow from the task: feature availability, units, label definition, eligible population, and important slices often matter. Keep a baseline and primary evaluation measure in the same contract. A technically valid metric can still fail to measure the decision consequence, and a copied fallback name can hide a procedure that cannot actually be used at the required time.

python Deterministic offline standard-library fixture

required = {"prediction_unit", "horizon_days", "metric", "owner", "fallback"}
task = {"prediction_unit": "synthetic event", "horizon_days": 2,
        "metric": "mean absolute error", "owner": "lab-owner",
        "fallback": "training-only constant"}
missing = sorted(required - task.keys())
assert not missing and task["horizon_days"] > 0
print("missing fields", missing)
print("unit", task["prediction_unit"])
print("horizon days", task["horizon_days"])

Expected output

missing fields []
unit synthetic event
horizon days 2

Presence checks make one narrow task declaration inspectable; they do not prove that the owner, metric, or fallback is appropriate.

Lifecycle states summarize completed evidence

A candidate may be evaluated, selected, activated, rejected, or retired under a defined process. The second fixture permits only specified state transitions and rejects a direct jump from candidate to active. These labels are conceptual and do not represent a particular registry API. A transition should refer to the actual artifact identity, evaluation record, compatibility checks, and responsible decision. Renaming an artifact approved does not create that evidence. Likewise, activation is not permanent scientific approval: later label evidence, changed input meaning, or an incident can require reassessment or retirement under the task contract.

python Deterministic offline standard-library fixture

transitions = {"candidate": {"evaluated", "rejected"},
               "evaluated": {"approved", "rejected"},
               "approved": {"active"}, "active": {"retired"},
               "rejected": set(), "retired": set()}
def allowed(current, proposed):
    return proposed in transitions[current]
print("candidate to active", allowed("candidate", "active"))
print("evaluated to approved", allowed("evaluated", "approved"))
print("active to retired", allowed("active", "retired"))

Expected output

candidate to active False
evaluated to approved True
active to retired True

The toy state machine encodes a declared lifecycle rule in memory; it neither authorizes a real promotion nor contacts a registry.

Automate stable checks while preserving judgment

Automated gates can check schema, artifact identity, test results, metric thresholds, and required records. They cannot infer every unstated requirement or establish that a use remains appropriate. Define what evidence a gate consumes and what happens when it is missing, ambiguous, or inconsistent. Keep operational actions and model-quality decisions distinguishable so a healthy endpoint is not mistaken for valid predictions. This course uses only deterministic synthetic in-memory fixtures; it does not create roles, approve deployments, run services, or claim external model quality. Later lessons make the evidence behind these lifecycle boundaries concrete.

Common errors and fixes

A successful training run is treated as a deployable decision process

Why it happens: Task, compatibility, and acceptance evidence were omitted.
How to fix it: Define and evaluate the complete input-to-decision contract.
Prevent it next time: Require a baseline, eligible population, and fallback before activation.

A lifecycle label is mistaken for completed review

Why it happens: The state changed without linking supporting evidence.
How to fix it: Bind the transition to immutable artifact and evaluation records.
Prevent it next time: Test required evidence as well as permitted state names.

A failure has no clear response owner

Why it happens: Responsibilities were listed abstractly without actions.
How to fix it: Assign concrete diagnosis, fallback, and decision responsibilities.
Prevent it next time: Exercise one synthetic failure through the documented ownership path.

Check your understanding

1. Why is an available prediction endpoint not enough to establish a reliable attendance forecast?

Show worked solution

Availability only says that requests receive a response under a defined service measure. The forecast also needs legitimate inputs at the two-day cutoff, a clear target, measured predictive behavior, compatible preprocessing, and an appropriate fallback. A fast response can still contain an unsupported or misleading prediction.

2. What evidence should accompany a candidate-to-evaluated transition?