hiding-informationlisted

# Hiding Information ## Overview Each module should encapsulate knowledge that its callers do not have and do not need. That knowledge is a design decision: a storage format, a protocol, an algorithm, a business rule's exact thresholds. Hiding it means a change to the decision cannot reach a caller. Information leakage is the opposite: the same knowledge appears in more than one module, or appears in an interface when it belongs in an implementation. Leakage is the single most damaging structural problem, because it turns one decision into many, silently. ## When to use - Two modules both know a date format, a status code, or a field layout - A change to one internal detail forced edits elsewhere - Deciding what to export from a new module - Modules named after steps of a process rather than kinds of knowledge - A value is threaded through five functions that never look at it Not for: judging whether a module is worth its interface, which is [designing-deep-modules](../designing-deep-modules/SKILL.md). ## Core rules 1. **Name the knowledge each module owns.** Write one line per module: "this module is the only place that knows X". If two modules claim the same X, that is leakage, and one of them must stop. 2. **Decompose by knowledge, not by time.** Modules named `parse`, `enrich`, `send` follow the order things happen. Order changes; knowledge does not. See [temporal-decomposition.md](references/temporal-decomposition.md). 3. **Export the least that st