Model Definitions
Model Definitions
Updated on Jul 7, 2026
Published on May 6, 2026
4 minute(s) read
Building an effective document-processing solution requires understanding how the components involved in model training work together. The Model Definitions table is designed to help manage these components. Model definitions separate configuration from the underlying models, providing a structured way to manage a model’s lifecycle. As training progresses, new model versions are created incrementally using updated training data within the same definition.
Understanding model definitions
A model definition is the configuration layer that represents a specific combination of scope (what the model operates on), task (what the model does), and model type (the model architecture used). Each row in the table acts as the control layer for models used in a specific task and scope and serves as the container that manages all models trained for that configuration. This approach allows you to retrain, evaluate, and deploy new model versions while maintaining a stable reference for the system.
Each row in the model definitions table represents a model definition associated with a specific layout, and each column displays key information about the model’s configuration, training status, deployment state, and version compatibility.
| Column | Description | Notes and examples |
| Scope | The data or objects the model operates on (for example, a layout or set of fields). | For example, ORCA VLMs extract fields from documents, such as invoices. In this case, the scope of ORCA VLMs is field processing. |
| Task | The type of problem the model is trained to solve. | For example, the task that ORCA VLMs are performing is field extraction — the task is to extract data (e.g., fields) from documents, based on the layout configuration. |
| Type | The model family used for this task and scope. | For example, VLM. |
| Compatibility | Compatibility of the most recently live model for this definition. | - Orange indicates the current application version.
- Green indicates one version ahead of the current application version.
- Blue indicates two versions ahead of the current application version.
Learn more about compatibility in our Model Compatibility Logic article. |
| State | Shows whether the model is Live or Inactive. | The state is Live when the model is deployed.
The state is Inactive when the model is not deployed |
| Training status | The status of the current model training. | Training status could be:
- Candidate trained— training completed successfully.
- Candidate imported— model was imported from a different instance.
- Training failed— the model-training process failed. You can view the details by clicking the info button.
- Training in progress— model is currently training.
- Ready to train— model meets all requirements and is ready to be trained. |
| Date deployed | The timestamp of the last deployment for this model definition. | Displays the date and time when the model was last deployed. |
Creating a model definition
This section explains how to create a model definition for ORCA VLM.
Before you start, ensure that:
- An ORCA base model is installed. Follow the process described in Installing ORCA VLMs to install and configure the ORCA base model.
- The layout you select is Semi-structured and contains at least one field. ORCA VLMs cannot extract data from tables.
- The latest version of the layout is locked.
- The layout is not already linked to another ORCA VLM model definition.
Next steps
Because ORCA is delivered as a base model, it provides general-purpose extraction capabilities and is not adapted to your specific document types or business requirements. To optimize extraction performance for your use case, you should:
- Annotate documents specific to your use case.
- Train a model on top of the ORCA base model. Doing so allows ORCA VLM to learn patterns specific to your use case.
Learn how to train a specialized model in Training a Specialized Model.