Method
How genEra dates a gene
genEra (Barrera-Redondo et al. 2023) assigns every protein in a genome to a phylostratum — the oldest node on the species' own lineage at which the gene can still be detected. The idea is simple enough to describe in one paragraph. The interesting part is where it breaks, and it breaks in ways that matter specifically for de novo gene claims.
The pipeline
Everything below is one focal species at a time. The ladder is the focal species' own NCBI
lineage, from cellular organisms at the root down to the species itself — 19 or 20
rungs for a plant.
The age is a maximum over hits. A maximum has no tolerance for a single bad observation — and NR contains bad observations. genEra knows this, which is why step 6 exists. The next section is a real case where step 6 did its job.
The representativeness gate, on a real gene
COR15A is an Arabidopsis cold-regulated LEA protein, genuinely restricted to Brassicaceae. In this project's genEra run it came back not as "Brassicaceae" but as possible contamination or HGT, with a representativeness of 22%. Here is why that was the right answer.
The failure the gate does not catch
Representativeness protects against a spurious hit making a gene look too old. Nothing in the method protects against the opposite error — real orthologs that the search cannot see, making a gene look too young. That is the error that matters for de novo claims, and it has a systematic cause.
Homology detection failure does not add noise symmetrically. It moves genes down the ladder, never up. The concepts page covers the null model that puts a probability on it, and the synteny-based argument against it. Any statement of the form "N% of genes in this genome are lineage-specific" is therefore an upper bound, and the size of the overestimate scales with how short and fast-evolving the genes are.
Five ways a genEra run can be wrong while reporting success
All five were hit on this cluster across ~40 runs. In every case genEra printed
Enjoy your results!!! and exited 0, and in four of the five it wrote one output row
per query gene — so neither the exit code nor a line count catches any of them.
| Failure | What the output looks like | Guard |
|---|---|---|
which leak | 100% of genes "Absent from the DIAMOND results" | --cleanenv; assert type which is a binary |
R_TempDir failure | 100% absent, on one bad node only | pass an explicit scratch TMPDIR into the container |
| FASTSTEP3R OOM | 100% absent; seff shows ~100% memory efficiency | size memory from the results-table size; gate on content |
| walltime truncation | fewer rows than query sequences, summary still written | compare row count against grep -c '^>' |
wrong -t taxid | output looks perfect; the ladder is the wrong species | print the resolved scientific name and read it |
The last one is the most dangerous, because it produces a clean, plausible, fully populated result. In the campaign behind this site it happened twice: one species was run under the taxid of a different species in the same genus, and another was run as a hybrid when it is not one. Both were caught by an audit that compared the manifest against NCBI, not by anything in the pipeline.