> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreflux.org/llms.txt
> Use this file to discover all available pages before exploring further.

# MODEL Inheritance

> Create model families with shared fields using the FROM keyword for code reuse and consistency

## Why Use Model Inheritance?

When your system has related data types—different kinds of alerts, equipment, or events—you often repeat the same fields across multiple models. Model inheritance lets you define common fields once in a **base model**, then extend it with specialized fields for each variant.

> [!TIP]
>
> **Like a family tree for data.** A "TemperatureAlert" is a child of "Alert"—it inherits all the standard alert properties (ID, timestamp, severity) but adds its own temperature-specific fields. Change the parent, and all children get the update.

### When to Use Inheritance

| Scenario | Example |
| - | - |
| **Alert systems** | Base alert + temperature, pressure, maintenance alerts |
| **Equipment monitoring** | Base equipment + pumps, conveyors, motors |
| **Event tracking** | Base event + production, quality, safety events |
| **Sensor networks** | Base sensor + temperature, pressure, flow sensors |

***

## Inheritance Syntax

The `FROM` keyword creates a child model that inherits all fields from a parent:

```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
DEFINE MODEL ChildModel FROM ParentModel
    ADD STRING "specialized_field"
    ADD DOUBLE "another_field"
```

The child model automatically includes every field from the parent, plus any additional fields you define.

### How It Works

```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
// Parent model with common fields
DEFINE MODEL BaseAlert COLLAPSED
    ADD STRING "alert_id"
    ADD STRING "timestamp"
    ADD STRING "severity"
    ADD STRING "message"
    ADD BOOL "acknowledged"

// Child model inherits all parent fields + adds specialized ones
DEFINE MODEL TemperatureAlert FROM BaseAlert
    ADD DOUBLE "temperature_value"
    ADD DOUBLE "threshold_exceeded"
    ADD STRING "sensor_location"
```

**Result:** `TemperatureAlert` has 8 fields total:

* 5 inherited from `BaseAlert` (alert\_id, timestamp, severity, message, acknowledged)
* 3 specialized fields (temperature\_value, threshold\_exceeded, sensor\_location)

> [!TIP]
>
> Base models are typically defined with `COLLAPSED` since they're meant to be extended, not used directly. The child models inherit this behavior.

***

## Designing Base Models

A good base model contains fields that **every variant needs**. Put yourself in the position of someone processing alerts, equipment data, or events—what fields do they always expect?

### Base Model Best Practices

```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
DEFINE MODEL BaseEquipment COLLAPSED
    // Identification - always needed
    ADD STRING "equipment_id"
    ADD STRING "equipment_name"
    
    // Context - helps locate and categorize
    ADD STRING "location"
    ADD STRING "status"
    
    // Operational data - common across equipment
    ADD INT "runtime_hours"
    ADD STRING "last_maintenance"
    
    // Metadata - for tracking and auditing
    ADD STRING "operator"
    ADD STRING "timestamp"
```

> [!WARNING]
>
> Don't include type-specific fields in base models. If only some variants need a field, it belongs in the child model.

### What to Include in Base Models

| Field Category | Examples | Why |
| - | - | - |
| **Identifiers** | `id`, `name`, `code` | Every record needs to be identifiable |
| **Timestamps** | `timestamp`, `created_at` | Essential for ordering and debugging |
| **Status** | `status`, `severity`, `state` | Common across most data types |
| **Context** | `location`, `source`, `operator` | Helps downstream processing |
| **Flags** | `acknowledged`, `processed` | Common workflow states |

***

## Creating Specialized Models

Child models add fields specific to their domain. Keep these focused—only add what that particular variant needs.

### Alert Family Example

Starting from a common base, create specialized alert types:

```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
DEFINE MODEL BaseAlert COLLAPSED
    ADD STRING "alert_id"
    ADD STRING "source_system"
    ADD STRING "timestamp"
    ADD STRING "severity"
    ADD STRING "message"
    ADD BOOL "acknowledged"
```

**Temperature Alert**

Temperature alerts add measurement data and thresholds:

```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
DEFINE MODEL TemperatureAlert FROM BaseAlert
    ADD DOUBLE "temperature_value"
    ADD DOUBLE "threshold_exceeded"
    ADD STRING "sensor_location"
    ADD STRING "unit"
```

