> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lexq.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Glossary

> Official terminology used across LexQ documentation, console, and API.

Every term below is the **canonical name** used in LexQ's API responses, console UI, and documentation.

## Policy Engine

<AccordionGroup>
  <Accordion title="Policy Group">
    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.
  </Accordion>

  <Accordion title="Policy Version">
    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.
  </Accordion>

  <Accordion title="Policy Rule">
    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).
  </Accordion>

  <Accordion title="Condition">
    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.
  </Accordion>

  <Accordion title="Action">
    An operation executed when a rule's condition is met.
    Built-in action types: `MUTATE_FACT`, `INCREMENT_FACT`, `EMIT_EVENT`, `EMIT_NOTIFICATION`, `EMIT_WEBHOOK`, `BLOCK`, `SET_FACT`, `ADD_TAG`.
    These are **domain-agnostic primitives** — the engine sees only numbers and structures, not commerce-specific concepts. Domain-specific semantics (e.g., "discount", "coupon", "loyalty point") are expressed through fact names and integration payloads, not the action type.
  </Accordion>
</AccordionGroup>

## Facts and Schema

<AccordionGroup>
  <Accordion title="Fact">
    A single input data field passed to the policy engine at execution time.
    For example, `user_id`, `customer_tier`, or `order_total`.
    Facts are the raw data that conditions evaluate and actions operate on.
  </Accordion>

  <Accordion title="Fact Definition">
    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**.
    Two facts (`user_id`, `user_tags`) are pre-registered on account creation for convenience; they can be edited or deleted like any other fact.
  </Accordion>

  <Accordion title="Pre-registered Facts">
    Two facts available to every tenant immediately after account creation: `user_id` and `user_tags`. They are provided for convenience — not protected, and can be renamed, retyped, or deleted like any custom fact. All other facts (e.g., `customer_tier`, `order_total`) are user-defined and registered via [Fact Definitions](/guides/fact-definitions).
  </Accordion>

  <Accordion title="Unregistered Fact">
    A fact key referenced in a rule's condition or action that has no [Fact Definition](/guides/fact-definitions). LexQ detects these on every rule save and reports them — with an inferred type and suggested name — without blocking the save, publish, or deploy.

    An unregistered fact still works at execution time if its value is supplied; registering it adds type validation, Console autocomplete, and inclusion in the requirements analyzer. List them with `lexq facts unregistered` or the `lexq_facts_unregistered` MCP tool.
  </Accordion>

  <Accordion title="Generated Variables">
    Variables exposed in the response (`generatedVariables`) that did not exist in the input facts.
    Includes per-action change keys following the `{key}__delta` naming convention:

    * `{refVar}__delta` — signed net change from `MUTATE_FACT` (`mutated - original`).
    * `{targetVar}__delta` — non-negative increment from `INCREMENT_FACT`.

    When multiple actions in a rule mutate the same fact, `__delta` reports the cumulative change. Per-action snapshots are available in `executionTraces` for audit drill-down.
  </Accordion>
</AccordionGroup>

## Deployment Lifecycle

<AccordionGroup>
  <Accordion title="Publish">
    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.
  </Accordion>

  <Accordion title="Deploy">
    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.
  </Accordion>

  <Accordion title="Undeploy">
    Removing the live version from a policy group.
    After undeployment, no traffic is processed for that group until a new version is deployed.
  </Accordion>

  <Accordion title="Rollback">
    Reverting a policy group to its previously deployed version.
    A rollback creates a new deployment record for audit purposes.
  </Accordion>

  <Accordion title="Scheduled Deployment">
    Arms an ACTIVE version with a future effective start to deploy automatically when that time arrives.
    The snapshot hash is sealed at scheduling and re-verified at execution; conflicting actions (manual deploy, A/B start, group archive) cancel the pending schedule automatically.
  </Accordion>
</AccordionGroup>

## Testing and Analytics

