Work around the products
Four areas of engagement, each built on a product in the portfolio. Each paragraph describes what the product's repository shows today; the status ledger says how far each product has got.
- Vision system engineering
-
Inspection programs built on VisionAI. The work starts from the quality question and ends with a program the line runs: a job that takes its image from a camera or an uploaded file, the vision tasks the job runs on it — find circle, find line, find angle, find distance, code and character reading, anomaly, classification — the region of the image each task reads, and the pass-or-fail logic over the measurements the tasks return. A run shows the verdict, the per-task results and the overlay that marks where each measurement was taken, and a finished program exports and imports as a unit, so what was tuned in the editor is what the operator triggers. VisionAI’s deep-learning tools are deterministic stubs today, so an engagement that needs a trained model is scoped together with the model lifecycle work below.
- Model lifecycle
-
Training, evaluation and ONNX export on VisionML, ending in a manifest that records what was made: the artifact’s sha256, the preprocessing recipe a consumer has to reproduce, the decision thresholds, the provenance — dataset hash, seeds, framework versions — parity evidence between the training framework and the ONNX runtime, and the pinned runtime contract. Dataset layouts are validated before a run, and duplicate images across train and test are flagged. Registration is the gate: configured acceptance criteria are compared with the measured metrics, a criterion that was not measured fails closed, a model registers only with passing parity evidence unless a waiver is recorded in its manifest, and every registration is appended to an audit log.
- Edge and fleet deployment
-
Putting inspection software on plant hardware and knowing what each device is running. On the image side, VisionEdgeOS: a product-image family on a supported upstream Linux rather than a distribution of its own, with versioned hardware profiles that carry an explicit lifecycle — experimental, supported, qualified, retired — where a profile counts as qualified only after tests on its physical hardware, and virtual-machine or CI results count as development evidence only. On the operations side, VisionFleet: where each commissioned device is assigned, its health and open incidents, the exact operating-system, application, runtime, model, manifest, firmware and driver versions and digests it reports, and the drift between what was intended and what is observed as a rollout progresses. Both repositories state their own status — design and scaffolding, and a development-only increment — and the status ledger on this site quotes them. Work in this area is profile, image and verification-harness work scoped against that status, not a production rollout.
- Laboratory evidence software and validation support
-
Bench capture and assisted counting with Digital Labs, with human review as the boundary. A capture records the task, the sample, the model package that would run and where it would run, and every outcome — including an abstain, a capture-gate failure and the case where no approved model exists. A counting run proposes editable per-object detections and refuses to give a number outside the method’s countable window, and a person accepts, corrects or rejects each result before a session can pass completeness review; the accepted or corrected value is what the step records. The product is designed to leave the laboratory’s own systems in charge: a session becomes a versioned evidence package handed to the system that owns the record, with a receipt from it. Where a deployment is regulated, the engagement extends to what the product’s own architecture says a validated profile needs beyond the software — intended use, risk assessment, validation plan and evidence, configuration control, procedures and training — prepared with the people who own the process. The software is not a validated record system and makes no compliance claim.
No engagement described here implies a customer, a price, an availability date, or a compliance status. What a specific deployment would need is decided with the people who own the process.
If one of these is close to what you need, describe the problem and we will say what it would take.
No form, no tracker. Mail goes straight to the person who built these products.