we also have an action per check. what happens if

  Rule.action = Action.AUDIT
  Check.action = Action.DENY 

?

For Rule.action = AUDIT, Check.action = DENY: the matched check's action wins, so the rule resolves to DENY. Then enforcement mode decides: ENFORCE blocks it, AUDIT downgrades it to log-only, DISABLED skips.

makes sense, thanks.
I would include this in a docstring as well

instead of a dataclass with a large bag of fields we should use hook-specific contexts as pydantic objects

  BeforeAgentContext
  AfterAgentContext
  BeforeModelContext
  ToolCallContext
  AfterToolContext

and create a union type for them. this will provide out-of-the-box model validation so one can t write stuff like:

  CheckContext(
      hook=LifecycleHook.TOOL_CALL,
      agent_output="some output",
      tool_name=""
  )

Splitting CheckContext into per hook Pydantic types plus a union touches multiple files: the models definition, every hook construction site in the evaluator, the places reading the context fields, and the context tests. Since it spans the stack, I'll track it in the parent PR and do it once these get merged.

CheckContext narrows most runtime payloads to str, but runtime inputs/outputs/tool results are often structured objects. should these be Any/dict/message types, or should serialization happen explicitly in the evaluator?

I'll pick this up together with the per-hook context split, since both touch the same CheckContext types and evaluator serialization. The fields are typed str today but the evaluator already stringifies, so I'll widen them to accept structured payloads and add explicit serialization in the evaluator as part of that refactor.

#129
created an issue for better tracking

we need to either delete this class now and update the uipath-core dependency once this PR gets merged, or at least leave a ToDo comment here and delete this class in a subsequent PR

Raising the uipath-core PR: UiPath/uipath-python#1727. I'll raise the runtime changes once the uipath-core changes are merged.

Deleted the class

this still leaves enforcement mode as process-global state in this PR, just behind _state instead of a global variable. shouldn t the resolved mode live under the evaluator instance?

Agreed, I'll move the resolved mode onto the evaluator instance in a follow up

#130
created an issue for better tracking