LexQ — the Decision Operations Platform for engineering teams

- MCP server for complete rule lifecycle management
- Visual rule builder with conflict resolution
- Dry Run: test rules with single inputs before publishing
- Impact Simulation: replay thousands of records against new rule versions
- A/B testing: split live traffic between rule versions
- Git-style versioning with instant rollback
- Webhook and notification integrations

- lexq_whoami: Show current authentication info (tenant ID, user ID, role).
- lexq_groups_list: List all policy groups (tenant-wide, priority ASC).
- lexq_groups_get: Get a single policy group by ID.
- lexq_groups_create: 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. Groups sharing an activationGroup must share the same activationMode / activationStrategy / executionLimit.
- lexq_groups_update: Update a policy group. Only provided fields are updated; omitted fields remain unchanged.
- lexq_groups_delete: Archive a policy group. Only non-live groups can be deleted. This is irreversible.
- lexq_groups_reorder: 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.
- lexq_ab_test_start: Start an A/B test on a policy group. Requires a challenger version ID and traffic rate.
- lexq_ab_test_stop: Stop a running A/B test. All traffic is restored to the control (current) version.
- lexq_ab_test_adjust: Adjust traffic rate of a running A/B test.
- lexq_versions_list: List all versions of a policy group.
- lexq_versions_get: Get a single version by ID, including its rules and fact requirements.
- lexq_versions_create: Create a new DRAFT version in a policy group. Optionally provide a commit message and effective date range.
- lexq_versions_update: Update a DRAFT version. Only DRAFT versions can be modified. Only provided fields are changed.
- lexq_versions_delete: Delete a DRAFT version. Only DRAFT versions can be deleted.
- lexq_versions_clone: Clone an existing version to create a new DRAFT. Useful when the source version is already published.
- lexq_rules_list: List all rules in a version (priority ASC). Returns summary with conditionSummary and actionSummary.
- lexq_rules_get: Get full rule detail including condition tree and action definitions.
- lexq_rules_create: Create a rule in a DRAFT version. Requires name, condition tree, and actions array. priority is auto-assigned (appended last); use lexq_rules_reorder to change order.

Before creating rules with new fact keys, call lexq_facts_list to check existing facts.
If a required key is missing, ask the user to confirm the type, isRequired, and description
before calling lexq_facts_create — registering facts enables type validation, Console UI
autocomplete, and the dry-run requirements analyzer.

After saving, lexq_facts_unregistered lists any keys this version references but has not
defined (non-blocking, version-wide) — use it to decide what to register.

Condition: { type: "SINGLE", field, operator, value, valueType } or { type: "GROUP", operator: "AND"|"OR", children: [...] }
Value types: STRING, NUMBER, BOOLEAN, LIST_STRING, LIST_NUMBER

Operators are constrained by the LEFT fact's type (from lexq_facts_list). Using one outside
its type is rejected by the server — check the fact type before choosing an operator.
- STRING fact: EQUALS, NOT_EQUALS, CONTAINS, IN, NOT_IN
- NUMBER fact: EQUALS, NOT_EQUALS, GREATER_THAN, GREATER_THAN_OR_EQUAL, LESS_THAN, LESS_THAN_OR_EQUAL, IN, NOT_IN
- BOOLEAN fact: EQUALS, NOT_EQUALS
- LIST_ fact: HAS_ANY, HAS_ALL, HAS_NONE (only these)

HAS_ query list-typed facts. Value is always an array whose element type matches the fact:
- HAS_ANY: fact has at least one of the given values
- HAS_ALL: fact has all of the given values
- HAS_NONE: fact has none of the given values
Example: { "type": "SINGLE", "field": "user_tags", "operator": "HAS_ANY", "value": ["VIP","GOLD"], "valueType": "LIST_STRING" }

Do NOT use CONTAINS on a list fact — CONTAINS is substring match on STRING facts only.
IN is the mirror of HAS_: IN takes a scalar fact with a list value; HAS_ takes lists on both sides.

Actions: [{ type, parameters }]

