Train in your browser. Export ONNX.

Why ONNX-oriented export packages matter

Many machine learning experiments never leave the tool where they were trained. A notebook model may depend on local code, and a cloud AutoML model may sit behind a hosted endpoint. ONNX helps by representing models in a standard graph format that can be loaded by supported ONNX Runtime environments.

For CSV modeling, export matters because teams often need a testable artifact. They may want to compare behavior in Python, try a browser inference check, review the input schema, or hand a package to an engineer for validation testing. MLdeck positions ONNX-oriented export packages as artifacts for external validation and testing, not as a shortcut around review. This keeps the conversation grounded in inspectable files rather than screenshots of scores.

MLdeck's browser-to-ONNX workflow

The workflow begins with a CSV in the browser. Users profile data, select a target, review feature inclusion, train candidate models, and inspect evidence. When a trained model is selected, MLdeck can prepare an ONNX-oriented export package designed for supported ONNX Runtime testing. During normal browser training flows, raw CSV data is not uploaded to MLdeck servers.

MLdeck's key technical differentiator is that it can generate ONNX-oriented export packages directly from browser-local training workflows, allowing users to test and validate portable model artifacts without uploading raw CSV data during normal browser training flows. This path is useful for teams that want a lightweight loop: explore locally, export an artifact, test it externally, and decide whether deeper validation or custom engineering is needed.

What gets included in the export package

Depending on the model and export path, MLdeck can include the ONNX graph, feature schema, preprocessing metadata, encoding schema, manifest information, sample inputs, and related validation context. The goal is to make the input contract visible. A useful export should explain feature order, categorical assumptions, task type, target, and the preprocessing scope that shaped the model.

Loading an exported model for a first external check takes a few lines with the standard onnxruntime package:

import onnxruntime as ort

session = ort.InferenceSession("model.onnx")
# Match feature names, order, and types to the schema in the package
outputs = session.run(None, {"input": sample_rows})
print(outputs[0])

Users should read the export package rather than treating it as a sealed binary. The schema and metadata are part of the evidence. They help identify whether a downstream service is sending the right columns, handling missing values appropriately, and using representative test rows. The broader AutoML export artifacts guide explains reports, manifest-driven package context, and user-side verification responsibilities.

This is especially important for CSV models because the model is rarely just an estimator. The surrounding contract includes imputation choices, category handling, clipping bounds, scaling assumptions, feature order, and target configuration. ONNX-oriented export packages should make those assumptions easier to test.

Why parity validation matters

ONNX is designed for portability, but portability still needs testing. Runtime versions, unsupported operators, numeric precision, preprocessing differences, and input encoding mistakes can all change behavior. A model that looks good in the training workflow should be tested against representative rows in the target environment.

Parity validation compares expected training-side behavior with exported-runtime behavior. It should include ordinary rows, missing values, categorical edge cases, rare values, and rows near decision boundaries. MLdeck's export artifacts are intended to support that process. They do not remove the need for it.

MLdeck records export metadata and parity status so reviewers can see model quality and export fidelity together. For important decisions, document parity checks alongside evaluation metrics. Exported artifacts should be verified in your target runtime before external use.

Where ONNX artifacts can be tested

ONNX artifacts can be tested in supported ONNX Runtime environments such as Python, browser runtimes, service containers, and other language bindings. The right target depends on the product architecture. A data scientist may start with Python checks, a web team may test browser inference, and an application team may use a Docker package to validate an API path.

Before relying on exported artifacts, teams should check schema validation, prediction stability, latency, error handling, monitoring, and the path for updating models. For high-impact decisions, use strict validation and governance review before relying on results.

A useful test plan includes both normal examples and uncomfortable examples. Try rows with missing values, unseen categories, boundary numeric values, and values that resemble future data rather than the easiest training rows. If the ONNX runtime behavior differs from training-side expectations, pause and investigate before integrating the artifact into another system.

Browser ONNX export FAQ