Writing a rule takes minutes. Enforcing it is the delicate part
If any path in your application sends the query the rule forbids, the proxy rejects it in production. A deterministic engine always gives the same verdict, but that does not make it infallible: before you enforce, the simulator answers what of your own traffic the change would have blocked.
How it works
- A candidate change combines up to 20 items: new or edited custom rules, disabled custom rules, and standard rules enabled, disabled or with another severity.
- The queries recorded by the TCP proxy and the runtime API are grouped into flows: the text with its literals replaced.
- Each statement is evaluated with today's engine, with your current rules and with the candidates. The difference is the effect of your change; drift from a new engine version is reported separately.
- Nothing runs against your database, nothing is blocked and nothing is written to the query history or your quota.
The report
A verdict (PASS, WARN, FAIL or INCONCLUSIVE), a sentence ready to paste into the PR and every affected flow, with its executions, identities and samples with the literals replaced. A flow is legitimate when all its executions passed, it ran at least 3 times on at least 2 days and it comes mostly from your application's identities.
From the dashboard or from CI
In the custom rule editor, "Simulate against production" simulates the rule you are writing, without saving it. From CI, an API key with the rules:simulate scope starts the simulation and the job fails when the verdict is FAIL.
curl -s -X POST https://api.vericto.com/api/v1/ci/rules/simulate \
-H "X-API-Key: $VERICTO_SIM_KEY" \
-H "Content-Type: application/json" \
-d '{ "days": 30, "candidates": [ ... ], "thresholds": { "fail_on_break": 0 } }'Up to 30 days of history on Builder, 90 on Team and per contract (up to 180) on Enterprise, never beyond your plan's retention. One simulation at a time per workspace: up to 10 a day on Builder and 30 on Team and Enterprise.