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

​
Policy Engine

A logical container for related policy rules. Each group has its own priority, activation 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 → PUBLISHED → DEPLOYED (live)
  • DRAFT: Editable. Rules can be added, modified, or removed.
  • PUBLISHED: Locked. No further modifications allowed.
  • DEPLOYED: Actively receiving live traffic.
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.
A boolean expression that determines whether a rule applies to a given request. Conditions evaluate input facts using operators like EQUALS, GREATER_THAN, CONTAINS, 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 include: DISCOUNT, POINT, COUPON, NOTIFICATION, WEBHOOK, SET_FACT, ADD_TAG.

​
Facts & 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.
In LexQ, “Fact” is the official domain term. It refers to any input variable consumed by the policy engine.
The schema definition for a fact — its key, display name, data type, and whether it is required. Fact definitions are managed in the Fact Definitions section of the console.System facts (e.g., payment_amount, user_id) are predefined and cannot be deleted.

​
Deployment Lifecycle

Transitioning a version from DRAFT to PUBLISHED. Once published, the version is locked — rules and settings cannot be modified. Publishing does not route live traffic to the version.
Promoting a PUBLISHED 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 & Analytics

A single-request test execution against a specific policy version. Dry runs do not affect live traffic, usage quotas, or execution logs. Useful for validating rule behavior before deployment.
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.
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 grouping key that controls how many matching rules are executed within a policy group. Activation modes include:
  • Allow All: Execute all matching rules.
  • Exclusive: Execute only one (the best match).
  • Max N: Execute the top N rules by priority.
A conflict resolution mechanism within a version. When multiple rules in the same mutex group match, only a subset is selected based on the configured strategy (first match, highest priority, or max benefit).

​
Billing & 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. Some plans block requests instead of allowing overage.
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 and above.
A connection to an external service (e.g., notification provider, point system, coupon service) used by policy actions. Configured with a base URL, API key, and optional parameters.

​
Marketing → 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 SimulationSimulation / Dry RunBatch or single-request testing
Instant Deployment PipelineDeploy to LiveOne-click deployment with optional A/B split