DARPA EDGE workstream recommendation

Goal

Choose a small, finite robotics/controls/sensing/calibration workstream that can be justified to management against a named EDGE criterion, starts before the new PCR/CRISPR instruments arrive, and delivers value independently of a larger platform project.

Recommendation

Superseded as the starting point. A second review agrees with this note’s technical corrections but dissents on the headline pick. As of the 2026-07-30 updates the recommended entry point is tip crash detection on pipetting motions — pipetting carries no force guard today, and the fix applies an existing production mechanism rather than building a detector. See Second reviewer’s addendum and the two dated updates within it.

Qualify one existing autonomous recovery end to end: induce a missing or partial tip pickup, let the existing physical verification detect it, exercise the existing eject/retry path, and prove successful protocol continuation in the campaign metrics.

This is more directly DARPA-relevant—and substantially smaller—than building another detector. EDGE’s CRISPR Phase A criterion requires logs showing:

1. a detected anomaly,
2. a triggered recovery routine, and
3. successful continuation without human assistance.

Tip pickup already has the sensing and control-flow halves. The bounded work is to instrument and physically qualify them as a contractual evidence chain. F/T remains correlated shadow evidence until it proves incremental value over the optical fork.

Manager pitch

EDGE explicitly requires the system to detect an unexpected process error, trigger recovery, and continue without human assistance. We already possess almost the entire mechanism for a common failure shared by both PCR and CRISPR: tip pickup verifies physical tip presence and automatically ejects, retries, and re-grasps. I propose a bounded qualification slice that injects a hidden missing-tip fault on an existing deck, instruments that recovery in the campaign metrics, and demonstrates successful continuation with attempts, human-minutes, and calendar time. It requires no incoming DARPA instruments, produces contract-relevant evidence immediately, and leaves behind a repeatable hardware regression for ML001.

Why this, why now

• The TDD says human protocols omit machine-critical detail and underspecify recovery behavior.
• Autonomous Error Recovery is an explicit CRISPR Phase A success criterion, not merely enabling infrastructure.
• Both PCR and CRISPR depend heavily on pipetting.
• The physical verifier and retry behavior already exist, keeping the slice finite.
• ml1-011/052/056 can support the qualification before new EDGE instruments arrive.
• The campaign-metrics backend already recognizes recovery_result. Active Fahmi branches add a system-owned recovery reporter; this work should contribute the pipette call site and physical qualification rather than rebuild that infrastructure.

The first slice is not the final contractual demonstration. It qualifies the mechanism before hardware arrival; the same recovery must later be demonstrated inside an ML001 CRISPR run.

Load-bearing audit

TDD

Source: /Users/saahas/Downloads/[FINAL] Medra DARPA Lab Autonomy_TDD_v2.docx.md

• Problem statement, lines 3–8: human protocols compress state, omit machine-critical detail, and underspecify recovery. The evaluation measures the rate at which the executability gap closes.
• Primary endpoint, lines 38–47: TVA is reported as attempts, human-minutes, and calendar time. A pass has no critical intervention or hard execution failure.
• PCR decomposition, lines 56–63: includes serial_dilute; thermocycling and electrophoresis are already represented in the repository.
• CRISPR decomposition, lines 101–108: includes read_absorbance, media_exchange, heat_shock, spread_plate, colony_pick, and sequence_load.
• CRISPR autonomy criterion, lines 129–138: fewer than five critical interventions and at least one autonomous anomaly detection → recovery → continuation event.
• Milestones, lines 152–163: ML001 instruments pass initial bench tests/calibrations at two months; measurement infrastructure at 2.5 months; PCR TVA at 3.5 months; CRISPR TVA at 4.5 months.

Repository readiness

• configs/ml1-001/hardware.json contains arm, camera, I/O, and plate-sealer configuration but no equipment-module inventory.
• Repository-wide searches found no implementation hits for: colony_pick, spread_plate, heat_shock, media_exchange, sequence_load, read_absorbance, or serial_dilute.
• Thermocycling and electrophoresis have actual models/actions/equipment support.