**Pressure Alert**

Pressure alerts track system-level concerns:

```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
DEFINE MODEL PressureAlert FROM BaseAlert
    ADD DOUBLE "pressure_value"
    ADD DOUBLE "max_safe_pressure"
    ADD STRING "pressure_unit"
    ADD STRING "system_affected"
```

**Maintenance Alert**

Maintenance alerts focus on service schedules:

```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
DEFINE MODEL MaintenanceAlert FROM BaseAlert
    ADD STRING "equipment_id"
    ADD STRING "maintenance_type"
    ADD INT "hours_since_service"
    ADD INT "recommended_interval"
    ADD STRING "priority_level"
```

***

## Publishing Inherited Models

Inherited models work exactly like regular COLLAPSED models—use `PUBLISH MODEL` from an Action and provide values for all fields (inherited + specialized):

```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
DEFINE ACTION GenerateTemperatureAlert
ON TOPIC "sensors/temperature/+/alert" DO
    SET "sensor_id" WITH TOPIC POSITION 3
    
    PUBLISH MODEL TemperatureAlert TO "alerts/temperature/" + {sensor_id} WITH
        // Inherited fields from BaseAlert
        alert_id = (RANDOM UUID)
        source_system = "TemperatureMonitor"
        timestamp = TIMESTAMP "UTC"
        severity = "HIGH"
        message = "Temperature threshold exceeded"
        acknowledged = FALSE
        
        // Specialized fields for TemperatureAlert
        temperature_value = (GET JSON "value" IN PAYLOAD AS DOUBLE)
        threshold_exceeded = (GET JSON "threshold" IN PAYLOAD AS DOUBLE)
        sensor_location = (GET JSON "location" IN PAYLOAD AS STRING)
        unit = "celsius"
```

### Polymorphic Action Pattern

One Action can handle multiple model types by checking the incoming data and publishing the appropriate variant:

```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
DEFINE ACTION PolymorphicAlertGenerator
ON TOPIC "sensors/+/+/alert" DO
    SET "sensor_type" WITH TOPIC POSITION 2
    SET "sensor_id" WITH TOPIC POSITION 3
    
    IF {sensor_type} EQUALS "temperature" THEN
        PUBLISH MODEL TemperatureAlert TO "alerts/temperature/" + {sensor_id} WITH
            alert_id = (RANDOM UUID)
            source_system = "SensorNetwork"
            timestamp = TIMESTAMP "UTC"
            severity = (GET JSON "severity" IN PAYLOAD AS STRING)
            message = "Temperature alert triggered"
            acknowledged = FALSE
            temperature_value = (GET JSON "value" IN PAYLOAD AS DOUBLE)
            threshold_exceeded = (GET JSON "threshold" IN PAYLOAD AS DOUBLE)
            sensor_location = (GET JSON "location" IN PAYLOAD AS STRING)
            unit = "celsius"
    
    ELSE IF {sensor_type} EQUALS "pressure" THEN
        PUBLISH MODEL PressureAlert TO "alerts/pressure/" + {sensor_id} WITH
            alert_id = (RANDOM UUID)
            source_system = "SensorNetwork"
            timestamp = TIMESTAMP "UTC"
            severity = (GET JSON "severity" IN PAYLOAD AS STRING)
            message = "Pressure alert triggered"
            acknowledged = FALSE
            pressure_value = (GET JSON "value" IN PAYLOAD AS DOUBLE)
            max_safe_pressure = (GET JSON "max_pressure" IN PAYLOAD AS DOUBLE)
            pressure_unit = "PSI"
            system_affected = (GET JSON "system" IN PAYLOAD AS STRING)
```

> [!NOTE]
>
> All alert types share the same base structure, so downstream systems can process common fields (like `severity` and `acknowledged`) without knowing the specific alert type.

***

## Complete Examples

**Equipment Hierarchy**

A complete equipment monitoring system with specialized equipment types:

