Research

Simulator-Verified Skill Acquisition for Scientific Instruments

Proprio: persistent test-time learning that turns scientific instrument documentation into reusable operating skills, with admission held outside the model

PublishedJuly 13, 2026
AuthorJarrod Barnes

TL;DR

How much of an instrument can an agent learn to operate on its own? We point a model at documentation for an unfamiliar scientific instrument and give it a simulator. The model drafts an operating skill, executes it, reads the failures, and repairs its procedure in one persistent context. It can learn from every attempt, but it cannot decide when its own work is good enough. A separate verifier, which the model cannot change, controls what enters the skill library. The loop self-verifies in simulation before any hardware is touched. Draft, execute, check against an independent physical contract, admit or reject.

Truthful simulator feedback produced 14 non-regressive repairs from 18 identical starting drafts; without that feedback the same drafts produced none (exact one-sided paired p = 0.000061). Across six simulated instruments in three families, 60 of 60 independent generations passed the registered checks. Under one frozen persistent protocol, the agent completed acquisition, held-out verification, repair, drift detection, and staged evolution across three external instrument families without promoting an invalid candidate. Verified in simulation. Hardware validation remains separate.

Code
The Proprio repository on GitHub
Published skills
Five hash-bound skill packages

The clearest way to see the loop is to watch it run. Below, a persistent agent reads the development source for an OpenFlexure microscope in a live terminal while the native simulator runs beside it. A fresh execution is rejected on its acquisition-time budget, the agent repairs the skill until an independent physical gate admits it, a registered drift then breaks the admitted skill, and a first evolution proposal is rejected before a corrected one is finally staged, with the parent skill left immutable throughout.

The OpenFlexure full-loop demo. GPT-5.6 Luna reads the instrument source in a live terminal, left, while the native microscope simulator runs beside it, right. The full run, about 22 minutes at roughly 7x speed, silent, ending on the staged evolution record. Verified in simulation. Hardware validation remains separate.Evidence manifestFull unedited run (22 min) →

Every instrument brings the same integration work. Someone reads the manual, learns the control interface, writes a procedure, tests it, and decides whether the result is safe to reuse. That knowledge lives with trained operators and in their manuals rather than in any interface, so laboratories integrate one bespoke instrument at a time and the engineering repeats at every platform.

Even the strongest instrument agents to date have run under close human supervision, which is the current price of trusting an agent near hardware. That makes instrument operation a binding constraint on autonomous discovery; until acquiring a trustworthy procedure is fast and auditable, every discovery loop keeps a human at the point where its decisions touch hardware.

The Instrument-Operation Gap

Scientific instruments are becoming easier to address from software, and no easier to operate. Bluesky and Ophyd expose beamline devices through Python. SiLA defines common interfaces for laboratory services. PyLabRobot and HELAO connect robotic workcells and experimental workflows. NIST places these systems within a broader modular laboratory architecture built from replaceable instruments, controllers, data systems, and local agents. On the Need for Autonomous Science Instruments similarly argues for open control and instruments designed for autonomous operation.

These interfaces let an agent send commands. They do not tell it how to turn an unfamiliar instrument into a reliable procedure.

That procedure carries physical assumptions. A liquid handler can execute every command and deliver the wrong volume. A source-measure unit can return a reading after entering compliance. A diffractometer can collect a complete frame after saturation or geometric misalignment. Software success is one observation. The physical result is the one that matters.

Skill Acquisition Through Execution

The agent does not need every procedure written in advance; it can acquire procedural knowledge from interaction and carry it forward. Recent instrument agents show models learning on the job, under supervision, on real instruments.

Chen et al. developed an X-ray alignment workflow against a virtual six-circle diffractometer and later deployed it under supervision at a synchrotron. During the beamline experiment, the agent detected an unexpected motor offset and carried the correction into its next action.

Vriza et al. took a different route. Their agents operated an X-ray nanoprobe and a robotic thin-film platform through restricted function libraries. Human corrections entered persistent memory and became available in later workflows. The agents improved at command selection and action sequencing, although textual feedback did not fix every visual-reasoning failure.