Task-check shape

medra_robotics/task_execution/task_checks/ has three vision checks:

File	Lines
deck_occupancy_checks.py	1,249
lid_seating_check.py	549
pipette_grasp_tilt_check.py	175

check_results.py is only 91 lines and provides the cheap reusable part: TaskCheckResult → failed verdict → RequireReview → operator pause.

The pipette-tilt feature is configured by PipetteGraspTiltCheckSettings, off by default. In pipette_tasks.py it has one actual run_post_checks detector call plus a behavior-tree policy switch that removes automatic pickup retry while the blocking check is on. It is not two detector call sites.

The important control-flow limitation is structural: runners invoke post-checks only after the hardware task has returned success and update_effects() has mutated state. That makes task_checks appropriate for post-task review, but the wrong layer for an automatic stamp recovery.

Existing tip-pickup recovery

PickUpPipetteTips already:

1. stamps,
2. verifies tips with camera or optical fork,
3. repeats the optical scan at half speed on mismatch,
4. returns FAILURE when the final detected pattern differs from the expected pattern.

PickUpPipetteTipsTask wraps that behavior in a selector:

1. normal pickup,
2. eject and retry,
3. eject, drop/regrasp the pipette, retry, and eject on final failure.

This is already an autonomous detect/recover loop. What is absent is explicit campaign evidence for this recovery and a repeatable hidden-fault hardware qualification.

Where F/T exists at runtime

F/T is neither MCAP-only nor currently available to task behavior:

1. C++ samples the wrist sensor at approximately 50 Hz during every Denso servo trajectory, filters with a three-sample mean, applies safety/user limits, and stores timestamped samples.
2. DensoControllerServicer returns the timestamped joint, F/T, current, and load sequences in the synchronous gRPC trajectory response.
3. DensoControllerClient.execute_servo_trajectory() passes the response arrays to an asynchronous MCAP/OTel writer.
4. The public method then discards those arrays and returns only APIState.
5. Executor and all controller backends are consequently typed around status-only returns.

Implications:

• A post-motion F/T detector does not need the live-stream branch. It needs a typed trajectory result propagated through the client/executor boundary.
• A real-time reactive controller still needs a live or C++-resident control path because the gRPC response arrives after the trajectory finishes.
• Adding a force check as a fourth task_checks file hides the real cost: result plumbing and correct behavior-layer integration.

F/T empirical limits

From Force based movements - working doc:

• A successful force-gated P1200 pickup produced a repeatable profile; seven traces had median cross-correlation 0.94.
• One observed failure took 92.5 seconds and made 12 erratic stamp attempts before retrying.
• The ml1-056 button experiment separated 5/5 good from 5/5 deliberately bad presses through lateral Fy/Tx, not aggregate force.
• The ml1-011 missing-tip study was a clean negative for identifying which tip was absent. Missing count was recoverable only after fitting out holder-position tilt and still required a per-position full-column baseline.
• The ml1-011 one-channel offset experiment was much stronger:
  • 65 cycles across good and ±x/±y offsets;
  • Tx versus dx: slope 0.90 N·m/mm, (R^2=0.98);
  • every 0.3 mm block separated from good by at least 3σ on one channel;
  • (\Delta Tx/\Delta Fy \approx 0.36) m, versus the approximately 0.12 m sensor-to-tip lever shadow, indicating a genuine cone-interface couple.

This is compelling local physics, not evidence for one universal F/T anomaly score.

F/T fleet and safety history

From ft-noise-floor-analysis and Force based movements RFC:

• Healthy raw noise is roughly 0.2–0.4 N and 0.04–0.09 N·m.
• Per-deck σ spans roughly 3–5×; thresholds must be deck-relative.
• Slow DC drift dominates over minutes.
• Nine fleet decks were σ/spike outliers; ml1-025 had a saturated DC offset with otherwise normal noise shape.
• Typical force-stop latency is about 50 ms, with an estimated 70 ms worst case; the arm continues forward during that delay.