```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
// Base model with common equipment fields
DEFINE MODEL BaseEquipment COLLAPSED
    ADD STRING "equipment_id"
    ADD STRING "equipment_name"
    ADD STRING "location"
    ADD STRING "status"
    ADD INT "runtime_hours"
    ADD STRING "last_maintenance"
    ADD STRING "operator"
    ADD STRING "timestamp"

// Pump-specific model
DEFINE MODEL PumpEquipment FROM BaseEquipment
    ADD DOUBLE "flow_rate"
    ADD DOUBLE "pressure_output"
    ADD INT "rpm"
    ADD DOUBLE "power_consumption"
    ADD STRING "pump_type"

// Conveyor-specific model
DEFINE MODEL ConveyorEquipment FROM BaseEquipment
    ADD DOUBLE "belt_speed"
    ADD INT "items_per_minute"
    ADD DOUBLE "belt_tension"
    ADD BOOL "emergency_stop_active"
    ADD STRING "direction"
```

**Action to publish equipment reports:**

```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
DEFINE ACTION EquipmentReporter
ON TOPIC "equipment/+/+/status_update" DO
    SET "equipment_type" WITH TOPIC POSITION 2
    SET "equipment_id" WITH TOPIC POSITION 3
    
    IF {equipment_type} EQUALS "pump" THEN
        PUBLISH MODEL PumpEquipment TO "equipment/reports/pump/" + {equipment_id} WITH
            equipment_id = {equipment_id}
            equipment_name = (GET JSON "name" IN PAYLOAD AS STRING)
            location = (GET JSON "location" IN PAYLOAD AS STRING)
            status = (GET JSON "status" IN PAYLOAD AS STRING)
            runtime_hours = (GET JSON "runtime" IN PAYLOAD AS INT)
            last_maintenance = (GET JSON "last_service" IN PAYLOAD AS STRING)
            operator = (GET JSON "operator" IN PAYLOAD AS STRING)
            timestamp = TIMESTAMP "UTC"
            flow_rate = (GET JSON "flow_rate" IN PAYLOAD AS DOUBLE)
            pressure_output = (GET JSON "pressure" IN PAYLOAD AS DOUBLE)
            rpm = (GET JSON "rpm" IN PAYLOAD AS INT)
            power_consumption = (GET JSON "power" IN PAYLOAD AS DOUBLE)
            pump_type = "Centrifugal"
    
    ELSE IF {equipment_type} EQUALS "conveyor" THEN
        PUBLISH MODEL ConveyorEquipment TO "equipment/reports/conveyor/" + {equipment_id} WITH
            equipment_id = {equipment_id}
            equipment_name = (GET JSON "name" IN PAYLOAD AS STRING)
            location = (GET JSON "location" IN PAYLOAD AS STRING)
            status = (GET JSON "status" IN PAYLOAD AS STRING)
            runtime_hours = (GET JSON "runtime" IN PAYLOAD AS INT)
            last_maintenance = (GET JSON "last_service" IN PAYLOAD AS STRING)
            operator = (GET JSON "operator" IN PAYLOAD AS STRING)
            timestamp = TIMESTAMP "UTC"
            belt_speed = (GET JSON "speed" IN PAYLOAD AS DOUBLE)
            items_per_minute = (GET JSON "throughput" IN PAYLOAD AS INT)
            belt_tension = (GET JSON "tension" IN PAYLOAD AS DOUBLE)
            emergency_stop_active = (GET JSON "estop" IN PAYLOAD AS BOOL)
            direction = (GET JSON "direction" IN PAYLOAD AS STRING)
```

**Event Tracking**

An event system for production, maintenance, and quality events:

```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
// Base event structure
DEFINE MODEL BaseEvent COLLAPSED
    ADD STRING "event_id"
    ADD STRING "event_category"
    ADD STRING "source"
    ADD STRING "timestamp"
    ADD STRING "severity"
    ADD STRING "description"

// Production-specific events
DEFINE MODEL ProductionEvent FROM BaseEvent
    ADD STRING "line_id"
    ADD STRING "batch_id"
    ADD INT "parts_affected"
    ADD STRING "operator"
    ADD DOUBLE "production_impact"

// Quality-specific events
DEFINE MODEL QualityEvent FROM BaseEvent
    ADD STRING "inspection_station"
    ADD STRING "product_batch"
    ADD INT "items_tested"
    ADD INT "items_failed"
    ADD STRING "failure_reason"

// Maintenance-specific events
DEFINE MODEL MaintenanceEvent FROM BaseEvent
    ADD STRING "equipment_id"
    ADD STRING "maintenance_type"
    ADD INT "downtime_minutes"
    ADD STRING "technician"
    ADD DOUBLE "cost_estimate"
```

