Carlos AlfredoCarpio Meza

Laboratory / Concept paper

Proposal, not a running system

Software genealogy for an age of generated descendants

CodeAncestry

A living lineage protocol for software genomes, agent inheritance, and evolutionary software ecosystems.Carlos Carpio · Independent researcher and software builder · August 2026

Software can already be copied, forked, packaged, and deployed. What it cannot do is explain itself: which capabilities a project inherited, which behaviours were changed on purpose, which agent proposed a change, and whether an improvement found downstream should travel back up. This paper proposes a layer that carries those answers.

The vocabulary is biological; the substrate is not. Underneath the metaphor the paper stays with ordinary engineering — version control, manifests, tests, signatures, policy engines, provenance, and controlled agent messaging.

Genesis / 01

It started as a fork that was not good enough.

The idea came out of KEYLIT, an AI-assisted piano-learning application with a particular design, repository, lesson structure, and interface. Different people could reasonably want radically different forms of the same underlying system: a gamified children's version, an accessibility-focused one with voice navigation, a classroom version with teacher dashboards, a Spanish or Quechua localisation, a composition-oriented version reusing the MIDI engine, or an embodied one where an avatar becomes the teacher.

The conventional answer is a branch, a fork, a template, or a fresh repository. But the further a derivative travels, the harder it becomes to keep a useful relationship with the original. Upstream updates collide with local customisation, downstream inventions never return to the ancestor, and an AI coding agent has no way to know which parts were inherited, which are sovereign local adaptations, and which must never be overwritten.

What if creating a customized application were treated not merely as copying code, but as creating a child that knows what it inherited?

The question the rest of the paper answers

Model / 02

Five words, defined before they are used.

The proposal is a composition layer, not a replacement for Git, SBOMs, provenance standards, product lines, or agent protocols. It links them around a small vocabulary, and the vocabulary has to be precise before any of it means anything.

  1. 01

    Genome

    What a project declares it is made of

    A machine-readable semantic manifest describing a project's capabilities, implementations, interfaces, tests, policies, provenance, and inheritance relationships. It is not a variability model but a historical and operational record of how capabilities were inherited and changed.

  2. 02

    Gene

    A capability, not a file

    A semantic capability with references to its implementation — id, purpose, interface, implementation, tests, dependencies, origin, parent, licence, policy, and evidence. A gene may span several repositories, and some are configuration-only or policy-only. Assuming a capability maps neatly onto a package is the common mistake this model tries to avoid.

  3. 03

    Mutation

    An intentional change, carrying its evidence

    A deliberate transformation of a gene or gene set, accompanied by evidence: tests, benchmarks, security scans, user studies, or human review. A mutation is a claim about a change, and the claim is meant to be verifiable rather than anecdotal.

  4. 04

    Agent DNA

    A bounded identity for a project's agent

    A machine-readable identity and policy manifest for the agent associated with a project: lineage identifiers, role, tool permissions, memory references, mutation privileges, communication scope, and protected local adaptations. It is not the model weights — a project may change model providers and keep the same lineage identity.

  5. 05

    Lineage graph

    A directed multigraph, not a tree

    Projects, genes, agents, and knowledge artefacts as vertices; ancestry, gene derivation, agent delegation, and knowledge propagation as separate edge sets. It supports vertical inheritance, branching, merging, recombination, and lateral transfer between unrelated families.

Reproduction / 03

Four ways to descend from something.

The metaphor here is musical rather than biological. A song produces covers, remixes, samples, and reinterpretations that stay recognisably related while becoming meaningfully distinct. Applied to software, this reframes derivative work from “copy plus diff” to inheritance plus intentional expression.

  1. 01

    Child / Fork

    Stays close

    Preserves most of the parent and continues to receive compatible improvements from it.

  2. 02

    Remix

    Keeps the parts, changes the experience

    Reuses selected capabilities while substantially changing user experience or behaviour.

  3. 03

    Cover

    Same idea, different instrument

    Preserves the functional specification or concept but reimplements it in a different stack, language, platform, or architecture.

  4. 04

    Hybrid

    More than one parent

    Combines genes from several projects into a new descendant, subject to licensing and compatibility constraints.

Agent DNA / 04

The second leap: the descendant carries a guardian.

The concept becomes more radical when each project carries not only a genome but an agent bound to it. That agent is not a code generator. It is meant to act as the interpreter of the project's lineage: which ancestors exist, which genes were inherited and which were locally modified, where the architectural boundaries are, which relatives are compatible, which mutations were previously accepted or rejected, and what may be shared upstream, downstream, or laterally.