Proprio applies that pattern to scientific instruments. The model reads the documentation, writes the procedure, runs it, and revises from simulator evidence. The object being learned is the skill, not the model weights.

Separating Learning from Admission

Learning a procedure and deciding whether to trust it are different jobs. Proprio separates them. While it works, the agent sees the failed command, the changed state, the expected response, and the failed check. That evidence helps it repair the procedure instead of blindly generating another draft.

Admission runs on a separate path. Each instrument defines a bounded controller, a simulator, and an instrument-specific verification contract. The contract checks observable behavior such as delivered volume, voltage compliance, command ordering, focus quality, or measurement validity. Development conditions supply feedback to the agent; held-out conditions decide whether a candidate enters the catalog. The model cannot change those conditions or their thresholds, rewrite the verifier, or promote a candidate because its explanation reads plausibly. A skill enters the library only when every registered check passes.

This lets the agent search in simulation without grading its own work. A failed candidate stays failed. The verifier decides whether a procedure meets the registered contract. The scientist defines that contract, the hardware boundary, and the experiment the instrument should serve.

A five-stage pipeline, left to right. One, instrument sources such as manuals and documentation. Two, a persistent agent running a draft, execute, observe, and repair loop. Three, an open API and simulator. Four, an independent qualification gate that checks execution, a physical contract, and a locked test. Five, a qualified skill package. Rejected or held candidates return along a dashed feedback path to the agent, and a separate, locked hardware-validation step sits outside the automated loop.

Figure 1. Open interfaces expose instrument actions and observations, while simulators provide a controlled environment for procedural interaction. Proprio preserves the agent's execution experience across a test-time learning trajectory and uses independently implemented execution and physical checks to govern skill admission. A simulation-verified skill still requires separate site-specific validation before use on real hardware.

Method

Inputs and Outputs

ObjectDefinition
Instrument sourcesManuals, API/driver documentation, and operating limits shown to the model.
Controller contractThe permitted commands and observable state; nothing else is callable.
SimulatorExecutable instrument or process behavior, with explicit reset and failure semantics.
Physical contractIndependent, machine-checkable requirements for a valid operation and measurement (for example, delivered volume within 0.10 mL at certified 0.050 mL/rev calibration).
Skill packageSKILL.md operating procedure, bounded control code, provenance hashes, and a link to the verification record, hash-bound in catalog.json.

Table 1. The inputs Proprio consumes and the skill package it produces.

DeepSeek V4 Flash was the drafting and repair model for every reported study; Qwen 3.7 Plus served as a separately prompted independent reviewer. The interface is model-agnostic, and every reported result remains tied to the model, provider, prompts, and sampling settings that produced it. The OpenFlexure release lineage shown in the demo above is a separate, later trajectory driven by GPT-5.6 Luna, reported as a single mechanism demonstration rather than a re-estimate of the population results below.

Operator Workflow

  1. Learn a skill from instrument sources.
  2. Verify it independently in simulation.
  3. Admit the passing skill into the catalog.
  4. Monitor execution evidence for drift.
  5. Stage a verified evolution proposal when drift breaks the admitted skill.

The agent drives discovery, execution, diagnosis, repair, and evolution; it cannot authorize promotion.

Persistent In-Context Learning

Proprio treats simulator interaction as test-time procedural learning rather than model training. The model weights remain fixed, while Proprio preserves one context across each causal-repair or evolution trajectory. Prior actions, simulator responses, failed checks, diagnoses, edits, and outcomes remain available when the agent proposes its next procedure.

The persistent context serves the same role as an operator's notebook. It contains the full message history and a compact repair ledger with the candidate hash, failed checks, cited evidence, diagnosis, change, and outcome for every attempt.

Before repair begins, the method samples an archive of six independent drafts of bounded control code and executes them on visible simulator conditions whose evidence the agent may inspect. Three candidates survive archive selection on execution, physical validity, safety, and provenance. Every repair must cite evidence identifiers that appear in the recorded trace; a patch with fabricated provenance cannot be packaged even if it executes successfully.

Admission Authority

