What is a Fact Definition?
A Fact Definition declares an input variable that your rules can reference in conditions and actions. Think of it like a function parameter — you define the name, type, and whether it’s required before writing the logic. Facts are tenant-wide: once defined, they’re available across all policy groups and versions.System Facts
Every tenant has 7 pre-registered system facts available immediately after account creation. These cannot be deleted:| Key | Type | Required | Description |
|---|---|---|---|
user_id | STRING | ✅ | User identifier |
payment_amount | NUMBER | ✅ | Payment amount |
phone_number | STRING | Phone number | |
email | STRING | Email address | |
device_token | STRING | Device token (for push notifications) | |
user_tags | LIST_STRING | User tags | |
total_point | NUMBER | Current point balance |
Custom Facts
Any input variable beyond the 7 system facts must be registered before use. For example,customer_tier, order_region, or product_category are custom facts.
Supported Types
| Type | JSON | Example Value |
|---|---|---|
STRING | "string" | "VIP" |
NUMBER | number | 100000 |
BOOLEAN | true / false | true |
LIST_STRING | ["a", "b"] | ["KR", "US"] |
LIST_NUMBER | [1, 2] | [10000, 20000] |
Naming Conventions
Fact keys must followsnake_case naming. Keys are case-sensitive.
- ✅
payment_amount,customer_tier,user_region - ❌
paymentAmount,Payment-Amount,PAYMENT AMOUNT
Required vs Optional Facts
- Required facts must be present in every execution request. If missing, the engine returns an
INVALID_INPUTerror. - Optional facts can be omitted. Rules referencing missing optional facts evaluate their conditions as
false(no match).
Managing Facts
Facts are managed in the Console under Management → Fact Definitions, or via the CLI:Next Steps
Policy Rules
Use facts in rule conditions and actions.
Policy Execution
See how facts are passed during execution.