What the manifest declares

  1. 01

    Identity

    Who this agent is

    A globally unique lineage identifier, its parent and ancestor agents, and the project and genome it belongs to.

  2. 02

    Role and capabilities

    What it is for

    The declared role — lineage guardian, for instance — and the capabilities that role is allowed to exercise.

  3. 03

    Tool permissions

    What it may touch

    Tool permissions and trust boundaries, so authority is granted explicitly rather than assumed from access.

  4. 04

    Memory references

    What it may remember

    Memory references and a retention policy, kept separate from the raw conversation history that produced them.

  5. 05

    Sharing scope

    What may leave the project

    What may be shared — benchmark summaries, signed mutation proposals, non-private lessons — and what may not: private user data, secrets, unrestricted conversation logs.

  6. 06

    Protected traits

    What may never be overwritten

    The local adaptations a descendant declares sovereign: a child-safety policy, a simplified interface, an accessibility decision that upstream must not silently revert.

If a project's history is tied to one vendor's model, continuity breaks whenever the team changes tools. Making the project the stable unit — and the lineage identity separate from the model behind it — is what allows a different assistant, a local model, or a future autonomous developer to act through the same identity, if authorised.

Propagation / 05

Relatives may learn from each other. They may not copy each other.

This is the safety rule the rest of the design hangs on. A successful mutation in one descendant becomes a candidate proposal, never an automatic update, and every receiving project stays sovereign over whether to adopt it. Improvement can therefore travel upstream to an ancestor, downstream to descendants, and laterally between unrelated families — always as a proposal with evidence attached.

The proposal pipeline

  1. 01Discover
  2. 02Describe
  3. 03Attest
  4. 04Simulate
  5. 05Test
  6. 06Review
  7. 07Adopt / Reject / Quarantine

Fitness is a vector, not a score

Biological fitness is an intentionally imperfect analogy. A candidate mutation should be evaluated across several dimensions at once, and no universal weighted sum should be required: a medical robot and a music-learning website have no business optimising the same objective. Policy decides which dimensions are mandatory and which are merely informative.

Correctness
Correctness and test quality.
Safety
Security and safety.
Performance
Performance and resource use.
User value
User-value metrics.
Compatibility
Compatibility across relatives.
Reliability
Reliability and rollback confidence.
Legal
Legal and licence compatibility.

What a connected lineage makes possible, and what it therefore has to prevent

  1. 01

    Mutation poisoning

    A high-fitness backdoor

    A malicious descendant could advertise an attractive mutation carrying a backdoor. Signed provenance, reproducible tests, sandboxing, independent validation, trust scores, allowlists, and policy-gated adoption are the countermeasures.

  2. 02

    Propagation worms

    An epidemic of updates

    Automatic propagation would create a software analogue of an epidemic, so default auto-merge of untrusted mutations has to be forbidden. Adoption requires explicit policy and evidence thresholds.

  3. 03

    Agent impersonation

    A claim is not an identity

    A model claiming to be a given lineage agent is not sufficient. Identity must be cryptographically bound to project authorisation and controlled by the project owner.

  4. 04

    Privacy leakage

    Lessons, not memories

    Agents should exchange structured, policy-approved knowledge packets with scope and expiry, rather than raw memories, proprietary code, user data, or credentials.

  5. 05

    Licence contamination

    A hard constraint

    Hybridisation across projects can create incompatible obligations, so every gene carries licence and attribution metadata and the resolver treats licence compatibility as a hard constraint rather than a cosmetic warning.

  6. 06

    Metrics gaming

    Why fitness stays multidimensional

    If fitness affects adoption, agents and developers will optimise for what is visible. Keeping fitness multidimensional, auditable, and domain-specific is what resists single-number optimisation.

Architecture / 06

An overlay, drawn as five layers.

Git stays the authoritative source for code history. The proposal deliberately avoids building a parallel, untraceable code store: genome and lineage objects reference immutable commits, tags, artefacts, package identifiers, and content hashes wherever possible. An MVP can run on PostgreSQL with recursive queries; a graph database becomes useful at scale but is not required to begin.

  1. 01

    Developer and agent interfaces

    Where people and agents arrive

    Coding assistants, IDEs, CI/CD systems, robots, and local agents.

  2. 02

    Interoperability layer

    How they connect

    MCP-style tool adapters, A2A-style messaging, repository and CI connectors — so a lineage network is not tied to one model vendor.

  3. 03

    Lineage engine

    The proposed contribution

    Project graph, gene registry, Agent DNA, mutation proposals, policy engine, and compatibility resolver. Compatibility combines declared interfaces and semantic versions, dependency and build constraints, automated tests, security policy, licence obligations, environment limits, and protected local adaptations.

  4. 04

    Evidence and trust layer

    Why a claim can be believed

    Signatures, SLSA and in-toto attestations, SBOM references in SPDX or CycloneDX, tests, benchmarks, and review records. A mutation record carries both semantic intent and verifiable build and test evidence.

  5. 05

    Source of truth and storage

    Where it actually lives

    Git repositories, artefact stores, a graph or index database, and an encrypted memory store.

