Deployment Lifecycle
Deployment is the process of routing live traffic to a published policy version. LexQ tracks every deployment action for a complete audit trail.Deployment Actions
Step-by-Step Deployment
1. Validate with Dry Run
Before publishing, always test your rules:2. Publish
Facts a rule only reads never block publishing, even when the schema does not define them. The publish proceeds and they are surfaced as a warning; run
lexq facts unregistered for the version to review them first. An action target is the exception: if a rule’s SET_FACT or MUTATE_FACT writes to a key that is not a registered fact, the publish fails with ACT-032.3. Deploy to Production
effectiveFrom is still in the future, an immediate deploy is rejected (P-037). Schedule it instead — the system deploys it automatically when the effective window opens:
4. Monitor
Rollback
A rollback restores the version that was live before the current deployment. It picks that version from the deployment that is current when the request arrives, so read the group first and pass what you read:lexq deploy overview carries the same fields for every group.
With both options passed, if anyone deployed, rolled back, or undeployed after you read the group, 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 decide whether to roll back.
Each option is checked only when you pass it. With neither, the rollback restores whatever the current deployment replaced at that moment, even if someone deployed after you looked.
The lexq_deploy_rollback MCP tool requires both values. The console’s rollback dialog shows the version it restores and sends both values itself.
Undeploy
To stop all traffic processing for a group:Scheduled Deployment
A Scheduled Deployment arms an ACTIVE version whoseeffectiveFrom is in the future. When that time arrives, the system deploys it automatically — within one scheduler tick (≤60s) — and records the deployment in the ledger like any manual action, attributed to System with the schedule’s memo.
Scheduling is explicit: publishing a future-dated version does not arm it by itself. Create the schedule from the console deploy dialog, lexq deploy schedule, or the lexq_deploy_schedule MCP tool.
Integrity is sealed at scheduling. The rule snapshot hash is captured when the schedule is created and re-verified at execution. If the version changed, was deleted, or the hash no longer matches, the schedule fails closed — status FAILED with a reason — instead of deploying something you didn’t review.
1 pending schedule per group. A second schedule request is rejected until the pending one is canceled.
A pending schedule is canceled automatically when a conflicting serving intent is expressed:
Deleting the referenced version is rejected (
P-043) while a schedule is pending — cancel the schedule first.
Every schedule keeps its full trail — who scheduled it, when it executed or why it was canceled or failed:
Deployment History
Every deployment action is recorded with a timestamp, actor, memo, and the previous/new version:Next Steps
Dry Run
Pre-deployment validation for individual inputs.
Impact Simulation
Impact validation against historical data before deploying.