LexQ

Adjust traffic rate of a running A/B test.

Start an A/B test on a policy group. Requires a challenger version ID and traffic rate. The challenger must be a published version of the same group; a version from another group is rejected with P-016. The split is computed from context.trafficKey on each execution request; requests that omit it never reach the challenger and the test stays at 0%. Starting cancels the group's pending scheduled deployment. Starting while a test is already running replaces its challenger and traffic rate.

Stop a running A/B test. All traffic is restored to the control (current) version.

Generate a sample CSV or JSON template based on the required facts of a version. Use this to understand the expected data format before uploading a dataset.

Upload inline CSV or JSON content as a simulation dataset. The content is stored as a dataset, and its path is returned in the "path" field.

To use the returned path in lexq_simulation_start, set: dataset: { "type": "UPLOADED", "source": "UPLOADED_FILE", "path": "" }

The content travels inside the tool call, so this suits small datasets, and the hosted server at mcp.lexq.io limits the size of a request. For a larger file, use lexq_dataset_upload_file on the local server (lexq serve --mcp), or upload it with the CLI or the console and pass the returned path.

CSV example: userId,paymentAmount user_001,150000 user_002,50000

In CSV, a cell holding a JSON array, such as ["gold","vip"], is read as a list; quote the cell, as CSV requires for a value with commas.

JSON example: [{"userId":"user_001","paymentAmount":150000}, {"userId":"user_002","paymentAmount":50000}]

List ACTIVE (published) versions that can be deployed for a group. Use this to find which versions are available before calling deploy live.

Get detailed info about a specific deployment including snapshot hash and integrity check.

Compare rule snapshots between two versions. Shows added, removed, and modified rules. Useful for reviewing changes before deploying a new version.

List deployment history across all groups.

Deploy an ACTIVE (published) version to live traffic. Takes effect immediately. Versions whose effective start date has not arrived are rejected (P-037) — use lexq_deploy_schedule for those. Versions whose effective end has passed are rejected (P-058). Undefined facts do not block deployment; use lexq_facts_unregistered to review what the version references but has not defined.

Show current deployment status of all groups — which version is live, last deployment type, and deployer. Each group also carries currentDeploymentId, previousVersionName (the version a rollback restores) and canRollback, as in lexq_groups_get.

Publish a DRAFT version (DRAFT → ACTIVE). Locks the version from further edits. Must have at least one rule. Undefined facts that rules only read do not block publishing; call lexq_facts_unregistered first to review them. Publishing fails if an action's targetVar is not a registered fact (ACT-032), if the version's compiled rules exceed 128 KB, or if its effective end has already passed (P-058); move the end into the future with lexq_versions_update first.

Roll the group back to the version that was live before the current one. Call lexq_groups_get first: currentVersionName is live now, previousVersionName is what a rollback restores, and a rollback is rejected while canRollback is false. A rollback needs a previous version that is still ACTIVE and whose effective end has not passed (P-058).

Pass the currentVersionId and currentDeploymentId from that call as expectedCurrentVersionId and expectedCurrentDeploymentId. If anyone deployed, rolled back or undeployed in between, the rollback is rejected with 409 and nothing changes: P-062 if another version or no version is live, P-063 if the same version is live but from a newer deployment. Read the group again and check with the user before retrying.

Schedule an ACTIVE version with a future effective start date to auto-deploy at that time (Scheduled Deployment). The time is the version's effectiveFrom, set on the DRAFT before publishing; this call takes no time of its own. One pending schedule per group; manual deploy/rollback/undeploy, starting an A/B test, or archiving the group cancels it. A scheduled deployment uses exactly the rules that were scheduled; if they do not match when it runs, it fails with HASH_MISMATCH and nothing is deployed.

List scheduled deployments across all groups (all statuses: PENDING, EXECUTED, CANCELED, FAILED), newest first.

Remove the live version from traffic. The version stays ACTIVE but no longer serves requests.

Cancel the pending scheduled deployment for a group. The version itself is not affected. Fails with P-039 if no pending schedule exists.

Apply a domain template to the current tenant. Creates the template's fact definitions and a new policy group pre-populated with its sample rules as a DRAFT version. Apply never overwrites existing schema: a key that already exists with the same definition is kept as it is. Run lexq_domain_templates_preview first. If its factConflicts is not empty, apply fails with P-061 and creates nothing until those facts are deleted or changed to match the template. A template whose isAvailable is false cannot be applied.