Action parameter schemas:
- MUTATE_FACT: { targetVar: string, operator: "ASSIGN"|"ADD"|"SUB"|"MUL"|"DIV", method: "PERCENTAGE"|"AMOUNT", operand: number, refVar?: string, rounding?: RoundingOption }
targetVar is the fact this action reads and writes. It must exist in facts at execution
time as a number — supplied as an input fact or written by a prior action in this rule.
A missing required fact throws (no 0 default).
operand is the arithmetic operand; the unit is dictated by method (percent when
PERCENTAGE, absolute amount when AMOUNT). Ranges are not constrained — negative values
and >100 percentages are valid (refunds, surcharges).
refVar is the base for percentage calculation and is OPTIONAL — omit it to use targetVar
itself. It is only meaningful in PERCENTAGE × {ASSIGN, ADD, SUB}; specifying it in any
other cell is an error. Use it when the base differs from the target, e.g.
"points += order_total × 5%" → { targetVar: "points", refVar: "order_total",
operator: "ADD", method: "PERCENTAGE", operand: 5 }.
operator × method matrix:
ASSIGN targetVar = operand | targetVar = refVar × operand/100
ADD targetVar += operand | targetVar += refVar × operand/100
SUB targetVar -= operand | targetVar -= refVar × operand/100
MUL targetVar = operand | targetVar = (operand/100 + 1)
DIV targetVar /= operand | invalid
Constraints: DIV + PERCENTAGE is invalid (use MUL with the inverse). DIV + AMOUNT
requires operand !== 0.
- SET_FACT: { targetVar: string, value: string|number|boolean } Creates the fact if absent
— this is the only action that does. MUTATE_FACT requires the target to already exist.
- BLOCK: { reason: string } Records a rejection decision. It does NOT halt rule execution —
subsequent actions and subsequent winning rules still run. Enforcement is the caller's
responsibility; the decision surfaces as the is_blocked fact.

RoundingOption (optional, MUTATE_FACT only): { scale: integer (0..34), mode?: "HALF_UP"|"HALF_DOWN"|"HALF_EVEN"|"FLOOR"|"C…
- lexq_rules_update: Update an existing rule in a DRAFT version. Only provided fields are changed.
- lexq_rules_delete: Delete a rule from a DRAFT version.
- lexq_rules_reorder: Reorder rules by specifying rule IDs in desired order. Priorities are assigned 1...N (1-based, continuous); array index 0 = priority 1 (highest precedence).
- lexq_rules_toggle: Enable or disable a rule without deleting it.
- lexq_facts_list: List all fact definitions (input variable schema). Shows key, type, required, and PII status. Always check this before creating rules.
- lexq_facts_create: Register a new input variable. Key must be lowercase with underscores (e.g. payment_amount). Types: STRING, NUMBER, BOOLEAN, LIST_STRING, LIST_NUMBER.
- lexq_facts_update: Update a fact definition. Key and type cannot be changed. Only provided fields are updated. System facts only allow name, description, and PII changes.
- lexq_facts_delete: Delete a fact definition. System facts cannot be deleted.
- lexq_facts_action_metadata: 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. Facts are supplied as input or written by a prior action in the same rule; only SET_FACT creates a fact from nothing. Static data, safe to cache in-session.
- lexq_facts_unregistered: List facts referenced by a version's rules but not yet defined (read-only — does not block publish/deploy, INV-4). Version-wide: covers every rule in the version. Each entry carries the inferred type, suggested name, and where it is referenced (condition/action). Register them with lexq_facts_create to enable type validation and the dry-run requirements analyzer.
- lexq_deploy_publish: Publish a DRAFT version (DRAFT → ACTIVE). Locks the version from further edits. Must have at least one rule. Undefined facts referenced by rules do not block publishing (INV-4); call lexq_facts_unregistered first to review them.
- lexq_deploy_live: 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. Undefined facts do not block deployment (INV-4); use lexq_facts_unregistered to review what the version references but has not defined.
- lexq_deploy_rollback: Rollback to the previous deployed version. Only available if there is a previous version.
- lexq_deploy_undeploy: Remove the live version from traffic. The version stays ACTIVE but no longer serves requests.
- lexq_deploy_schedule: Schedule an ACTIVE version with a future effective start date to auto-deploy at that time (Scheduled Deployment). One pending schedule per group; manual deploy/rollback/undeploy, starting an A/B test, or archiving the group cancels it. The snapshot hash is sealed at scheduling and re-verified at execution (fail-closed).
- lexq_deploy_unschedule: Cancel the pending scheduled deployment for a group. The version itself is not affected. Fails with P-039 if no pending schedule exists.
- lexq_deploy_schedules: List scheduled deployments across all groups (all statuses: PENDING, EXECUTED, CANCELED, FAILED), newest first.
- lexq_deploy_history: List deployment history across all groups.
- lexq_deploy_detail: Get detailed info about a specific deployment including snapshot hash and integrity check.
- lexq_deploy_overview: Show current deployment status of all groups — which version is live, last deployment type, and deployer.
- lexq_deploy_deployable: List ACTIVE (published) versions that can be deployed for a group. Use this to find which versions are available before calling deploy live.
- lexq_deploy_diff: Compare rule snapshots between two versions. Shows added, removed, and modified rules. Useful for reviewing changes before deploying a new version.
- lexq_dry_run: Execute a single dry run against a version. Tests how rules evaluate given input facts without side effects.

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

Example input: { "facts": { "payment_amount": 100000, "customer_tier": "VIP" } }
Always dry-run before publishing to validate rule behavior.
- lexq_dry_run_compare: Compare dry run results between two versions using the same input facts. Useful for validating changes.

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
- lexq_requirements: Analyze which input facts a version requires. Returns required keys, types, and an example request body.
- lexq_simulation_start: Start an Impact Simulation against historical, uploaded, or inline data.

dataset.type and dataset.source are BOTH required, and must be paired:
HISTORICAL → source EXECUTION_LOGS, with dataset.from / dataset.to (yyyy-MM-dd)
UPLOADED → source S3_BUCKET, 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, default 10000)
options.baselinePolicyVersionId: uuid (optional, for baseline comparison)
options.includeRuleStats: boolean
options.metricConfig: optional — omit for plain execution count. To aggregate a fact, pass
{ "targetVariable": "<fact>", "aggregationType": "COUNT" | "SUM" | "AVG" }

