The def itself isn’t special, its just handed off to the mk-session call. Unless I am miss interpreting your question

@matthew.pettis I think I don’t know exactly what you are asking either, but perhaps you are just trying to understand what the ancestors fn does?

it takes a type, and returns a set of ancestors

And in rules, a type T matches any rule type that is the same type T or any ancestor in the set of ancestors of T - as returned from ancestors fn

the docs http://www.clara-rules.org/docs/fact_type_customization/ here seem to explain this with an example though - so not sure this is where you the confusion is

> I get that a map can work in the function position, and will look up the value for a key given as argument, but I am struggling to see how this def works as a function to look up ancestors. A map is a fn of 1 argument. It looks no different from the callers perspective. So the clara-rules engine has a fact with type T, it looks up ancestors like: (ancestors-fn T) which returns the ancestor types

in pure clj with the above example:

(let [ancestors-fn {:precise-temperature-reading #{:temperature-reading}}]
  (ancestors-fn :precise-temperature-reading))
;;= #{:temperature-reading}}

@mikerod Thanks, I think that what you said is enough for me. The missing thing for me, which I understand from your code snipped, is that it interacts with the fact-type-function. That is, it seems that first the fact-type-function is used to get a value, and then that value (like :precise-temperature-reading), and then that is the argument to the ancestor-fn, which returns a set of ancestors that the argument belongs to, and then rules that use any of those ancestors are considered. I was trying to figure out how that ancestor-fn could be applied directly to the the fact, instead of the result of the fact-type-function applied to the fact.

So, in short, I was missing that ancestor-fn operated on the result of fact-type-fn, not on the original fact itself, which I couldn't see how that would work.

yes exactly!