Thanks for the PR @aprakhar!

I think this change as-is would be a breaking change at the type level. Specifically, DynamicFactCallback changes its params parameter from Record<string, any> to Record<string, any> | Record<string, any>[]. That means anyone implementing a dynamic fact callback today would get a type error — their existing (params: Record<string, any>, almanac) => ... signatures would no longer satisfy the widened union without narrowing it first.

Similarly, consumers reading ConditionProperties.params from rule results who have typed their code assuming it's always a record would also break.

Widening input types (like ConditionProperties.params when constructing rules) is fine, but widening callback parameters and output types is a breaking change since it forces consumers to handle a new case.

One option would be to scope this to just the input positions (e.g. where users are defining conditions/events) while keeping the callback and result types unchanged. Alternatively this could be something we pick up in the next major version.