Current main already classifies physically impossible F/T magnitudes as sensor faults. A later startup gate and non-resumable handling were reverted: the pre-zero check treated normal static bias and gravity wrench as a fault and blocked healthy decks. A correct health workstream must use a known-safe unloaded condition, post-zero measurements, and a remote recovery path.

Calibration evidence

From ml1-052-autocalibrate-force-debug:

• 37 Z probes: 27 healthy, 6 deep, 4 missed contact entirely and traversed the full 30 mm envelope.
• The dominant cause was incorrect starting geometry, not a broken 10 N force gate.
• All six calibrated_arm.urdf artifacts were byte-identical to each other and effectively nominal, so there was no meaningful per-robot kinematic correction.

Current calibration code:

• has 8 literal top-level autocalibrate_*.py scripts;
• has 59 top-level calibration Python files and 78 recursively;
• uses find_force_boundary() with a 10 N / 1 N·m gate and returns only the final waypoint;
• already has verify_tip_holders.py, which exercises calibrated corner/edge pickups but does not produce a quantitative contact/overtravel acceptance certificate.

Branch shapes

Branch	Shape relative to main	Interpretation
saahas/ft-experiments	15 new files, 2,334 additions; 12 ahead / 1,407 behind	Useful experimental scripts, but not a small merge-ready unit.
saahas/ft-cal-force-live	10 files, 695 additions; 1 ahead / 1,987 behind	Live Get/Stream/Tare RPC and renderer; unnecessary for post-motion scoring.
saahas/tool-recovery-state-snapshots	4 files, 568 additions; 2 ahead / 1,962 behind	Only persistence substrate, not usable recovery alone.
origin/fahmi/campaign-metrics-safety-sync	Active stacked branch, updated 2026-07-27	Already adds autonomous-recovery reporting infrastructure; coordinate rather than duplicate.

The state-recovery notes explicitly split the full work into:

1. serialization/persistence,
2. fleet-wide runner lifecycle integration, and
3. hardware-facing held-tool/payload recovery.

The latter two require end-to-end simulation and robot validation. It is not a small one-branch cleanup.

Ranked shortlist

Rank	Workstream and first valuable slice	Rough size	Named TDD criterion	Main risk
1	Qualify missing-tip autonomous recovery. Hide one physical missing tip from robot state; demonstrate detection, eject/retry, task success, next-task continuation, and a system-owned recovery metric. Keep F/T as shadow evidence.	3–5 days + one deck session	Autonomous Error Recovery; Human Interventions; TVA	Proves an existing mechanism rather than inventing one; depends on coordination with active metrics work.
2	Force-probe calibration acceptance certificate. A standalone verifier reports contact travel, full-envelope misses, stop-position variance, and pass/fail bounds on existing decks.	4–6 days	ML001 bench tests/calibrations; TVA hard failures	Thresholds may be fixture-specific; geometry can dominate sensor behavior.
3	Couple-null identifiability study—not autocalibration yet. Repeat the cross-pattern on multiple holders/decks and test invariance to tip, approach direction, orientation, and matched free-space baselines.	4–7 days	ML001 calibrations; Primitive Novelty	The measured zero may not equal geometric center.
4	Gemini affordance → classical planner in simulation. Convert one two-view target into a collision-checked approach/contact/depart plan, supplying orientation from the canonical primitive.	3–5 days	Specification Deficit; Primitive Novelty	14–26 mm ray gaps and missing orientation can yield a demo that does not reduce TVA.
5	Correct post-zero F/T health acceptance. Rework the reverted startup gate around a known-safe pose, post-zero readings, and remote recovery.	1–2 weeks	Functional checkout; Human Interventions	Safety-sensitive, and the predecessor blocked healthy field decks.
6	Expose trajectory-scoped F/T to one shadow detector. Return a typed trajectory result and score one physically motivated signature inside tip pickup.	1–2 weeks	Autonomous Error Recovery	Cross-backend/executor plumbing is broader than it appears; labels are insufficient for a production gate.
7	Revive generic held-tool recovery. Rebase snapshots, integrate lifecycle persistence, then qualify payload put-down.	~1 week substrate; 3–4 weeks usable recovery	TVA human-minutes/calendar time	Operator-invoked recovery does not satisfy the autonomous-recovery criterion.
8	Offline admittance replay. Verify frames, units, delay sensitivity, saturation, and passivity inequalities against logs.	3–5 days offline	Operational Complexity, weakly	Recorded wrench is not generated by the counterfactual controller, so replay cannot validate closed-loop stability.

