Self-evolving software needs a selection boundary
Something quietly converged over the last two years: half a dozen serious research efforts independently arrived at the same architecture for software that improves itself.
Different domains, same loop: a model proposes, an evaluator measures, a selector decides what survives. The proposer is the easy part — every frontier model can draft plausible programs. The evaluator is engineering. The selector — what is allowed to run next — is where these systems differ most, and where almost everything interesting lives.
The selector is a security boundary wearing a lab coat
Strip away the benchmarks and the selector is answering one question: does this proposed program get authority? DGM's archive, AlphaEvolve's database, Voyager's skill library — each is a gate between "a model emitted bytes" and "bytes become behavior."
Most implementations make that gate implicit: a Python process that happens to run whatever scored well. That works in a lab. It is a strange foundation for production, because the gate is exactly where you want the strongest guarantees — and where you get the least.
ALGAL's position is that the selection boundary should be a contract, not a convention:
algal.organism.v1) as an ordinary value — through spawn, or by handing a manifest to the host. Proposing costs the proposer nothing and grants the candidate nothing.The loop — propose → admit → measure → select — is what the civilization doc calls an epoch. It is the same shape DGM and AlphaEvolve use; the difference is that every stage has a contract and a receipt rather than a Python convention.
Why the program must be data
There is a deeper requirement hiding under the selection boundary: the candidates have to be inspectable objects. You cannot meaningfully gate what you cannot cheaply examine.
DGM patches Python source; its gate is benchmark score plus human review of diffs. That works because the experiment is contained. But "program as arbitrary code" is a bad unit of selection for anything you want to trust incrementally — the diff surface is the whole language.
An ALGAL manifest is a small typed document. Diffing two candidates is diffing data. Admitting one is running a bounded checker, not auditing Turing-complete source. The candidate that cannot express the attack is cheaper to trust than the candidate that expresses everything. This is the same reason the manifest carries no host code at all — the only executable content is bounded algal.expr.v1 evaluated under fuel by the contract's own evaluator.
It is also what makes a population practical: a store of manifests is a store of hashed documents — deduplicated, lineage-tracked, diffable. algal civ runs an epoch where an on-device ~3B model proposes plans, a host function compiles them into checked manifests, candidates run train and validation, and the winner promotes. Every step — proposal digests, case outcomes, the promoted manifest — lands on receipts that verify offline. The fossils are how you audit evolution after the fact.
What stays honest
Three disclaimers worth repeating, because they are the difference between self-evolving software and a demo:
Where this goes
The research wave is answering "can programs improve themselves?" with an emphatic yes. The next question is the infrastructure question: what is the substrate where proposed programs are cheap to check, cheap to measure, and safe to select? A language where the program is data, a VM that treats runs as replayable fossils, and a selection boundary that is a contract rather than a convention — that is the bet ALGAL makes.
Read the machinery: habitats · civilization · foundry spec. Or watch a program propose a child on the tour.