**Sensor Network**

A sensor hierarchy for different measurement types:

```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
// Base sensor structure
DEFINE MODEL BaseSensor COLLAPSED
    ADD STRING "sensor_id"
    ADD STRING "sensor_name"
    ADD STRING "location"
    ADD STRING "status"
    ADD STRING "last_calibration"
    ADD BOOL "calibration_valid"
    ADD STRING "timestamp"
    ADD INT "reading_count"

// Temperature sensor
DEFINE MODEL TemperatureSensor FROM BaseSensor
    ADD DOUBLE "temperature"
    ADD STRING "temperature_unit"
    ADD DOUBLE "min_range"
    ADD DOUBLE "max_range"
    ADD DOUBLE "accuracy"

// Pressure sensor
DEFINE MODEL PressureSensor FROM BaseSensor
    ADD DOUBLE "pressure"
    ADD STRING "pressure_unit"
    ADD DOUBLE "max_working_pressure"
    ADD STRING "connection_type"
    ADD BOOL "overpressure_protection"

// Flow sensor
DEFINE MODEL FlowSensor FROM BaseSensor
    ADD DOUBLE "flow_rate"
    ADD STRING "flow_unit"
    ADD DOUBLE "pipe_diameter"
    ADD STRING "fluid_type"
    ADD DOUBLE "viscosity"
```

***

## Best Practices

> **Keep Base Models Focused**
>
> Only include fields that **every** child model needs. If only some variants use a field, it belongs in the child model, not the base.
>
> ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
> // Good - base has universal fields only
> DEFINE MODEL BaseAlert COLLAPSED
>     ADD STRING "alert_id"
>     ADD STRING "timestamp"
>     ADD STRING "severity"
>
> // Bad - 'temperature_unit' doesn't apply to all alerts
> DEFINE MODEL BaseAlert COLLAPSED
>     ADD STRING "alert_id"
>     ADD STRING "timestamp"
>     ADD STRING "severity"
>     ADD STRING "temperature_unit"  // Too specific!
> ```

> **Use Descriptive Model Names**
>
> Name child models to clearly indicate their specialization:
>
> ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
> // Good - clear inheritance relationship
> DEFINE MODEL TemperatureAlert FROM BaseAlert
> DEFINE MODEL PressureAlert FROM BaseAlert
>
> // Bad - unclear relationship
> DEFINE MODEL TempData FROM BaseAlert
> DEFINE MODEL PressData FROM BaseAlert
> ```

> **Document the Hierarchy**
>
> When you have multiple inheritance levels, keep the structure clear:
>
> ```
> BaseEntity
> └── BaseEquipment
>     ├── PumpEquipment
>     ├── ConveyorEquipment
>     └── MotorEquipment
> ```

> **Provide All Fields When Publishing**
>
> When using `PUBLISH MODEL`, you must provide values for both inherited and specialized fields:
>
> ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}}
> PUBLISH MODEL TemperatureAlert TO "alerts/temp" WITH
>     // Don't forget inherited fields!
>     alert_id = (RANDOM UUID)
>     timestamp = TIMESTAMP "UTC"
>     severity = "HIGH"
>
>     // Plus specialized fields
>     temperature_value = 85.5
>     threshold_exceeded = 80.0
> ```

***

## Limitations

> [!WARNING]
>
> **Current limitations of model inheritance:**
>
> * **Single inheritance only** — A model can only inherit from one parent (no multiple inheritance)
> * **No field override** — Child models cannot redefine fields from the parent with different types
> * **COLLAPSED required** — Base models should use `COLLAPSED` since they're templates, not triggered models

***

## Next Steps

> **[Publishing Models](./publish-model)**
>
> Master the PUBLISH MODEL syntax for dynamic data creation.

> **[Model Examples](./examples)**
>
> See more inheritance examples in context.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.