Most software is designed around a simple assumption: the program we write today will remain fundamentally the same program tomorrow.
It may receive new data, store new state and react differently to different inputs, but its underlying structure normally changes only when a developer edits the source code and releases a new version.
My Gnome project is exploring a different question:
What would software look like if adaptation, development, maturation, inheritance, dormancy, mutation and evolution were fundamental programming concepts rather than features bolted on afterwards?
The project is built around a model I call the Temporal Genome Interaction Graph, or TGIG.
TGIG is intended to provide a controlled computational equivalent of a biological genome. Programs contain genes, chromosomes, regulatory relationships, signals, fitness evidence, maturity, lineage and evolutionary history. Parts of the program can become more or less active depending on their environment, successful behaviours can mature, unsuccessful behaviours can become dormant, candidate mutations can be evaluated, and descendants can eventually replace their ancestors.
However, this is not an attempt to create uncontrolled self-modifying software.
The central design principle is:
Evolution proposes. Validation decides.
Gnome deliberately separates the parts of a system that are allowed to evolve from the trusted runtime that governs evolution.
From conventional software to a digital genome
A conventional application might contain a number of functions:
read_data()
analyse_data()
select_strategy()
produce_result()Those functions exist because the developer decided they should exist.
In Gnome, the same capabilities could instead be represented as genes within a genome.
A simplified biological hierarchy looks like this:
Population
↓
Organism
↓
Genome
↓
Chromosome
↓
Gene
↓
Expression
↓
Protein / Behaviour
↓
PhenotypeThe important difference is that possessing a gene does not necessarily mean that the gene is currently being used.
TGIG therefore makes an important distinction between:
GENOTYPE ≠ EXPRESSION ≠ PHENOTYPE ≠ ENVIRONMENTThe genotype describes the capabilities the organism potentially possesses.
Expression determines which capabilities are currently active.
The phenotype is the observable behaviour produced by those expressed capabilities.
The environment provides the conditions that influence expression and determines whether the resulting behaviour is useful.
This distinction becomes particularly interesting when the environment changes.
Instead of rewriting the entire program, the organism may alter which genes it expresses, change regulatory parameters, reactivate a previously dormant capability or, eventually, create a controlled mutation candidate.
The main Gnome/TGIG runtime
The most important part of the project is not any individual demonstration. It is the shared TGIG runtime underneath them.
All of the demonstrators use the same architecture.
ENVIRONMENT
│
▼
Signals
│
▼
┌─────────────────┐
│ GENOME │
│ │
│ Chromosomes │
│ │ │
│ Genes │
│ │ │
│ Regulation │
└───────┬─────────┘
│
Expression
│
▼
Behaviour
│
▼
PHENOTYPE
│
▼
Performance
│
▼
Fitness
│
▼
Adaptation
│
┌───────┴────────┐
│ │
Regulation Mutation
│
Candidate
│
Validation
│
Promote / RejectEvery meaningful change is also recorded by TGIG.
That historical record is extremely important.
An event-sourced evolutionary system
Gnome does not simply keep an object in memory and periodically save whatever state it happens to be in.
The project uses an event-sourced architecture.
Conceptually:
TGIG state at time T
=
initial TGIG state
+
every valid event up to time TEvents can describe things such as a gene being expressed, a mutation being proposed, a mutation being rejected, a descendant being promoted, a gene entering dormancy, a gene reactivating or an organism interacting with its environment.
This means the project should eventually be able to answer questions such as:
What changed?
When did it change?
Why did it change?
Which gene was its parent?
What environmental conditions influenced the decision?
Did fitness improve afterwards?
Why was a mutation accepted?
Can the same result be reproduced?
This is one of the major differences between TGIG and a conventional genetic optimisation experiment.
Evolution should not be a mysterious process happening inside an algorithm.
It should be observable and auditable.
Replaying evolution
Because evolution is event-sourced, a TGIG experiment can be replayed.
If an organism reaches a particular state after 5,000 generations, the runtime should be able to reconstruct exactly how it arrived there.
The goal is:
Genesis
+
All events
↓
Final state Xand independently:
Snapshot
+
Remaining events
↓
Final state XBoth reconstructed states should match the actual final state produced during the original experiment.
This is particularly important for research.
If an adaptive system produces an interesting behaviour but the result cannot be reproduced, it becomes extremely difficult to determine whether that behaviour was meaningful or simply an accident of execution.
Deterministic randomness
Evolution obviously requires randomness.
Mutations, exploration and environmental variation may all depend upon random choices.
The solution is not to remove randomness but to make it deterministic and isolated.
TGIG therefore uses independently derived random-number streams.
For example, the random stream controlling the environment should be different from the stream controlling mutation.
That means adding one additional mutation decision should not suddenly alter the future environment.
Conceptually:
root seed
│
├── environment RNG
├── exploration RNG
├── mutation scheduler RNG
├── candidate mutation RNG
├── validation RNG
└── reactivation RNGUsing the same seed and configuration should reproduce the same experiment.
This becomes even more important when many Gnomes eventually inhabit the same environment.
The constitutional runtime
Perhaps the most important safety concept within Gnome is the distinction between the evolvable genome and the constitutional runtime.
The genome is allowed to change within defined boundaries.
The runtime governing those changes is not.
┌──────────────────────────────────┐
│ CONSTITUTIONAL RUNTIME │
│ │
│ Event integrity │
│ Type enforcement │
│ Contracts │
│ Capabilities │
│ Mutation validation │
│ Fitness evaluation │
│ Sandboxing │
│ Replay │
│ Rollback │
└─────────────────┬────────────────┘
│
▼
┌──────────────────────────────────┐
│ EVOLVABLE SYSTEM │
│ │
│ Genome │
│ Chromosomes │
│ Genes │
│ Regulation │
│ Behaviour │
│ Phenotype │
└──────────────────────────────────┘An evolving gene should never be able to decide that it no longer likes the mutation validator and rewrite it.
It should not be able to modify the fitness evaluator to award itself a perfect score.
It cannot give itself filesystem access, network access or arbitrary operating-system permissions.
A mutation is therefore treated more like a proposed software update than arbitrary self-modification.
Evolution proposes. Validation decides.
Suppose a gene develops a candidate descendant.
The parent is not immediately overwritten.
Instead, TGIG can conceptually perform:
Existing gene
│
▼
Mutation candidate
│
▼
Static validation
│
▼
Type / contract validation
│
▼
Capability / security validation
│
▼
Shadow testing
│
▼
Fitness comparison
│
├── REJECT
│
└── PROMOTEIf the candidate is worse, unsafe or incompatible, it is rejected.
If it performs better under the required validation conditions, it may become a promoted descendant.
Its ancestry remains recorded.
This gives TGIG a digital equivalent of lineage.
Genes can mature
Another unusual concept in the project is gene maturity.
In Gnome, a gene is not considered trustworthy simply because it has existed for a long time.
Age and maturity are deliberately different concepts.
A gene might have executed successfully hundreds of times under many environmental conditions and accumulated strong evidence that its behaviour is reliable.
Another gene might be equally old but rarely used.
They should not automatically have the same maturity.
Maturity can therefore be based on evidence such as reliability, fitness, behavioural stability, environmental coverage, execution history and statistical confidence.
A gene can progress through developmental states conceptually resembling:
EMBRYONIC
↓
EXPERIMENTAL
↓
DEVELOPING
↓
STABLE
↓
MATUREA mature gene can still later become:
ADAPTING
DORMANT
SENESCENT
APOPTOTIC
DEADdepending upon evidence and environmental relevance.
Dormancy instead of immediate deletion
Biology often retains genetic capabilities that are not currently useful.
Gnome explores a similar idea.
Imagine that a strategy becomes irrelevant because the environment changes.
A conventional optimiser might simply discard it.
TGIG may instead allow the gene to become dormant.
If similar environmental conditions return hundreds or thousands of generations later, that capability could potentially reactivate.
This raises an interesting research question:
Can dormancy provide a form of long-term computational memory and help an adaptive system recover more quickly when old environmental conditions return?
The demonstrators are intended to help answer questions like this experimentally rather than assuming the biological analogy is automatically beneficial.
Apoptosis
At the other end of the lifecycle is apoptosis.
In biology, apoptosis is controlled cell death.
Within TGIG it represents the controlled retirement of a component that is no longer useful or safe to retain.
A possible lifecycle might be:
ACTIVE
↓
DORMANT
↓
SENESCENT
↓
APOPTOTIC
↓
DEADImportantly, death does not mean deletion from history.
A dead gene remains visible in its lineage.
Researchers should still be able to determine where it came from, what it did and why it was eventually removed from active use.
Demonstrator 1: The Adaptive Sorting Organism
The first TGIG demonstrator deliberately uses a simple problem: sorting numbers.
At first glance this might seem uninteresting, but that is exactly why it is useful.
Sorting algorithms are well understood, their correctness is easy to verify and their strengths vary depending on the type of input.
The initial Gnome contains a Sorting chromosome with four genes:
GeneInsertionSort
GeneQuickSort
GeneMergeSort
GeneHeapSortThe environment can contain information such as input size, sortedness, duplicate ratio, memory pressure and processing conditions.
The organism must decide which sorting behaviour to express.
The initial regulatory policy is deliberately imperfect.
The objective is therefore not simply:
Can Gnome sort a list?
Any ordinary Python program can do that.
The interesting question is:
Can the organism gradually specialise its expression strategy while TGIG records exactly how that adaptation occurred?
What evolution looks like in the sorting demonstrator
Initially the organism may select inefficient algorithms for particular workloads.
Over repeated generations the regulatory system receives evidence about which genes perform well in different environmental conditions.
Successful genes may become more mature.
Poor strategies may be suppressed.
Some genes may become dormant when environmental conditions make them less useful.
Regulatory mutation candidates can alter parameters such as affinities and expression thresholds.
Some candidates should fail validation.
Others may outperform their parents and be promoted.
The result is a lineage rather than a single continuously rewritten function.
Conceptually:
QuickSort_v1
│
├── QuickSort_v2 REJECTED
│
└── QuickSort_v3 PROMOTED
│
├── QuickSort_v4 REJECTED
│
└── QuickSort_v5 PROMOTEDThis simple demonstrator is essentially the project’s laboratory organism.
It is designed to prove the TGIG machinery before more visually interesting systems are attempted.
Why sorting is scientifically useful
The sorter also provides something extremely important: an unquestionable correctness oracle.
A sorting algorithm either produces the correct result or it does not.
Performance should never compensate for incorrect behaviour.
A candidate that sorts extremely quickly but occasionally returns incorrect data must therefore fail.
That principle extends beyond sorting.
In future TGIG systems, correctness and safety constraints should dominate optimisation.
Evolution is allowed to search for better solutions, but it is not allowed to redefine what counts as correct merely because doing so improves its fitness score.
Demonstrator 2: The Digital Foraging Organism
The second demonstrator moves TGIG into a much more visual environment.
Instead of selecting sorting algorithms, a digital Gnome inhabits a two-dimensional world.
The world contains resources, obstacles and hazards.
The organism must find food, conserve energy, avoid danger and survive.
A simplified world might look like:
+-------------------------------------------+
| FOOD |
| |
| ####### |
| obstacle |
| |
| G |
| |
| HAZARD FOOD |
| |
+-------------------------------------------+G represents the Gnome.
Unlike the sorting demonstrator, the phenotype is now something that can be watched directly.
A genome for behaviour
The Digital Forager can contain several functional chromosomes.
A Sensing chromosome might contain genes associated with detecting food, hazards, obstacles and internal energy.
A Movement chromosome might contain behaviours such as random movement, moving toward food, avoiding obstacles and escaping hazards.
A Decision chromosome might contain strategies such as explore, exploit, retreat and rest.
A Memory chromosome can eventually support remembering previously useful or dangerous areas.
The important point is that all of these genes may exist simultaneously while only some are expressed at any particular moment.
For example:
Food detected
│
▼
FoodDetection gene
│
▼
FOOD signal
│
▼
MoveTowardFood activated
│
▼
RandomWalk suppressed
│
▼
Movement phenotypeIf a hazard is detected:
HAZARD signal
│
├── activates EscapeHazard
│
└── suppresses MoveTowardFoodThe resulting behaviour is therefore a product of interaction between genes, signals, regulation, internal state and environment.
Watching an organism develop
The foraging demonstrator should make TGIG much easier to understand visually.
Early behaviour might involve inefficient movement, wasted energy and poor hazard avoidance.
Later generations might show more specialised sensing, improved resource acquisition, more efficient movement and better hazard responses.
A dashboard can eventually show the world alongside the organism’s internal biological state.
For example:
Generation: 1842
Current phenotype:
MOVE_TO_FOOD
Energy:
73%
Active genes:
FoodDetection_v4 0.91
MoveTowardFood_v7 0.87
RandomWalk_v2 0.08
EscapeHazard_v3 0.12
Maturity:
FoodDetection_v4 0.82
MoveTowardFood_v7 0.76
Environment:
Food scarce
Hazard density mediumThe aim is to be able to watch the external behaviour and simultaneously inspect the internal evolutionary explanation.
Environmental change
A major part of the foraging experiment is concept drift.
The environment should not remain permanently stable.
For example, an early environment might have plentiful food and few hazards.
A later phase could contain less food and significantly more danger.
Another phase might introduce additional obstacles.
Eventually, an earlier type of environment could return.
This allows TGIG to test adaptation, forgetting and dormancy.
If a previously successful gene became dormant during a long environmental change, does reactivating it allow the organism to recover more quickly when the original conditions return?
That is a much more interesting question than simply asking whether overall fitness increased.
Demonstrator 3: The Digital Ecosystem
The third demonstrator takes another major step.
Instead of one Gnome existing alone, multiple complete TGIG organisms inhabit the same world.
Initially there might be twenty organisms.
Eventually experiments could involve considerably larger populations.
Conceptually:
+------------------------------------------------+
| G1 FOOD G7 |
| |
| G3 HAZARD |
| |
| FOOD G12 |
| |
| G5 G18 |
| |
| FOOD G9 |
+------------------------------------------------+Each Gnome is its own organism.
It has its own genome, expression, maturity, fitness, history and lineage.
They share the environment but not their private internal state.
Organism isolation
This distinction is essential.
Gnome A cannot simply inspect Gnome B’s genome and discover exactly what it intends to do.
An organism may only learn about another organism through mechanisms available in the simulated environment.
Initially that may simply mean seeing another organism occupy a nearby position or competing for the same food.
Later it can include typed communication signals.
This creates an artificial ecology rather than a single optimisation process controlling many agents.
Competition
The first form of interaction is intentionally simple: competition for scarce resources.
Imagine two Gnomes attempting to consume the same resource.
FOOD
▲
/ \
/ \
G1 G2Both organisms create an intent.
Neither immediately changes the world.
The ecosystem collects those intents and resolves the conflict deterministically.
Gnome 1 ──► intent ──┐
│
▼
Resolver
│
▼
Outcome event
▲
│
Gnome 2 ──► intent ──┘This is important because simply processing Gnome 1 before Gnome 2 would give the first organism an artificial advantage.
Operating-system scheduling, CPU timing or Python iteration order must not determine evolutionary success.
Communication between Gnomes
A later ecosystem phase introduces communication.
Messages are not arbitrary executable code.
They are typed data.
For example:
FOOD_DETECTED
HAZARD_NEARBY
HELP_REQUIRED
COOPERATE_READYA signal may contain its producer, intended scope, signal type, strength, lifetime and payload.
The interesting evolutionary question is not whether Gnomes can send messages.
That is trivial to program.
The interesting question is whether using those signals provides a measurable advantage.
A system should therefore not receive a fitness reward merely for producing lots of communication.
If communication is useful, that usefulness should appear through real consequences such as improved survival, reduced hazard exposure, better resource acquisition or successful cooperation.
Cooperation
The ecosystem can later contain resources that are difficult or impossible for a single Gnome to exploit.
Two or more organisms might need to be present within a particular time window.
This allows TGIG to investigate whether cooperative behaviour can emerge and persist.
Again, the experiment should avoid simply awarding a “cooperation bonus”.
The reward should result from the actual environmental outcome.
If cooperation costs more energy than it provides, it should not automatically be considered beneficial merely because it looks socially interesting.
Reproduction and inheritance
One of the most ambitious stages of Demonstrator 3 is reproduction.
The initial approach is intentionally conservative: asexual reproduction first.
A sufficiently successful and mature organism may produce an offspring containing an inherited genome.
However, an important distinction is made between inherited structure and earned evidence.
An offspring may inherit the parent’s genotype.
It should not automatically inherit the parent’s maturity, reliability, confidence or fitness history.
A newborn descendant must earn its own evidence.
This prevents a mutation from creating a new gene and immediately claiming the trust accumulated by its parent.
Later experiments may explore controlled two-parent recombination.
That opens much larger research questions around inheritance, diversity and speciation.
Lineages and artificial species
Once many organisms reproduce, TGIG can construct complete ancestry graphs.
Researchers could inspect which lineages survived, which disappeared and which became dominant.
Different groups may specialise in different ecological niches.
For example, one lineage might perform well in hazardous areas while another becomes highly efficient at exploiting scarce resources.
TGIG may eventually classify such groups into observational niches or species-like clusters.
However, these labels should describe what happened rather than influence the fitness function.
The system should not evolve toward “becoming a new species” merely because the researcher wants to see one.
A population dashboard
The Digital Ecosystem creates particularly interesting possibilities for visualisation.
A dashboard could display the entire world and allow a researcher to click on any Gnome.
Selecting an organism could reveal its genome, parents, descendants, mutations, maturity, fitness and current phenotype.
An interaction graph could show relationships such as:
Gnome A ── COMPETES_WITH ──► Gnome B
Gnome C ── COOPERATES_WITH ──► Gnome D
Gnome E ── SIGNALS_TO ──► Gnome F
Gnome G ── PARENT_OF ──► Gnome HA generation slider could then move backwards through history.
The state displayed at generation 500 should not be an approximate reconstruction created by the visualisation.
It should be the actual TGIG state produced by replaying the canonical evolutionary events.
Explainable evolution
One of the long-term goals is a WHY panel.
Imagine selecting a mutation in the visualiser and asking:
Why was this mutation promoted?
TGIG should be able to display the relevant evidence.
Or:
Why did this gene become dormant?
The system could show declining environmental relevance, execution frequency and fitness evidence.
Or:
Why did this organism move toward that resource?
The dashboard could identify the sensory signal, the regulatory activation, competing behaviour suppression and the resulting phenotype.
The important requirement is that the explanation comes from recorded evidence.
If the evidence is unavailable, the interface should say that it is unavailable.
The project should never invent a plausible-sounding explanation after the event.
Measuring whether the biological ideas actually help
An important part of Gnome is that the biological metaphors are not assumed to be beneficial.
They must be tested.
TGIG can therefore be compared with simpler systems.
For the adaptive sorter, this might mean comparing it against a fixed algorithm, rule-based dispatcher, ordinary optimiser, genetic algorithm or reinforcement-learning selector.
The forager can be compared against a fixed rule-based controller or simpler adaptive policy.
Individual TGIG mechanisms can also be removed.
For example, the same experiment can be run with maturation disabled or dormancy disabled.
If removing dormancy produces identical or better results, then dormancy may not be providing useful value in that scenario.
That is a perfectly acceptable research result.
The project should be capable of disproving its own assumptions.
Why three demonstrators?
The three demonstrators deliberately increase in complexity.
DEMONSTRATOR 1
Adaptive Sorting
│
│ proves core evolution
▼
DEMONSTRATOR 2
Digital Foraging
│
│ adds visible phenotype
▼
DEMONSTRATOR 3
Digital Ecosystem
│
│ adds interaction and population evolution
▼
Future TGIG LanguageThe Adaptive Sorter is the laboratory test.
The Digital Forager demonstrates visible embodied behaviour.
The Digital Ecosystem investigates whether independently evolving Gnomes can coexist, compete, cooperate, communicate and eventually reproduce.
Only after those foundations behave coherently does it make sense to consider turning TGIG into a complete programming language.
The eventual programming language
The long-term objective is not simply to create another evolutionary simulation.
TGIG is intended to become the semantic foundation of a programming language.
A programmer might eventually be able to declare concepts such as:
gene FoodDetectorbut that declaration would mean much more than defining a conventional function.
It could create a TGIG entity possessing identity, contracts, capabilities, regulation, expression rules, mutation policy, fitness evidence, lifecycle state, maturity and lineage.
Likewise, concepts such as chromosomes, signals, receptors, environments and mutation policies could eventually become first-class language constructs.
The runtime would understand what it means for software to develop rather than merely execute.
What Gnome is not
Gnome is not intended to be an unrestricted program that continually rewrites its own source code.
It is also not an attempt to allow AI to arbitrarily modify operating systems, network services or security boundaries.
The project deliberately constrains evolution.
Early mutation is primarily regulatory and parameter-based.
More powerful structural mutation, if introduced later, should use typed structured representations rather than uncontrolled editing of source strings.
Every evolutionary mechanism should remain subordinate to validation, contracts, capabilities and reproducibility.
The larger research question
Ultimately, Gnome is exploring a broader question about software engineering:
Can evolutionary behaviour be made safe, typed, explainable, transactional and reproducible enough that it becomes an intentional programming paradigm rather than merely an optimisation experiment?
Biology demonstrates that extraordinarily complex adaptive systems can arise from genomes, regulation, development, environmental interaction and selection.
That does not mean copying biology directly will automatically produce better software.
But concepts such as maturation, dormancy, lineage, controlled mutation, environmental expression and inheritance may offer useful new abstractions for systems that must operate for long periods in changing environments.
TGIG provides a framework in which those ideas can be tested.
Where the project could eventually lead
If the three demonstrators are successful, there are many possible directions.
Future Gnomes could develop specialised ecological niches. Populations could undergo controlled recombination. Typed signalling could become increasingly sophisticated. Dormant genes could preserve capabilities across long environmental changes. Controlled horizontal gene transfer might eventually allow validated capabilities to move between organisms.
A distributed version of TGIG could potentially allow populations to evolve across multiple computing environments while maintaining a common lineage and validation framework.
But these are future research directions.
The immediate priority remains proving each layer before adding the next.
Conclusion
Gnome began with a simple idea:
What if software had a genome?
That question quickly leads to much deeper ones.
What does it mean for software to mature?
Should successful components accumulate evidence before being trusted?
Can unused capabilities become dormant instead of being deleted?
Can they reactivate when the environment changes?
Can software produce descendants without allowing unsafe self-modification?
Can we preserve complete evolutionary lineage?
Can many independently evolving programs interact without losing determinism?
Can we replay an entire evolutionary history and explain why every significant change happened?
And ultimately:
Could development and evolution become normal concepts within programming languages?
That is what the Gnome project and the Temporal Genome Interaction Graph are designed to explore.
The aim is not evolution for its own sake.
It is controlled, measurable and explainable adaptation.
Or, in the principle that sits at the centre of the project:
Evolution proposes. Validation decides.
Recent Comments