<AccordionGroup>
  <Accordion title="Dry Run">
    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.
  </Accordion>

  <Accordion title="Impact Simulation">
    An impact 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.
  </Accordion>

  <Accordion title="Decision Replay">
    Re-evaluation of one past execution's exact input facts against a candidate version, producing a decision diff: changed or not, fired rules on both sides, and effect changes.
    The stored decision is the baseline and is never re-evaluated; external effects are always mocked.
    Window replay extends this to a date range and measures the blast radius — how many past decisions would change.
  </Accordion>

  <Accordion title="Execution">
    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.
  </Accordion>

  <Accordion title="Execution Trace">
    A per-rule record showing whether the rule's condition matched, the evaluated expression, the input facts the rule saw, and the actions it generated.
    Part of the **audit trail** for every execution.
  </Accordion>

  <Accordion title="Decision Trace">
    A per-rule record showing the final selection outcome with two classifying fields:

    * **`status`** — `SELECTED`, `NO_MATCH`, `NOT_SELECTED`, `BLOCKED`, `ERROR`.
    * **`reasonCode`** — the specific reason within that status (e.g., `FINAL_WINNER`, `CONDITION_MISMATCH`, `MUTEX_PRIORITY_LOST`, `GROUP_LIMIT_REACHED`, `ACTION_ERROR`).

    See [Policy Rules — Decision Trace](/guides/policy-rules#decision-trace) for the full status × reasonCode mapping.
  </Accordion>

  <Accordion title="A/B Test">
    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.
  </Accordion>
</AccordionGroup>

## Audit and Provenance

<AccordionGroup>
  <Accordion title="Decision Provenance">
    The sealed lineage of one decision: the outcome, deterministic per-rule reasons, input facts (PII masked), the rule snapshot fingerprint, and the authored/published/deployed responsibility chain.
    Sealed at write time — never reconstructed after the fact.
  </Accordion>

  <Accordion title="PII Masking">
    Facts marked as PII arrive masked (`••••••`) on every read surface, with `maskedKeys` naming them.
    A display-layer policy only — the engine always evaluates real values.
  </Accordion>

  <Accordion title="PII Reveal">
    The audited, console-only act of viewing a masked value.
    The audit row is committed before the value is shown (write-then-reveal); API keys are rejected with 403.
  </Accordion>

  <Accordion title="Reveal Audit Ledger">
    An append-only, metadata-only record of every reveal: who revealed which fact of which trace, and when. Values are never stored.
    Readable by more roles than can reveal, and collectable by API for periodic access-log inspection.
  </Accordion>
</AccordionGroup>

## Rule Execution Control

<AccordionGroup>
  <Accordion title="Mutex Group">
    A conflict resolution mechanism within a version. Rules sharing the same `mutexGroup` key compete for execution.
    When `mutexMode` is `EXCLUSIVE`, only the single winning rule fires; when `MAX_N`, up to `mutexLimit` rules fire. The configured strategy decides which rule(s) win.
  </Accordion>

  <Accordion title="Mutex 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.
  </Accordion>

  <Accordion title="Mutex Limit">
    When using `MAX_N` mode, `mutexLimit` controls how many rules from the mutex group can fire (default: 1).
  </Accordion>
</AccordionGroup>

## Billing and Infrastructure

<AccordionGroup>
  <Accordion title="Overage">
    Usage exceeding the plan's base allocation for API executions or simulations.
    Overage is billed at a per-unit rate defined by the plan.
  </Accordion>

  <Accordion title="Throttle">
    Requests rejected because the tenant exceeded the plan's maximum TPS (transactions per second).
    Throttled requests return HTTP `429 Too Many Requests`.
  </Accordion>

  <Accordion title="Billing Profile">
    Business information used for invoices and tax documents — company name, tax ID, representative, and address.
  </Accordion>

  <Accordion title="Fail-open">
    A resilience policy where the engine allows requests to pass through (instead of blocking) when an internal error occurs.
    Available on Pro plans.
  </Accordion>

  <Accordion title="Integration">
    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.
  </Accordion>
</AccordionGroup>

***

## Marketing to Product Term Mapping

Some terms used on the [LexQ website](https://lexq.io) differ from the console and API terminology.

| Marketing Term              | Product Equivalent                        | Notes                                        |
| --------------------------- | ----------------------------------------- | -------------------------------------------- |
| Visual Rule Builder         | Rule Edit tab                             | Console's rule editing interface             |
| Conflict Resolution Engine  | Mutex Group                               | Rule conflict handling via mutex strategies  |
| Full Audit Trails           | Execution Traces + Decision Traces        | Combined trace data per execution            |
| Git-Style Versioning        | Policy Versions                           | Draft → Publish → Deploy lifecycle           |
| Pre-deploy Simulation       | Impact Simulation / Dry Run               | Batch or single-request testing              |
| Every Decision, Verifiable  | Decision Provenance + Reveal Audit Ledger | Sealed lineage plus an audited access record |
| Instant Deployment Pipeline | Deploy to Live                            | One-click deployment with optional A/B split |