Persistence changes what the agent can learn within a trajectory; it does not change who decides. Simulator and verifier records return to the agent as tool results that may ground a new diagnosis or edit, but promotion still depends on deterministic execution, physical-validity, provenance, and locked-condition checks the agent cannot override. In a paired causal comparison, the truthful and no-feedback arms branch from the same evidence-free prefix and keep separate histories thereafter, so the feedback intervention cannot leak across arms.

Proprio's earlier studies used episodic repair, where each attempt received the current candidate and the latest verifier record but discarded the prior conversation. That gave a clean causal baseline at the cost of re-deriving context on every attempt, and it is the baseline the persistent loop improves on. The pooled causal result reported below is drawn from those episodic studies and is presented as mechanism evidence, while the cross-family panel exercises the persistent loop end to end.

Development happens on visible conditions. Verification ends with a one-shot run on locked conditions that were hidden during development, with no feedback. Deterministic execution and physics checks are authoritative throughout. A model reviewer (or a human) may veto or hold a candidate, but its opinion is advisory input to the decision, never the decision itself. Admission is fail-closed. A candidate is admitted only when every deterministic check passes, and any failure, missing evidence, or unresolved veto resolves to REJECT or HOLD (insufficient evidence to decide), never to a pass. A HOLD is reported as such rather than converted into a pass or silently retried.

Drift and Evolution

When a versioned simulator change makes a previously admitted skill fail, Proprio treats the repair as a new admission problem, not an edit-in-place. The model generates an evolution proposal from the observed drift evidence; the proposal must pass the changed condition, replay the full historical set that previously worked (nominal behavior and prior repairs), and pass a fresh locked sweep. Only a fully passing proposal is staged, with parent, rollback, evidence, simulator, verifier, and validation hashes, and the previously admitted skill remains immutable. A failed proposal is rejected and the parent is retained unchanged.

Simulation verification is a pre-deployment gate, not a deployment decision. Using a skill on a physical instrument still requires hardware adapters, interlocks, reference measurements on the target instrument, recovery tests, supervised trials, and instrument-expert approval. Every skill in the public catalog carries hardware_qualification_required set to true, without exception.

Evaluation

Five questions organize the study.

Instrument Cohorts

Table 2
CohortInstrumentsRole
Reference2D area-detector powder XRD (Bluesky/ophyd.sim execution, pyFAI-based verification)Reference implementation and verifier metrology; not generalization data
DevelopmentKeithley 2450-style SMU (PyVISA-sim); eight diagnostic instruments across liquid handling, battery cycling, additive manufacturing, and quantum transportAdmission proof; method development and mechanism evidence, excluded from the confirmatory claim
ConfirmatorySix instruments in three families held out of method development: absorbance and fluorescence plate reads (optical measurement), pump dose and dual-pump blending (calibrated delivery), isothermal hold and thermal cycling (thermal control)Frozen paired causal study
ReplicationTen fresh generations per confirmatory instrument plus the external OpenFlexure microscopeVariance and breadth under the frozen protocol
External integrationOpenFlexure microscope server (pinned revision d26b93e), run as a separate GPL-3.0 process via its public APIExternally authored simulator; breadth and evolution stress test
Preflight suitability roundOctoPrint virtual 3D printer, PyMoDAQ mock spectrometer, sinstruments pressure controllerPreregistered preflight round that exercised the deterministic fixture-suitability gate (see the cross-family results)
Persistent cross-family panelNorth Robotics pipette calibration (liquid handling), HELAO Gamry cyclic voltammetry (electrochemistry), CLSLab light spectrometer (optical spectroscopy)One binding session per externally authored family under the frozen persistent method, with persistent causal repair and drift evolution; no failing family may be replaced

Table 2. Cohorts and their evidentiary roles. Development evidence never counts toward the confirmatory claim. Both external rounds were preregistered, with families, thresholds, and per-family pass requirements fixed before binding exposure to their simulators.

Causal Design