Recommended first slice

Experiment

1. On a deck with an optical fork and multichannel pipette, remove one physical tip from a column that the in-memory state still believes is full.
2. Run the normal production PickUpPipetteTipsTask; do not bypass its detector or retry tree.
3. Confirm the optical fork detects the mismatch after its normal confirmation scan.
4. Confirm the tree ejects any attached tips, advances to another source column, and succeeds.
5. Run a subsequent task to prove continuation rather than mere recovery-task completion.
6. Preserve the F/T trace as shadow diagnostic evidence, not the gating signal.

Definition of done

• Five hidden-fault trials; five autonomous continuations.
• No human action after the run starts.
• One recovery_result per induced recovery, actor=system.
• Metadata includes expected channels, detected channels, source holder/column, recovery routine, and final task status.
• The next task succeeds.
• Attempts, human-minutes, recovery duration, and calendar time are reported.
• Any F/T claim is explicitly comparative against the optical fork:
  • earlier detection,
  • less recovery latency, or
  • detection of a failure class the fork misses.

Scope exclusions

• No generic recovery framework.
• No runtime F/T streaming.
• No production F/T gate.
• No broad task-check refactor.
• No assay/QC/statistical work.
• No dependency on incoming EDGE instruments.

Strongest argument against

This can be criticized as contractual evidence for a retry that already exists, rather than a new capability that closes the executability gap. A deliberately injected fault may also be challenged as not truly “unexpected.”

The honest response is:

• the fault is predeclared to the evaluator but hidden from the running system, as in a normal robustness test;
• this slice qualifies the mechanism and measurement path before hardware arrival;
• it does not replace the later in-protocol ML001 recovery demonstration.

If management wants net-new scientific capability rather than de-risked contractual evidence, choose the calibration acceptance certificate or couple-null validation.

Why the previous ranking is wrong

1. Couple-null was promoted from correlation to calibration too early

Let measured torque under a lateral offset (d) be

[ m(d)=k(d-d_*)+b, ]

where (d_*) is the geometric center and (b) is gravity, sensor bias, or an interface-specific offset. The sweep identifies (k) and the combined intercept (-kd_*+b). Its measured zero is

[ d_0=d_*-\frac{b}{k}, ]

not (d_*), unless (b) is independently known or canceled.

The existing experiment takes its baseline at hover and its read while seated, and explicitly flags pose-dependent gravity DC. The slope and direction response are strong; the absolute +1.2 mm center is not yet identifiable. The right first slice is a symmetry/baseline and cross-deck repeatability experiment, not a waypoint-writing autocalibrator.

2. “A fourth file in task_checks” is the wrong abstraction

The reusable verdict-to-review path is cheap, but:

• task checks do not receive trajectory F/T;
• post-checks run after task success and state effects;
• a failed check pauses a human;
• tip pickup already has a behavior-layer detector and recovery selector.

A force-seating detector belongs inside that control loop if it proves incremental value. Putting it in task_checks optimizes for code-file similarity rather than the required behavior.

3. The health monitor underestimates recent failure history

Main already contains physically impossible-value classification. The attempted startup re-zero/non-resumable work was reverted after normal pre-zero bias and gravity blocked healthy decks. A correct version is useful but must solve:

• safe unloaded-state identification,
• post-zero validity,
• orientation/payload dependence,
• remote recovery,
• resumable versus non-resumable policy.

