Skip to content
PracticalHandbooksSoftware Handbooks
Library

AI Systems Handbook / Chapter 33

MLOps and LLMOps Foundations

Operate AI releases as reproducible bundles of code, data, models, prompts, policies, evaluation evidence, and approvals.

The Release That Nobody Could Reconstruct

On Tuesday morning, an internal knowledge assistant begins citing obsolete support procedures. The model registry offers an apparently reassuring fact: the hosted model has not changed. But the parser was updated on Friday, the knowledge index was rebuilt on Sunday, a system prompt was edited in a console, and an access rule now excludes a collection that supplied the current procedure. The release dashboard records only the application commit and the model name.

Operators can restore the code. They cannot restore the behavior, because no record identifies the exact combination that produced it. Even a correct rollback target would be incomplete: pointing yesterday’s code at today’s index and prompt creates a combination that may never have been evaluated.

The registry answered “which model?” The incident demands a larger answer: which system behaved this way, what evidence admitted it to production, and which known combination can replace it?

The operational unit of an AI-enabled system is a versioned release bundle, not a model file. MLOps and LLMOps make that bundle traceable, testable, deployable, and reversible.

Five versioned tracks for code, data, model, prompt, and policy converge through an evaluation gate into a release bundle and deployment; a lineage ledger links every input to the bundle and a rollback path returns deployment to a prior bundle.
A deployable AI release is the signed intersection of behavioral artifacts and evidence. The lineage ledger makes rollback and incident reconstruction possible.

Begin with the Behavior Path

The incident team traces one failed answer backward. The interface displayed a citation chosen by a retrieval service, which queried an embedding index built from parsed documents under an access policy. A prompt combined those results with user context and sent them, with inference settings, to a hosted model. Output policy and interface code then determined what the employee saw.

Any change along that path can alter behavior. The team therefore identifies a release by immutable references to the application and orchestration code; source corpus, parser, chunker, embedding model, and index; provider model and inference configuration; prompts, routing rules, thresholds, and safety policy; tool schemas and permission scopes; interface and escalation path; evaluation set and evaluator versions; and monitoring rules, runbooks, and rollback target.

The manifest need not contain every artifact. Large or sensitive objects can remain in controlled stores while the manifest records immutable identifiers, digests, provenance, rights, owners, and retention rules. What matters is that a stable name such as latest is resolved at release time. The approval decision and the evidence supporting it belong to the same record. For a consequential system, the manifest should also be signed or otherwise protected against unnoticed alteration.

This extends ordinary software operations rather than replacing them. Source control, automated tests, build artifacts, environment management, deployment automation, observability, and incident response remain necessary. Data and probabilistic components add new kinds of change:

  • DataOps supplies reliable acquisition, validation, transformation, lineage, access, quality, and delivery of data.
  • MLOps connects reproducible training and evaluation to registration, deployment, monitoring, and change control.
  • LLMOps applies the same discipline to provider models, prompts, retrieval corpora and indexes, tool contracts, safety policies, evaluators, and token and cost behavior.

These names describe capabilities, not departments or products to buy. Version control, immutable artifact storage, and queryable metadata may be sufficient at modest scale. A sophisticated platform that cannot reconstruct the behavior path is still operationally weak.

Let Two Pipelines Meet at One Gate

The team discovers how the invalid combination reached production. Its application pipeline deployed the parser change on Friday. A separate scheduled job rebuilt the index on Sunday and moved a current pointer after checking only document count. The prompt edit bypassed both. Each subsystem appeared healthy because no gate evaluated their combination.

Most production AI systems need two connected delivery paths. The system pipeline builds and tests code, infrastructure, prompts, policies, retrieval configuration, interfaces, and tool contracts. The learning or adaptation pipeline validates data, creates or selects a model, records lineage, and proposes a candidate. Adaptation may mean training weights, rebuilding a retrieval index, changing a feature definition, or qualifying a hosted-model revision.

Neither pipeline promotes its own output. They meet at a release gate that assembles one candidate bundle. A new model must work with the serving path, prompt, interface, and policy. A new index must preserve authorization, freshness, deletion, and retrieval quality. A prompt change must be evaluated with the model and context it will actually receive.

change -> validate inputs -> build candidate -> component tests
       -> end-to-end evaluation -> risk and approval gates
       -> immutable release bundle -> staged exposure
       -> production verification -> monitor and learn

The environments need parity in the dimensions that can change the conclusion: schemas, transforms, permissions, dependencies, provider configuration, and resource constraints. Exact hardware may differ, but the difference and its consequence must be known. Secrets remain outside the bundle even while permission scopes and secret references are versioned.

Automation can enforce a schema, metric floor, artifact signature, or required approval. It cannot decide whether an unmeasured risk is acceptable. That authority belongs to a named owner who can explain the intended use, the evidence, the remaining uncertainty, and the exposure being authorized.

Make the Candidate Earn Promotion

