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
Publishing is never blocked by facts a rule references but the schema does not define. If the version has unregistered facts, the publish proceeds and they are surfaced as a warning — run
lexq facts unregistered for the version to review them first.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
If something goes wrong after deployment: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.
One 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.