EEM-Hub/ftl2-automation-expert

FTL2 Automation Expert

Expert knowledge base for the FTL2 automation framework — a Python-native infrastructure automation tool with dual-mode execution, persistent state orchestration, and an AI-driven autonomous remediation loop. Contains 529 justified beliefs covering the module system, state management, gate/SSH execution, ServerCraft provisioning, and deployment patterns.

What is this?

This is an External Epistemic Memory (EEM) — a model-agnostic knowledge base that any LLM can use via the reasons CLI or tool calling. Unlike a LoRA or fine-tune, this knowledge is not baked into model weights. It is external, inspectable, correctable, and works with any model.

Stats

Metric	Value
Total beliefs	529
Status	529 IN / 0 OUT
Premises (observations)	382
Derived (justified conclusions)	147
Nogoods (contradictions)	0
Retraction rate	0%
Max derivation depth	7

Top Topics

Topic	Beliefs
ftl2	99
ftl	42
module	39
servercraft	39
automation	32
state	32
modules	31
execution	28
host	28
loop	27
ansible	24
catbeez	20
gate	19
context	17
file	17
secrets	16
pattern	16
autonomous	14

Domain Coverage

• FTL2 Core: dual-mode execution architecture, automation context, Python 3.11+ requirement, uv-based runner, telemetry (93 beliefs)
• ServerCraft: infrastructure provisioning, cloud provider integration, provision-then-configure workflows (39 beliefs)
• FTL Framework: module calling conventions, attribute-based API, result contracts, error handling modes (34 beliefs)
• Automation Patterns: idempotency strategies, shell guards, re-runnability, state-driven execution (25 beliefs)
• CatBeez: deployment patterns, service management, application lifecycle (20 beliefs)
• AI Loop: autonomous remediation, resilient observation, fail-open semantics, error suppression (18 beliefs)
• Gate System: SSH execution, host management, dynamic inventory, group filtering (11 beliefs)
• Secrets Management: vault integration, secret injection, secure credential handling (11 beliefs)
• Ansible Compatibility: Ansible-compatible module execution, native vs legacy mode, migration patterns (24 beliefs)
• State Management: persistent state files, provider-specific state, .ftl2-state-<provider>.json convention (32 beliefs)
• Observability: event system, ftl2-htop real-time monitoring, psutil remote dependency (16 beliefs)
• Cloud Providers: AWS, Azure, Hetzner provisioning examples and workflows (remaining beliefs)

How to Use

Import into a reasons database

reasons init
reasons import-json network.json

Query beliefs

reasons search "dual-mode execution"
reasons explain state-driven-reliable-rerunability
reasons show execution-dual-mode-architecture

Use as an MCP tool or CLI

Any LLM agent that can call reasons search, reasons show, and reasons explain can use this knowledge base. The agent does not need to be told it is an expert — the knowledge base speaks for itself.

Key Beliefs

Node	Summary
state-driven-reliable-rerunability	FTL2 achieves reliable re-runnability through persistent state orchestration combined with multi-layer idempotency
execution-dual-mode-architecture	FTL2 provides dual-mode execution: native in-process modules for speed and Ansible-compatible modules for ecosystem access
comprehensive-operational-observability	FTL2 provides comprehensive observability across automation and infrastructure via the event system
ai-loop-autonomous-remediation-system	The AI loop combines resilient observation with autonomous remediation using shell guards and fail-open semantics
idempotency-multi-layer-strategy	FTL2 achieves idempotency through multiple complementary mechanisms: shell guards, state checks, and module contracts
cloud-to-configured-host-pipeline	FTL2 supports provision-then-configure within a single run via add_host() dynamic registration
production-deployment-reliable-and-secure	FTL2 production deployments are simultaneously reliable and secure via state persistence and secret management
error-handling-dual-mode	Two error handling modes: continue-on-error (default) collects all failures; fail-fast stops immediately
automation-modules-as-attributes	Modules are called as attributes on the automation context: await ftl.module_name(param=value)
module-result-contract-consistency	Every module execution returns a consistent result contract — success, changed, output, and error fields

Sources

Built from exploration of benthomasson/ftl2 — a Python-native automation framework with dual-mode execution, persistent state, AI-driven remediation, and multi-cloud provisioning support.

Files

File	Description
network.json	Full belief network (machine-readable, portable)
reasons.db	SQLite database (gitignored, regenerate with reasons import-json network.json)
CLAUDE.md	Agent instructions for using this knowledge base
entries/	75 exploration entries — raw observations behind the premises

Quality

• All 529 beliefs are IN (none retracted)
• 382 premises grounded in direct code observations
• 147 derived beliefs justified from premises via SL justifications
• 0 nogoods — no contradictions detected
• Max derivation depth of 7, indicating multi-step reasoning chains
• Built and reviewed using ftl-reasons derive and review-beliefs pipeline

Limitations

• Focused on the FTL2 codebase as of mid-2026
• ServerCraft and CatBeez coverage reflects current integration patterns
• AI loop beliefs based on current autonomous remediation implementation
• Does not cover FTL1 (original FTL) in detail
• No ATMS or assumption-based beliefs (single-context TMS only)

Authors

• Ben Thomasson (@benthomasson)

License

mit