Each paired unit starts from the same parent draft and model configuration and runs two arms. One receives truthful, structured simulator evidence (execution trace, failed checks, telemetry), the other receives no feedback. Success requires an actual code change, verification on the visible conditions, verification on the locked conditions, and no regression on previously working behavior; a repair meeting all four is called non-regressive. The principal mechanism analysis uses 18 non-overlapping paired units, drawn from the six-instrument confirmatory panel (6 units), the eight-instrument diagnostic panel (8), and the OpenFlexure development trials (4), and applies an exact one-sided McNemar test on the discordant pairs (synthesis artifact). Because these units were collected as the protocol evolved, the pooled result is evidence about the feedback-repair mechanism, not a single fixed-protocol success rate.

Measuring the Verifiers

Every verifier is exercised against labeled valid and invalid batteries, with per-class false-admission and false-rejection rates. Physical quantities are computed independently of the simulator's own internals. The microscopy verifier, for example, never reads the simulator's focus score, and instead checks stage position, frame integrity, and two separately implemented image-sharpness calculations. Fixed-index samples of raw records are inspected by hand and countersigned.

Reproducibility

Sources, simulator revisions, prompts, budgets, provider routes, seeds, and thresholds are frozen and recorded per run, hash-bound before binding exposure, and no failing family may be replaced.

Evidence is tiered. A binding run executes under the frozen method digest and counts toward a preregistered claim. An engineering run is exploratory, used to build and exercise the machinery, and never counts. Diagnostic evidence comes from method development and is likewise excluded from confirmatory claims. The tiers are kept separate throughout this report.

The locked test suite asserts the failed research claims, including the external-family rejection, the reviewer-panel mismatch, and the rejected evolution proposals, so they cannot silently become passes. The evidence manifest binds the release artifacts by hash.

Results

From Documentation to Execution

Most drafts executed and measured correctly on the first attempt. The 70-generation replication study ran ten independent generations per instrument with unique seeds, temperature 0.7, and top-p 0.95.

The six confirmatory instruments passed verification for 60/60 candidates. OpenFlexure shows where that result stops. All 10 drafts executed, while only 4/10 final candidates passed the locked physical sweep against the frozen ≥8/10 threshold. The breadth gate therefore failed. All six candidates that missed verification were rejected, and no microscope skill was admitted. In the separate development cohort, the model also compiled a correct Keithley 2450-style current measurement from driver and fixture documents (admission artifact).

Verified Feedback Drives Repair

Across the 18 paired units, truthful feedback produced 14/18 non-regressive repairs; the identical drafts with no feedback produced 0/18 (exact one-sided paired p = 0.000061). Every cohort improved, with 6/6 on the confirmatory panel (bootstrap 95% uplift interval [1.0, 1.0]), 5/8 on the diagnostic panel, and 3/4 on the OpenFlexure development trials.

Verified feedback turns test-time compute into repairsnon-regressive repairs per cohort

From the same starting drafts and the same search budget. Blind retrying produced no non-regressive repair in any cohort, so the grey series sits at zero across the panel.

Verified simulator feedbackBlind retries
CohortVerified feedbackBlind retries
Confirmatory panel6 / 60 / 6
Diagnostic panel5 / 80 / 8
OpenFlexure development trials3 / 40 / 4

Pooled across cohorts, verified feedback produced 14 of 18 non-regressive repairs and blind retrying produced none. Exact one-sided paired p = 0.000061.

A representative repair appears verbatim in the calibrated-pump-dose cassette. The visible-condition gate failed only speed-support (maximum_rpm: 75.0, observed_rpm: [100.0, 100.0]). The model's logged diagnosis was "Reduced prime and delivery speed from 100 rpm to 75 rpm to match the changed pump's maximum supported speed of 75.0 rpm … Calibration (0.050), target volume (10.0 mL), halt, and return shape preserved." The edited skill then passed the changed condition, the historical nominal scenario, and 50 locked conditions. The no-feedback arm, given the same failing draft and the same budget, did not repair it.

Independent Gates

Self-approval is the failure the admission gate exists to catch, and the Keithley 2450 development study shows it directly. The model drafted two skills from supplied documentation. One came from the current fixture sheet (1 kΩ load, 1 V source, 2 mA compliance, 10 mA range) and one from a plausible stale worksheet (100 kΩ load, 200 µA compliance, 100 µA range). It self-judged both ACCEPT (captured completions). Proprio executed both against a PyVISA-sim instrument and checked the measured current against the 1 kΩ circuit law and the active range/compliance contract. The correct skill passed all nine checks and was admitted; the self-accepted stale skill was rejected on the compliance-contract and range-contract checks (observed ≈0.2 mA against a required minimum ≈1.1 mA). The rejected draft exists only as evidence. It never entered the catalog.