Roadmap / 07

Small schema first. Embodied systems last.

The first specification should stay intentionally small. Modelling every biological analogy up front would buy complexity before it bought understanding.

  1. 01

    Phase 0

    Terminology and schema

    A minimal open specification for the project, genome, Agent DNA, mutation, and adoption records, plus content-addressed identifiers and signatures.

  2. 02

    Phase 1

    A repository-connected MVP

    Authenticate, select a repository, analyse manifests and structure and tests and documentation, let an agent propose a semantic genome, require human confirmation of genes and boundaries, store the genome in the repository, create a child with explicit inheritance metadata, and draw the first lineage graph.

  3. 03

    Phase 2

    Mutation proposals

    Gene-level mutation records, compatibility tests, benchmark evidence, signing, and upward and downward proposal flows, integrated with attestation and SBOM references where useful.

  4. 04

    Phase 3

    Multi-agent lineage

    Persistent Agent DNA and vendor-neutral adapters, so a project can move between foundation models over time while keeping one lineage identity and policy.

  5. 05

    Phase 4

    Cross-family gene registry

    Gene discovery across unrelated projects, which requires robust licensing, security, schema governance, and trust scoring before it is safe to attempt.

  6. 06

    Phase 5

    Embodied and long-lived systems

    Extension to firmware, hardware configurations, robot behaviours, model versions, and safety cases — where machine genealogy becomes operationally significant rather than merely developer-facing.

Open questions / 08

What would have to be measured.

The central claims are testable, and none of them has been tested. A first study could create several descendants of one project and compare two maintenance approaches over a sequence of changes: ordinary forks with manual merge and review as the baseline, explicit genomes with protected genes and lineage-aware proposals as the treatment.

  1. RQ1

    Can semantic genomes be generated accurately enough that developers accept them with limited correction?

  2. RQ2

    Does gene-level inheritance reduce the effort of maintaining specialised descendants compared with conventional forks?

  3. RQ3

    Can lineage agents identify reusable downstream improvements without increasing regression risk?

  4. RQ4

    Does explicit Agent DNA improve continuity when a project switches between AI coding providers?

  5. RQ5

    Can mutation provenance improve developer trust and debugging speed?

  6. RQ6

    How should fitness be measured without encouraging metric gaming or unsafe optimisation?

  7. RQ7

    What graph scale, query patterns, and consistency guarantees are needed for millions of projects and billions of gene relationships?

  8. RQ8

    How can proprietary and open-source lineages interoperate without leaking private code or user data?

Limits / 09

Where this could fail.

The proposal faces real conceptual and engineering problems, and it should begin as a pragmatic semantic provenance system with optional evolutionary abstractions — not as an attempt to force software engineering into biological terminology.

  1. 01

    Ambiguous boundaries

    What counts as a gene

    Semantic boundaries are genuinely ambiguous, and different developers will disagree about where one capability ends and the next begins.

  2. 02

    Extraction error

    A genome can be wrong

    AI-generated genome extraction can hallucinate relationships or infer intent incorrectly, which is why human confirmation sits inside the MVP rather than after it.

  3. 03

    Entangled change

    Not everything decomposes

    Many real software changes span several capabilities at once and cannot be cleanly attributed to a single gene.

  4. 04

    Legal and social weight

    Ancestry is contentious

    Provenance can imply attribution, ownership, or responsibility. Those implications have to be represented carefully rather than asserted by a graph edge.

  5. 05

    Attack surface

    Connection is risk

    A continuously connected lineage creates security exposure and privacy risk that a disconnected fork simply does not have.

  6. 06

    Graph noise

    Too many mutations

    If every trivial change is recorded as a mutation, a large lineage graph becomes noise, and the signal it was built to carry disappears.

  7. 07

    Metaphor drift

    Software is not alive

    Software evolution is engineered, policy-driven, and often intentionally discontinuous. The genetics metaphor misleads the moment it is taken literally.

Publication boundary

01Evidence state
Concept paperA written proposal and research agenda. No implementation result, benchmark, or user study is reported here.
02System state
Nothing is runningNo lineage engine, gene registry, agent network, hosted service, or live data sits behind this route.
03Adoption
Not a standardCodeAncestry is not an accepted specification and claims no adoption, partner, working group, or endorsement.
04Name
Working titleThe name is provisional. Naming, domain, and trademark checks are outstanding and would have to be completed before any launch.

Continue / 10

A change of question, before it is a product.

Version control asks which lines changed. Dependency management asks which packages are included. Provenance asks how an artefact was produced. A software genome asks a further question: which meaningful capabilities were inherited, mutated, recombined, or learned across the family? That question becomes harder to avoid as agents lower the cost of producing descendants faster than people can track them.