How this site is written

1. How claims are sourced

A technical claim on this site should be traceable to a document you can open. In practice that means three things.

The source is the primary document, not an article about it. Where a standard is discussed, the reference is the standards body's own catalogue record. Where a software interface is described, the reference is that project's own documentation at a named version, not a tutorial that paraphrases it.

Every reference states what was actually checked in it. Not just a link, but the sentence that reference supports and the date it was read. Documentation moves; a link that was accurate in November is not self-evidently accurate in March, and a reader deserves to know which it is.

Where a fact could not be confirmed, it is not asserted. There is at least one claim this site deliberately does not make because the primary record could not be found to support it, even though the claim appears widely elsewhere. Leaving it out is the correct outcome, not a gap.

What does not count as a source here: a vendor's marketing page, a figure with no stated method, an aggregated statistic with no underlying study, or a number that appears in many places with no traceable origin. Claims about how often robotics projects fail are the usual example, and this site does not make them.

2. What has been reviewed, and by whom

This is the section that matters most, so it is stated plainly rather than softened.

Nothing on this site has been technically reviewed. No qualified robotics professional has checked the engineering content. No lawyer has checked the licensing or notice pages. The content is researched against primary sources and edited by a named person, and that is a different and weaker thing than review by someone qualified in the subject.

If that changes, this table changes first, and the page in question will name the reviewer and the date. A reviewer will not be claimed anywhere on this site without a real person having actually done the work. Until then the absence is stated in every byline rather than left for a reader to notice.

3. Illustrative examples

Several resources on this site carry a worked example — a filled-in specification, a completed questionnaire, a rights register, a pilot scorecard with real arithmetic in it.

Every one of those is invented. The organisations do not exist, the deployments never happened, no robot ran any of the tasks, and every number was chosen to demonstrate how the arithmetic relates rather than to report what something achieved. Each is labelled hypothetical in the file itself as well as on the page, and the labelling is deliberately repetitive because an example separated from its page is exactly the thing that gets quoted.

They are included because an empty template teaches nothing. A reader who sees a field filled in at the right level of detail understands what the field is asking for; a reader who sees a blank does not. That benefit is worth the risk only if the invented status is impossible to miss.

None of it should be cited, benchmarked against, or used as evidence of anything. Where a number looks like a performance claim, it is not one.

4. Corrections

Send corrections to support@embodiedsoftwarelabs.com. A factual error, a dead or wrong source link, a misread standard, a mistaken technical claim — all of it is welcome, and disagreement from someone who has actually deployed hardware is worth more than agreement from someone who has not.

What happens then:

• A factual error is corrected on the page, and the page carries a dated correction note saying what was wrong and what it now says. The error is described rather than silently replaced.
• A source that has moved or changed is re-read, and the reference is updated with a new checked date. If the source no longer supports the claim, the claim goes.
• A disagreement about interpretation may not produce a change, but it will get an answer explaining why.
• A resource that changes substantively gets a new version number and a change-log entry. The previous version's number is not reused.

Modified dates are not bumped by a deployment. If a page's date changes, something on that page changed.

5. Disclosures

Who publishes this. Embodied Software Labs is a working brand of Synthari AI LLC, a Florida limited liability company. Randy Levine is the publisher and editor and is the person accountable for everything on this site. He is not a robotics engineer and does not hold himself out as one.

No commercial relationships. Nothing on this site is sponsored, paid for, or placed. There are no affiliate links, no referral arrangements, no commissions on anything mentioned, and no advertising. No vendor, manufacturer or supplier has paid for, reviewed, approved or seen any page before publication. Where a product, project or company is named, it is named because it is relevant.

No partners, no customers. No organisation has agreed to participate in any of this, there are no pilot customers, and there is no product to buy. Any page suggesting otherwise would be describing a different venture.

No tracking beyond measurement. This site uses privacy-preserving analytics to count page views and performance. It does not use advertising cookies, does not build profiles, and does not sell data. The privacy notice describes what is collected.

How the pages are produced. Research, drafting and the build scripts behind this site are done with AI assistance. Every page is then checked against its primary sources, edited and published by Randy Levine, who is accountable for what appears here — including the mistakes. That is disclosed because a section headed Disclosures that left it out would be a worse section, and because it bears on how much weight to put on section 2: the sourcing is checked, the subject-matter expertise is not.

The resources are free and will stay that way. The four downloadable templates are published under CC BY 4.0 with no email gate, no account and no registration. That is not a lead-generation tactic with the gate removed; there is no gate to put back.

6. What would change this page

This policy describes current practice, which is the practice of a pre-product venture with one accountable person and no reviewers. Three things would change it, and each would be noted here with a date:

A qualified technical reviewer. The review table in section 2 would change first, the relevant pages would name the reviewer and the date reviewed, and the standing disclosure in each byline would be replaced rather than quietly dropped.

Legal review. Same, for the licensing checklist and the notice pages. Until then those pages deliberately avoid stating legal conclusions, and that constraint is enforced in how they are built rather than left to judgement.

An actual product. If something ships, the claims on this site stop being about a proposal and start being about a thing, and the standard of evidence has to rise accordingly. The development status page is where that would show up first.

Until any of that happens, the position is the one stated at the top: sourced, edited, unreviewed, and honest about which.