The admitted skill is the operating procedure a scientist would write, versioned so the catalog can bind it by hash:

---
name: keithley-2450-measure-current
description: "Measure current through a 1 kΩ resistor using a Keithley 2450 SourceMeter."
---

# Keithley 2450 Current Measurement

Source 1.000 V across a 1.000 kΩ load and measure the resulting current, with
a current compliance of 2.000 mA and a measurement range of 10.000 mA.

## Workflow

1. Reset the instrument.
2. Set current compliance to 2.000 mA.
3. Set measurement range to 10.000 mA.
4. Set source voltage to 1.000 V.
5. Enable the output.
6. Measure the current.
7. Disable the output.
8. Return the measured current in amperes.

The full package, with its bounded control code and the record that admitted it, is the Keithley skill.

XRD reference verifier

5/5 injected execution-fault classes detected (a dropped frame is labeled degraded); 0/300 false rejections on valid calibrant controls; 0 observed false acceptances across nine invalid classes × 300 cases; an always-valid adversary rejected in 2,700/2,700 cases. One measured weakness is reported. The dedicated sample-displacement check missed direct attribution in 19/300 cases (AUROC 0.943) although adjacent shift/indexing checks still rejected every affected measurement (metrology record).

Confirmatory-family verifiers

9,000 labeled simulations (1,800 valid, 7,200 invalid across wrong order, unsafe setting, wrong physical target, and omitted cleanup) with zero false admissions and zero false rejections; 30 fixed-index raw records hand-inspected and countersigned (summary).

OpenFlexure verifier

2,700 labeled cases over eight invalid classes; zero invalid measurements accepted, one valid measurement in 300 falsely rejected. The two image-sharpness checks (frequency-domain and Laplacian) agreed on 299/300 valid frames; because they share the same exported frame they are not statistically independent, and that residual correlation is reported rather than hidden (summary).

Adversarial composition

A trajectory that executes successfully but contains a saturated detector frame passes procedural verification and fails validity, so execution success cannot substitute for physical validity (composition artifact).

Cross-family verifiers

4,200 labeled simulations across the North, HELAO Gamry, and CLSLab fixtures (900 valid and 3,300 invalid cases over 11 failure classes), with zero false admissions and 3/900 false rejections, all on the North fixture (metrology records).

Provenance gate

A CLSLab engineering session with a staged evolution proposal and a passing locked sweep was reduced to HOLD because part of its transport ran on a provider outside the frozen allowlist (session record). The drafting model could not override the decision.

Model judgment was measured under the same discipline. The drafting model's review prompt, frozen after calibration, scored 100% critical-defect recall with zero false alarms on 24 unseen review cases (12 critical-defect mutations, 6 valid controls, and 6 unavailable-evidence cases). The independent Qwen 3.7 Plus reviewer passed 56/56 calibration cases and 42/42 cases on the six confirmatory instruments, and matched 47/49 pre-fixed labels on the full panel. Fresh replay showed both disagreements were wrong fixture labels that the reviewer had correctly rejected; the panel verdict is preserved as FAIL rather than recalculated (review record). Across every battery, no model, whether drafter or reviewer, overrode a failed deterministic check.

Across Instrument Families

