SurveyBrainBody's badges point at a repository with a different name

The badges and the issue links point at a different repository

Read the badge row at the top of the file and two of the targets are not this repository.

The commit activity graph and the issues badge both resolve to a repository under the same owner account but with a much longer name, one that spells out the topic in full. The survey itself lives in a repository whose name is a short pun on brain and body co-design.

That is a leftover from a rename, and it matters in a specific way. If you click the issues badge expecting to file a paper that is missing from the list, you arrive somewhere else. Whether that other repository still exists, is a redirect, or is empty is not something the readme says.

The rest of the badge row is conventional: an awesome-list badge pointing at a widely used template, a pull request welcome badge, and an attribution badge for the JavaScript library that renders the table of contents. There is also a badge link that is commented out, pointing at a completely different arXiv identifier from an earlier year.

So of six badge targets, two point elsewhere in the same account, one is dead by being commented out, and three are generic. That is a higher mislink rate than the visual polish of the row suggests.

The first news entry predates the paper by eleven months

There are three entries in the update list and they are not in the order you would expect from reading them top to bottom.

The first is dated the first of January 2025 and says the author is updating the survey and will update the site fully when the survey is updated to arXiv. The second is dated the first of December 2025 and announces that the paper is publicly available on arXiv. The third is dated the twenty-sixth of June 2026 and announces acceptance with minor revisions.

So the list is chronological. The oddity is the relationship to the paper itself. The arXiv identifier encodes December 2025, and the citation block gives the year as 2025 with the journal field set to an arXiv preprint, which is the conventional form for a preprint that has not yet appeared in a venue. The acceptance announcement then arrives in mid 2026.

That sequence is internally consistent. What it means for a reader is that the January 2025 entry describes work in progress eleven months before the preprint existed, so the readme has been a work-in-progress page for about a year before there was a paper behind it.

If you are citing this, use the venue acceptance rather than the preprint year, since the paper is no longer a preprint.

The contribution template is a markdown row inside a python fence

Contributions are welcome and the process is three steps: fork the repository, add a row to the readme, and submit the pull request to that branch.

The row format is given as an example, and the example is a markdown table row with four columns: a linked title, a venue, an agent type, and a linked code or project. The instructions list five things to supply, which is consistent once you notice that the title and the paper link are one column and the page-or-code link and the project link are the other.

Two details will trip a first-time contributor. The example is inside a fence tagged as Python, which it is not; it is a markdown table row, and the fence tag was chosen so the pipe characters render. And the row is indented by two spaces, which in markdown makes it a code block rather than a table row. So copying the example literally puts an indented code line in the middle of your table instead of a row in it.

The agent type column is the one with no definition. Nothing in the readme explains what values belong in it, whether it refers to the kind of agent or the kind of embodiment, or whether it is free text. That is the field to ask about in the pull request.

The repository is a readme, an image folder, and a licence

The entire top level is three entries: a licence, the readme, and an images directory. There is no code, no data, no build configuration, and no scripts.

That is what an awesome-list style survey is, and it is the right shape for something that is meant to be read and updated by hand rather than generated. There is no taxonomy file to diff, no benchmark harness to run, and nothing to break.

It also explains why the platform cannot classify the primary language. There is barely any code in the repository to classify, and what prose exists is wrapped in raw HTML with inline styling, which defeats most language detectors.

Two consequences follow from the hand-maintained shape. First, there are no releases, so the only way to cite a specific version of the list is a commit. Second, the images directory has no documentation, so the figures in the readme are referenced by whatever naming convention the author used and nothing tells you what is in there beyond what you see inline.

For a survey that will keep changing, that is an acceptable trade. For anything you want to consume programmatically, it is not.

Three components and one algorithm at the root of the taxonomy

The organising idea is stated early and everything else hangs off it. Creating an embodied agent hinges on three components: the controlling brain, the body morphology, and the task environment. A fourth element, the co-design algorithm, is what optimises those three together.

The contrast drawn in the abstract is against conventional work. The claim is that most existing approaches focus on control optimisation alone, while co-design optimises morphology and control jointly, which improves environmental interaction and task performance relative to control design by itself.

The three components are also the axes the taxonomy classifies along. The survey says it introduces a hierarchical taxonomy to classify design spaces and representation methods for control, morphology, and tasks, and that the taxonomy is what makes it possible to analyse more than one hundred recent studies in the field.

So there are two taxonomies stacked. The first splits the field into four method families and further into sub-methods. The second is applied at the level of each study, classifying how it represents control, morphology, and tasks.

That second layer is the part that makes the survey more than a reading list, because it is what lets a reader compare two papers that used completely different hardware and bodies.

Four method families, each with its own sub-divisions

Below the taxonomy section the readme is organised as a menu, and the shape of that menu is the survey's second contribution.

Bi-level co-design is the first family, split into evolutionary reinforcement learning, surrogate-assisted methods, and other methods. Single-level co-design is the second, split five ways: evolutionary-computation-based, reinforcement-learning-based, physics-based, diversity-based, and other.

Generative co-design is the third, split into rule-based generation, latent-based generation, and language-model-based generation. The third of those is the one that has moved fastest, and having it as its own entry rather than as an example inside latent generation is a statement about the field.

Open-ended co-design is the fourth, split into brain-body-environment co-evolution and developmental co-evolution. After the four families come sections on theoretical and experimental analysis, on simulated benchmarks, on real-world systems, a pointer to other surveys, and contact details.

Two structural choices are worth noting. Open-ended co-design is separated from generative co-design even though both produce designs, because the former iterates against an environment over time and the latter produces a design in one shot. And every family ends with an other bucket, which is how a survey of a moving field avoids pretending its categories are exhaustive.

Almost all the prose is raw HTML inside a markdown file

Most of the readme's paragraphs are wrapped in HTML tags rather than written as markdown. The style attribute for justified text appears on paragraph after paragraph, and centred divider elements sit between sections.

The reason is visible in the badge row. The table of contents is attributed to a JavaScript library that renders markdown in the browser, and that library honours embedded HTML where GitHub's own renderer handles it differently. The author was optimising for the rendered page.

On GitHub the effect is inconsistent rather than broken. Markdown outside the HTML renders normally, so headings, lists, and tables are fine. The paragraphs inside the tags render as blocks with no markdown parsing inside them, which means any emphasis written with markdown syntax inside such a paragraph shows its asterisks literally. There is at least one instance of that in the closing notes of the contribution section, where bold markers are visible around a paragraph that also has a stray closing tag.

The table of contents links are another symptom. Most anchors are written as emoji shortcodes, including numbered markers that are not standard and have to be substituted by the rendering library. Two of them are misspelled in a way that matches the heading they point at, so the link resolves but the visible heading reads wrong.

None of this affects the content. All of it affects whether the readme reads as carefully maintained when it is opened on the platform people will actually open it on.

Editorial conclusion

Read this survey if you are starting in embodied co-design and want a map rather than a result. The taxonomy is the contribution: three components and one optimisation algorithm at the root, then four families of method underneath, which is a usable structure for locating work rather than a list of citations. Two things to know before you rely on the repository itself. The badges and the issue links point at an earlier repository under a longer name, so an issue filed from a badge does not land where you think. And the update list is not in chronological order relative to the paper, so the newest-looking entry in the readme is not the most recent event. If you want to contribute, the row format in the instructions is a markdown table row shown inside a Python fence, and the required fields are five while the template has four columns, so match the columns rather than the fence language.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. Yuxing-Wang-THU/SurveyBrainBody on GitHub