List all domain templates. A domain template is a starter pack of fact definitions and sample rules for a common decision, such as checkout pricing (ECOMMERCE) or transfer approval (FINTECH). Each entry reports its key, whether it can be applied (isAvailable), and how many facts and sample rules it provisions. Call this before preview or apply to see which templates exist.

Preview exactly what a domain template will provision before applying it: the fact definitions it registers (an input with a value domain carries its allowed values or range), the sample rules it creates with a description of each, and an apply plan. This is a read-only dry run; nothing is created. factConflicts lists keys this tenant already has with a different type, or with different allowed values or a different range on an input fact. While it is not empty, apply fails with P-061 and creates nothing: delete those facts or change them to match the template, then apply. plan is null for a template that cannot be applied yet.

Execute a single dry run against a version. Tests how rules evaluate given input facts without side effects. Not billed and not counted toward the plan's usage. Dry runs, dry run compares, and single-decision replays share two limits for each organization: 60 evaluations per minute and 1000 per UTC day; a compare counts as two. Past the per-minute limit, a call fails with 429 (C-007); wait a minute before trying again. Past the daily limit, a call fails with 429 (AN-041) until 00:00 UTC. A call refused by the per-minute limit does not count toward the daily limit.

Returns: inputFacts — normalized input facts mutatedFacts — input facts changed by rule actions (e.g. MUTATE_FACT mutates paymentAmount) generatedVariables — system-generated values; every fact in mutatedFacts gets a paired {factName}__delta key (signed difference) executionTraces — per-rule match status decisionTraces — per-rule decision (SELECTED / NO_MATCH / BLOCKED / etc.)

Example input: { "facts": { "paymentAmount": 100000, "customerTier": "VIP" } }

Compare dry run results between two versions using the same input facts. Useful for validating changes. Not billed and not counted toward the plan's usage. Dry runs, dry run compares, and single-decision replays share two limits for each organization: 60 evaluations per minute and 1000 per UTC day; a compare counts as two. Past the per-minute limit, a call fails with 429 (C-007); wait a minute before trying again. Past the daily limit, a call fails with 429 (AN-041) until 00:00 UTC. A call refused by the per-minute limit does not count toward the daily limit.

Returns: resultA / resultB — full DryRunResponse for each version diff.mutatedDiff — changes in mutatedFacts between A and B (key → {before, after}) diff.generatedDiff — changes in generatedVariables between A and B

Retrieve runtime fact requirements per Action type. For each Action, shows which input facts must be present in the execution payload — e.g. MUTATE_FACT always requires its targetVar fact, plus refVar when one is specified. The factRequired flag describes the FACT, not the parameter: refVar is an optional parameter, but if you specify it the named fact must exist. A required fact absent at runtime throws — the engine never defaults to 0. These facts must be sent in the request (P-015 otherwise), even when an earlier action in the same rule writes them. SET_FACT requires no input fact: it is the only action whose targetVar the request does not have to send, and that targetVar must be a registered fact (ACT-032). Static data, safe to cache in-session.

Register a new input variable. Key starts with a letter, then letters, numbers, and underscores (e.g. paymentAmount). Casing is not enforced. Types: STRING, NUMBER, BOOLEAN, LIST_STRING, LIST_NUMBER.

Delete a fact definition. System facts cannot be deleted. Neither can a fact that any rule references: that call fails with FD-006 and reports the count. Rules in deleted groups do not count. Remove the references first.

Export the fact catalog. The two formats carry different things: CSV is the catalog as it stands, system facts included, for reading in a spreadsheet, without value domains; JSON lists each definition with only the fields a new definition takes (key, name, type, description, isRequired, isPii, valueDomain), without IDs. Returns the file contents as text. An export longer than 100,000 characters is refused.

List all fact definitions (input variable schema): key, name, type, description, PII and system flags, and value domain. isRequired is stored on the definition only; the engine does not read it.

List facts referenced by a version's rules but not yet defined (read-only). Keys that rules only read do not block publish/deploy; a rule whose action targetVar is not a registered fact is rejected at save and publish with ACT-032. Version-wide: covers every rule in the version. Each entry carries the inferred type, suggested name, and where it is referenced (condition/action). Registering one with lexq_facts_create before the version is published makes the engine check request values for it against its type (P-060) and any value domain (P-052).

Update a fact definition. The key is immutable. The type can change only while no rule references the fact; if any does, the call fails with FD-007 and reports the count. Rules in deleted groups do not count. Only the fields you send are changed. System facts (isBlocked, blockReason) accept changes to name, description, PII, and the value domain; isRequired is ignored, and their type cannot change (FD-003).

