Skip to main content
Every term below is the canonical name used in LexQ’s API responses, console UI, and documentation.

​
Policy Engine

A logical container for related policy rules. Each group has its own priority, execution mode, and deployment lifecycle. A group can have multiple versions, but only one can be live at a time.
An immutable snapshot of rules within a policy group at a specific point in time.Lifecycle: DRAFT → ACTIVE → ARCHIVED
  • DRAFT: Editable. Rules can be added, modified, or removed.
  • ACTIVE: Published and locked. No further modifications allowed. Ready for deployment.
  • ARCHIVED: Superseded by a newer version. Read-only history.
  • EXPIRED: Past its effectiveTo date. Auto-transitioned by the scheduler.
An individual rule consisting of a condition and one or more actions. When the condition evaluates to true, the associated actions are executed. Rules are ordered by priority within a version (0 = highest).
A boolean expression that determines whether a rule applies to a given request. Conditions evaluate input facts using operators like EQUALS, GREATER_THAN, CONTAINS, IN, etc. Conditions can be nested into groups using AND / OR logical operators.
An operation executed when a rule’s condition is met. Built-in action types: DISCOUNT, POINT, COUPON_ISSUE, BLOCK, NOTIFICATION, WEBHOOK, SET_FACT, ADD_TAG.

​
Facts and Schema

A single input data field passed to the policy engine at execution time. For example, payment_amount, user_id, or email. Facts are the raw data that conditions evaluate and actions operate on.
The schema definition for a fact — its key, display name, data type, and whether it is required. Managed in the Console under Management → Fact Definitions. System facts (e.g., payment_amount, user_id) are pre-registered on account creation and cannot be deleted.
Seven pre-registered facts available to every tenant immediately after account creation: user_id, payment_amount, phone_number, email, device_token, user_tags, total_point. These cannot be deleted.

​
Deployment Lifecycle

Transitioning a version from DRAFT to ACTIVE. Once published, the version is locked — rules and settings cannot be modified. Publishing does not route live traffic to the version. A separate Deploy step is required.
Promoting an ACTIVE version to live status. After deployment, the version actively receives and processes production traffic. Only one version per policy group can be live at any time.
Removing the live version from a policy group. After undeployment, no traffic is processed for that group until a new version is deployed.
Reverting a policy group to its previously deployed version. A rollback creates a new deployment record for audit purposes.

​
Testing and Analytics

A single-request test execution against a specific policy version. Dry runs do not affect live traffic, usage quotas, or execution logs. External integration calls are mocked by default. Set mockExternalCalls to false to execute real calls instead.
A batch test that runs a dataset (historical or manual) against a policy version. Produces match rates, rule statistics, and optional metric comparisons against a baseline version. Integration calls are always mocked during simulation.
A live policy evaluation triggered by an API call. Each execution is logged with a unique trace ID and includes execution traces and decision traces.
A per-rule record showing whether the rule’s condition matched and the evaluated expression. Part of the audit trail for every execution.
A per-rule record showing the final selection outcome — whether the rule was selected, blocked by mutex, lost priority, etc. Includes a reason code explaining the decision.
A traffic-splitting mechanism that routes a percentage of requests to an alternate policy version. Used to compare version performance in production with real traffic.

​
Rule Execution Control

A conflict resolution mechanism within a version. Rules sharing the same mutexGroup key compete for execution. When mutexMode is set to EXCLUSIVE, only the winning rule fires based on the configured strategy.
Determines which rule wins when multiple rules in the same mutex group match:
  • FIRST_MATCH: First matching rule in priority order wins.
  • HIGHEST_PRIORITY: Rule with the lowest priority number wins.
  • MAX_BENEFIT: Rule producing the highest output value wins.
When using EXCLUSIVE mode, mutexLimit controls how many rules from the mutex group can fire (default: 1).

​
Billing and Infrastructure

Usage exceeding the plan’s base allocation for API executions or simulations. Overage is billed at a per-unit rate defined by the plan.
Requests rejected because the tenant exceeded the plan’s maximum TPS (transactions per second). Throttled requests return HTTP 429 Too Many Requests.
Business information used for invoices and tax documents — company name, tax ID, representative, and address.
A resilience policy where the engine allows requests to pass through (instead of blocking) when an internal error occurs. Available on Pro plans.
A connection to an external service (e.g., notification provider, point system, coupon service) used by policy actions. Six types: WEBHOOK, COUPON, POINT, NOTIFICATION, CRM, MESSENGER.

​
Marketing to Product Term Mapping

Some terms used on the LexQ website differ from the console and API terminology.
Marketing TermProduct EquivalentNotes
Visual Rule BuilderRule Edit tabConsole’s rule editing interface
Conflict Resolution EngineMutex GroupRule conflict handling via mutex strategies
Full Audit TrailsExecution Traces + Decision TracesCombined trace data per execution
Git-Style VersioningPolicy VersionsDraft → Publish → Deploy lifecycle
Pre-deploy SimulationBatch Simulation / Dry RunBatch or single-request testing
Instant Deployment PipelineDeploy to LiveOne-click deployment with optional A/B split