Routine Instance

Author: Drew Shea, Created: 2026-02-18

A Routine Instance is a user-created object derived from a Routine that serves as the execution context for data science operations. Think of it as bringing a template to life - while a Routine defines what can be done, a Routine Instance is where it happens.

---

Overview

Each time you want to execute data science operations using Routines provided by the SensibleAI Studio, you work with a Routine Instance. The instance:

• Holds configuration specific to your use cases
• Manages state for stateful Routines
• Tracks history of all runs executed against it
• Provides isolation so different users or processes don’t interfere

---

Key Concepts

Routine vs. Routine Instance

Aspect	Routine	Routine Instance
What it is	A template/blueprint defining capabilities	A live, usable object you interact with
Quantity	One (of each version)	Many instances per Routine Type
State	Defines what state can exist	Actually holds the state
Runs	Defines what methods can be called	Tracks all runs that have been executed

---

Instance Lifecycle

A Routine Instance follows a predictable lifecycle:

---

Instance Properties

Every Routine Instance contains the following metadata:

Core Identification

• Instance ID: A unique, system-generated identifier
• Name: A human-readable name you can provide
• Description: Optional text describing the instance’s purpose
• Routine Type: the name of the Routine this instance was created from
• Version: The semantic version of the Routine (e.g., 1.0.0)

Ownership and Tracking

• Created By: The user who created the Routine Instance
• Modified By: The user who last modified the Routine Instance
• Creation Time: When the instance was created
• Modified Time: When the instance was last updated
• Solution Name: The application or solution this instance can be attributed to

Organization

• Labels: Tags for filtering and organizing Routine Instances (e.g., “Production”, “Sales-Team”)

Resource Management

• Memory Override: Custom memory allocation (in GB) for runs on this instance

Extra

• Attributes: Key-value pairs for custom metadata

---

Stateful v Stateless Routine Instances

Routine Instances behave differently depending on whether their Routine Type is stateful or stateless. Differences are covered in depth in Stateful v Stateless Routines.

In short:

• Stateful Routine Instances maintain internal data that persists across runs.
• Stateful Routine Instances require a Constructor run (__init__ method) before other methods can be executed.
• Stateless Routine Instances don’t maintain internal state between runs.

---

Common Operations

Creating a Routine Instance

When creating a Routine Instance, the following is provided:

• Routine Type: Which Routine to instantiate
• Input Parameters (for Stateful Routines): The parameters for the constructor
• Name (Optional): A human-readable name for the instance
• Description (Optional): What this instance is for
• Memory Override (Optional): Custom memory allocation
• Labels (Optional): Tags for organization
• Attributes (Optional, programmatically only): Custom key-value metadata

Updating an Instance

You can modify certain properties after creation:

• Name: Rename the instance
• Description: Update the description
• Memory Override: Adjust resource allocation

Note: the Routine Type and Version cannot be changed after creation. To use a different Routine Version, create a new instance.

Deleting an Instance

When you delete a Routine Instance:

• All associated Runs are removed
• All Artifacts produced by those Runs are deleted
• The instance state (for stateful routines) is purged
• Cleanup hooks execute any routine-specific cleanup logic (if applicable)

Deleting a Routine Instance is permanent and cannot be undone

---

Best Practices

Naming Conventions

Use descriptive, consistent names that indicate the purpose of the Routine Instance, such as the dataset or domain it operates on.

Use Labels Effectively

Labels help organize and filter Routine Instances. Common labeling strategies:

• Environment or experimentation stage: production, staging, development
• Team: sales-team, finance
• Purpose: anomaly-detection, reporting
• Time Period: q4-2025, monthly

Memory Optimization

• Start with the Routine’s default memory allocation
• Only increase if Runs fail due to memory constraints
• Consider breaking large operations into smaller runs