Create a new policy group. Requires name. Priority is auto-assigned (appended last, tenant-wide); use lexq_groups_reorder to change order. Optionally set conflict resolution, activation group, and description. Policy groups that share an activationGroup form a cluster and must share the same activationMode / activationStrategy / executionLimit; executionLimit is how many of those groups run, not how many rules. A tenant can have at most 20 groups that are not ARCHIVED; archive groups you no longer use to free a slot.

Delete (archive) a policy group. A deployed group cannot be deleted (P-020); undeploy it first with lexq_deploy_undeploy, which also ends a running A/B test. This cannot be undone. The group no longer appears in lexq_groups_list and its name can be reused right away. Calls that change it (settings, versions, rules, starting an A/B test, publish, deploy, rollback, scheduling a deployment) return 409 P-059. If it was ever executed, deployed, or replayed, it is kept for audit; otherwise it is permanently deleted after 30 days.

Get a single policy group by ID. Its currentVersionId and currentDeploymentId are what lexq_deploy_rollback expects, and previousVersionName is the version a rollback restores.

List policy groups (tenant-wide, priority ASC). Deleted groups are not included.

Reorder policy groups by priority. Priority is tenant-wide and flat (1...N continuous); array index 0 = priority 1 (highest precedence). activationGroup is not affected — this only changes priority.

Update a policy group. Only provided fields are updated; omitted fields remain unchanged. A deleted group cannot be updated (409 P-059).

Get full execution detail including inputFacts, mutatedFacts, generatedVariables, executionTraces, and decisionTraces.

List policy execution history. Shows trace ID, group, version, status, match result, and latency.

Get execution KPIs: total executions, success/failure counts, success rate, and average latency. Without dates the window is the last 30 days through today, in the organization time zone. At most 31 days per call; a longer range is rejected with AN-039. startDate alone runs through today.