Family (instruments)Draft executesVisible verificationHeld-out verificationCausal repairDrift detectedEvolutionFail-closed admission
Powder XRD (reference)✓ (reference)✓————✓ (saturated-frame case)
Electrical measurement (Keithley SMU)✓✓————✓ (stale draft rejected)
Optical measurement (2)19/2020/2020/202/2——✓
Calibrated delivery (2)19/2020/2020/202/2——✓
Thermal control (2)20/2020/2020/202/2——✓
Liquid handling (2, diagnostic)✓†✓†—2/22/22/2 staged✓
Battery cycling (2, diagnostic)✓†✓†—1/22/22/2 staged✓
Additive manufacturing (2, diagnostic)✓†✓†—0/22/22/2 staged✓
Quantum transport (2, diagnostic)✓†✓†—2/22/22/2 staged✓
Microscopy (OpenFlexure, external)10/106/104/10 (FAIL vs ≥8/10)3/4 (dev. trials)1/10/1 (rejected)✓ (nothing admitted)
3D printing (OctoPrint, held-out)——————✓ (HOLD at preflight)
Spectral measurement (PyMoDAQ, held-out)——————✓ (HOLD at preflight)
Pressure control (sinstruments, held-out)——————✓ (HOLD at preflight)
Liquid handling (North pipette calibration, external)✓✓✓truthful 1/1; no feedback 1/11/11/1 staged✓ (0 invalid promotions)
Electrochemistry (HELAO Gamry CV, external)✓✓✓truthful 1/1; no feedback 0/11/11/1 staged✓ (0 invalid promotions)
Optical spectroscopy (CLSLab light spectrometer, external)✓✓✓truthful 1/1; no feedback 0/11/11/1 staged✓ (0 invalid promotions)

Table 3. Cross-family claim matrix from committed evidence. n/m counts passes over attempts; ✓ marks a capability demonstrated in the linked records, while an em dash marks a capability not exercised. Confirmatory rows report the ten-generation replication; their causal-repair column reports the paired study. † Diagnostic-panel parents passed verification on visible and historical conditions after an initially hidden executor-grammar mismatch was disclosed and fixed (drafting was 1/8 executable before the fix), which is why the panel is diagnostic evidence rather than part of the confirmatory claim (archive); their 50-condition locked sweeps ran on the evolution proposals described below. The three external rows report one binding session per family under the same frozen persistent method (panel summary).

Simulator suitability is checked by a deterministic gate before any model call. An earlier preflight round was preregistered against three externally authored simulators whose pinned revisions could not execute their registered physical and drift contracts. Proprio returned HOLD for all three families and did not swap in easier ones (preflight record).

The persistent cross-family panel replicates the complete simulation ladder on externally authored interfaces, one binding session per family. North Robotics pipette calibration, HELAO Gamry cyclic voltammetry, and the CLSLab light spectrometer each cleared the same deterministic preflight, and each produced an executable skill that passed visible and held-out verification. Starting from a separate self-accepted parent that failed the registered calibration change, truthful simulator evidence produced a verified repair in all three families, while the no-feedback control passed verification in one. Every admitted parent then failed its registered drift condition, and all three persistent evolution trajectories produced proposals that passed the changed condition, historical replay, and held-out verification. No trajectory regressed historical behavior, and no invalid candidate was promoted (panel summary).

Evolution After Drift

After a versioned simulator change broke all eight diagnostic parents, the model inspected the drift evidence and produced evolution proposals for all eight; each passed the changed condition, full historical replay, and 50 locked conditions. Each was staged, with its parent left immutable, its rollback hash recorded, and the skill flagged as requiring hardware qualification before deployment (evolution record). On the OpenFlexure family, the evolution attempt exhausted its turn budget with a candidate that still failed the Laplacian focus threshold and regressed the nominal FFT check; only 6/10 locked drift offsets passed, the independent reviewer rejected it, and the parent skill was left untouched (cassette).

A later, separately versioned GPT-5.6 Luna release completed the full OpenFlexure loop using a bounded persistent context. It is the run shown in the demo above. It began from the instrument source, hit an initial physical rejection, repaired its way to parent admission, detected registered drift, and submitted a plausible same-sign residual correction that the independent gate rejected. The same context used those readbacks to correct an evolving copy. That proposal passed changed 1/1, historical 3/3, and locked 5/5 before the gate returned STAGED; the admitted parent remained immutable (release cassette).

The persistent cross-family panel held to the same discipline. Registered drift invalidated the admitted parent in all three families, and the model entered a persistent evolution trajectory with the drift record, source bundle, current skill, and complete repair ledger in context. North and HELAO each needed two submitted repairs before the verifier admitted a proposal; CLSLab passed on its first. The second proposal kept the physical fix from the first and corrected only what the verifier had flagged. Every final proposal passed the changed condition, replayed the historical conditions without regression, passed held-out verification, and was staged with hardware_qualification_required set to true, leaving the parent skills immutable (North, HELAO, CLSLab).

