Evaluation scheduling
Judging rules in the right order
Evaluation scheduling decides the order in which Parlant judges your rules on a turn. Most rules can be judged at once. Two kinds cannot: a rule that depends on another rule, and a rule whose condition refers to your other policies. Parlant holds those back until the evidence they need has arrived, and judges them in a second pass.
- Why some rules must wait for other verdicts before being judged
- How dependent rules are ordered, and how resolution enforces them
- How rules that refer to other policies are handled
- Why a dependency adds a little latency, and when to introduce one
Most turns judge every candidate rule in one pass, with discovery and the model verdicts running at the same time. But two kinds of rule cannot be judged correctly until other judgments have landed, so Parlant schedules them into a second pass.
The first kind is a rule with a dependency. If rule A depends on rule B, judging A before B's verdict is in either wastes A's call or judges it on incomplete premises. So Parlant waits for B's verdict, and then judges A with that state in its prompt.
Note that scheduling only orders the evaluations. Resolution is what enforces the dependency. A dependent rule survives only if its prerequisite matched this turn or earlier in the session, which Parlant records in a ledger of every rule that ever matched. Once the prerequisite has matched, the dependent rule stays available for the rest of the session.
Discovery alone never satisfies a dependency. Discovery is deliberately generous, and its false positives must not unlock gated rules.
The second kind is a rule whose condition refers to your other policies, for example "anything not covered by another policy". Such a rule cannot be judged in isolation, and Parlant flags it at startup.
If such a rule has nothing attached to it, Parlant renders it and leaves it to the model's judgment. If it does have attachments, it waits for discovery to report, so that the set of policies it is judged against is complete.
The scheduling is bounded and fails open: at most two passes, phasing engaged only when there are enough candidates to be worth it, and any failure falls back to judging everything in one pass rather than dropping a rule.
This is also why a dependency costs a little latency on the turns where it applies, and why we recommend introducing a dependency hierarchy once a catalog reaches a few dozen policies, not before. Scaling complexity covers that structure.