That is not a trivial monitor built from fleet σ.

4. State snapshots do not equal autonomous recovery

The 568-line branch only reconstructs logical deck state. Usable recovery also requires fleet-wide lifecycle writes and hardware-facing payload placement. More importantly, its target is operator-invoked recovery after a failed/interrupted run. It reduces human-minutes and calendar time, but does not satisfy “without human assistance.”

5. Offline admittance replay cannot establish closed-loop behavior

Replay can falsify:

• wrong frames or signs,
• unit errors,
• excessive gain,
• actuator saturation,
• obvious delay/passivity violations.

It cannot validate stability or task usefulness because the recorded contact wrench arose under a different commanded trajectory. Under admittance, motion changes contact, contact changes wrench, and wrench changes motion. That causal loop is absent from log replay.

6. Generic runtime F/T plumbing has no standalone program outcome

For post-motion use, samples already cross gRPC; expose them only as part of a named recovery/calibration result. For reactive control, the architecture is materially larger. Plumbing alone is a platform-shaped first slice.

7. Gemini is technically stronger than MolmoAct but not the immediate TVA path

From molmoact-pilot, MolmoAct produced 18/18 traces anchored to the current gripper rather than the target. From gemini-affordance-3d, Gemini Robotics-ER produced semantically correct target points and a working two-view 3D reconstruction, but ray gaps remained 14–26 mm and orientation was unresolved.

A planner push is a legitimate small experiment and directly addresses Specification Deficit. It still needs a classical contact primitive and canonical orientation, so it ranks behind the recovery and calibration slices.

Overall view on force-based verification

Force verification is not the wrong bet. Verification without an automatic corrective action is the wrong unit of progress for EDGE.

The data show three different physical regimes:

• point-contact button pressing: lateral force and its lever-arm torque shadow;
• missing multichannel tips: mainly detrended axial force, no recoverable tip identity;
• seated cone interface: a genuine transmitted couple with excellent offset sensitivity.

There is no evidence yet for one generic F/T anomaly detector. Force sensing should be promoted when it:

1. connects to a named recovery,
2. eliminates manual calibration time, or
3. detects a failure class the existing camera/fork cannot.

Another detector that only pauses the run can increase the human-minute component of TVA. Optimize the closed loop—detect, recover, continue—not the detector count.

Shape of the proposed first diff

New files

• medra_robotics/scripts/testing_scripts/tip_pickup_recovery_qualification.py — repeatable hidden-fault hardware qualification using the production task path.
• medra_robotics/tests/task_execution/test_tip_pickup_recovery_reporting.py — protects anomaly-report and successful-retry semantics.
• docs/knowledge/log_entries/<timestamp>-tip-pickup-recovery-qualification.md — PR-level knowledge entry.

Edited files

• medra_robotics/task_execution/behaviors/pipette_behaviors.py — emit one recovery report after the confirmed optical mismatch.
• docs/knowledge/subsystems/task-execution.md — document the qualified detection → retry → campaign-metric flow.

Second reviewer’s addendum (Claude, 2026-07-28)

I produced the earlier ranking this note critiques. I verified the architectural claims above against main before writing this; all four load-bearing ones hold:

Claim	Verified
check_results.py is 91 lines	yes
Post-checks run after update_effects()	yes — runner.py:948 then :958
execute_servo_trajectory() returns only APIState	yes
PickUpPipetteTipsTask already has an eject/retry/dropoff selector	yes
recovery_result in campaign metrics + active Fahmi branch stack	yes, six branches

Where this note is right and my ranking was wrong

