Fathom

Fathom sits at the decision boundary — every agent action is evaluated before execution. Tool calls, data requests, agent handoffs — all of it passes through the rule engine first. This is an expert system, not a policy engine. The distinction matters: policy engines evaluate isolated requests against static rules. Fathom reasons about accumulated state, which means the decision on request number four can depend on what happened in requests one through three.

The architecture is built on five primitives: templates, facts, rules, modules, and functions. You author rules in YAML. Fathom compiles them down to CLIPS, the expert system shell that has been running in aerospace and defense environments for over thirty years. A single rule evaluates in under 100 microseconds. A hundred rules against a populated working memory still comes in under 500 microseconds. The Python API wraps all of this — fathom.load() takes a rule file, returns an engine, and engine.evaluate() takes a fact dict and returns a decision with a full reasoning trace.

That persistent working memory is what separates Fathom from tools like OPA or Cedar. Those are stateless by design — every evaluation is independent. Fathom accumulates facts across evaluations within a session, so you can write rules like “if this agent has accessed three classified data sources in the last ten minutes, deny further requests and flag for review.” That pattern is a single rule in Fathom. In a stateless engine, it is a custom integration with an external state store that you have to build, maintain, and trust.

Fathom is open source under MIT. It ships as a standalone Python library for direct integration, or composes with Nautilus for data-broker-level enforcement and Railyard for pipeline-stage gating. The compliance rule packs are maintained separately and versioned against the frameworks they implement.