Anatomy of a Module

An OpenClaw module is a self-contained unit of functionality. It has a trigger interface (how the module gets invoked), a logic layer (what the module does), and a data layer (where the module reads from and writes to). These three layers are not optional design guidance. They are structural requirements. When a module violates layering — when presentation logic leaks into the data layer, when business rules get tangled with API calls — the module works until the first requirement change, then it breaks.

I keep a Technical Debt Ledger for every engagement. The single most common entry is "module with collapsed layers." Someone built a skill that fetches data from an API, transforms it, formats a Telegram message, and sends it — all in one function. It works. It ships. Then the client wants the same data in Slack instead of Telegram. Now you are rewriting the entire skill because the presentation layer (Telegram formatting) is welded to the data layer (API fetching). The 3-layer rule prevents this. Separate what you fetch from what you compute from how you display it.

1. Data Layer Handles all external data access: API calls, database queries, file reads. Returns raw, structured data. Does not format, filter, or transform for display. If your data layer contains the word "message" or "format," it has presentation logic in it.
2. Logic Layer Transforms raw data into business-meaningful results. Filters, aggregates, computes derived values, applies business rules. Takes structured data in, returns structured data out. If your logic layer contains HTTP calls or message formatting, the layers have collapsed.
3. Presentation Layer Formats the business result for a specific output channel: Telegram, Slack, email, file. Only this layer knows about message formatting, character limits, or channel-specific features. Swapping this layer changes the delivery without touching what gets delivered.