Variant Lineage Log¶

Register — instantiates Variation–Selection–Retention Engine Design

A running record of every variant's ancestry and fate — losers included — so the engine can trace which forebear a trait, or a failure, descends from.

When a trait — or a failure — surfaces in a population of variants, the first question is where did it come from, and it can only be answered if the ancestry was kept. Variant Lineage Log is that memory: a running record in which every variant carries an identity and a link to its parent(s), and each generation's outcome — survived, reproduced, or died, and with what score — is appended, building an ancestry graph of the whole engine over time. Its defining discipline is that it logs the losers as well as the survivors. A record of only what won can tell you the population's current state but never why selection went the way it did; it is that causal, cross-generation traceability — parentage preserved, not just a snapshot — that the log exists to provide.

Example¶

A specialty-chemicals maker improves a coating formulation the way most products actually evolve — a long series of small tweaks, each shipped because it tested a little better than the last. Months later a batch fails in the field: the coating cracks in cold weather. Without a lineage record the team faces hundreds of undifferentiated changes and no way to tell which one introduced the weakness.

With a Variant Lineage Log, every formulation carries an ID and a parent link, and each version's test results — including the ones that were rejected — are recorded. The team walks the ancestry back from the failing batch, finds the branch point where cold-crack performance first dropped, and sees that the culprit change had been retained only because the test suite at that time never checked low temperatures. The log does not fix the formulation, but it converts "somewhere in a year of changes" into a single identified ancestor — and shows that the losing variants, had anyone read them, had flagged the same risk generations earlier.

How it works¶

Every variant is assigned a stable identity and a link to the parent(s) it descends from, and each generation appends that variant's fate — retained, reproduced, or pruned — together with the score and conditions under which it was judged. The accumulating parent-child links form an ancestry graph rather than a flat metrics table, which is what makes retrospective queries possible: which ancestor first introduced this trait, which lineage is the common source of this failure, how concentrated is the current population's ancestry. The move that separates it from an ordinary log is retaining the pruned variants and their reasons; the cases selection removed are exactly the ones that later explain why the survivors won, and a survivors-only record has thrown that explanation away.

Tuning parameters¶

Granularity — log every variant or a representative sample. Finer enables precise tracing but grows storage and write cost; coarser is cheap but leaves gaps in the ancestry.
Loser retention — whether, and for how long, pruned variants are kept. Keeping them is the whole defence against survivorship bias; dropping them to save space quietly destroys the log's explanatory power.
Record depth per node — identity and parentage only, or also scores, environment, and the specific mutations applied. Richer nodes answer more questions later but cost more to capture at the time.
Retention horizon — how many generations back the graph is kept. Deeper horizons enable long-range ancestry queries but the record grows without bound.
Link fidelity — how reliably parentage is captured when variants recombine or have several parents. Low fidelity turns a clean tree into a guess.

When it helps, and when it misleads¶

Its strength is that it makes selection auditable: a trait or a failure can be traced to the forebear that introduced it, inherited failure modes can be told apart from fresh ones, and the concentration of the population's ancestry becomes a signal other mechanisms can read. It is the engine's institutional memory of what it has already tried and how each attempt fared.

Its failure modes are quieter than most. Logging only survivors bakes in survivorship bias — the record cannot explain what selection removed, because what selection removed is exactly what is missing.^[1] The log is descriptive, not causal: a lineage correlating with an outcome is a lead, not a proof, and reading it as proof invents ancestral villains. And an unread log is dead weight — the classic misuse is keeping it for compliance while never querying it, or pruning the losers to reclaim storage and thereby discarding the one thing that made it worth keeping. The discipline is simple to state and easy to skip: log the losers, and actually query the graph.

How it implements the components¶

Variant Lineage Log realizes the retention-memory side of the archetype's machinery — the single component that gives the loop a past:

retention_and_lineage_memory — it is the engine's memory: the persistent ancestry graph of what was retained, what each variant descended from, and what it in turn produced, losers kept alongside winners.

It records but neither decides nor acts. It does not set the rule for what persists (differential_persistence_rule → Retention / Pruning Protocol), draw the population's boundary (variant_population_boundary → Selection Loop Map), enforce a diversity floor on what it observes (variance_floor_or_diversity_reserve → Variance Floor Trigger), or judge whether the recorded scores track real fitness (fitness_metric_or_survival_proxy → Fitness Proxy Audit).

Instantiates: Variation–Selection–Retention Engine Design — it supplies the retention-and-memory the "R" of the loop depends on, without which selection cannot learn.
Sibling mechanisms: Variance Floor Trigger · Retention / Pruning Protocol · Selection Loop Map · Fitness Proxy Audit · Champion–Challenger Rotation · Selection Pressure Sandbox · Generation Cadence Review · Environmental Shift Retest · Multi-Pressure Tradeoff Matrix · Escape Variant Watchlist · Adverse Adaptation Red Team

Notes¶

Keeping the pruned variants is the design decision that makes this more than a registry of the current population. A survivors-only record answers "what do we have now"; the losers are what let it answer "why", and "why" is the only question a selection engine actually needs its memory for.

References¶

[1] Reasoning only from the variants that survived, while the ones selection removed are absent from view, is survivorship bias — and the removed cases often carry the information that explains the outcome. A lineage log defeats it only to the extent that it retains the losers rather than quietly dropping them. ↩