Randy Levine

What he actually does here

Three things, and the third is the one that takes the discipline.

Research against primary documents. Standards claims link the catalogue record. Software interface claims link that project's own documentation at a named version. Every reference carries the date it was read, because documentation moves and a link that was right in November is not self-evidently right in March. Where a fact could not be confirmed from a primary record, it does not appear — there is at least one claim this site deliberately declines to make for that reason, even though it is repeated widely elsewhere.

Original work, given away. Four editable resources — a capability specification, an integration questionnaire, a rights inventory and a pilot scorecard — published under Creative Commons with no email gate, no account and nothing to accept. Each carries a fully worked example, and every example is invented and labelled as such, repeatedly, because an example separated from its page is exactly the thing that gets quoted.

Saying what has not been checked. No page here has been reviewed by a qualified robotics professional and none of the notice pages has been reviewed by a lawyer. Every byline says so. The editorial policy carries a table listing, page type by page type, exactly what is sourced and what is unreviewed — and every entry in the review column currently reads No, because that is true.

The standard, and failing it

A stated standard is only worth something if it costs you occasionally.

On 14 November 2026, while preparing a review request for an outside engineer, two claims on this site turned out to fail its own rule. One was an injury statistic with no source behind it. The other was a publication date taken from industry coverage rather than a primary record — on a page that, four paragraphs later, correctly declined to state a date for a different document for exactly that reason.

Both were corrected the same day, before the review request was sent. Neither needed outside judgement to settle; they needed the site to apply to itself the standard it applies to everyone else. The corrections are recorded, and the review request now asks the engineer to check the rewrites rather than the originals.

That is the whole method, and there is not much more to it than that: cite the source, name what you do not know, and fix it in public when you get it wrong.

Inviting people to find the errors

This site was built from an independent audit that was commissioned specifically to find what was wrong with it. Its criticisms — inaccurate standards claims, an unexplanatory homepage, a sprawling content index, resources that did not exist — were implemented rather than argued with.

Two review packets now exist and are being sent out: one extracting every technical claim on the safety pages into a checkable list for someone qualified in that field, the other setting out the legal questions on the notice pages for counsel. Neither asks for an endorsement. Both ask for the errors.

If you work in this field and something here is wrong, that is the most useful message this inbox can receive. Disagreement from someone who has deployed hardware is worth more than agreement from someone who has not, and a correction gets a dated note on the page saying what was wrong.

The venture

Embodied Software Labs is pre-product. There is no robotics software, no supported robot, no customer, no partner, no funding and nothing for sale. What exists is published reference work and four templates.

The position it is built on: the hard part of robotics is increasingly not the machine but the software layer that decides what the machine should do — and that layer has no shared vocabulary, no agreed way to describe what a capability can and cannot do, and no convention for who owns what when one organisation builds a capability and another runs it. The platform page sets out what is proposed, what would have to be validated, and what can be discussed now. The fourth column of the table on that page lists what nobody is responsible for yet, and it has an entry on every row.

That is a position to disagree with rather than a plan. Testing it against people who build, make or operate robots is the current objective.

Getting in touch

support@embodiedsoftwarelabs.com reaches a person. Useful things to send: a correction, a disagreement, a filled-in template that did not work, or a question one of the guides should have answered and did not.

Please keep a first message non-confidential — no source code, no credentials, no unpublished work under embargo, nothing an employer would object to. How a first conversation would go sets out the four steps, and confidential discussion needs an agreement in place before it starts rather than afterwards.