Although models are stored natively inside Wizata, the platform can optionally integrate with an external ML Flow tracking server.

Model Identification Structure

Every model stored in Wizata is uniquely identified using a structured naming scheme.

This structure ensures that models trained across different assets, conditions, or recipes can coexist and be automatically selected for inference.

A model identifier follows the pattern:

<key>.<twin>.<property>@<alias>

Key

The key is the base name of the model, typically describing its purpose or algorithm. This is free text and can be anything.

Examples:

• XgBoost_Anomaly_Detection
• LSTM_Forecast
• RandomForest_QualityModel

Twin

The Twins represents the asset the model is associated with and its identified from the twin hardware_id. This allows Wizata to maintain different models for different machines or pieces of equipment.

Example:

• Oven 1
• plant_Argentina
• motor_1

Property

A property is a variable used inside a Pipeline to contextualize the model. Again platforms can store different train models per property.

Properties often represent:

• Product recipes
• Material types
• Process conditions
• Equipment operating modes

Example:

• MaterialsA
• CementType3
• Recipe_42

Alias

The alias uniquely identifies a specific version of the model. It is automatically generated every time a model is saved, uploaded, or retrained.

Aliases are composed of, but can be renamed to any valid text:

• The date
• A random color
• A random animal
• A unique ID

Example:

251120_green_wolf_355

Example

Here is a complete identifier based on above sample:

XgBoost_Anomaly_Detection.Oven 1.MaterialsA@251120_green_wolf_355

On the platform the model would be shown on the AI Lab > Pipelines > Models then navigating to:

This means:

• Model key: XgBoost_Anomaly_Detection
• Asset (Twin): Oven 1
• Property (Condition): MaterialsA
• Alias (Version): auto-generated unique identifier

Model Storage Format

Models are stored inside Wizata following a generic MLflow-compatible structure.

This means:

• The primary model artifact is stored as a pickle or torch file (if using Python version 3.11 or above)
• Additional model resources (preprocessing, scalers, features) can be attached
• Model versions include metadata and artifacts organized in a predictable format

This structure ensures compatibility with external MLflow systems when needed.

Model Metadata

Each saved model version contains metadata that helps trace training history, context, and reproducibility. Metadata varies depending on whether a model was trained inside or outside Wizata.

Metadata for Models Trained Inside Wizata

Models trained within a Pipeline automatically include:

• Pipeline reference: Link to the Pipeline used to train the model
• Execution logs: Containing training details, steps executed, evaluation metrics
• Evaluation visualizations: Plots generated during training (e.g., scoring curves, error charts)
• Training timestamp: Exact date and time of training
• Dataframe structure: Columns, dtypes, sample shape, and other structural metadata

These allow users to audit, reproduce, and compare training results over time.

Additionnal Artifacts and Files

Regardless of how a model is trained, users may attach extra files to a model version. These files help support the full inference logic or context required by the model.

Examples of common extra artifacts:

• Scalers / Normalizers: (e.g., StandardScaler.pkl)
• Feature definitions: (features.json describing engineered features)
• Referenced datasets: Sample data snapshots used for calibration or testing
• Custom preprocessing scripts or lookup tables

These artifacts become part of the model version and are available at inference time.

---

Summary

Wizata organizes models using a structured storage and naming convention that supports:

• Per-asset and per-condition model granularity
• Clean versioning and automatic version selection
• MLflow-compatible metadata structure
• Complete traceability of training pipelines
• Ability to attach arbitrary supporting artifacts

This storage architecture enables reliable deployment, retraining, and inference across cloud and edge environments.