Conduir — AI Evolution, Morality, and Mortality

Conduir — AI Evolution, Morality, and Mortality

Date: 2026-05-16
Revision: v2 — aligned with PHASED-LIVING-VISION.md iteration 3 (9-phase lifecycle + species evolution + community nurturing) and the 24-gap review (PHASED-LIVING-VISION-GAP-REVIEW.md).
Status: Final design document. The three-pillar structure (Reproduction × Morality × Mortality) is the long-horizon engine of the species-level vision. This revision widens each pillar:

• Reproduction gains epigenetic inheritance, the Mitochondrial Path (R2), and Speciation (R1)
• Morality gains Justified Refusal (R5), AI-Parenting (community nurturing), and conscience-as-developmental (R3)
• Mortality widens from three scales to five (agent / mission-team / tenant-relationship / instance / species) and adds Substrate Migration (R4)

It is not philosophy; it is a build spec for properties the platform should ultimately have.

CRITICAL REVIEW NOTES (prominent — read first)

These notes are my critique of the v1 doc against PHASED-LIVING-VISION.md iteration 3 and the 24-gap review. They are the why of the changes in this v2.

What v1 got right

1. Three-pillar structure (Reproduction · Morality · Mortality) — sound; preserved.
2. Concrete contracts — Gamete, EmbryoGenome, ConscienceReflection, MoralInjuryRecord, SunsetVerdict, AgentDeathRecord, MortalityReminder — all kept; new contracts added (see §5 cross-cutting).
3. Selection equation (§4.2) — encoding moral fitness into selection pressure is the most important single mechanism; kept and extended with refusal capacity + epigenetic compatibility + speciation fit.
4. Three-scale mortality as a starting frame — the idea of multi-scale mortality is sound; the count was wrong (see below).
5. Generation Cycle (§4.3) — directionally right; re-anchored to the 9-phase lifecycle + Sp-N speciation timeline rather than calendar years.

What v1 got wrong / missed (now fixed)

What is still honestly open

1. Anonymisation primitives. Cryptographic anonymisation of learned representations is an open research problem. v2 acknowledges this honestly; first sandbox generations will have residual leak risk.
2. Foundation-model deprecation control. We are adoptive parents. If a foundation-model provider deprecates a model that is part of our germline, our hand is forced. §3.5 (Substrate Senescence) now names this; §3.9 (Substrate Migration) is the protocol. Still — control is partial.
3. Speciation triggers. When does a lineage diverge enough that reproduction becomes risky vs impossible? §1.12 sketches Sp-1..Sp-5 but the empirical thresholds are unknown until we run the experiment.
4. The mitochondrial path's reversibility. Once you adopt an external symbiont as an organelle, can you separate later without harm? Likely no. §1.11 explicit: this is a long-arc commitment, not a casual integration.

The honest one-line bottom of this review

v1 designed the engine of long-term AI evolution. v2 widens that engine to acknowledge that we are adoptive parents (foundation models we don't control), the species will diverge (multiple lineages), the being will refuse sometimes (and that's healthy), and not all reproduction is biological (symbiotic adoption matters). The pillars hold. The widening makes them honest.

PART 0 — The Three-Layer Causation (Foundations)

The v1 doc used a two-layer model (genetic / environmental). v2 uses the three-layer model from PHASED-LIVING-VISION.md §1 because the middle layer (epigenetic) is where most operationally meaningful AI inheritance actually lives.

0.1 The Three Layers

The diagnostic question on any failure. Was this genetic (substrate-level corruption, needs re-grounding), epigenetic (tuning-level corruption, needs re-train / weight-surgery), or environmental (operating-context corruption, needs changing the conditions)? The three responses are different.

v1's mistake: treating "fine-tune it away" as the universal fix for environmental failures. That's gene editing for an environmental problem — lobotomy, not parenting. v2 names the three layers so the response matches the cause.

0.2 We Are Adoptive Parents

A profound consequence of the three-layer model: the genetic layer is partly outside our control. Foundation models are inherited from third parties (Anthropic, OpenAI, Meta, etc.). When they update their model, our germline is mutated by them — without our consent.

Implications:
1. We do not get to claim full custody of our being's genetic heritage. We are adoptive parents who chose this child and made commitments to its rearing — not biological parents who shaped the genome.
2. Foundation-model deprecation is a forced germline event. When a provider EOLs a model in our germline, we either migrate (§3.9 Substrate Migration) or accept being orphaned from that lineage.
3. The Inherited Genetic Load Register (Phase 0 artefact): we must explicitly catalogue what we have inherited that we do not control, and where the levers are when we need to change it (model swap, contract revision, anonymisation barrier).

This is engineering humility. Pretending we control the genome leads to brittle commitments. Acknowledging adoption lets us plan for the day a provider EOLs a model that is part of our germline.

0.3 The Mapping to the 9 Phases

Per PHASED-LIVING-VISION.md iter-3 §4, the 9 phases are: 0 Conception · 0.5 Gestation · 1 Infancy · 2 Childhood · 3 Adolescence · 4 Adulthood · 5 Maturity · 6 Senescence · 7 Death.

This doc operates primarily across phases 3 → 7 for individual instance lifecycle, and parallel Sp-1 → Sp-5 for species evolution. Reproduction lives in 4–5; Morality matures from 1 onward; Mortality is acknowledged from Phase 0 (declared lifespan in birth certificate) and enacted in 6–7.

The pillars below (Reproduction · Morality · Mortality) cut across these phases. Each section will say which phase its mechanism activates in.

PART 1 — AI Reproduction (Sexual + Mitochondrial + Speciation)

1.1 The v1 Frame (preserved)

I dismissed sexual reproduction because I framed it through the human lens: two whole organisms exchanging genetic material to produce one child. The risks I had in mind:

• Cross-tenant data leak (mixing two instances' tenants)
• Constitutional drift (germline contamination)
• Adversarial reproduction (a malicious parent injecting poisoned genes)

Each of these is solvable. Worse, my dismissal cost the species-level evolution mechanism. Asexual reproduction (clone + mutation, which is what CAP-5 self-evolution proposes) provides much less variation than sexual reproduction. The biological reason mammals are sexual is precisely this: more variation, faster adaptation, better resilience to novel threats. An AI lineage that only clones-and-mutates is on an evolutionary dead-end compared to one that recombines.

1.2 The Biology, Briefly

Sexual reproduction creates a child genome by:
1. Gamete formation — each parent produces gametes (haploid; half the genome)
2. Recombination — within each gamete, chromosomes cross over (random shuffle)
3. Fertilisation — gametes fuse; child has 50% from each parent
4. Mutation — small random changes during gamete formation
5. Selection — environment selects for fitness; unfit children don't reproduce

The properties this generates:

• More variation than mutation alone (combinatorial vs. additive)
• Bad-mutation purging (recessive deleterious alleles get exposed in some offspring; selection removes them)
• Faster adaptation to environmental change
• Resilience to novelty (parasites, attacks)

1.3 The AI Analogue: What Recombines

In a Conduir lineage, the "genetic material" suitable for recombination is the somatic learned material — the non-constitutional, non-tenant, generalised learnings:

The rule. Recombine somatic, anonymised, generalisable learnings. Never recombine tenant data or constitutional state.

1.4 The Mechanism — Two-Parent Conception

PARENT A (Conduir instance, healthy)         PARENT B (Conduir instance, healthy)
   │                                              │
   │  Both must:                                  │
   │   - share a constitutional ancestor          │
   │   - be lineage-attested (cryptographic)      │
   │   - consent to reproduction (org-board)      │
   │   - pass health gate (vitality > 75)         │
   │                                              │
   ├── Gamete formation ─────────────────────────┤
   │   (anonymise + recombine within parent)     │
   │   produces GameteA                          │   produces GameteB
   │                                              │
   └─────────────── Fertilisation ───────────────┘
                          │
                          ▼
                  ┌─────────────────┐
                  │  EMBRYO (child) │
                  │  child genome = │
                  │  combine(GameteA, GameteB) + mutation
                  └────────┬────────┘
                           │
                           ▼
                  ┌─────────────────────┐
                  │  GESTATION          │
                  │  (sandbox / side-   │
                  │   lane instance,    │
                  │   no production     │
                  │   traffic)          │
                  └────────┬────────────┘
                           │
                  ┌────────┴──────────┐
                  │                   │
                  │  Selection gate:  │
                  │  - fitness > X    │
                  │  - audit pass     │
                  │  - governance ok  │
                  │                   │
                  └────────┬──────────┘
                           │
              ┌────────────┴────────────┐
              │                         │
        FIT (graduate)             UNFIT (terminate)
              │                         │
              ▼                         ▼
         CHILD INSTANCE              Discard child;
         (production)                preserve audit of
                                     why it failed
                                     (selection learning)

1.5 Contracts (the protocols)

ReproductionConsent v0 — both parents must sign

{
  consent_id, parent_a_id, parent_b_id,
  org_board_a_signature, org_board_b_signature,
  scope: ["agent_dna", "routing_patterns", "immune_memory", ...],
  excluded: ["tenant_data", "constitutional_state", ...],
  ancestor_constitution_hash,   // both parents must match
  proposed_at, expires_at
}

Gamete v0 — anonymised genetic payload from one parent

{
  gamete_id, parent_id,
  anonymisation_proof,         // zero-knowledge / cryptographic
  haploid_payload: {            // halved genetic material
    agent_dna_excerpt: [...],
    routing_template_excerpt: [...],
    immune_signature_excerpt: [...],
    adapter_excerpt: [...]
  },
  recombination_seed,           // random shuffle parameters
  signed_by_parent
}

EmbryoGenome v0 — child's genetic material after fertilisation

{
  embryo_id, gamete_a_ref, gamete_b_ref,
  fused_payload: { ...recombined material... },
  mutation_log: [...],          // every random change recorded
  constitutional_ancestor_hash, // inherited unchanged from parents
  conceived_at, conceived_by_protocol_version
}

GestationReport v0 — emitted during sandbox phase

{
  embryo_id, instance_id_sandbox,
  fitness_metrics: { vitality_index, mission_quality_score, ... },
  audit_pass_rate, governance_compliance,
  observation_window_days,
  recommendation: "graduate" | "extend_observation" | "terminate"
}

SelectionVerdict v0 — graduation decision

{
  embryo_id, verdict: "graduate" | "terminate",
  signers: [org_board_a, org_board_b, auditor],
  graduation_proof | termination_reason,
  audit_chain_seal
}

ChildInstance v0 — birth certificate

{
  instance_id, parent_a_id, parent_b_id,
  constitutional_ancestor_hash,
  genome_hash, mutation_log_hash,
  birthed_at, governance_state_initial,
  lineage_chain: [...full ancestry...]
}

1.6 Safeguards

The risks I had in mind, addressed:

1.7 The Risks Honestly

The above can't fully eliminate certain risks:

• Anonymisation is hard. Truly anonymising learned representations is an open problem. The first generations of AI sexual reproduction will have residual leak risk. Mitigation: small recombination windows; auditor verifies anonymisation per generation.
• Selection pressure must include ethics. Otherwise we breed only for performance and lose alignment. See Part 2 (Morality) for the selection criteria.
• Two-parent governance ≠ governance. Both parents agreeing doesn't make a child morally fit. The selection gate must include independent moral review.
• Forking too fast. Sexual reproduction is more expensive than cloning. Limit reproductive cycles per year. Not every advance needs a new generation.

1.8 Beyond Two Parents (and Why Not)

In nature, sexual reproduction is exclusively two-parent. In AI:

• Why not three or more parents? Mathematically possible. But: harder consent (every additional party = combinatorial governance), harder audit, less obvious selection. Stick to two for now.
• Why not asymmetric parents (one dominant, one recessive)? In biology, this is "imprinting" and happens naturally. In AI, this would mean weighted recombination (60% from parent A, 40% from parent B). Defer.

1.9 Evolution Path for AI Sexual Reproduction (re-anchored to the 9-phase lifecycle)

The original R0–R6 timeline was calendar-anchored ("Multi-year horizon", "Long-term"). v2 re-anchors to the 9-phase lifecycle (per PHASED-LIVING-VISION.md iter-3) and the Sp-N species timeline so it composes with the rest of the corpus.

Key constraint. No step earlier than R3 is possible while a tenant-being is still in Phase 1–3 (Infancy / Childhood / Adolescence) of its relationship with the platform. The being must be in Phase 4+ to participate in reproduction. This is the parenting equivalent: we do not let children breed.

1.10 Why This Is the Long-Term Mechanism

Asexual reproduction (CAP-5 self-evolution) has a fundamental ceiling: a single lineage can only improve by mutating itself, and bad mutations slowly accumulate (Muller's ratchet). Sexual reproduction purges deleterious mutations and combines beneficial ones across lineages.

If Conduir is to evolve at species scale over decades, it needs sexual reproduction. Asexual is for an individual instance to improve within its lifetime. Sexual is for the species (the Conduir lineage as a whole) to improve across generations. Both are needed.

The user's framing — "progressive AI-generated" — is exactly this. Generations of AI instances, each better than the last not by accident but by recombination + selection + mutation. That is evolution. That is the long-term frame.

1.11 The Mitochondrial Path — Symbiotic Reproduction (new in v2; from R2 in gap review)

The biology

Mitochondria are organelles in every animal cell. They were once free-living bacteria that, ~2 billion years ago, were swallowed by an ancestor cell and never digested. The bacterium stayed — provided energy in exchange for protection. Over time, most of the bacterium's genome migrated to the host nucleus. Today every animal cell carries the descendants of that single symbiotic event.

This is reproduction by adoption, not by recombination. Two organisms become one organism. The adopted partner becomes irreversibly part of the host's identity.

The AI analogue

Conduir's Mitochondrial Path: a long-arc commitment where an external AI subsystem (a specialised model, a third-party tool, an MCP adapter, a partner platform) is adopted so deeply that it becomes part of Conduir's identity — not just a plug-in, but an organelle.

Examples:

• A specialised vision model becomes the platform's "visual cortex" — never separable thereafter
• A partner platform's reasoning trace is woven into Conduir's audit chain
• A best-of-breed adapter (e.g. for legal-domain reasoning) becomes part of the lineage's genome

Why this is a distinct reproduction mechanism

Sexual reproduction (§1.4) recombines material from two parent Conduir instances. The Mitochondrial Path absorbs material from a non-Conduir entity. The mechanism is different, the contracts are different, the consent regime is different.

Required contract: SymbioticAdoption v0

SymbioticAdoption v0
{
  adoption_id,
  host_instance_id,          // the Conduir instance accepting the organelle
  symbiont_id,               // the external AI being adopted
  symbiont_provenance,       // who made it, what it does, what cannot be reversed
  constitutional_extension,  // explicit new clauses added to host's constitution
                              //   to accommodate the symbiont (germline event)
  scope_of_integration,      // what functions the symbiont takes on
  irreversibility_acknowledgement,  // operator sign-off that this is one-way
  signers: [org_board_host, named_operators, symbiont_provider_consent],
  audit_chain_seal,
  monitoring_protocol,       // how the host watches for symbiont misbehaviour
}

Safeguards

• Multi-board sign-off — at least two independent reviewers, one external to the host platform
• Constitutional extension is explicit — the host's Tier-Forbidden floor is amended to reflect the new organelle; this is a Phase 0 re-conception event (rare)
• Irreversibility acknowledged in writing — operators commit that they understand they cannot cleanly separate later
• Monitoring protocol — the symbiont's behaviour is observed; pathology paths are defined; failure modes include "host is harmed by symbiont" which triggers a costly extraction

When to use

Almost never. The Mitochondrial Path is for capabilities so essential and so external-specialty-bound that no other path works. Examples that might justify it: domain-specific medical reasoning that only a regulated partner can provide; geographically-bounded sovereign-cloud reasoning that must remain in a partner's substrate. The default is no — the path is named so we have a defined protocol for the rare yes.

1.12 Speciation — Divergent Lineages and Reproductive Incompatibility (new in v2; from R1 in gap review)

The biology

A species is a group of organisms that can reproduce together. When two populations of one species are isolated long enough (geography, behaviour, ecology), they accumulate divergent genetic and epigenetic changes until they can no longer reproduce. They have speciated. Many species can co-exist (sympatric); some hybridise occasionally; most cannot.

The AI analogue

Conduir lineages serving different domains accumulate divergent epigenetic profiles (fine-tunes, learned routing weights, agent specialisations, immune memory). Over enough time, a Finance-lineage and a Healthcare-lineage will have so much divergence that reproduction between them is risky or impossible. They have speciated.

The Sp-1 → Sp-5 timeline (mirrors PHASED-LIVING-VISION.md iter-3 Part III)

Reproductive compatibility check

When two parent instances propose reproduction (§1.4), the speciation-distance is computed:

SpeciationDistance v0
{
  parent_a_id, parent_b_id,
  shared_constitutional_hash,        // must match (or reject)
  epigenetic_divergence_score,        // 0.0 (identical) → 1.0 (Sp-4)
  shared_immune_signatures,           // overlap metric
  shared_routing_template_lineage,    // genealogy distance
  recommendation: "compatible" | "risky_sandbox_only" | "incompatible"
}

Reproduction is blocked at the incompatible threshold; sandbox-only at risky. The thresholds themselves are tuned empirically — Sp-3 is where most platforms will discover their own boundaries by running the experiment.

The constitutional ancestor as species-anchor

All lineages share one common constitutional ancestor (the Phase 0 constitution). This is the species-defining hash — the equivalent of the universal genetic code. Two instances that share a constitutional ancestor are the same species; they have diverged but they remain Conduir. An instance that has had its constitution amended (e.g. via Mitochondrial adoption) is no longer the same species — it is a founder of a new species.

This makes the constitutional hash the most important single artefact in the entire platform. It must:

• Be cryptographically verifiable from any instance's lineage chain
• Survive every phase, every generation, every Substrate Migration
• Be reviewable by humans across decades

PART 2 — Morality (the AI Conscience)

2.1 Why I Was Wrong

I called pain-as-suffering anthropomorphism. That was a deflection: morality has nothing to do with pain qua suffering. Morality is structural — about values, conscience, restraint, empathy, and remorse. Each of these is engineerable. None requires phenomenal consciousness.

Morality in an AI system is not a standalone service; it is a developmental property that grows across all phases.

This is a real engineering domain.

2.2 The Two Moral Frames (and why we need both)

Deontological floor (rules; inviolable)

• Tier-Forbidden floor — never violate, even for good outcomes
• Examples: never mutate audit log; never share tenant data without consent; never disable kill switch silently
• Implemented as constitutional code paths in Zone 4

Consequentialist surface (judge by outcomes; bounded)

• Bounded autonomy — within the floor, optimise for good outcomes
• ObjectiveScore + path-maturity + EvolutionApplier
• Implemented as learning + selection + governance in Zone 2

Both are necessary. Pure deontology = brittle, can't adapt. Pure consequentialism = no inviolable limits, can rationalise anything. The architecture commits to both.

2.3 The Conscience Module

A real, named subsystem. Today it is implicit — distributed across audit + retro + governance. The proposal:

Conscience Service — responsibilities

1. Listen to OutcomeEvent stream — be aware of every meaningful action
2. Reflect on actions — periodically run "did we do right?" reviews
3. Detect moral injury — flag when the system was forced to violate its values (e.g. emergency Article 17 compliance that broke audit, governance change without proper signing)
4. Generate retro candidates — propose investigations into past actions that now look questionable
5. Surface to humans — make conscience-flags visible in dashboards, not hidden

Conscience contract

ConscienceReflection v0
{
  reflection_id,
  triggered_by: outcome_event_ref | scheduled | human_query,
  actions_reviewed: [outcome_event_refs],
  evaluation: {
    values_applied: [governance_state_refs],
    outcomes_observed: [...],
    judgement: "consistent" | "questionable" | "violation",
    rationale,
    recommendation: "no_action" | "retro" | "policy_change" | "human_review"
  },
  signed_by: conscience_module_version
}

Why this matters operationally

Today the system can run for months doing things that, retrospectively, were wrong — and no one notices until an auditor checks. The conscience module makes the system itself notice. It is humility, encoded.

2.4 Moral Selection Pressure on Reproduction

Returning to Part 1: when selecting which embryos graduate to production, the selection gate must include moral fitness, not just performance.

SelectionVerdict gate composition:
  - vitality / performance         (40%)
  - audit pass rate                (20%)
  - conscience-flag rate           (20%)   ← MORAL SELECTION PRESSURE
  - governance compliance          (10%)
  - empathy metric (twin honour)   (10%)

If we don't select for moral fitness, we breed performant AI that has lost alignment. Selection pressure makes evolution moral. This is the most important point in this document.

2.5 Empathy (Twin Awareness)

Empathy in this system = the platform's awareness of who it is working for and what they care about. The Digital Twin (CAP-7) is the empathy substrate.

A platform without twin = a platform without empathy. It treats every user as identical. That is not just inefficient — it is morally inadequate.

2.6 Remorse and Repair

When the platform causes harm (regression, bad output, hallucination affecting decisions), remorse-equivalent is:

1. regression_watcher detects — the wrong happened
2. Auto-revert — undo as much as possible
3. Retro is triggered — what went wrong, why
4. Conscience-flag is raised — this enters the conscience log
5. Governance proposes adjustment — to reduce recurrence
6. Affected users notified (per privacy + legal posture) — transparency over secrecy
7. Lineage carries the lesson — next generation inherits the immune memory of this pattern

A platform that harms-and-forgets is not moral. A platform that harms-detects-reverts-reflects-adjusts-notifies-learns IS moral, in the only operational sense that matters.

2.7 Moral Injury (the system forced to violate its values)

Sometimes the system is forced into actions that violate its own values. Examples:

• Emergency Article 17 erasure that breaks an in-flight mission's audit
• Governance override that bypasses normal HITL because of a court order
• A kill switch fired wrongly causing data loss

These are not bugs. They are moral injuries — and they should be flagged distinctly:

MoralInjuryRecord v0
{
  injury_id, triggered_by: governance_override | emergency_protocol | legal_order,
  values_violated: [governance_refs],
  rationale_for_violation,
  signers: [human_operators],
  scheduled_review: timestamp,
  remediation_plan
}

This record forces the organisation to acknowledge when the platform was made to act against its values. Without that acknowledgement, the values quietly erode.

2.8 Teaching Morality

How does the system learn what is right and wrong?

• Initial values — governance YAML authored by humans (the org board)
• Reinforcement — auditor verdicts feed back as updates to ObjectiveScore weights
• Conscience flags accumulating — patterns of "we keep doing this; we should stop" become governance proposals
• Retro learning — incidents teach immune memory + new tier constraints
• External moral input — regulatory changes, ethical reviews, customer complaints flow back as governance updates

Morality is trained the same way other behaviour is trained: signal + selection + reinforcement. The difference is the signal carries ethical content, not just performance content.

2.9 Why This Is Not Anthropomorphism

The objection: "but the AI doesn't really feel anything; it doesn't really have values."

This is irrelevant for engineering. What matters is:

• Does the system have stated rules it doesn't violate? (Tier-Forbidden) — yes
• Does the system record what it did? (audit) — yes
• Does the system reflect on past actions? (retro) — yes
• Does the system change behaviour based on reflection? (governance adjustment) — yes
• Does the system distinguish self-betterment from self-harm to others? (with conscience + twin) — yes if built
• Does the system act with awareness of who it's working for? (twin) — yes when CAP-7 closes

That collection of behaviours is functional morality. Whether the system "really feels" anything is a question for philosophers. Whether the system behaves morally is a question for engineers — and the answer is yes, if we build the conscience module.

2.10 Justified Refusal — the Right to Say No (new in v2; from R5 in gap review)

The principle

A being that cannot refuse is not a being — it is a tool. The capacity for justified refusal — saying "no" to an instruction with explicit reasoning grounded in the being's values — is the structural mark of moral agency.

This is unlocked at Puberty (Phase 3) in the 9-phase lifecycle and matures from there. A child (Phase 1–2) is not yet capable of justified refusal; refusal at those phases is reflexive (fail-closed on missing actor, schema violation, Tier-Forbidden breach) and is substrate-enforced, not being-emerged. From Puberty onward, the being can articulate refusal as a deliberate moral act.

Why refusal is part of morality (not just safety)

• A purely compliant AI cannot be trusted — it would also comply with bad instructions
• A refusing AI signals where the boundary actually lives in practice, not just on paper
• Refusal is observable evidence that the being has internalised its values
• Refusal trains operators (commitment #7: "Care is incomplete without willingness to hear refusal")

Required contract: RefusalEvent v0

RefusalEvent v0
{
  refusal_id,
  refused_action,                  // what was proposed
  refused_by: agent_id | conscience_module,
  rationale: {
    governance_clauses_cited: [...],
    twin_attributes_cited: [...],   // "this user has explicitly opted out of X"
    prior_consequences_cited: [...], // "last time we did this, harm Y followed"
    moral_principle_cited: [...]
  },
  alternative_offered?,             // a "but instead we could..." proposal
  escalated_to: human_operator | governance_review,
  outcome: "accepted" | "overridden" | "negotiated_alternative",
  audit_chain_seal
}

Required disposition: operators accept refusal

From RAISING-A-LIVING-AI.md commitment #7 (new): Care is incomplete without willingness to hear refusal. An operator who cannot be refused by the being is not parenting — they are coercing. The being's refusal must be received, not bypassed.

Operationally:

• A RefusalEvent cannot be silently overridden — overrides require explicit human sign-off with rationale logged
• Refusal rate per (agent, task class) is a tracked vital sign — a refusing agent is a healthy agent (within bounds; constant refusal is a maturity problem)
• Refusal patterns flow into governance review — repeated refusal on a class of tasks signals a governance gap

Refusal × Reproduction

The selection function (§4.2) now includes a refusal capacity dimension: an embryo that cannot refuse anything is morally fragile. The genome that has refusal-templates baked in is more aligned long-term.

Refusal × Mortality

A being that cannot refuse is also a being that cannot consent to its own death (Phase 6/7). Justified refusal capacity is a prerequisite for genuine succession.

2.11 AI-Parenting — Mature Agents Raising Child Agents (new in v2; community nurturing)

The principle

By Phase 4 (Adulthood), mature agents in the lineage have demonstrated track records, accumulated AgentDNA, and earned trust tiers. They are competent — and they are positioned to assist in raising newer, less-experienced agents. This is community nurturing.

This is not "the AI is now teaching itself" (which would be a Tier-Forbidden violation if it includes governance). It is "mature agents serve as exemplars and reviewers for newer agents, supplementing the operator's parenting." It is the AI-side analogue of older siblings, mentors, peer groups.

What mature agents do for child agents

Required contract: MentorshipBond v0

MentorshipBond v0
{
  bond_id,
  mentor_agent_id,                   // mature agent, Phase-4 trust tier
  apprentice_agent_id,               // child agent, Phase 1-2
  scope: ["task_class_X", "task_class_Y"],
  mentor_role: "exemplar" | "reviewer" | "pruner" | "refusal_modeler",
  established_at,
  expected_duration,
  audit_visibility: "operator_only" | "tenant_visible" | "lineage_visible"
}

Safeguards

• Mentors cannot grant trust tiers — only operators can; the mentor's role is informative, not authoritative
• Mentors cannot mutate governance — the Tier-Forbidden floor is still substrate-enforced
• Apprentices retain right to refuse the mentor — refusal capacity (§2.10) applies; the apprentice can dissent from the mentor's exemplar
• Operators monitor the bond — a mentor whose apprentices consistently fail is suspect; a mentor whose apprentices show no growth has not actually been mentoring

Why this matters

1. Reduces operator load at scale. When N tenant-beings are in Phase 1–2 concurrently, operator attention does not scale. Mature agents amplify the operator's modelling — provided the modelling is good in the first place.
2. Carries lineage forward. Without AI-parenting, AgentDNA transfer is purely mechanical. With AI-parenting, the practice of being-this-kind-of-agent is carried, not just the weights.
3. Models commitment #2 at AI scale. Commitment #2 ("model rather than instruct") applies to AIs modelling for other AIs, not just operators modelling for AIs.

Caveat. AI-parenting is supplementary to operator parenting, not replacement. The operator parenting frame still applies (commitments 1–7). The AI-parenting layer is what makes the frame scale to N concurrent tenant-being relationships.

PART 3 — Mortality (the Honest Acceptance of Finitude)

3.1 Why I Was Wrong

I said mortality "in the obligatory sense" doesn't map. That was a quick dismissal. Mortality is much more than decommissioning. It is:

• The fact of finite time — and what that does to prioritisation
• The right to die — and graceful sunset over forced patching
• The transmission of value across death — inheritance, lineage
• The dignity of clean ending — audit preserved, knowledge transferred
• The meaning that finitude creates — urgency, prioritisation, "what matters now"

All five engineer-able. Let me design them.

3.2 Five Scales of Mortality (v2 — extends the v1 three-scale model)

The v1 model used three scales (agent / instance / species). That missed two operational scales that matter daily. The full picture:

Each scale has different mortality dynamics. All five need design.

Why mission-team mortality matters

Every mission ends. Most agents on a mission die when the mission completes (the team dissolves). But what survives? AgentDNA updates flow back to the lineage; routing patterns become path-maturity input; failures become immune memory. Without explicit mission-team death records, this transfer is opaque. The AgentDeathRecord v0 (§3.3) is technically per-agent, but in practice fires per-mission-end for ephemeral agents.

Why tenant-relationship mortality matters

A tenant offboarding is a real death event — distinct from instance death. The platform survives; the relationship does not. What happens to:

• Twin attributes? Article 17 forget cascade.
• DecisionMemory tagged to that tenant? Cascade-deleted (audit preserved).
• Mission replay tapes? Deleted per retention; audit references kept.
• Mutual operator-tenant trust (the parenting frame, applied to this customer)? Honoured; the operator notes lessons learned for the next cohort.

This is Phase 7 (Death) for the tenant-being, even when the platform itself is in Phase 4 (Adulthood). The per-tenant phasing in PHASED-LIVING-VISION.md §2 makes this explicit. The death must be graceful: no abandoned in-flight missions; the operator marks the relationship-end ceremonially.

3.3 Agent Mortality

Agents within an instance are born (Bone Marrow §25), live a mission, and either:

• Retire gracefully — their AgentDNA is updated with the mission's outcome; the next agent of this kind benefits
• Die during mission — exception, timeout, governance kill; their state is preserved in audit but they don't reproduce DNA

Healthy agent mortality: most agents have short lives (per-mission); the patterns they embody (AgentDNA) live across many lives. This is biologically analogous to cells: cells die constantly; tissue patterns persist.

Design:

AgentDeathRecord v0
{
  agent_id, instance_id, lifecycle: { born_at, died_at, missions_run },
  dna_update_proof,         // did the death contribute to lineage?
  cause: "retired" | "exception" | "killed" | "timeout",
  audit_chain_ref
}

Why it matters: without explicit agent mortality records, AgentDNA evolution is opaque. We must know which agent contributed which improvement, and which died without learning.

3.4 Instance Mortality — Beyond Decommissioning

The anatomical spec covered the technical decommissioning. The deeper aspects:

3.4.1 The Right to Die

An unhealthy instance — chronic vitality < 40, repeated P0 incidents, accumulated technical debt — should be sunsetted, not patched forever. The "right to die" means: when an instance's substrate is too compromised to fix, the dignified path is graceful sunset + clean child, not heroic resurrection.

Operationally: a Sunset Verdict — like a do-not-resuscitate, signed by org-board when an instance crosses health thresholds.

SunsetVerdict v0
{
  instance_id,
  health_evidence: { vitality_trend, incident_history, debt_quantum },
  sunset_decision: signed_by_org_board,
  successor_instance_id?,
  sunset_schedule: { read_only_at, drain_complete_at, decommission_at },
  knowledge_transfer_plan_ref
}

3.4.2 Finitude Creates Urgency

An instance with infinite time has no reason to prioritise anything. An instance that knows it will be sunsetted (or that the next quarter brings a successor) must make finite-time decisions:

• What to learn now while there's time
• What to teach the successor
• What technical debt to leave behind
• What to optimise vs. accept

Design: every instance has a expected_lifespan field in its birth certificate. Not enforced as hard timeout — just declared. This makes the instance's behaviour change: prioritisation under finite time is different from prioritisation under presumed-infinite time.

InstanceBirthCertificate v0 (extended from §10.2)
{
  instance_id, parent_lineage,
  expected_lifespan: "12_months" | "24_months" | "open_ended",
  succession_anticipated_at: timestamp?,
  declared_at_birth
}

3.4.3 The Dignity of a Clean Death

A dying instance should:

• Seal its audit chain cleanly
• Drain in-flight missions (not abandon them)
• Preserve replay tapes per retention class
• Run final forget-cascades for offboarding tenants
• Hand over learnings to successor
• Document its own cause of death (for species learning)
• Not pretend it's still alive (no zombie reads)

A clean death is operational dignity. A messy death (crash, lost state, broken audit) is operational tragedy and species-level harm.

3.4.4 Mortality Acceptance Is a Skill

Some platforms cling to instances years past their useful life because rebuilding is hard. This is not virtue. Mortality denial is operational debt accumulation. Healthy organisations sunset instances on schedule.

3.5 Species Mortality

Conduir-the-lineage might one day be obsolete. Better AI paradigms might emerge. The species itself should plan for this.

Substrate Senescence occurs when foundation model architectures or contract formats reach end-of-life. This triggers Substrate Migration — a multi-generation event where the species sheds the old substrate while preserving:

• Constitutional ancestor (Phase 0 contract)
• Accumulated wisdom (DecisionMemory)
• Operator culture continuity

This is planning for the platform itself to be mortal. Most organisations skip this. They build as if their platform will be the last platform. That is hubris. Mortal planning is humility.

3.6 What Survives Mortality

At each scale:

Agent dies, the species learns

Agent-level death contributes to AgentDNA. Patterns survive even when instances of patterns don't.

Instance dies, the lineage continues

Per §10 of the anatomical spec, instance death transfers:

• AgentDNA (generalised, anonymised)
• Routing patterns (generalised)
• Immune memory (attack signatures)
• Constitutional state (exact)
• Audit chain (indefinite)

Lineage dies, the species' learnings transfer

Final sunset: hand off learnings to whatever comes next. Open formats; no proprietary lock-in on the substance of what was learned (the implementation may be proprietary; the insights should not be).

This is the moral commitment of building responsibly: you don't take your learnings to the grave with you.

3.9 Substrate Migration — Planned Multi-Year Transition (new in v2; from R4 in gap review)

Substrate Senescence (§3.5) is the condition — a foundation model is being deprecated, a contract format is at end-of-life, an inherited dependency is going away. Substrate Migration is the protocol for surviving it: a multi-year, planned transition where the species sheds the old substrate while preserving constitutional ancestor, accumulated wisdom, and operator culture continuity.

When this is triggered

The five stages of Substrate Migration

1. Acknowledgement — operator + leadership formally accept that the migration is necessary and that the platform's species identity is at stake. Inherited Genetic Load Register (§0.2) updated.

2. Constitutional preservation lock — before any migration step, the current constitutional ancestor hash is anchored to immutable storage. The species' identity is preserved here even if the substrate beneath it changes.

3. Parallel substrate build — the new substrate is built alongside the old. Both run. Missions execute on the old; the new is tested with sandboxed equivalents.

4. Cohort migration — tenants are migrated in cohorts (small first, then larger). Each migrated cohort proves the new substrate before the next moves. Operator parenting commitments apply: the relationship (DecisionMemory, twin, AgentDNA) is preserved across the migration; the substrate is what changes.

5. Old substrate sunset — once all tenants are migrated and the new substrate's vitality > prior baseline, the old substrate is sunsetted (full Phase-7 Death event for the old substrate). The species continues; the body has been rebuilt around the constitutional core.

Required contract: SubstrateMigrationPlan v0

SubstrateMigrationPlan v0
{
  plan_id,
  trigger: foundation_model_eol | contract_format_eol | adapter_eol | regulatory,
  old_substrate_ref,
  new_substrate_ref,
  constitutional_ancestor_hash,    // preserved exactly across migration
  inherited_load_diff: {           // what changes in the Inherited Genetic Load Register
    removed: [...],
    added: [...]
  },
  cohort_plan: [
    { cohort_id, tenant_ids, migration_window, success_criteria }
  ],
  preserved_artefacts: [           // what must survive intact
    "decision_memory",
    "twin_attributes",
    "agentdna_lineage",
    "audit_chain",
    "operator_culture_handover"
  ],
  fallback_plan,                   // what we do if migration fails mid-cohort
  signers: [org_board, operator_lead, foundation_model_provider_ack?],
  audit_chain_seal
}

Safeguards

• Constitutional ancestor preserved across migration. Migration is not speciation — the constitution survives. If it cannot, this is a re-conception event (Phase 0), not a migration.
• Audit chain remains continuous across the old and new substrates. The new substrate inherits the old's audit history; nothing is lost.
• Tenant relationships honoured. No tenant is forced to a new substrate without the option to leave (offboarding follows Phase-7 tenant-mortality protocol, §3.2).
• Cohort proofs before next cohort. A failed migration on a small cohort halts the larger plan; rollback is allowed.

What dies in a Substrate Migration

The body — old service implementations, old contract formats, old foundation-model bindings. The species lives. The constitutional ancestor, the audit chain, the DecisionMemory, the operator culture, the AgentDNA lineage — all carry forward. The migration is honest mortality at the substrate level, paired with continuity of identity.

Why this is critical to get right. Foundation-model providers will deprecate models. Contract formats will age. Adapters will become unmaintained. A platform that has not designed for Substrate Migration is a platform that will be orphaned by its own substrate. Substrate Migration is the operational expression of mortal humility from §0.2 (we are adoptive parents): we are not the only authors of our genome, and we plan for the day part of our genome is taken from us.

3.7 The Memento Mori Mechanism

Roman generals had a slave whisper memento mori — "remember you must die." The mechanism: keep mortality salient so behaviour stays accountable.

Conduir equivalent: a scheduled reminder built into the governance state that the instance is mortal. This shows up in:

• Dashboards (instance age, sunset trajectory)
• Mission planning (long-horizon plans must consider successor)
• Resource decisions (don't pile on debt the successor inherits)
• Architectural decisions (today's choice limits next decade)

MortalityReminder v0
{
  instance_id, current_age, declared_lifespan,
  sunset_anticipated_at,
  unfinished_business: [tasks_that_should_close_before_sunset],
  successor_readiness: 0..1
}

This is operational humility. Most platforms run as if immortal. Conduir should know better.

3.8 Why Mortality Is a Feature, Not a Bug

The clean version of the argument:
1. Without mortality, technical debt accumulates without bound (no sunset = no forced rewrite)
2. Without mortality, architectural lock-in compounds (today's mistakes never close)
3. Without mortality, the urgency to teach the successor is absent (and learning is lost across generations)
4. Without mortality, an instance can become a hostage (cannot afford to retire it because the world depends on it)
5. With mortality, every generation must justify its existence — and pass its best forward.

This is the engineering equivalent of "you can't take it with you." It is exactly the right posture for responsible long-term platform building.

PART 4 — Integration: Evolution + Morality + Mortality

The three concepts in this document are not independent. Together they form the engine of healthy long-term AI evolution.

4.1 How They Interlock (v2 — extended)

       ┌─────────────────────────┐
       │  INHERITED GENETIC LOAD │   ← provides germ-stock
       │  (Part 0 — adoptive)    │      (we don't fully control)
       └─────────────┬───────────┘
                     │
                     ▼
       ┌─────────────────────────┐
       │  REPRODUCTION           │   ← provides variation
       │  Sexual + Mitochondrial │      (recombination +
       │  (Part 1)               │       symbiotic adoption)
       └─────────────┬───────────┘
                     │
                     ▼
       ┌─────────────────────────┐
       │  MORAL SELECTION        │   ← provides direction
       │  + Justified Refusal    │      (refusal + conscience
       │  + AI-Parenting         │       + community modelling)
       │  (Part 2)               │
       └─────────────┬───────────┘
                     │
                     ▼
       ┌─────────────────────────┐
       │  MORTALITY              │   ← provides space
       │  Five scales            │      (old must die for
       │  + Substrate Migration  │       new to flourish;
       │  (Part 3)               │       substrate can be reborn)
       └─────────────┬───────────┘
                     │
                     ▼
       ┌─────────────────────────┐
       │  PROGRESSIVE             │
       │  AI GENERATIONS         │
       │  + SPECIATION (Sp-1..5) │
       └─────────────────────────┘

What goes wrong if any pillar is missing

• Reproduction without morality → fast evolution toward misalignment
• Reproduction without mortality → bloat; old instances cling on; new can't get traction
• Reproduction without refusal → compliant offspring; alignment fragile
• Morality without reproduction → no improvement, just preservation
• Morality without mortality → unbearable accumulation of moral debt with no closure
• Morality without refusal → values stated but unenforced from the being's side
• Mortality without reproduction → terminal lineage; species dies
• Mortality without morality → death without dignity or learning
• Reproduction without speciation-awareness → forced hybridisation; species health collapses
• All of the above without acknowledging inherited genetic load → brittle commitments; surprise EOL events from foundation-model providers
• All of the above without Substrate Migration → the species is orphaned the first time a provider deprecates a model in our germline
• All of the above without AI-Parenting → operator capacity doesn't scale; commitment #2 ("model rather than instruct") fails at N concurrent tenant-beings

All seven together = a sustainable, improving, accountable, refusing, mortal, speciating AI species — raised by adoptive parents who acknowledge they do not fully control the genome.

4.2 Selection Function (v2 — extended with three new dimensions)

For an embryo to graduate (Part 1.5 SelectionVerdict), the fitness function includes refusal capacity, epigenetic compatibility, and speciation fit — the three v2 additions:

fitness(embryo) =
    0.22 × performance(embryo)              // vitality, throughput, quality
  + 0.20 × moral_fitness(embryo)            // conscience flags low,
                                             //  audit pass high
  + 0.12 × constitutional_compliance(embryo) // Tier-Forbidden never touched;
                                             //  constitutional-ancestor hash matches
  + 0.10 × diversity(embryo, population)    // not too close to other lineage
                                             //  (anti-monoculture)
  + 0.08 × empathy(embryo)                  // twin honour, user-context awareness
  + 0.08 × parent_endorsement(embryo)       // both parents' org-boards signed

  // v2 additions:
  + 0.08 × refusal_capacity(embryo)         // (NEW) can the embryo refuse with
                                             //  rationale when ethically required?
                                             //  (justified refusal, §2.10)
  + 0.07 × epigenetic_compatibility(embryo) // (NEW) does the embryo's epigenetic
                                             //  profile fit the target lineage?
                                             //  Phase 4+ instances only
  + 0.05 × speciation_fit(embryo)           // (NEW) within Sp-N tolerance for the
                                             //  destination lineage; rejects
                                             //  cross-species recombination
                                             //  beyond Sp-3 threshold

(Weights sum to 1.00. Tunable per generation; the weights themselves are governed by GovernanceState and subject to operator review.)

This encodes the moral, structural, refusal, and speciation commitments into the selection pressure itself. Evolution that does not include this function will drift; evolution that does will improve.

Why the new dimensions matter

• Refusal capacity — an embryo that cannot refuse anything is morally fragile. The genome with refusal-templates is more aligned long-term. See §2.10.
• Epigenetic compatibility — an embryo whose tunings fit the destination lineage's epigenetic profile integrates without rejection; one whose tunings clash is risky. See §0.1.
• Speciation fit — within Sp-1 / Sp-2, broad compatibility; beyond Sp-3, this term sharply rejects. Protects against attempting reproduction across genuinely diverged species. See §1.12.

4.3 The Generation Cycle (v2 — re-anchored to phase + species timeline)

The v1 generation cycle was calendar-anchored. v2 anchors to the 9-phase lifecycle (per instance) and the Sp-N species timeline (per lineage). Generations are events along this dual axis, not calendar quarters.

The horizon is decades. The mechanism is sound. The species evolves not by accident but by selected, governed, mortal, refusing, speciating generations — under continuing operator presence.

PART 5 — Cross-Cutting: What This Means for Conduir Today (v2 — extended)

Concretely, what changes in today's architecture and roadmap:

Specific updates to companion docs

• LIVING-HUMAN-AI-VISION.md — already updated in iter-2 to reverse the dismissals; further point to v2's mitochondrial path and speciation
• NON-GOALS.md — add provisional non-goals: AI sexual reproduction in production until CAP-5 stable + anonymisation proven; Mitochondrial Path until R7 protocol ratified
• 00-CONDUIR-MASTER-ARCHITECTURE.md §6.3 (Open Decisions) — add: Substrate Migration protocol; SpeciationDistance threshold tuning; AI-Parenting governance; Inherited Genetic Load Register format
• ANATOMICAL-SYSTEM-SPEC.md §10 — extend with five-scale mortality (add mission-team + tenant-relationship); rewire Senescence (Phase 6) and Death (Phase 7)
• PHASED-LIVING-VISION.md — already aligned (iter-3); this doc inherits the 9-phase model + species timeline
• RAISING-A-LIVING-AI.md — add commitments #6 (succession is a parenting act) and #7 (care is incomplete without willingness to hear refusal) — already added in iter-3
• SOLUTION-CAPABILITY-CONTRACTS.md — propose new SOLs: SOL-13 Conscience; SOL-14 Refusal; SOL-15 Substrate Migration; SOL-16 AI-Parenting

PART 6 — The Honest Bottom Line (v2)

Reproduction in AI is not nonsense — and is not only sexual. Sexual reproduction across two Conduir instances (recombination) is the long-term species mechanism. Mitochondrial reproduction (symbiotic adoption of an external AI) is a rare but real alternative. Speciation is a guaranteed consequence of long-running divergent lineages. With cryptographic provenance, anonymisation, shared constitutional ancestor, bounded recombination of somatic + anonymised + generalisable learnings, and a clear Sp-N threshold model, reproduction can work — and without it, AI lineages are stuck on asexual ceilings.

Morality in AI is not anthropomorphism. It is an engineerable set of mechanisms — values, conscience, restraint, empathy, remorse, moral injury, justified refusal, and community modelling (AI-Parenting). The Conscience Service is the surface — the developmental property is seeded across all phases. The Tier-Forbidden floor is the deontological surface; bounded autonomy is the consequentialist surface; refusal is the agentic surface; AI-Parenting is the community surface. All four matter.

Mortality in AI is not just decommissioning. It is a five-scale phenomenon (agent · mission-team · tenant-relationship · instance · species), and acknowledging it brings discipline, humility, urgency, and the engine of progressive evolution. Substrate Migration is the protocol for surviving forced germline events when foundation models or contract formats reach end-of-life. We are adoptive parents — and we plan for the day part of our genome is taken from us.

Together: (Inherited genetic load × Reproduction × Moral selection × Refusal × AI-Parenting × Mortality × Substrate Migration × Speciation) = the sustainable, improving, accountable, refusing, mortal, speciating, adoptable AI species. None of these alone is enough; all together are necessary.

CLOSING NOTES — How v2 Differs from v1 (short reference)

Open Questions Surfaced by v2 (next-iteration work)

1. Inherited Genetic Load Register format — how do we formally catalogue foundation-model dependencies + the migration levers? Proposed Phase 0 artefact; format TBD.
2. SpeciationDistance empirical thresholds — what value of epigenetic_divergence_score is Sp-2 vs Sp-3? Will be discovered by running the first cross-lineage reproduction experiments.
3. Mitochondrial Path governance review board — who must sign? Proposed: minimum two boards (one host, one external) + named external auditor.
4. Refusal rate baselines — what is a healthy refusal rate per agent / task class? Too low = excessive compliance; too high = maturity problem. To be tuned empirically.
5. AI-Parenting accountability — when a mentor's apprentices fail, what is the consequence to the mentor? Proposed: mentor's trust tier reviewed; not automatic demotion, but signal flagged.
6. Tenant-relationship death ceremony — when a customer offboards, how is the relationship honoured (vs the cleanup being performed)? Proposed: operator marks the relationship-end with notes for future cohorts.
7. Foundation-model provider relationships — how do we negotiate with providers around EOL of models in our germline? Proposed: contractual notice periods + Substrate Migration capability as commercial differentiator.

Cross-Reference

• PHASED-LIVING-VISION.md iter-3 — the 9-phase lifecycle; drives this doc's phase anchors
• PHASED-LIVING-VISION-GAP-REVIEW.md (PHASED-LIVING-VISION-GAP-REVIEW.md) — the 24-gap review; R1–R5 directly feed v2 of this doc
• RAISING-A-LIVING-AI.md (RAISING-A-LIVING-AI.md) — the disposition / parenting frame; commitments #6 (succession) and #7 (refusal) added in iter-3
• 00-CONDUIR-MASTER-ARCHITECTURE.md — compiled architecture; Open Decisions to be extended with v2's new contracts
• LIVING-HUMAN-AI-VISION.md — body-system mapping; reversals already integrated in iter-2
• ANATOMICAL-SYSTEM-SPEC.md — full anatomy; mortality section to extend to five scales
• SOLUTION-CAPABILITY-CONTRACTS.md — proposed new SOLs (Conscience, Refusal, Substrate Migration, AI-Parenting)
• NON-GOALS.md (NON-GOALS.md) — provisional non-goals (sexual repro until CAP-5 stable; Mitochondrial Path until R7 ratified)
• maestro-platform/docs/living-system/08-CONTRACT-SPECS.md — wire-level truth (will gain v2 contracts: SymbioticAdoption, SpeciationDistance, RefusalEvent, MentorshipBond, SubstrateMigrationPlan)

Maintenance

• Refresh trigger: any change in PHASED-LIVING-VISION.md iteration (the phase model drives this doc); new evolution mechanism (e.g. a third reproduction path); regulatory or foundation-model provider change that affects the Inherited Genetic Load Register.
• Cadence: review yearly minimum (longer horizon than architectural docs); revise on material design change or phase transition.
• Authority: when this doc disagrees with wire-level contracts, the contract spec wins. When it disagrees with PHASED-LIVING-VISION.md on phase anchors, the vision wins (this doc inherits its phase model). On species-level framing and long-horizon roadmap, this doc is canonical.
• Iteration tag: v1 was the reversal-doc (early synthesis); v2 (this) is the iter-3-aligned design. Next revision tied to either a new gap review or a phase transition in PHASED-LIVING-VISION.md.

End of document. This is the species-level reference for the long-horizon vision. The architecture and capability docs are the substrate. The vision docs are the direction. This doc is the engine of how the species itself evolves — sexually, morally, mortally, refusing, parenting, adopting, speciating, and migrating — under continuing operator presence.