Describe an organism, get its blueprint. From ontologies, not imagination.

Worked blueprints

Pick a description. The tree is what the ontologies say for that taxon; click any node to open its official record. A badge on each organ says whether Uberon states the organ for an ancestor of the taxon or merely does not rule it out.

How it works, step by step

1. Read the description. Taxon words are looked up in the team's species inventory (common and scientific names of the taxa Darwin and Thompson mention) and then in a small hand-written lexicon (). The most specific taxon wins, checked live against NCBI Taxonomy.
2. Refuse the held-out clade. If the taxon is inside the clade frozen in holdout/exam.json, the tool refuses, writes nothing, and removes any cached query from the attempt, so no held-out organism leaves a trace in the folder.
3. Filter by taxon. A structure is dropped when Uberon says it never occurs in a taxon that contains ours (on the term, a superclass, or a whole it is part of), or only occurs in an unrelated taxon. Non-vertebrates also lose Uberon's vertebrate-only terms. A structure that is not dropped is not thereby present: the badge says what the ontology actually states.
4. Build the tree. Organ systems and organs come from Uberon's own core subsets, ranked major organs first and then by how many cell types the Cell Ontology records for them (a measure of curation, not importance). Tissues and cells are the ontology's part of statements. Structures named in the description are always kept.
5. Store the evidence. Every SPARQL query, its row count and retrieval time sit in the output; every response is cached by hash so a clean checkout rebuilds the same file offline.

Blind predictions for the holdout exam

The holdout thread froze class Aves (all birds) as the exam before anything was built, provisionally until the team lead confirms. This thread did not open any bird trait table. Instead it emitted, for every roster species and every Uberon core term that carries a taxon constraint, a present-or-absent prediction derived only from the ontology. The holdout thread commits its scoring rule before reading the file, so neither side can tune to the other.

Smoke test of a hosted structure model: ESMFold

The recommendation on the main page was to call one hosted structure model on one real sequence and file the result against a claim with provenance. Two routes are wired. The BioNeMo NIM route (NVIDIA) needs a valid API key; the latest attempt and the server's answer are in the runs table. Its input is bovine serum albumin, the calcium-carrying protein behind Thompson's "albuminous solution" claim. The ESM Atlas route (Meta's public ESMFold service, no key) ran now on cytochrome c from cattle, tuna and yeast, the protein on which the molecular clock was first read, and the three predictions were superposed and filed against Kimura's substitution-rate claim.

Every record as a nanopublication, drafted

The standing order for this project is that each micro-discovery becomes a nanopublication with its evidence attached. This thread's output is a design rather than a measurement, so the records say so in their own terms: a blueprint is typed as a proposal whose evidence item is the ontology queries behind it, a predicted structure is typed as a model output, the comparison over three predictions is a derived claim, a documented refusal from a hosted service is a method observation, and another thread's scoring of the blind predictions stays a separate record attributed to that thread. Every number carries the file and the checksum it was read from, and every record states what it does not establish. Nothing is signed, nothing is published, and no person is named: there is no key on this machine, no ORCID appears in any draft, and the test registry, let alone production, is the key owner's decision. Drafting the records also turned up a defect in the shared tooling, which is itself filed as a record below.

What is here and what is not

Sources