1. Couple-null identifiability. The (d_0 = d_* - b/k) argument is correct and decisive. The working doc already flagged it (“slopes are contact, absolute nulls are first-order”) and I promoted a caveat-flagged result to a shippable autocalibrator. An identifiability and cross-deck repeatability study is the right first slice; writing waypoints is not.
2. task_checks is the wrong layer. Post-checks fire after the task returns success and state effects have applied, so a force check there can only pause a human — it cannot drive automatic recovery. My “fourth file, ~175 lines” estimate was reasoning from file size rather than control flow.
3. The TVA inversion is the sharpest point in the note. A detector that pauses a run adds to the human-minutes component of TVA. That directly undercuts the DARPA justification I built the pitch on. “Optimize the closed loop, not the detector count” is the correct frame.
4. F/T plumbing cost. The samples cross gRPC but are discarded at the client boundary, and every backend is typed around status-only returns. Any post-motion detector pays that threading cost first.
5. Tip pickup is not a silent-failure case. Optical-fork verification plus an automatic retry tree already exist. My “silent failures only surface at QC” framing was too strong here; it holds for plate seating and button presses, not for tip pickup.

Where I dissent — the #1 pick

The ranking is sound on technical merit but optimizes for contract evidence, and the stated purpose of this exercise is justifying my own effort to my manager. Those want different things.

• The deliverable is thin as personal work product. A qualification script, one metric emission, and a test — proving an existing retry path already works. The note concedes this in its own “strongest argument against” and hands off to the calibration slice if management wants net-new capability. Given the stated purpose, that fallback should be the primary.
• Hardware-session risk is asymmetric and unpriced. The definition of done needs five clean hidden-fault trials with zero human action after start. Deck sessions fail for unrelated reasons constantly — latched Denso safety states, wedged instruments, checkout/redis skew are all in my own notes. A bad session there yields a blocked deliverable, not a partial result. An identifiability or acceptance-certificate study degrades gracefully: noisy data is still data, and the analysis is the artifact.
• Coupling to an active six-branch stack is the wrong shape for a first task back. Coordinating with the campaign-metrics work is correct in principle, but “my deliverable merges after yours” is how a five-day task becomes three weeks of waiting.

Revised recommendation

Take rank 2 (force-probe calibration acceptance certificate) as the primary, and fold rank 3 (couple-null identifiability) into it as the research component. Reasons:

• Standalone — no dependency on another engineer’s branch.
• Degrades gracefully under hardware flakiness.
• Produces a visible, quantitative artifact per deck rather than a passing test.
• Serves milestone 2 directly: ML001 instruments “passing initial bench test and calibrations.”
• Has a concrete motivating “before” number already in hand: 4/37 Z probes missing contact entirely and 6/37 running deep on ml1-052, against an autocalibration path that reports no quantitative acceptance signal today.
• The certificate is the natural eventual home for a couple-null measurement, so the two compose instead of competing.

Rank 1 stays valuable — it should be done, and it is the cleanest contractual evidence available before hardware arrives. It’s better handed to whoever owns the EDGE evidence chain, or picked up after the certificate ships.

Update 2026-07-30 — instruments have arrived; PCR-line bringup is already live

The PCR/CRISPR instruments are physically on site. Both rankings above assumed a ~2-month gap and used “starts before hardware arrives” as a selection criterion; that tiebreaker is gone. Repo state as of origin/main + active branches:

