EvolutionStrong architectural inferencev1.22.1

In plain English

This page explains how AI systems can change over time through updates, tests, retraining, memory, and approvals even when no single model rewrites itself.

  • Why this matters: AI risk can come from the whole arrangement, not one obvious model.
  • What to look for: data, memory, routes, adapters, tools, evaluators, updates, and rollback paths.
  • Technical version below: the expert terminology remains available and is linked through the glossary.

When a Model Changes Without Changing Its Name

Evidence levelStrong architectural inferenceTechnical label: Architectural inference

If “latest” points to a new hash, A set of adapters loaded together, usually in a defined order. Open glossary definition, quantization setting, or route, the model name stayed stable while the safety unit changed.

Mechanism

Variation, evaluation, selection, inheritance, and succession can exist as properties of the broader development process. The model does not need to rewrite itself at runtime. The ecology changes because operators, pipelines, routers, and release controllers alter the population.

Assurance implication

A descendant needs fresh evidence for safety-relevant behavior. A content hash can identify an artifact, but it cannot prove that a related descendant preserved all relevant guardrails.

Review question

What behavior is being tracked, where could it be encoded, which descendants or reservoirs may carry it, and what evidence would count as absence across active compositions?

<!-- expanded-release-content -->

Stable labels, unstable systems

Evidence levelStrong architectural inferenceTechnical label: Architectural inference

A deployed AI service can keep the same product name, endpoint, or model alias while its internals change. Operators may update prompts, swap adapters, revise routing thresholds, consolidate memory, change tool permissions, quantize weights, patch dependencies, or point an alias to a new descendant. Users and auditors may still see the same public name.

That creates a documentation gap. A name is not a A machine-readable record of the exact runtime composition used for an evaluation, release, incident, or rollback. Open glossary definition. It may be a convenience label that spans many materially different systems. When incidents occur, the question is not only “which model name was used?” but “which exact components, transitions, and permissions were active at the time?”

Assurance decay

Confidence, backed by evidence, that a system meets safety or governance requirements. Open glossary definition decays when the evaluated object diverges from the deployed object. Small changes can matter when they affect the activation condition for a behavior. A prompt change may alter refusal behavior. A router change may expose a specialist to tasks it was not tested for. A memory change may preserve a precedent created under an older policy. A quantization change may leave benchmark accuracy intact while changing boundary behavior.

Required logging

Every release alias should resolve to a timestamped composition manifest. The manifest should include all safety-relevant components and transition history. The logging system should preserve UTC times, actor identity, approval records, evidence references, and Returning a system to an earlier known state. Open glossary definition targets. Without that, a stable name can launder a changing system.