Example (uploaded dataset):
{
"policyVersionId": "<uuid>",
"dataset": { "type": "UPLOADED", "source": "S3_BUCKET", "path": "<path from lexq_dataset_upload>" },
"options": { "baselinePolicyVersionId": "<uuid>", "includeRuleStats": true, "maxRecords": 10000 }
}

Example (historical):
{
"policyVersionId": "<uuid>",
"dataset": { "type": "HISTORICAL", "source": "EXECUTION_LOGS", "from": "2026-01-01", "to": "2026-01-31" },
"options": { "baselinePolicyVersionId": "<uuid>", "includeRuleStats": true }
}
- lexq_simulation_status: Get simulation status and results. Poll until status is COMPLETED or FAILED.
- lexq_simulation_list: List simulation history with optional filters.
- lexq_simulation_cancel: Cancel a running or pending simulation.
- lexq_simulation_export: Export simulation results as JSON or CSV. Returns the raw data.
- lexq_dataset_upload: Upload inline CSV or JSON content as a simulation dataset.
The content is uploaded to S3 and a path is returned in the "path" field.

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

CSV example:
user_id,payment_amount
user_001,150000
user_002,50000

JSON example: [{"user_id":"user_001","payment_amount":150000}, {"user_id":"user_002","payment_amount":50000}]
- lexq_dataset_template: 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.
- lexq_profile_overview: Per-rule latency profile of a policy group over a time window: group TOTAL distribution split by cache state (HIT = compiled ruleset cache hit, MISS = deep-load + compile), 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 deterministic 1% sample of calls; TOTAL is recorded for every call. Defaults: last 24h, live version, cacheState HIT.
- lexq_profile_rule: 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.
- lexq_replay_decision: 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 and free of charge (TPS throttle only). A replay sends no webhook, notification, or event: rule actions produce no outward effects.
- lexq_replay_start: 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.
- 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.
- lexq_replay_list: List window replay job history (reverse-chronological). Lightweight items — use lexq_replay_status for summary and changed samples.
- lexq_replay_cancel: Cooperatively cancel a PENDING or RUNNING window replay job. Other states are rejected. VIEWER role cannot cancel.
- lexq_history_list: List policy execution history. Shows trace ID, group, version, status, match result, and latency.
- lexq_history_get: Get full execution detail including inputFacts, mutatedFacts, generatedVariables, executionTraces, and decisionTraces.
- lexq_history_stats: Get execution KPIs: total executions, success/failure counts, success rate, and average latency.
- lexq_provenance_get: 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.
- lexq_pii_reveals_list: 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.
- lexq_logs_list: List system failure logs from background tasks (platform event webhooks, scheduled deployments).
- lexq_logs_get: Get failure log detail by ID.
- lexq_logs_action: Process a single failure log: RESOLVE (mark as manually fixed) or IGNORE (skip intentionally).
- lexq_logs_bulk_action: Process multiple failure logs at once. Provide an array of log IDs and the action.
- lexq_domain_templates_list: List all domain templates. A domain template is a curated, industry-specific starter pack of fact definitions and sample rules (e.g. ECOMMERCE). Each entry reports its key, status (ACTIVE or COMING_SOON), and a summary of what it provisions. Call this before preview or apply to discover which templates can currently be applied.
- lexq_domain_templates_preview: Preview exactly what a domain template will provision before applying it: the fact definitions it registers, the sample rules it creates, and an apply plan. This is a read-only dry run — nothing is created. Only ACTIVE templates can be previewed.
- lexq_domain_templates_apply: 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. Existing facts are skipped — apply is additive and never overwrites existing schema. Run lexq_domain_templates_preview first to review what will be created. Only ACTIVE templates can be applied.
- lexq_webhook_subscriptions_list: List platform event webhook subscriptions. These receive deployment lifecycle notifications (publish, deploy, rollback, undeploy).
- lexq_webhook_subscriptions_get: Get webhook subscription detail by ID.
- lexq_webhook_subscriptions_save: Create or update a webhook subscription. Omit id to create, provide id to update. Events: VERSION_PUBLISHED, DEPLOYED, ROLLED_BACK, UNDEPLOYED. Formats: GENERIC (full JSON), SLACK ({"text": "..."}).
- lexq_webhook_subscriptions_delete: Delete a webhook subscription by ID.
- lexq_webhook_subscriptions_test: Send a test event to verify webhook connectivity. Returns the HTTP status code and success/failure message.