Naming conventions

Why naming matters

Consistent naming is the single most impactful practice for maintainable LoT systems. These conventions apply to all LoT entities and keep notebooks readable as your project grows.

Like street names in a city. Predictable patterns let anyone find an address without a map — and let AI assistants generate code that matches your project.

Entity names

All LoT entities use PascalCase. Names should be descriptive and purpose-driven.

Entity	Convention	Good Examples	Bad Examples
Actions	PascalCase, verb-first	`ProcessTemperature`, `MonitorPressure`, `SendDailyReport`	`temp_process`, `action1`, `myAction`
Models	PascalCase, noun-based	`SensorReading`, `EquipmentStatus`, `ProductionRecord`	`sensor_model`, `Model1`, `data`
Rules	PascalCase, descriptive scope	`AllowAdminActions`, `ProtectSysTopics`, `RestrictDevicePublish`	`Rule1`, `myRule`, `newRule`
Routes	PascalCase, destination-based	`CloudBridge`, `SensorDatabase`, `AlertEmail`	`route1`, `my_route`, `dbRoute`
Callable Actions	PascalCase, function-like	`CalculateAverage`, `ConvertCelsiusToFahrenheit`	`calc`, `helper`, `util`

Variable names

Variables use snake_case inside double quotes for SET declarations, and curly braces for references.

DEFINE ACTION ProcessSensorData
ON TOPIC "sensors/+/raw" DO
    SET "sensor_id" WITH TOPIC POSITION 2
    SET "raw_value" WITH (GET JSON "value" IN PAYLOAD AS DOUBLE)
    SET "converted_value" WITH ({raw_value} * 1.8 + 32)
    PUBLISH TOPIC "processed/" + {sensor_id} + "/fahrenheit" WITH {converted_value}

Context	Convention	Examples
Declaration (`SET`)	`snake_case` in double quotes	`"sensor_id"`, `"raw_value"`, `"cycle_time"`
Reference	Curly braces	`{sensor_id}`, `{raw_value}`, `{cycle_time}`
Model fields	`snake_case` in double quotes	`"equipment_id"`, `"runtime_hours"`, `"last_update"`
Action inputs	`snake_case` after keyword	`INPUT value AS DOUBLE`, `INPUT threshold AS DOUBLE`

Topic names

Topics use lowercase with forward-slash separators. Multi-word segments use snake_case. Whenever possible, follow a Unified Namespace (UNS) format for topic naming. This enables readability and scalability as systems grow.

Pattern	Example	Use Case
`domain/entity/attribute`	`sensors/temperature/value`	General data
`domain/instance/attribute`	`sensors/temp001/raw`	Instance-specific data
`domain/category/instance`	`alerts/critical/pump03`	Categorized events
Prefixed namespaces	`processed/`, `alerts/`, `config/`, `cache/`, `state/`, `system/`	Functional separation

For hierarchy design, functional namespaces, and domain-specific UNS patterns, see Designing your data layer.

Quick Start

Developing and Managing Coreflux

Coreflux MQTT Broker

LoT Language

Product Updates

Why naming matters

Entity names

Variable names

Topic names

Next Steps

Designing your data layer

Anti-patterns

​Why naming matters

​Entity names

​Variable names

​Topic names

​Next Steps

Designing your data layer

Anti-patterns

Why naming matters

Entity names

Variable names

Topic names

Next Steps