Typed drift A/B/C and obsolescence

The engine classifies every change in the AI system into one of three drift types, because the drift type determines the required regulatory response. An incorrect classification — treating a substantial change as routine — is a conformance error, not merely a technical one.

---

The three types

Drift A — Substantial

A change to the inputs (features, data format), the outputs (decision, value scale), or the purpose of the system (EU AI Act Art. 9(2)) constitutes substantial drift.

Required response: full risk re-triage. Re-measuring existing controls is insufficient; the risk space may have changed. The ISO 23894 §6.4.2 (identification) cycle must be reopened.

Drift B — Routine

A change to the model (architecture, weights, version) or the prompt of an LLM-based system constitutes routine drift, provided the purpose and the input/output contracts do not change.

Response: re-measurement. Existing controls are re-evaluated against the new model; if the metric crosses the threshold, the treatment cycle is reopened for that control.

Drift C — Data

A change to the training or validation dataset (incorporation of new instances, label correction, change in demographic distribution) constitutes data drift.

Response: re-measurement with particular attention to fairness controls and the EU AI Act Art. 10(5) requirement (sufficiency and representativeness of data).

Classification is the operator's, not the engine's

The engine infers the drift type from the diff of the triple (code digest / model digest / dataset digest) in sei.lock. However, the operator must confirm or escalate the classification: an architecture change that also broadens the system’s purpose is Drift A even if the diff is only in the weights.

---

The typed dependency graph

The system artifacts (training code, exported model, dataset, metrics, evidence bundle) form a dependency graph whose edges are labelled with the drift type each change activates.

sei.lock stores the anchors of the triple at the last verified sei run. When the engine runs sei status, it compares the current digests against those recorded in sei.lock without recomputing anything:

Detect drift without re-running the pipeline

sei status
# possible output (one line per SECTION, not per file):
#   classification: Reused
#   risks: Reused
#   model: Stale (re-measure)
#   data: Reused

If a section’s digest has changed, sei status reports it as Stale and classifies the drift type; unchanged sections stay Reused. The conformance gate remains closed: there is no false green because sei status does not sign new evidence.

---

A/B/C classification: the engine infers it (not a declared envelope)

The drift-type classification (A/B/C) is not declared in sei.yaml: the engine infers it from the triple diff (sei.lock + the dependency graph). There is no field or feature for a change “envelope” of acceptable changes today.

Future line: change envelope

For teams with frequent update cycles, a future improvement would be to declare in sei.yaml a change envelope (that certain changes are invariably Drift B or C under the deployment conditions, forcing only re-measurement rather than re-triage). This capability is not built: today the classification is always inferred.

---

Obsolescence detection

A signed evidence bundle becomes obsolete when any of the three digests in sei.lock diverges from the current state of the repository. sei status emits exit ≠ 0 in that case, allowing obsolescence detection to be integrated into CI/CD pipelines as a necessary condition before any conformance assertion.

The principle is simple: without fresh evidence, conformance cannot be asserted. This is the first gate of the RDD flow, described in The two gates.

---

References

Artifact	Role in drift management
sei.lock	Records the verified anchors of the triple
sei status	Detects divergence vs sei.lock without recomputing
sei run	Recomputes, measures, and re-anchors the triple
sei.yaml	Declares the control classification (the A/B/C drift is inferred by the engine)

See the sei CLI reference for command details and the sei.yaml reference for the manifest schema.