Core Concepts
The vocabulary of the AI Rule Engine and how the pieces fit together: organizations and projects at the top, rule sets and rules in the middle, and conditions, actions, context, and values doing the work at the bottom.
The big picture
An organization owns projects. A project contains rule sets (along with reusable conditions and action sets). A rule set holds an ordered list of rules; each rule pairs a condition with one or more actions. When a rule set runs inside an environment, rules are evaluated against a context — a bag of named values addressed by context keys — and matching rules execute their actions.
Definitions
| Term | What it is |
|---|---|
| Organization | The ownership and billing boundary. Holds members, plan and credits, projects, and environments. Every project belongs to exactly one organization. |
| Project | A container for related rule sets, conditions, and action sets. Has a type (Standard, Extension, or Template) and a member list. |
| Rule Set | An ordered collection of rules plus a context definition. Controls how rules run: in order or in parallel, optionally with a randomized order and a cap on how many rules may match. |
| Rule | A single unit of decision logic: one condition plus one or more actions. The actions run only when the condition matches. Actions within a rule can also run in order or in parallel. |
| Condition | The test that decides whether a rule matches. A condition is a group of clauses; it can be saved and reused, or defined inline on a rule. |
| Clause | The smallest test: a context key, an operator (such as Equals or Contains), and a value to compare against. Some operators evaluate the value with AI. |
| Clause group | A set of clauses (and nested groups) combined with a logic mode: All (every part true), Any (at least one true), or None (no part true). |
| Action | A step that does something when a rule matches: call an API, transform data, write to context, log, run an AI prompt, invoke an extension, and more. |
| Action Set | A named, reusable list of actions a rule can reference instead of defining actions inline. |
| Variable | A named value stored in an environment that rules and actions can read while running, separate from the per-run context input. |
| Context | The working data of a single run: the inputs you supply to the rule set plus anything actions add to it as they execute. |
| Context key | The address used to read or write a value in the context, for example ticket.subject. |
| Context definition | The declared shape of the inputs a rule set expects. |
| Data type / Data value | A value's type (String, Integer, Decimal, Boolean, DateTime, Url, and others) and the typed value itself. Values may be literals or references to context. |
| Environment | An isolated place where rule sets run, owned by an organization, with its own settings, variables, schedules, storage, and logs. Rule sets are authored once and run inside an environment. |
How conditions are structured
Conditions form a tree. At the leaves are clauses — each one compares a context value to a target using an operator. Clauses are gathered into groups that apply All, Any, or None logic, and groups can nest inside other groups to express complex logic. Operators range from simple comparisons (Equals, Greater Than, Contains) to pattern matching and AI-evaluated prompts. See Conditions for the complete operator list.
How actions relate to rules
When a rule's condition matches, its actions run. A rule can hold actions inline or reference one or more reusable action sets — one approach or the other, never both. Actions read from and write to the shared context, so an earlier action can prepare data that a later action consumes. The action catalog spans data and transform steps, integration calls, control-flow constructs such as looping over arrays, human-in-the-loop pauses, and a family of AI actions. Start at Actions Overview.
Authoring versus executing
A recurring theme is the split between designing rules and running them. You author projects, rule sets, conditions, and actions in one place, and you run them inside an environment. Understanding that boundary explains why environments, variables, and run logs live apart from the rule definitions themselves. Continue with Authoring & Executing.