LexQ — the Decision Operations Platform for engineering teams

Show current authentication info (tenant ID, user ID, role).

List all policy groups (tenant-wide, priority ASC).

Get a single policy group by ID.

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.

Update a policy group. Only provided fields are updated; omitted fields remain unchanged.

Archive a policy group. Only non-live groups can be deleted. This is irreversible.

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.

Start an A/B test on a policy group. Requires a challenger version ID and traffic rate.

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

Adjust traffic rate of a running A/B test.

List all versions of a policy group.

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

Create a new DRAFT version in a policy group. Optionally provide a commit message and effective date range.

Update a DRAFT version. Only DRAFT versions can be modified. Only provided fields are changed.

Delete a DRAFT version. Only DRAFT versions can be deleted.

Clone an existing version to create a new DRAFT. Useful when the source version is already published.

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

Get full rule detail including condition tree and action definitions.

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…

Update an existing rule in a DRAFT version. Only provided fields are changed.

Delete a rule from a DRAFT version.

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.

List all fact definitions (input variable schema). Shows key, type, required, and PII status. Always check this before creating rules.

Register a new input variable. Key must be lowercase with underscores (e.g. payment_amount). Types: STRING, NUMBER, BOOLEAN, LIST_STRING, LIST_NUMBER.

Update a fact definition. Key and type cannot be changed. Only provided fields are updated. System facts only allow name, description, and PII changes.

Delete a fact definition. System facts cannot be deleted.

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.

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.

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.

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.

Rollback to the previous deployed version. Only available if there is a previous version.

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

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).

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

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

List deployment history across all groups.

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

Show current deployment status of all groups — which version is live, last deployment type, and deployer.

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

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

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.

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

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

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 } }

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

List simulation history with optional filters.

Cancel a running or pending simulation.

Export simulation results as JSON or CSV. Returns the raw data.

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}]

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.

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.

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.

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.

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.

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

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

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

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

Get execution KPIs: total executions, success/failure counts, success rate, and average latency.

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.

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.

List system failure logs from background tasks (platform event webhooks, scheduled deployments).

Get failure log detail by ID.

Process a single failure log: RESOLVE (mark as manually fixed) or IGNORE (skip intentionally).

Process multiple failure logs at once. Provide an array of log IDs and the action.

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.

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.

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.

List platform event webhook subscriptions. These receive deployment lifecycle notifications (publish, deploy, rollback, undeploy).

Get webhook subscription detail by ID.

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": "..."}).

Delete a webhook subscription by ID.

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