The repaired pipeline starts with cheap, local evidence: lint, schema, unit, contract, data-quality, and feature checks. It then tests the parser, retrieval, model, policy, and tools separately so a failure can be located. Before exposure, it evaluates the assembled assistant end to end against golden cases and past regressions, including restricted, stale, multilingual, adversarial, and unanswerable requests. Service, latency, cost, privacy, security, accessibility, and human-oversight evidence join the quality results.

The candidate is compared with the production bundle, and both results are preserved. Its gate names direction, tolerance, uncertainty, protected floors, and the limited exceptions an owner may approve. “Overall quality improved” cannot erase a cross-tenant retrieval failure or a severe regression for one language.

Deterministic fixtures protect contracts such as schemas, access decisions, citation formats, and tool arguments. Repeated samples describe behavior that varies. When a provider can change the implementation behind an alias, the team records request parameters, returned version metadata, dates, and repeated-run results; it also creates a reevaluation trigger for a change it cannot prevent.

Passing the gate produces an immutable candidate, not automatic production authority. Promotion remains distinct from experiment registration or artifact creation. The team uses the staged exposure described in the previous chapter, carries bundle identifiers into telemetry, verifies production after deployment, and keeps a compatible known-good bundle ready. Rollback must restore a coherent combination rather than a convenient collection of old parts.

Use the Registry to Reconstruct a Decision

During the incident, the registry is useful only if an operator can move from the bad answer to the release, then from the release to its components and decision. It should answer:

  • what artifacts exist and who owns them;
  • which are approved, restricted, deprecated, or retired;
  • which systems consume them;
  • what evidence and limitations apply;
  • where they are deployed;
  • what supersedes them and how to roll back.

A model registry alone cannot answer those questions for this assistant. Its release catalog must link the model to the prompt, policy, evaluation set, corpus, index, tool, and application manifests. Lineage also runs forward: when the parser is found defective, the team must be able to identify every index and release built from it.

Promotion rights follow consequence. The engineer who registers an experiment need not have authority to deploy it; artifact creation, technical review, risk acceptance, and production promotion can be separated without forcing the same ceremony on every low-risk change. Exceptions are explicit, time-bounded, owned, and visible in the release record.

Reproduce the Explanation, Not Only the Bits

Bit-for-bit model reproduction may be expensive or impossible with external providers. Operational reproducibility asks for enough evidence to reconstruct the request path, investigate the output, and compare it with a known release:

  • source and artifact versions;
  • environment, dependencies, hardware or provider, and configuration;
  • data and evaluation snapshots with lineage and rights;
  • random seeds and training parameters where applicable;
  • prompts, context assembly, retrieval candidates, tool calls, and policies;
  • evaluator versions, thresholds, human-rater instructions, and approvals.

The incident record now shows that the new parser discarded product-version metadata. The index then ranked a well-written but obsolete page above the current procedure, while the prompt edit made the assistant less likely to abstain. No single component explains the failure. The versioned path does.

That path can contain confidential or personal data. The team retains identifiers, hashes, structured events, or redacted evidence when raw prompts and retrieved content are unnecessary. Access, retention, and deletion rules preserve investigative value in proportion to risk rather than turning observability into an uncontrolled archive.

Treat Every Adaptation as a Candidate

After the repair, the team considers rebuilding the index whenever the corpus changes and fine-tuning the model from user corrections each night. These are different adaptations, but both can create unreviewed production behavior.

Continuous training means that new evidence can create a candidate. It does not mean that every drift signal silently promotes new weights. A shift may come from a data bug, policy change, attack, seasonal event, or valid new population. Training on contaminated or weakly labeled feedback can preserve the incident as the next model’s lesson.

Each adaptation therefore passes through triggers, quarantine, validation, evaluation, approval, staged exposure, and rollback. Higher-consequence systems may require controlled retraining with human review even when candidate creation is automatic. For a generative system, the smallest effective repair may be the corpus, retrieval, prompt, policy, or workflow rather than the model. Independent versions let the team discover which change helped.

Audit One Release Before Buying a Platform

Take a prototype your organization wants to operate. Choose one real output or action and write the exact production combination that would create it: code, data or corpus, transforms, model, prompt, policy, tools, interface, evaluator, and operating configuration. Mark any component currently known only by a mutable name.

Then follow one proposed change through the operating path. What creates the candidate? Which component and end-to-end evidence can reject it? Who may accept residual risk? Which bundle identifier reaches telemetry? What known-good combination can replace it? Which effects—written records, user actions, learned behavior, or exposed data—would require compensation beyond a software rollback?

Finally, change a second component at the same time. If the evaluation result worsens, can the records distinguish interaction from coincidence? If not, the prototype has automation but not yet operational control.

The repaired knowledge assistant now has that control. Its release record identifies the parser fault and prompt interaction, the new gate prevents independently “healthy” components from assembling themselves in production, and the known-good bundle can be restored as a whole. The next chapter begins where this one stops: carrying the release identity into telemetry and deciding when a change in production is evidence of failure.

MLOps earns speed by making evidence, authority, and reversal ordinary.

Source Notes