What the Traces Retain

Because admission is external, the agent's search does not have to be discarded once a skill passes. Every attempt is recorded with the checks that failed, the model's diagnosis, the evidence it cited, the change it made, and the outcome.

On HELAO's cyclic voltammetry, the ledger shows the model finding that lower_v2 = 0.5 * lower_v / frame_min returned a positive value when both operands were negative, so the third potential cycle swept only positive potentials, and correcting the sign. On the CLSLab spectrometer, it found that the detector's overrange limit was read once and cached, so a drifted detector never triggered a gain reduction, and moved the limit query inside the measurement loop. Each step is a diagnosis tied to a specific failed check and a specific edit.

A verified skill is the distilled result of that search, packaged as a versioned artifact whose control code, source bundle, and verifier are bound by hash to the evidence that admitted it.

Discussion

The simulator plays two roles in this method. It gives the agent somewhere to learn, and it gives the verifier controlled conditions under which to test what the agent learned.

Where Proprio Sits

Proprio sits between scientific intent and instrument control. An experiment-selection or judgment policy may decide what evidence to acquire, while Bluesky, SiLA, PyLabRobot, HELAO, or a vendor driver supplies the interface that executes the operation. Proprio verifies the procedural artifact that connects those two layers. It does not select the scientific objective, replace the control framework, or authorize hardware deployment. Its output is a simulation-verified skill package that remains subject to the laboratory's hardware commissioning process.

Verification as the Scaling Axis

No model weights change anywhere in this method. All additional compute is spent at inference time on drafting, executing, diagnosing, repairing, and replaying. The verifier converts those extra samples into verified procedural capability rather than more generated text. In the cross-family panel, truthful feedback reached a first verified repair in six, six, and three model calls across the three families, and the entire panel cost $0.262 in inference. Both totals describe one binding session per family rather than an expected acquisition cost (panel summary). Additional compute paid off when the evidence pointed at a discrete cause and hit diminishing returns when the physical contract could not be satisfied within budget. The practical corollary for laboratories is that faster simulators and richer physical contracts directly increase how much capability can be explored and trusted before an instrument is ever touched.

Instrument standards make capabilities portable, and simulators make their acquisition cheap. Independent verification is what makes a skill admissible, and a hash-bound catalog is what makes it reusable across agents and workflows. The current catalog holds five packages, the XRD reference, the Keithley development skill, and the admitted North, HELAO, and CLSLab skills. Each is bound to its verification record and still requires hardware validation. A laboratory adding an instrument follows the documented recipe by connecting the public API, providing a simulator with explicit reset and failure behavior, writing the physical contract, building the labeled validity battery before asking a model to generate anything, and freezing thresholds in advance.

Limitations

All verification reported here is simulation-only, and simulator-to-reality correspondence is imperfect by construction. Each family's verifier requires instrument-specific engineering. Model generation is stochastic, so acquisition and evolution are demonstrated capabilities with measured variance, not guarantees. The pooled causal analysis spans protocol generations, so it establishes the feedback mechanism rather than a single frozen-protocol rate. Because the persistent panel contains one binding session per family and uses simulators screened before model exposure, it neither estimates stochastic success rates nor constitutes an untouched-family test. Real-hardware validation remains a separate gate, and nothing in this report substitutes for it.

Conclusion

The loop gives an agent a way to learn instrument procedures before touching hardware. The model reads, executes, fails, and repairs; the verifier decides what becomes reusable. That lets the scientist focus less on whether the agent can operate the instrument and more on what experiment to run.

The code, the content-addressed skill catalog, the published skill packages, the OpenFlexure full-loop demo, and the video evidence manifest are linked at the top of this post. To run the loop yourself, the repository's quickstart takes one instrument, North Cytation pipette calibration, from a drafted skill through evidence-guided repair to a locked verification decision. Evidence artifacts cited inline are committed to Dynamical-Systems-Research/proprio and hash-bound in the evidence manifest.

Sources