AutoML export artifacts

What export artifacts can include

Export artifacts can include a readable report, feature schema notes, manifest metadata, package files, sample input context, and ONNX-oriented model artifacts where supported by the workflow. The exact contents depend on the trained model and export path.

The important point is that an export is not just a score. Useful artifacts help reviewers understand the target, feature order, preprocessing assumptions, warnings, validation context, and what should be tested in another environment.

Manifest-driven package concept

A manifest-driven package uses public-safe metadata to describe what was produced. It can identify package contents, task type, feature schema, export status, and verification context without exposing private implementation details. This makes the package easier to inspect and less dependent on screenshots or memory.

Manifest context is especially important for CSV workflows because the model contract includes feature order, missing-value handling, categorical assumptions, and target configuration. Reviewers should read the package metadata before testing predictions.

ONNX-oriented packages need external testing

ONNX is useful because it is designed for portable model representation in supported runtimes. Portability still needs testing. Runtime versions, preprocessing mismatches, unsupported operators, numeric precision, and schema mistakes can all change behavior.

MLdeck positions ONNX-oriented export packages as artifacts for external validation and testing. They should be checked with representative rows, missing values, rare categories, boundary values, and the target runtime environment before any important use.

Reports, reproducibility metadata, and boundaries

Reports can document metrics, warnings, assumptions, and review notes. Reproducibility metadata can help reviewers understand the run context at a public-safe level, such as schema, task, artifact status, and package contents. These materials support review; they do not certify performance, compliance, or readiness for every external environment.

If source data is sensitive, treat generated reports, manifests, model files, and packages as sensitive derived artifacts. Share them only with the same care used for other analytics outputs.

Portable artifacts with documented boundaries

MLdeck's supported export artifacts are files you download — reports, schema and preprocessing metadata, manifests, and, where a workflow supports it, ONNX-oriented model packages. Schema and preprocessing metadata are included to improve inspectability, so a reviewer can read the feature order, preprocessing assumptions, and task configuration rather than guess at them.

Supported ONNX artifacts use an open graph format designed for portable model representation, and they can be tested in compatible external runtimes such as ONNX Runtime. That portability is real but bounded — it is not a promise of universal compatibility, and it is not evidence that a model is ready to deploy.

• Downloadable by you. Supported artifacts are yours to download and keep; using them elsewhere does not require an MLdeck account or API.
• Inspectable. Schemas and preprocessing metadata travel with the export to make the model contract reviewable.
• Open format where supported. ONNX-oriented packages use an open graph format and can be tested in compatible runtimes.
• Not parity evidence. Export availability is not proof of numeric parity, and it is not deployment readiness.
• No universal-compatibility guarantee. MLdeck does not guarantee that every artifact behaves identically in every runtime or version.
• Validation stays with you. Deployment validation — schema, preprocessing, runtime versions, edge cases, and target-environment behavior — remains the user's responsibility.
• Some combinations are limited. Certain estimators or preprocessing combinations may have unavailable or approximate export states; the export surfaces that status rather than hiding it.

Because these boundaries are documented rather than absolute, this page avoids an unqualified "no vendor lock-in" promise: the artifacts are portable and open where supported, and the remaining compatibility and validation work is described plainly instead of assumed away.

Export artifacts FAQ