<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Robotics on Liam Ding</title>
    <link>https://www.liamding.com/en/tags/robotics/</link>
    <description>Recent content in Robotics on Liam Ding</description>
    <image>
      <title>Liam Ding</title>
      <url>https://www.liamding.com/img/og-cover.png</url>
      <link>https://www.liamding.com/img/og-cover.png</link>
    </image>
    <generator>Hugo -- 0.147.7</generator>
    <language>en</language>
    <lastBuildDate>Sun, 25 Oct 2026 00:00:00 +0800</lastBuildDate>
    <atom:link href="https://www.liamding.com/en/tags/robotics/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Human in the loop is not a robot safety specification, and ADAS already proved it</title>
      <link>https://www.liamding.com/en/posts/2026-10-14-human-in-the-loop-is-not-a-robot-safety-spec/</link>
      <pubDate>Wed, 14 Oct 2026 00:00:00 +0800</pubDate>
      <guid>https://www.liamding.com/en/posts/2026-10-14-human-in-the-loop-is-not-a-robot-safety-spec/</guid>
      <description>Anthropic&amp;#39;s usage policy treats autonomous physical operation as high risk. My reading from ADAS: &amp;#39;human in the loop&amp;#39; is a compliance condition, not a safety specification. Spec the numbers instead.</description>
      <content:encoded><![CDATA[<h2 id="the-problem">The problem</h2>
<p>Anthropic&rsquo;s usage policy puts autonomous physical operation in a high-risk category that requires a human in the loop, and separately bars using its models to arm drones. My conclusion is that the risk tier is right and the boolean is wrong: what belongs in that sentence is a set of numbers, not a person&rsquo;s presence. The drone clause is uncontroversial. The human-in-the-loop clause looks like a bright line and is not one, because it carries no engineering content. It does not say how fast the human must respond, how many machines one human may hold, what the robot does when the human is unreachable, or how any of it is verified.</p>
<p>Automotive went through this phase. &ldquo;The driver is supervising&rdquo; was both the regulatory and the marketing answer to level-2 assistance, and it satisfied nobody — not the regulator who had to define supervision, not the insurer pricing it, not the engineers implementing a sentence with no threshold in it. What moved the industry was quantification: a declared ODD, a measured takeover time, a published operational number, argued inside a taxonomy everyone had agreed on.</p>
<p>The timing is the interesting part. The same week, Anthropic published research showing a 9B model running inference on eight of the nine hardware classes it tested, with 30B-and-below models completing most individual steps of autonomous replication; Epic Games moved to an AI-first pipeline where Claude writes all the code and directs all the art on a project tied to a $1.5bn Disney partnership; and QGIS merged QEP428 on 2026-10-07 declaring AI-assisted contributions NOT ALLOWED. Three policy postures toward machine autonomy in one week — and only one concerns a domain where a wrong action can be undone.</p>
<h2 id="what-i-concluded">What I concluded</h2>
<p>Naming physical action as its own risk surface is correct and overdue. Expressing the control as a boolean is the mistake. The line that matters is not human versus no human; it is reversible versus irreversible error. A software agent that leaves a background daemon running after you close the terminal — Codex CLI 0.157.0 does exactly this by default, with <code>codex app-server --managed-daemon</code> — is an annoyance you end with a process kill. An arm moving through a shared aisle is not undoable, and &ldquo;the operator was watching&rdquo; does not reverse the outcome.</p>
<p>What should be written instead is a quantified human-in-the-loop specification with four numbers: teleoperation ratio (share of runtime or task attempts that genuinely needs a remote human), takeover latency as a distribution with a stated P95, operator concurrency (robots per trained operator per shift), and the minimum risk state the robot enters when the human link fails. A fifth, if allowed: the authority model — what the robot may do when it cannot reach a human and stopping is the worse option.</p>
<p>That reframes the question. &ldquo;A human must be in the loop&rdquo; asks whether someone is watching. &ldquo;Disclose your teleop ratio and your takeover P95&rdquo; asks whether the deployment is actually supervised. Only the second is auditable.</p>
<h2 id="constraints">Constraints</h2>
<p>Four constraints decide how far this gets.</p>
<p>Vocabulary. ADAS inherited a coarse but shared taxonomy of levels and a shared concept of ODD. Mobile manipulators and humanoids have no equivalent: no agreed definition of a task, no ODD language for mixed-traffic warehouses, no rule for when a model version change makes it a different deployment. Without that, a teleop ratio is not comparable across vendors.</p>
<p>Measurement culture. Automotive has a reporting habit for disengagements and mileage. Robotics has demos. There is no public benchmark for takeover latency in manipulation and no cross-vendor reporting of operator concurrency, so the numbers I am asking for have to be built by each deployer rather than compared against a norm.</p>
<p>Split incentives. Model providers inherit the compliance obligation, integrators carry the deployment cost, the site carries the physical risk. Nobody in that chain is naturally funded to measure.</p>
<p>The constraint that decides the outcome: auditability asymmetry. A boolean is cheap to check, and therefore attractive to a regulator with no robotics headcount. A P95 requires telemetry, definitions and a competent auditor. Policy gets written at the level of what can be verified — which is exactly why the boolean survives unless deployers bring the numbers first.</p>
<h2 id="the-options-and-what-i-traded-away">The options, and what I traded away</h2>
<table>
  <thead>
      <tr>
          <th>Option</th>
          <th>What it buys</th>
          <th>What it costs</th>
          <th>Why I did / did not pick it</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>Treat the clause as a checkbox: name a remote supervisor, define nothing</td>
          <td>Fastest route to a signed deployment; lowest headcount</td>
          <td>Zero risk reduction — the failure mode is unchanged, only documented; will not survive the first incident or a serious procurement audit</td>
          <td>Not picked. It turns a safety question into a documentation question, and it is why &ldquo;supervision&rdquo; became a dirty word in ADAS</td>
      </tr>
      <tr>
          <td>One full-time teleoperator per robot</td>
          <td>Real fallback authority; the only thing that works today on the hardest tasks</td>
          <td>Fleet size becomes a function of headcount; unit economics does not close; fatigue degrades it into the checkbox within a shift</td>
          <td>Not picked as the target; kept as the data-collection mode</td>
      </tr>
      <tr>
          <td>Publish a quantified human-in-the-loop spec — teleop ratio, takeover P95, robots per operator, minimum risk state</td>
          <td>An acceptance-testable product claim; forces takeover-latency telemetry and a minimum-risk-state definition before concurrency is raised; gives procurement something to contract on</td>
          <td>Expensive to instrument; you will miss your own numbers early; it slows the roadmap</td>
          <td>Picked. A number is the only thing that can be argued with</td>
      </tr>
      <tr>
          <td>Wait for a standard, or lobby the clause away</td>
          <td>Avoids failing your own numbers in public</td>
          <td>Nothing ships meanwhile; buyers default to the checkbox, which then becomes the de facto standard</td>
          <td>Not picked</td>
      </tr>
  </tbody>
</table>
<p>I would deliberately run the second option during data collection and contract to reach the third. What I traded away is the comfort of pretending the checkbox was sufficient.</p>
<h2 id="evidence">Evidence</h2>
<p>The reversibility asymmetry is directly observable. Codex CLI 0.157.0 opening a persistent managed daemon when an interactive session starts is a real agent-containment failure, recoverable in seconds. QGIS can declare AI-assisted contributions NOT ALLOWED (QEP428, merged 2026-10-07) because its worst case is a bad patch in a review queue. Epic&rsquo;s Claude-driven pipeline can iterate because the artefact is code and art. Those domains can afford blunt policy because a wrong action is reversible. Physical action is the one category where that assumption fails — which is why I accept the risk tier and reject the boolean.</p>
<p>Capability is documented too: Anthropic&rsquo;s own research shows 9B models running on eight of nine tested hardware classes, with 30B and below completing most single steps of autonomous replication. Read that as a forecast about cheap autonomy attempts, not about robots doing useful work.</p>
<p>What I am not treating as evidence: the automotive record, which I can describe structurally but will not quote as a benchmark here. And no public dataset exists for manipulation takeover latency, so my four numbers are a proposal, not a standard.</p>
<h2 id="where-this-stops-being-true">Where this stops being true</h2>
<p>Inside a fenced cell with hard interlocks and one repeated task, &ldquo;no human inside the fence while the cell runs&rdquo; is correct and sufficient, because the fence is the control and the human is not. The boolean is right there.</p>
<p>Fleet size: below a handful of units — order of one to ten — the operator is effectively the integration layer and a takeover P95 is theatre. The argument bites once the operator-to-robot ratio reaches a hiring plan.</p>
<p>Segment: this is about unstructured, multi-task manipulation in spaces shared with people. A fixed-track AGV in a closed aisle is a different problem with a defensible fixed rule. And the numbers themselves move: if a coming VLA generation pushes interventions down to exception handling, the four metrics are still the right specification while their acceptable values shift a long way. Today&rsquo;s numbers are not the target.</p>
<p>Company size and region: a small team cannot fund the measurement stack, and what a deployer must file differs by jurisdiction. Proportion the spec to the fleet and to who owns the risk. The argument also stops being true in the good way if standards bodies put the numbers into the rule — then a boolean attestation is fine, because the standard carries the engineering content.</p>
<h2 id="what-i-would-do-differently">What I would do differently</h2>
<p>If I were drafting the clause, I would keep the risk tier and replace the condition: disclose teleop ratio, takeover latency with a P95, robots per operator and minimum risk state at deployment, and update the disclosure when the model or the operating domain changes.</p>
<p>If I were buying, I would put those four numbers in the contract with a test procedure and a remedy, and refuse &ldquo;the operator is in the loop&rdquo; as an answer to a technical question.</p>
<p>If I were deploying, I would instrument the human link before adding robots — link loss, takeover latency and minimum-risk-state entry as first-class telemetry — and cap concurrency at what is genuinely supervised, raising it only with data.</p>
<p>The wider lesson from ADAS is that the industries which measured got the better regulation. Robotics should start that measurement culture before an incident makes it mandatory, because boolean rules that fail do not get refined. They get replaced with something much blunter.</p>
<p>This post is part of my <a href="/en/agents/">personal AI agents guide</a>.</p>
]]></content:encoded>
    </item>
  </channel>
</rss>
