> ## 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. # RULE Syntax > Complete reference for LoT rule syntax, conditions, operation scopes, and access control patterns ## Write Your Broker's Access Policy Every broker operation—creating users, deploying Actions, publishing to topics—passes through Rules before it executes. This page is the complete syntax reference for writing those rules: the conditions you can check, the scopes you can target, and the patterns that tie them together. **Like writing house rules on a whiteboard.** Each rule says "IF you are on the approved list, THEN you may enter the room—ELSE the door stays locked." LoT rule syntax works the same way: you name the rule, pick the door (scope), and write the condition. ### When You Need This Reference | Scenario | You'll use | | - | - | | Restricting who can create or delete users | User Management scopes | | Controlling who deploys Actions, Models, or Routes | Entity Management scopes | | Locking down MQTT topic access per user or role | Publish / Subscribe scopes with `TO TOPIC` | | Protecting `$SYS` command topics | System topic scopes | | Building role-based access across departments | Permission tags with `USER HAS` | **Deploying rules:** In a [LoT Notebook](/v2.0/quick-start/vscode), just write the rule and run the cell—the extension handles the rest. For MQTT clients, use the `-addRule` [broker command](/v2.0/mqtt-broker/commands#rules). *** ## On This Page * [Rule Structure](#rule-structure) — the anatomy of every rule definition * [Conditions](#conditions) — user identity checks, permission checks, and combining logic * [Operation Scopes](#operation-scopes) — every scope category (user, entity, asset, system, log) * [Topic Access Rules](#topic-access-rules) — controlling Publish/Subscribe on standard and `$SYS` topics * [Permission Tags](#permission-tags) — standard tags and how to use them * [Priority and Evaluation](#priority-and-evaluation) — how the broker picks which rule wins * [Complete Examples](#complete-examples) — production-ready rule sets for common scenarios *** ## Rule Structure Every rule follows this structure: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} DEFINE RULE WITH PRIORITY FOR [TO TOPIC ""] IF THEN ALLOW ELSE DENY ``` | Component | Description | | - | - | | `RuleName` | Unique identifier for the rule | | `PRIORITY` | Evaluation order (lower numbers = higher priority) | | `Scope` | The operation type this rule controls | | `TO TOPIC` | Optional topic pattern for Publish/Subscribe rules | | `condition` | Logic that determines access (user checks, permissions) | *** ## Conditions Rules evaluate conditions to decide whether to ALLOW or DENY an operation. ### User Identity Checks Check if the current user matches a specific username: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} USER IS "root" USER IS "admin" ``` ### Permission Checks Check if the user has a specific permission tag: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} USER HAS AllowedUserManagement USER HAS AllowedSystemConfiguration USER HAS AllowedAssetManipulation ``` ### Combining Conditions Use `OR` and `AND` to create complex conditions: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} IF USER HAS AllowedUserManagement OR USER IS "root" THEN ALLOW IF USER HAS AllowedSystemConfiguration AND USER IS "admin" THEN ALLOW ``` *** ## Operation Scopes Rules control different categories of operations. Each scope targets specific broker functionality. ### User Management Control who can manage broker users: | Scope | Controls | | - | - | | `UserManagementCreation` | Creating new users | | `UserManagementRemove` | Deleting users | | `UserManagementUpdate` | Modifying user parameters | | `UserManagementPasswordChange` | Changing user passwords | This example allows users with the `AllowedUserManagement` permission or the `root` user to create new accounts: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} DEFINE RULE AllowUserCreation WITH PRIORITY 1 FOR UserManagementCreation IF USER HAS AllowedUserManagement OR USER IS "root" THEN ALLOW ELSE DENY ``` ### Entity Management Control who can create and manage LoT entities: | Scope | Controls | | - | - | | `ActionManagementCreation` | Creating Actions | | `ActionManagementRemove` | Deleting Actions | | `ActionManagementRun` | Manually running Actions | | `ModelManagementCreation` | Creating Models | | `ModelManagementRemove` | Deleting Models | | `RouteManagementCreation` | Creating Routes | | `RouteManagementRemove` | Deleting Routes | | `RuleManagementCreation` | Creating Rules | | `RuleManagementRemove` | Deleting Rules | This example restricts Action creation to administrators and the root user: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} DEFINE RULE AllowActionAdd WITH PRIORITY 1 FOR ActionManagementCreation IF USER HAS AllowedSystemConfiguration OR USER IS "root" OR USER IS "admin" THEN ALLOW ELSE DENY ``` ### Asset Management Control who can manage installed assets (plugins, extensions): | Scope | Controls | | - | - | | `AssetManagementCreation` | Installing assets | | `AssetManagementRemove` | Uninstalling assets | | `AssetManagementStart` | Starting assets | | `AssetManagementStop` | Stopping assets | | `AssetManagementPolicySet` | Setting asset policies | This example allows asset installation only for users with the appropriate permission: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} DEFINE RULE AllowAssetInstall WITH PRIORITY 1 FOR AssetManagementCreation IF USER HAS AllowedAssetManipulation OR USER IS "root" THEN ALLOW ELSE DENY ``` ### System Operations Control access to system-level operations: | Scope | Controls | | - | - | | `SystemConfiguration` | Changing broker configuration | | `ShellCommand` | Executing shell commands | | `CommandCall` | Calling broker commands | This example restricts configuration changes to authorized administrators: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} DEFINE RULE AllowConfigurationChange WITH PRIORITY 1 FOR SystemConfiguration IF USER HAS AllowedSystemConfiguration OR USER IS "root" THEN ALLOW ELSE DENY ``` ### Log Management Control who can manage log traces: | Scope | Controls | | - | - | | `LogManagementCreation` | Creating log traces | | `LogManagementRemove` | Deleting log traces | | `LogManagementUpdate` | Modifying log traces | This example allows log trace management for users with logging permissions: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} DEFINE RULE AllowLogTraceCreation WITH PRIORITY 1 FOR LogManagementCreation IF USER HAS AllowedLogManagement OR USER IS "root" THEN ALLOW ELSE DENY ``` *** ## Topic Access Rules Control who can publish to or subscribe from specific MQTT topics. ### Standard Topics Use `Publish` and `Subscribe` with `TO TOPIC` to control access: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} DEFINE RULE AllowPublishTopic WITH PRIORITY 1 FOR Publish TO TOPIC "#" ALLOW DEFINE RULE AllowSubscribeTopic WITH PRIORITY 1 FOR Subscribe TO TOPIC "#" ALLOW ``` ### System Topics (\$SYS) Use `PublishSys` and `SubscribeSys` for system topic access: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} DEFINE RULE AllowSubscribeSysClient WITH PRIORITY 1 FOR SubscribeSys TO TOPIC "$SYS/#" IF USER IS "root" THEN ALLOW ELSE DENY DEFINE RULE AllowPublishSysCommand WITH PRIORITY 1 FOR PublishSys TO TOPIC "$SYS/Coreflux/Command" IF USER HAS AllowedAssetManipulation OR USER HAS AllowedSystemConfiguration THEN ALLOW ELSE DENY ``` System topics (`$SYS/#`) contain sensitive broker information and command interfaces. Restrict access to administrative users only. *** ## Permission Tags Permission tags are assigned to users and checked with `USER HAS`. These are the standard permission tags: | Permission Tag | Grants Access To | | - | - | | `AllowedUserManagement` | User creation, removal, updates | | `AllowedSystemConfiguration` | System config, rules, shell commands | | `AllowedAssetManipulation` | Asset install, start, stop, policies | | `AllowedLogManagement` | Log trace creation, removal, updates | | `AllowedModelManagement` | Model creation and removal | You can define custom permission tags for your organization. Assign them to users through the broker's user management system. *** ## Priority and Evaluation Rules are evaluated in priority order (lower number = higher priority). The first matching rule determines the outcome. ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} // This rule is evaluated first (priority 1) DEFINE RULE DenyGuestUsers WITH PRIORITY 1 FOR ActionManagementCreation IF USER IS "guest" THEN DENY // This rule is evaluated second (priority 2) DEFINE RULE AllowAdminUsers WITH PRIORITY 2 FOR ActionManagementCreation IF USER IS "admin" THEN ALLOW ``` Use lower priority numbers for more specific rules (like denying specific users) and higher numbers for general allow/deny rules. Structure layered access as specific deny rules first, then broader allow rules: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} DEFINE RULE ProtectSysTopics WITH PRIORITY 10 FOR PublishSys IF USER IS "root" THEN ALLOW ELSE DENY DEFINE RULE AllowDevicePublish WITH PRIORITY 50 FOR Publish TO TOPIC "sensors/#" IF USER HAS AllowedSensorPublish THEN ALLOW ELSE DENY ``` | Practice | Guideline | | - | - | | Priority 1–20 | Critical deny rules (system protection) | | Priority 21–50 | Specific allow rules (per-feature access) | | Priority 51–100 | General allow rules (broad access) | | Condition style | Prefer `USER HAS ` over `USER IS ""` for maintainability | *** ## Complete Examples A typical production setup with role-based access control: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} // Only root can manage users DEFINE RULE RestrictUserManagement WITH PRIORITY 1 FOR UserManagementCreation IF USER IS "root" THEN ALLOW ELSE DENY // Admins and root can deploy Actions DEFINE RULE AllowActionDeployment WITH PRIORITY 1 FOR ActionManagementCreation IF USER IS "root" OR USER IS "admin" THEN ALLOW ELSE DENY // Users with permission can manage models DEFINE RULE AllowModelManagement WITH PRIORITY 1 FOR ModelManagementCreation IF USER HAS AllowedModelManagement OR USER IS "admin" THEN ALLOW ELSE DENY // Everyone can publish to non-system topics DEFINE RULE OpenPublish WITH PRIORITY 1 FOR Publish TO TOPIC "#" ALLOW // Restrict $SYS subscriptions to root DEFINE RULE ProtectSysTopics WITH PRIORITY 1 FOR SubscribeSys TO TOPIC "$SYS/#" IF USER IS "root" THEN ALLOW ELSE DENY ``` Limit IoT devices to their own topic namespace: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} // Devices can only publish to their own topics DEFINE RULE DevicePublishRestriction WITH PRIORITY 1 FOR Publish TO TOPIC "devices/#" IF USER HAS DevicePermission THEN ALLOW ELSE DENY // Devices cannot access command topics DEFINE RULE DenyDeviceCommands WITH PRIORITY 1 FOR PublishSys TO TOPIC "$SYS/Coreflux/Command" IF USER HAS DevicePermission THEN DENY // Devices can subscribe to their config topics DEFINE RULE DeviceConfigSubscription WITH PRIORITY 1 FOR Subscribe TO TOPIC "config/devices/#" IF USER HAS DevicePermission THEN ALLOW ELSE DENY ``` Separate access by organizational department: ```lot wrap theme={"theme":"css-variables","languages":{"custom":["/languages/lot.json"]}} // Engineering team access DEFINE RULE EngineeringPublish WITH PRIORITY 1 FOR Publish TO TOPIC "engineering/#" IF USER HAS EngineeringAccess THEN ALLOW ELSE DENY // Operations team access DEFINE RULE OperationsPublish WITH PRIORITY 1 FOR Publish TO TOPIC "operations/#" IF USER HAS OperationsAccess THEN ALLOW ELSE DENY // Shared topics for cross-team communication DEFINE RULE SharedTopicAccess WITH PRIORITY 1 FOR Publish TO TOPIC "shared/#" IF USER HAS EngineeringAccess OR USER HAS OperationsAccess THEN ALLOW ELSE DENY ``` *** ## Best Practices Create restrictive rules first, then add specific allow rules for authorized users. This prevents accidental access. Check `USER HAS ` rather than `USER IS ""` when possible. This makes it easier to manage access as users change. Always restrict access to `$SYS/#` topics. These contain broker commands and sensitive system information. Use clear, descriptive rule names that explain their purpose. `AllowAdminActionCreation` is better than `Rule1`. *** ## Next Steps Build event-driven automation with Actions. Structure your MQTT data with Models. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.