Evaluate Datalog-style derived facts for policy history and tool-call reasoning

[bglusman]

Context

Wardwright will accumulate structured facts from requests, routes, stream policy, tool context, receipts, state transitions, and history/cache events. Some facts live in ETS for recent runtime decisions; the same or richer event stream may also be persisted into sinks for longer-range analysis.

Open question: should Wardwright build composable Datalog-style queries over these facts and expose the derived conclusions as higher-level policy tools or policy predicates?

This is not a request to add dynamic user-authored Datalog at runtime. The first question is whether Wardwright-authored, bounded logical queries over known schemas would be more expressive, intuitive, or performant than explicit bespoke checks.

Hypothesis

Datalog-style derived facts could be useful for narrow policy reasoning where individual datum checks become brittle. Examples might include:

• detecting unsafe tool sequences across a session window;
• classifying repeated equivalent tool calls by tool name, argument hash, result hash, phase, and state;
• deriving whether a session is in an approval-sensitive state based on recent transitions and unresolved alerts;
• detecting that a model route changed after a specific policy trigger;
• summarizing whether a request path satisfied required guard conditions before an irreversible tool call;
• comparing recent ETS state with longer-term sink-backed history when a rule asks for broader context.

The result could be exposed as read-only derived predicates/tools such as unsafe_tool_sequence?, unresolved_approval?, or recent_policy_loop?, rather than asking every policy rule to inspect raw events directly.

Skeptical framing

This may be unnecessary complexity. Explicit Elixir/Gleam predicates over typed event structs may be easier to test, profile, and explain than introducing a logic query layer. Datalog only earns its keep if it reduces duplicated policy logic, improves explanation/simulation, or makes cross-event reasoning meaningfully clearer.

Prolog-style general logic programming is probably too broad for the initial product. Datalog is the more plausible candidate because it can be bounded, query-oriented, and easier to reason about over finite event facts.

Current likely fact families

Known schema areas to inspect before any spike:

• request/caller/session/tenant identifiers
• route decisions and synthetic model selection
• policy actions, rule matches, conflicts, retries, stop/rewrite outcomes
• stream trace events and TTSR-style triggers
• tool context: lifecycle phase, namespace/name, risk class, argument hash, result hash, status, visibility/source
• state-machine transitions and current scoped policy state
• receipts, alert status, and event sink metadata
• policy-cache/history events currently available through ETS or configured sinks

The schema may need small additions if derived queries need stable event ordering, causal links, run/session boundaries, or explicit source/visibility metadata.

Questions to answer

• Which useful derived predicates can be expressed over the current schema without adding new data?
• What schema gaps prevent useful logic queries?
• Are the same predicates simpler as plain typed Elixir/Gleam functions?
• Would Datalog improve simulation and UI explanation enough to justify the extra layer?
• Can derived facts be computed from both ETS windows and sink-backed historical data with identical semantics?
• How do we bound query cost, ordering semantics, and session/run scoping?
• Should results be exposed to policy only, to model-facing tools, or to both?

Possible first spike

Pick 3 to 5 concrete derived predicates around tool and policy history, then implement them twice in a throwaway branch:

1. typed Elixir/Gleam functions over normalized facts;
2. a Datalog-style representation using an evaluated library or small internal query interpreter.

Compare expressiveness, explainability, testability, and performance over realistic ETS-sized windows and fixture sink histories. Do not expose user-authored Datalog until the internal version proves useful.

Falsification criteria

Do not proceed if:

• the derived predicates are clearer as ordinary typed functions;
• query cost or ordering semantics are hard to bound;
• authors cannot understand the derived facts in the UI;
• the layer encourages hidden policy authority that receipts/simulation cannot explain;
• current schema lacks enough stable facts to make meaningful deductions.