Pre-built Prolog rule modules for DataGrout logic cells. The npm of living software.
Insert a battery into a logic cell and it has new capabilities immediately — no schema setup, no migration, no boilerplate. Assert facts into the same namespace and the battery's predicates reason over them.
| Module | Predicates | Description |
|---|---|---|
| fsm | 25 | General-purpose finite state machine — reachability, shortest paths, cycle detection |
| temporal | 12 | Event ordering, overlap, gaps, and deadline reasoning over timestamped facts |
| taxonomy | 10 | Hierarchical classification with transitive membership and property inheritance |
Requires ProbLog. Query exact probabilities instead of thresholds — zero LLM calls per tick.
| Module | Predicates | Description |
|---|---|---|
| prob-loot | 4 | Drop probabilities and expected yields — layered on loot-tables |
| prob-detection | 4 | Guard perception and stealth probability from environment and alert state — requires combat |
| prob-economy | 5 | Market uncertainty: supply disruption and demand spike probabilities — requires economy |
| prob-npc | 5 | NPC trust and disposition probability from faction standing — requires npc-state and faction |
| Module | Predicates | Description |
|---|---|---|
| inventory | 7 | Item carrying, weight, slot constraints |
| loot-tables | 6 | Drop weights, rarity, condition-gated loot |
| quests | 6 | Prerequisite chains, objectives, turn-in |
| progression | 5 | XP curves, level gates, stat scaling, prestige |
| combat | 6 | Damage types, resistances, status effects, turn order |
| economy | 5 | Crafting costs, supply/demand pricing |
| npc-state | 5 | Affinity tracking, dialogue availability |
| puzzle-fsm | 5 | FSM transitions, win conditions, hints |
| world | 6 | Time of day, weather, season, moon phase |
| faction | 5 | Reputation scores, standing tiers, area access |
| dialogue | 5 | Context-aware lines, gated choices, memory |
| crafting | 5 | Recipe knowledge, skill requirements, discovery |
| permissions | 5 | Role-based access, inheritance, ownership |
| ai-director | 5 | Pacing states, spawn eligibility, difficulty scaling |
| dungeon | 5 | Room connectivity, key locks, clearance tracking |
| Module | Predicates | Description |
|---|---|---|
| lead-scoring | 5 | Weighted scoring, tier derivation, disqualification |
| invoice-rules | 5 | Overdue detection, late fees, escalation levels |
| approval-chains | 5 | Multi-step approvals, delegation, rejection tracking |
| inventory-mgmt | 5 | Stock levels, reorder triggers, supplier selection |
| pricing-rules | 5 | Tier pricing, discounts, bulk breaks, floor/ceiling |
| loyalty | 5 | Points balance, tier benefits, redemption costs |
| scheduling | 5 | Slot availability, conflicts, advance windows |
| compliance | 5 | Policy checks, retention windows, consent registry |
The batteries.* toolsuite lets agents search, install, and manage batteries directly from an LC session — no manual Prolog URL handling needed.
| Tool | Description |
|---|---|
batteries.search(query?, category?, tags?) |
Search by keyword, category, or tags — omit query to browse all |
batteries.install_many(ids[], namespace) |
Install one or more batteries into a namespace |
batteries.installed(namespace) |
List all batteries currently installed in a namespace |
batteries.remove(id, namespace) |
Retract a battery's rules from a namespace |
Installation state is tracked directly in the LC: attribute('_batteries', battery_id, version). This makes batteries.installed a plain lc.query call and keeps state co-located with the rules.
Tether is the Lua client for DataGrout. The dg object in module README examples is a Tether client instance.
dg:batteries().install("inventory", "my-namespace", function(result)
print(result.installed_count .. " batteries installed")
end){
"tool": "batteries.install_many",
"ids": ["inventory"],
"namespace": "my-namespace"
}A DataGrout logic cell is a persistent, queryable Prolog fact store — the reasoning substrate for your application or agent. You assert facts into it (logic.assert) and query them (logic.query). It's the brain.
Logic Batteries provides pre-built reasoning engines that run inside that brain. Each battery is a self-contained Prolog library that operates over facts you assert into the same namespace. Load the FSM battery and your LC becomes a finite state machine engine. Load the game batteries and it becomes your game's rules engine.
Batteries are designed to compose. A game using quests + inventory + loot-tables + npc-state has four batteries sharing a single fact namespace — quest completion triggers dialogue unlocks, loot items land in inventory, NPC disposition gates quest availability. The composition happens through Prolog unification over shared facts. No event bus. No integration code. Just facts and rules.
These aren't examples or recipes. They're programs you load into a living reasoning substrate.
Batteries must stay within the predicate whitelist provided by the LC runtime. Rules that call predicates outside this set — process execution, file I/O, networking, global mutable state, or runtime fact modification — are not permitted. This ensures batteries are safe to load in any environment, not just the managed runtime.
make lint runs a static check over all battery files and fails if any prohibited predicates are present. CI enforces this on every push.
Elastic License 2.0 — free to use; cannot be used to provide a competing managed Logic Cell service.