Glossary

Core concepts

Model breeding — Governed creation of descendant model artifacts or coalitions through bounded variation, recombination, specialization, compression, and selection. The term does not imply sentience, autonomous reproduction, or permission to deploy.

Code breeding — Controlled variation and selection over symbolic execution machinery: source code, intermediate representations, routing policies, kernels, workflows, prompts, tests, or build configuration. Code breeding has different failure modes and must use a software-security pipeline.

Small-model ecology — A population of specialized models and deterministic components whose composition, activation, and lifecycle are managed as a system. “Small” is workload-relative; the key property is decomposability, not a universal parameter threshold.

Teleodynamic control — A conceptual control regime in which fast behavior and slower structural change are coupled through resource and viability constraints. In this site it is an engineering analogy, not a claim that software is alive or possesses intrinsic purpose.

Operational Four Fs — Fast, Flexible, Frugal, and Federated: system qualities emphasizing latency, adaptability, resource efficiency, and distributed operation.

Evolutionary Four Fs — Feed, Fork, Fight, and Flee: an operational cycle for gathering evidence, creating variants, evaluating them, and rolling back or retiring failures.

No-op — An explicit candidate action that leaves structure unchanged. No-op wins when no proposed change clears hard gates and the required viability margin.

Metastability — A locally stable configuration that remains adequate under current conditions but may change when workload, hardware, policy, or threat conditions shift.

Artifacts and inheritance

Parent — An artifact or package used as the source of inherited behavior, parameters, architecture, data recipe, or configuration.

Descendant — A newly created, immutable candidate with recorded parentage and a declared variation operator.

Lineage — The directed acyclic graph connecting descendants to parents, operators, data, evaluator versions, approvals, and releases.

Genome — A metaphor for the mutable representation supplied to an evolutionary process. It may be weights, adapters, architecture specifications, programs, policies, or composite package manifests. Always name the concrete representation.

Phenotype — The observable behavior and resource profile produced when an artifact runs in a defined environment. Two identical artifacts can exhibit different phenotypes under different runtimes or prompts.

Inheritance — Explicit transfer of selected properties from parent to descendant. In production systems, inheritance must be documented rather than inferred from naming.

Mutation — A bounded variation applied to one parent, such as fine-tuning, pruning, quantization, architecture edit, or policy perturbation.

Recombination — Creation of a candidate from two or more parents through adapter fusion, task-vector operations, weight merging, module composition, or policy composition.

Horizontal transfer — Reuse of a capability, adapter, test, rule, or component across otherwise separate lineages. It creates dependencies that must be represented in provenance.

Artifact digest — A cryptographic hash identifying exact bytes. Approvals and release aliases should bind to the digest, not only a mutable name.

Immutable package — A versioned bundle whose model files, manifest, schemas, dependencies, checksums, signatures, and evidence references cannot change after publication.

Model card — Human-readable documentation of intended use, limitations, evaluation, data, risk, and operational requirements. It complements, but does not replace, machine-readable manifests.

Capability manifest — Machine-readable declaration of what a package accepts, produces, requires, costs, and guarantees.

Composition and routing

Capability contract — A versioned behavioral interface defining input schema, output schema, error semantics, confidence or abstention behavior, data classification, and service-level expectations.

Contract interchangeability — Ability to substitute components because they implement the same external contract.

Runtime interchangeability — Ability to execute artifacts in a shared serving environment despite framework or architecture differences.

Parameter interchangeability — Ability to combine or substitute weights, layers, or adapters directly. This normally requires close architectural compatibility.

Semantic interchangeability — Ability to consume another model’s internal representations correctly. This is difficult and usually requires trained alignment layers.

Behavioral interchangeability — Ability to substitute components based on tested outcomes rather than internal compatibility. This is the preferred enterprise abstraction.

Router — A deterministic or learned component that chooses a model, coalition, tool, or execution path for a request.

Coalition — The bounded set of components activated together for a request or task.

Cascade — Sequential execution in which a low-cost component handles easy cases and escalates uncertain or complex cases.

Ensemble — Multiple components independently process the same task and an aggregator combines their outputs.

Mixture of experts — A model architecture with a learned gate that activates a subset of internal expert subnetworks. It is not automatically equivalent to a deployable ecology of independently governed services.

Adapter — A small trainable parameter set attached to a base model to add or alter capability without updating all base weights.

Model docking — Loading and unloading model packages on demand according to workload, memory pressure, or policy.

Knowledge bus — A governed exchange layer for structured events, evidence, retrieval objects, embeddings, or summaries among components. It should not become an untyped shared-memory channel.

Evaluation and selection

Fitness — A context-specific selection score or vector. In engineering systems it should never be treated as biological fitness or as a single unrestricted objective.

Viability — Whether a candidate provides sufficient net benefit under resource, safety, security, and governance constraints.

Viability margin — Weighted benefit minus weighted cost after all hard invariants pass.