Get failure log detail by ID. Logs can be read here but not resolved or ignored. An organization admin does that in the LexQ console: Management → Failure Logs (https://console.lexq.io/management/failure-logs).

List system failure logs from background tasks (platform event webhooks, scheduled deployments). Without dates the window is 7 days back through today, in the organization time zone; pass startDate to look further back. Logs can be read here but not resolved or ignored. An organization admin does that in the LexQ console: Management → Failure Logs (https://console.lexq.io/management/failure-logs).

List the PII reveal audit ledger — who revealed which fact of which trace, and when. Metadata only; revealed values are never stored or returned. Use for monthly access-log inspection and SIEM collection.

Per-rule latency profile of a policy group over a time window: group TOTAL distribution split by cacheState (HIT = calls on a version already prepared for execution, MISS = calls that had to prepare the version first and run slower), a per-rule CONDITION/ACTION percentile table, and slow-rule flags. flagged = p50 ≥ 10× median of per-rule p50s within the group; absolute thresholds are intentionally not supported. Every percentile is accompanied by its sample count n; a percentile is withheld (null) unless n×(1−q) ≥ 3 (p50 needs n ≥ 6, p95 n ≥ 60, p99 n ≥ 300 — display gate, separate from the n ≥ 100 judgment gate). Baselines report INSUFFICIENT_COHORT when fewer than 3 rules qualify. Rule detail comes from a 1% sample of calls; TOTAL is recorded for every call. Defaults: last 24h, live version, cacheState HIT.

Single-rule latency detail: merged phase × cacheState distributions plus a per-window time series (60s windows). Missing windows are genuine gaps — never interpolated. Series points carry each window's own values; percentiles in merged distributions are withheld (null) unless n×(1−q) ≥ 3 (p50 n ≥ 6, p95 n ≥ 60, p99 n ≥ 300). flagged = p50 ≥ 10× median of per-rule p50s within the group; absolute thresholds are intentionally not supported.

Get the lineage of a single decision: what was decided, deterministic why per rule, input facts (PII facts are masked as •••••• with maskedKeys listing them — values are revealable only in the console, audited), the authored/published/deployed responsibility chain, and the rule snapshot fingerprint.

Cancel a PENDING or RUNNING window replay job. Other states are rejected. VIEWER role cannot cancel.

Re-evaluate a past execution (traceId) against a candidate version and return the decision diff (decisionChanged, effect changes, fired rules) plus a determinism verdict. Synchronous. Not billed and not counted toward the plan's usage. Dry runs, dry run compares, and single-decision replays share two limits for each organization: 60 evaluations per minute and 1000 per UTC day; a compare counts as two. Past the per-minute limit, a call fails with 429 (C-007); wait a minute before trying again. Past the daily limit, a call fails with 429 (AN-041) until 00:00 UTC. A call refused by the per-minute limit does not count toward the daily limit. A replay sends no webhook, notification, or event: rule actions produce no outward effects.

Export a COMPLETED window replay job; a job that has not completed is rejected. The two formats carry different things: CSV holds the effect blast radius, whose columns are fixed; JSON holds the changed samples and action parameters, which nest and whose keys differ per tenant. JSON is not a superset of CSV. Returns the file contents as text. An export longer than 100,000 characters is refused.

List window replay job history (reverse-chronological). Lightweight items — use lexq_replay_status for summary and changed samples.

Submit an async job that replays a date window of past executions against a candidate version and measures the blast radius (how many decisions change). Billed per replayed record (REPLAY metric); VIEWER role cannot submit. Poll with lexq_replay_status.

Poll a window replay job. RUNNING shows progress 0–100; COMPLETED fills summary and changedSamples; FAILED carries errorMessage. capped=true means the window exceeded the sample cap and only part was replayed.

Analyze which input facts a version requires. Returns required keys, types, and an example request body.

Create a rule in a DRAFT version. It goes last in priority order; lexq_rules_reorder changes the order.

An action's targetVar must be a registered fact (ACT-032 otherwise). Keys a rule only reads (condition fields, refVar) may stay unregistered.

Condition: { type: "SINGLE", field, operator, value, valueType } or { type: "GROUP", operator: "AND"|"OR", children: [...] } Value types: STRING, NUMBER, BOOLEAN, LIST_STRING, LIST_NUMBER Limits: 25 SINGLE conditions per rule (GROUP nodes do not count), 10 levels of nesting below the root, 100 rules per version.

Operators that work on each fact type:

• STRING: EQUALS, NOT_EQUALS, CONTAINS (substring), IN, NOT_IN

• NUMBER: EQUALS, NOT_EQUALS, GREATER_THAN, GREATER_THAN_OR_EQUAL, LESS_THAN, LESS_THAN_OR_EQUAL, IN, NOT_IN

• BOOLEAN: EQUALS, NOT_EQUALS

• LIST_STRING, LIST_NUMBER: HAS_ANY, HAS_ALL, HAS_NONE IN and NOT_IN test whether the fact's value is in the array. HAS_ANY, HAS_ALL and HAS_NONE match when the fact's list holds at least one, all, or none of the array's values. The array holds values of the fact's type, or for a list fact, of its element type. Example: { "type": "SINGLE", "field": "userTags", "operator": "HAS_ANY", "value": ["VIP","GOLD"], "valueType": "LIST_STRING" }

Actions: [{ type, parameters }]

• MUTATE_FACT: { targetVar, operator: "ASSIGN"|"ADD"|"SUB"|"MUL"|"DIV", method: "PERCENTAGE"|"AMOUNT", operand: number, refVar?, rounding? } Reads and writes targetVar. The request must send it (P-015 otherwise), and it must hold a number when the action runs. operand may be negative, and a percent may be over 100. AMOUNT PERCENTAGE (base = refVar, or targetVar when omitted) ASSIGN targetVar = operand targetVar = base × operand/100 ADD targetVar += operand targetVar += base × operand/100 SUB targetVar -= operand targetVar -= base × operand/100 MUL targetVar *= operand targetVar *= (operand/100 + 1) DIV targetVar /= operand invalid refVar is allowed only with PERCENTAGE and ASSIGN, ADD or SUB. DIV with AMOUNT needs a nonzero operand. rounding: { scale: integer (0..34), mode?: "UP"|"DOWN"|"CEILING"|"FLOOR"|"HALF_UP"|"HALF_DOWN"|"HALF_EVEN" }. mode defaults to HALF_UP. Without rounding, the result keeps full precision.

• SET_FACT: { targetVar, value: string|number|boolean }. The request does not have to send targetVar.

• BLOCK: { reason? } sets isBlocked to true and blockReason to the reason, or "Policy Violation" without one. It does not stop later actions or rules; the caller enforces the block. Only BLOCK writes these two keys: a SET_FACT or MUTATE_FACT targeting either is rejected (ACT-033).

Every condition is checked against the input facts before any action runs, so a condition never sees a value an action writes in the same request. The winning rules' actions then run in priority order, each on the values the actions before it left.

Delete a rule from a DRAFT version.

Get full rule detail including condition tree and action definitions.

List all rules in a version (priority ASC). Returns summary with conditionSummary and actionSummary.

Reorder rules by specifying rule IDs in desired order. Priorities are assigned 1...N (1-based, continuous); array index 0 = priority 1 (highest precedence).

Enable or disable a rule without deleting it.

Update an existing rule in a DRAFT version. Only provided fields are changed. A new condition tree must stay within 25 conditions (SINGLE nodes) and 10 levels of nesting below the root. Saving re-checks every action in the rule, including ones you did not change, and fails with ACT-032 if any action's targetVar is not a registered fact.

Cancel a running or pending simulation.

Export simulation results as JSON or CSV. Returns the raw data. An export longer than 100,000 characters is refused.

List simulation history with optional filters.

Start an Impact Simulation against historical, uploaded, or inline data.

Every record a simulation processes counts toward the plan's simulation usage, including records processed before a cancel. When the plan's limit is reached, a new simulation cannot start.

dataset.type and dataset.source are BOTH required, and must be paired: HISTORICAL → source EXECUTION_LOGS, with dataset.from / dataset.to (yyyy-MM-dd, whole days in the organization time zone, both inclusive) UPLOADED → source UPLOADED_FILE, with dataset.path (the path returned by lexq_dataset_upload) MANUAL → source REQUEST_BODY, with dataset.manualData (array of fact records)

options.maxRecords: number (max 100000). When omitted, HISTORICAL and UPLOADED run at most 1000 records and MANUAL runs every record sent. options.baselinePolicyVersionId: uuid (optional, for baseline comparison) options.includeRuleStats: boolean options.metricConfig: optional — omit for plain execution count. To aggregate a fact, pass { "targetVariable": "", "aggregationType": "COUNT" | "SUM" | "AVG" }

Example (uploaded dataset): { "policyVersionId": "", "dataset": { "type": "UPLOADED", "source": "UPLOADED_FILE", "path": "" }, "options": { "baselinePolicyVersionId": "", "includeRuleStats": true, "maxRecords": 10000 } }

Example (historical): { "policyVersionId": "", "dataset": { "type": "HISTORICAL", "source": "EXECUTION_LOGS", "from": "2026-01-01", "to": "2026-01-31" }, "options": { "baselinePolicyVersionId": "", "includeRuleStats": true } }

Get simulation status and results. Poll until status is COMPLETED or FAILED.

Clone an existing version to create a new DRAFT. Useful when the source version is already published. The new DRAFT counts toward the limit of 20 DRAFT versions per group, and a source with more than 100 rules cannot be cloned.

Create a new DRAFT version in a policy group. Optionally provide a commit message and effective date range. A group can hold at most 20 DRAFT versions at a time; published versions do not count. Publish or delete drafts to make room.

Delete a DRAFT, ACTIVE, or EXPIRED version. A version that is live, in an A/B test (P-017), or targeted by a pending scheduled deployment (P-043) cannot be deleted. A version that has been executed is kept as ARCHIVED instead of removed: it no longer appears in lexq_versions_list and cannot be deployed, executed, simulated, replayed, cloned, or used in a dry run (P-008). Deleting it again does nothing.

Get a single version by ID, including its rules and fact requirements.

List all versions of a policy group.

Update a DRAFT version. Only DRAFT versions can be modified. Omitted fields keep their current values. To remove an end of the effective window, set clearEffectiveFrom or clearEffectiveTo to true instead of sending a value.

Delete a webhook subscription by ID.

Get webhook subscription detail by ID.

List platform event webhook subscriptions. These receive deployment lifecycle notifications: publish, deploy, rollback, and undeploy, plus a deployment being scheduled or a schedule being canceled.

Create or update a webhook subscription. Omit id to create, provide id to update. Events: VERSION_PUBLISHED, DEPLOYED, ROLLED_BACK, UNDEPLOYED, DEPLOY_SCHEDULED, DEPLOY_SCHEDULE_CANCELED. Formats: GENERIC (full JSON), SLACK ({"text": "..."}).

Send a test event to verify webhook connectivity. Returns the HTTP status code and success/failure message.

Show current authentication info (tenant ID, user ID, role) and tenantTimezone, the organization time zone that every yyyy-MM-dd date filter uses. Work out "today" or "yesterday" in that zone, not in UTC.