• PCR-line bringup is underway on ml1-030, not ML001, and is not labeled DARPA. origin/jared/fa-bringup brings up the Agilent Fragment Analyzer 5400 — capillary electrophoresis, i.e. protocol P2.4 — with commits dated 2026-07-30, a fragment_analyzer_config block in configs/ml1-030/hardware.json, a new fragment_analyzer_client.py, and PyRPA drawer/stage control over a Windows instrument host.
• configs/ml1-001/hardware.json still has no equipment-module inventory. Recent ml1-001 commits are camera cleanup (#12244), not equipment.
• The primitive gap is narrower than the TDD implies. Thermocycling has three drivers (biorad_cfx_opus_96, biorad_ptc_tempo, inheco_odtc) and CE now has one; absorbance and fluorescence have equipment (epoch2, biotek_cytation_5) even without named primitives. The genuine holes are colony_pick and spread_plate — both CRISPR-side, neither with a primitive nor any equipment driver.

Effect on the ranking:

1. Rank 1 weakens. Its stated rationale was “qualifies the mechanism before hardware arrival.” With instruments present, a reviewer can reasonably ask why the recovery isn’t demonstrated inside a real protocol run instead of a synthetic hidden-fault trial.
2. Rank 2 strengthens, and becomes time-sensitive. Milestone 2’s exit criterion is instruments “installed, and passing initial bench test and calibrations.” That calibration work is happening right now, by hand, on ml1-030 — and there is still no quantitative acceptance signal. A certificate has a live consumer this week; in a month the decks are calibrated and it’s retrospective.
3. Coordinate with jared/fa-bringup. New instrument, new holders, new waypoints — the FA is the natural first subject for an acceptance certificate, and its bringup is generating the exact manual-calibration effort the certificate is meant to quantify.
4. Milestone compression. If arrival ≈ the 2-month mark, then measurement infrastructure (2.5 months) and PCR TVA (3.5 months) are close behind. That disfavors speculative work and favors anything with an immediate consumer.

On the two F/T scope exclusions

“No runtime F/T streaming” and “no production F/T gate” are fences on the rank-1 slice, not permanent policy. Their justifications differ and are worth keeping straight:

• Streaming is excluded because post-motion detection does not need it — trajectory samples already cross gRPC and are merely discarded at the client boundary, so the missing piece is a typed return, not new transport. Only reactive control needs a live path, since the gRPC response lands after the trajectory completes. The fence stops scope creep from “save a trace” into “build the admittance controller.”
• Gating is excluded on three grounds: the TVA inversion (a gate that pauses adds human-minutes); threshold generalization (per-deck σ spans 3–5×, DC drift dominates, so thresholds must be deck-relative and false positives stop production); and regime specificity (three studies, three different signatures, no universal anomaly score). Precedent supports the caution — a startup F/T gate was already tried and reverted for reading normal bias and gravity wrench as a fault.

Consequence worth stating plainly: with streaming and gating both excluded and F/T demoted to shadow evidence, rank 1 contains almost no force work. It is a recovery-qualification slice that saves traces. The calibration certificate needs neither exclusion lifted — it uses force as a contact trigger through the existing find_force_boundary(), offline and standalone — which is another reason it is the better fit for a force-focused workstream.

Update 2026-07-30 (later) — the silent-failure gap, and tip crash detection as the entry point

Two findings from working through failure classes. These supersede both rankings above as the recommended starting point.

1. There is a structural silent-failure window mid-protocol

Tip state is verified at pickup (fork/camera confirms present) and at eject (_handle_tip_eject_verification → task fails only if any(channels_with_tips), i.e. it confirms tips are absent). Nothing verifies in between, and the eject check structurally cannot catch a mid-protocol tip loss: a tip that already fell off is indistinguishable from one that ejected cleanly. It passes. There is no pressure or tip-presence sensing on the Picus. (#12265, 2026-07-28, removed pre-ejection camera validation and the 457-line bent-tip detector; per its own description those were empty on every deck and the result deliberately ignored, so nothing regressed.)

How EDGE scores the three outcomes — the asymmetry is the important part:

Outcome	Cost
Caught + auto-recovered	Attempts + calendar time only. Still an autonomous pass. Credited — the Autonomy criterion requires such an event in the logs.
Caught + needs a human	Counts against ”< 5 critical interventions”; adds human-minutes; breaks the pass condition.
Silent	Run looks clean by execution criteria; fails at QC → TVA hit anyway → and the attribution is destroyed.

The attribution loss is what makes silent failures disproportionately expensive here. Oracle uplift is TVA(human-written) − TVA(oracle); random silent mechanical failures inject noise into both arms, do not cancel, and widen the error bars on the program’s headline number. EDGE’s metrics are built so that failing loudly and recovering scores better than failing quietly — so detection has value even where recovery is impossible, because it converts a corrupted-attribution QC failure into an honest, attributable execution failure.

This refines the TVA-inversion objection: for this failure class the comparison is not detector-vs-nothing but pause vs lost run. On a 3–5 day CRISPR cycle a pause is drastically cheaper. The inversion argument is weakest exactly where failures are silent, high-cost, and long-cycle.

2. Pipetting motions carry no force guard at all — this is the entry point

pipette_behaviors.py has exactly two ForceControlParameters uses: the stamp (line 966) and the tip-holder return descend (line 1515, ForceControlParameters(70), “Descend with force sensing to fail safely if a collision occurs”). The pipetting motions — descend into well, aspirate, dispense, blowout, mix — have none. Only the always-on collision loop watches them, at the deck-configured force_limit: 200 N / force_rate_threshold: 600 N/s. Against a 0.2–0.4 N noise floor that leaves roughly 1–200 N unguarded; a tip crashing into a well bottom at ~40 N, enough to bend it, is invisible.

Why this is the best entry point discussed. It is not a new detector — it applies an existing, production-proven mechanism to the motion next door. It therefore dodges all three standing objections: the task_checks layering problem (a force limit trips in the C++ servo loop, before the task returns and before update_effects()), the F/T plumbing cost (ForceControlParameters is a motion input; no typed trajectory result needed), and most of the gating exclusion’s rationale (per-deck σ spanning 3–5× is decisive at ~1 N and irrelevant at 40 N; one threshold on one motion class is not a universal anomaly score). EDGE hook: PCR Phase B requires “>90% successful robotic run completion with correct liquid handling.”

Caveats:

• Intentional contact exists. drag_tip_against_wall blowout, blowout dips, mixing near the bottom. Contact ≠ fault.
• False trips cost more here than anywhere else. Thousands of pipetting moves per run vs a handful of plate placements; a rate that is harmless for place_plate_gently is a run-killer.
• Multichannel likely won’t resolve per-channel. The ml1-011 missing-tip study is the evidence — 8-channel aggregate |Fz| could not recover per-channel state and holder tilt dominated. Single-channel is the better bet.
• Detection, not prevention: 50–70 ms latency means 0.3–1.9 mm of over-travel regardless, so a bent tip is probably already bent. The value is silent → loud.

First slice — characterize the normal pipetting force envelope. Same experiment shape as the button-press and offset studies, so novelty risk is near zero: log F/T across descend/aspirate/dispense/blowout/depart segmented per phase; establish the normal envelope including drag_tip_against_wall and blowout dips; induce crashes by commanding Z 1–3 mm deep (same mutation pattern as the button-press BAD arm); report separation, a recommended threshold per tip type and channel count, and a measured false-trip rate. The characterization stands alone as a deliverable; if it ships, the production diff is one ForceControlParameters(N) on the descend, matching line 1515.

Verify early: whether a descend force trip routes into an existing retry path or merely fails the task. If it reaches a retry, this yields the full detect → recover → continue chain the CRISPR Autonomy criterion asks for, which is a materially bigger claim than crash detection alone.

Relation to the calibration certificate (rank 2): they address the same root cause from two sides — a tip crash is usually calibration drift in Z, so the certificate catches drift offline and crash detection catches it at runtime. The certificate has the better milestone-2 story; crash detection has the better liquid-handling and error-recovery story and a much smaller production diff.

One thing neither ranking addresses

ml1-052’s six calibrated_arm.urdf artifacts are byte-identical to nominal — that deck carries no per-robot kinematic correction at all. That is independent of whichever slice is chosen and worth raising with whoever owns fleet calibration regardless.

Related notes

• Force based movements RFC
• Force based movements - working doc
• ft-noise-floor-analysis
• fleet-ft-characterization
• ft-analysis-process
• live-force-rendering-ml1-049
• force-based-plate-placement
• probe-calib-research
• ml1-052-autocalibrate-force-debug
• tool-recovery-pr-split
• well-plate-presence-check
• vla-task-space
• molmoact-pilot
• gemini-affordance-3d
• path-planning
• kautilya-path-planning-summary
• multi-deck-sim