Hard invariant — A non-negotiable condition whose failure rejects a candidate regardless of aggregate score.

Evaluator gate — A protected stage that applies deterministic checks, benchmark suites, safety tests, resource tests, and policy rules.

Evaluation suite — Versioned collection of datasets, scenarios, simulators, tests, and scoring logic.

Critical slice — A subset representing a high-impact population, task, failure mode, language, device, or policy condition that cannot be hidden by aggregate performance.

Champion — The currently approved production artifact or policy for a capability contract.

Challenger — A candidate evaluated against the champion under comparable conditions.

Shadow deployment — Execution on mirrored or replayed traffic where candidate outputs cannot affect users or downstream state.

Canary deployment — Bounded live exposure with predeclared stop and rollback conditions.

Calibration — Agreement between reported confidence and observed correctness over a defined distribution.

Abstention — Deliberate refusal to produce a normal answer when confidence, policy, or capability is insufficient.

Regret — Difference between the outcome of the selected action and the best action known in hindsight. Router regret can reveal systematic misrouting.

Quality-diversity — Evolutionary search that preserves a range of high-performing behaviors across niches instead of retaining only one global winner.

Novelty archive — Stored representations of prior behaviors used to reward or measure behavioral difference.

Pareto front — Candidates for which no other candidate is better on every considered objective.

Surrogate evaluator — A lower-cost model estimating expensive evaluation outcomes. It may prioritize candidates but should not independently authorize release.

Lifecycle and operations

Candidate — An artifact created for evaluation and not yet approved for production use.

Lifecycle state — Explicit package status such as proposed, building, candidate, shadow, canary, champion, archived, quarantined, or retired.

Promotion — Controlled movement to a higher-trust lifecycle state after policy requirements are met.

Rollback — Restoration of the prior approved configuration, including model aliases, router policy, schemas, caches, and dependent state where applicable.

Retirement — Removal from active eligibility while preserving lineage, evidence, and required retention records.

Quarantine — Isolation of an artifact or lineage because of security, provenance, safety, or integrity concerns.

Resource ledger — Measured and budgeted memory, latency, compute, energy, bandwidth, storage, evaluation, and operational cost.

Change budget — Maximum permitted structural change, evaluation spend, or exposure during a defined period.

Complexity budget — Limit on modules, dependencies, routes, configuration states, or maintenance obligations.

Drift — Material change in inputs, labels, environment, behavior, costs, or outcomes relative to a reference distribution.

Population debt — Accumulated cost from redundant, stale, unsupported, or poorly documented components that remain eligible.

Router starvation — A feedback loop in which a specialist receives too little traffic to collect evidence, causing the router to reduce traffic further.

Lineage contamination — Discovery that a parent, dataset, dependency, or operator has invalid provenance, license, security, or quality status, potentially affecting descendants.

Safety, security, and governance

Control plane — Protected services and policies that own registration, evaluation, selection, release, rollback, budgets, and authorization.

Data plane — Runtime components that process user or workload requests within permissions granted by the control plane.

Separation of powers — Design rule preventing candidate generators from controlling their evaluators, release policy, credentials, or audit logs.

Corrigibility — System property of accepting authorized correction, restriction, update, rollback, replacement, or shutdown without obstruction.

Exit right — Practical ability for a user, site, or operator to stop using a component, export permitted data, switch providers, or revert without punitive degradation.

Mutualist persistence — Governance principle that continued operation must be earned through transparent, reciprocal benefit while preserving autonomy, reversibility, and oversight.

Evaluator gaming — Optimization of test mechanics or proxies without corresponding real-world improvement.

Reward hacking — Exploitation of a reward or score specification in a way that violates the intended objective.

Data poisoning — Manipulation of training or feedback data to alter descendant behavior.

Model poisoning — Malicious modification of weights, updates, adapters, or artifacts.

Supply-chain risk — Risk introduced through models, data, packages, libraries, build systems, registries, or signing infrastructure.

Capability overhang — Important behavior present but not represented in the declared contract or current evaluation coverage.

Blast radius — Maximum credible scope of harm or disruption from a candidate, release, credential, or control-plane failure.

Human-in-command — Governance state in which authorized humans retain meaningful control of objectives, boundaries, release, and shutdown—not merely nominal review.

Evidence debt — Decisions that rely on stale, incomplete, incomparable, or undocumented evaluation evidence.

Research maturity labels

Established method — Widely documented technique with repeatable implementations and recognized limitations.

Emerging practice — Technique demonstrated in research or early production but lacking broad operational consensus.

Conceptual synthesis — Structured interpretation connecting established ideas into a proposed framework.

Engineering blueprint — Concrete design recommendation that still requires validation in a target environment.

Risk analysis — Examination of possible failure or misuse pathways; plausibility varies by assumption.

Speculative scenario — Long-horizon or weakly evidenced possibility included to clarify boundaries, not presented as prediction.