What sorts of introspection did you have in mind? If you mean introspection on what the rules engine did and why, there's a good amount of that, you can take a look at the inspect namespace and if you wanted something lower level the tracing namespace. If you mean introspection on the rules network, possibly yes if you write things yourself, but since the rules can contain arbitrary code (that the user writes) you have the usual problems with inspecting arbitrary code.

Regarding dynamic modification, if you want to change the rules you have to build a new session and rerun the rules.

no, not in that respect. I'm interested in reading the rules to see what data they are looking for, fetched, and put into working member before running. For DB/REST calls.

Basically, its an optimization so multiple calls aren't made while rules run, can do them all up front with single calls.

The second part, probably thinking about the wrong way, but for parts of the rules that have variables, I'd kind of like to see the rules served up with the variables replaced with actual values, so that it's easier to understand for user (developer). Basically I'll be serving up the rules from a server, and the server will also know what some of the vars should be in the rules, if server could basically inject that info, my thinking it's easier than having to reason about than having to look-up the values by hand. These variables change infrequently. Maybe server could inject them not necessarily inline so at least easy to see in one place. Hope that makes sense.

@UH13Y2FSA The way to model what you are saying in the “second part” above, would be to make your variables expressed as facts instead.

That’s the typical way it’d be done and the most straightforward with the way the forward-chaining data flow of the rules engine works.

> if server could basically inject that info The “injection” would be to just insert these facts.

You base logic on them. If you need to derive things from them for other rules - derive “intermediate facts”, ie facts meant to just build up higher-level concepts to relay to other rules.

Remember, the working memory “session” state is immutable. So if you don’t want to continually put in these infrequently changed facts, you could potentially create a session, insert these facts only, then use that as your base session for other later independent memory states with the more frequently changing facts.

This will work and is probably easiest, but if you really want to have the values be determined statically note that Clara can build sessions from rule data structures that you pass it; rules/queries don't have to be created with the defrule/defquery macros. So you can have arbitrary generation logic. You can look at the schemas namespace and the data under rule/query vars for examples. It might be best to become familiar with code generation e.g. macros in Clojure if you go down this route though.