Basalostat Runtime · In development

Field conditions change. Learning needs control.

We’re developing on-device adaptation for perception models in field robotics. The goal: learn from local conditions, test whether an adjustment helps, and return useful learning to your team — while keeping the original model intact.

Research prototype. The original model stays unchanged and the separate candidate does not control the robot. Effects on shared CPU, memory and latency still need to be measured.

The development approachRuntime
Field experienceA new site, season or visual condition
Reference modelOriginal parameters kept unchanged
Candidate adapterEvaluated separately · does not control the robot
Independent evaluationDid it help? Did anything regress?
Evidence for your teamReview the candidate, retain useful data, or reject

Intended workflow. Validation and field-learning export are under development.

For teams that own their perception models
Incubated bySprinT-CT
The problem we’re working on

The model shipped. The environment didn’t stand still.

New fields, lighting and seasons can expose gaps in a trained perception model. For teams building agricultural and outdoor robots, learning from those failures means deciding what data matters — and what can safely change.

01

Learn locally

Explore bounded adapter updates from field experience, with the customer’s original model kept frozen.

02

Verify the benefit

Compare candidates on independent data and check reference performance before considering any deployment.

03

Feed the learning loop

Aim to return traceable candidates and useful field-data records to your existing model-development process.

How Runtime is being developed

Adapt. Evaluate. Then decide.

The first evaluation path is shadow learning: candidate adjustments are isolated from production. Your team remains responsible for deciding what is useful and what to deploy.

01

Start from your model

Scope one supported vision task and a recorded field episode. Keep the original model’s parameters unchanged as a reference.

02

Create a candidate

Adjust a separate adapter: a small set of trainable parameters attached to the model. Record the data, configuration and model used to create it.

03

Test on unseen data

Measure local benefit and reference regression. A lower training loss alone is not evidence of improvement.

04

Return an outcome

Provide evidence for review, useful data, or a clear rejection. Feed the existing training workflow.

This is the intended evaluation workflow, not a claim of automatic production adaptation or guaranteed recovery.

Where we are today

A focused research prototype.

For one selected vision setup on CPU, we have checked that the original model and candidate can run through separate prediction paths. We have also checked that the candidate adapter’s saved parameters can be restored to a previous state.

End-to-end learning, independent candidate validation and the field-learning package remain in development. Adaptation benefit, broad model compatibility and target-device performance have not yet been established.

Before we talk

A few useful distinctions.

Scope the model, the data and the question before an evaluation.

Who is Runtime for?

Robotics and autonomy teams that own their perception models and training workflow. Our initial focus is agricultural and outdoor robotics, where environments vary across sites and seasons.

Will it change the model controlling my robot?

The initial evaluation approach preserves the original model’s parameters and evaluates a separate candidate that does not control the robot. This separation does not establish zero impact on shared CPU, memory or latency; those effects still need measurement. Your team decides what to deploy. Automatic production activation is outside the current prototype.

Which models and hardware are supported?

Compatibility must be assessed per model and adaptation point. Current verification covers a selected static CPU vision configuration using ONNX Runtime. General architecture support, target-hardware costs and integration requirements are still being evaluated.

Does this replace our central training pipeline?

The goal is to complement it: learn from field experience, evaluate candidate changes, and return useful data or candidate artifacts with supporting evidence. Data access, retention and export would be agreed for each evaluation.

What changes when your robots meet the field?

Tell us about one model, one environment and the problem your team is investigating.

Discuss your use case