# Failures keep their meaning

Principle `failures-keep-their-meaning`. Expected refusals, infrastructure faults, and defects need different policies.

Also searched as: domain error, infrastructure error, defect, exception masking.

Model expected business failures explicitly. Hide recoverable details only where callers do not need them to preserve correctness.

> These different kinds of errors require different implementations.

Source: [Q15](/bibliography#q15); [B7](/bibliography#b7-domain-modeling-made-functional), [B10](/bibliography#b10-a-philosophy-of-software-design).

## Failure it prevents

A broken execution becomes a permanent business refusal, or a permanent refusal triggers endless retry.

## Our Effect 4.0.5 reading

Schema.TaggedError and Effect.catchTag carry named expected outcomes. Classification and defect policy remain domain decisions. A service seam can own recoverable mechanics.

Source: `packages/effect/src/Schema.ts`, `packages/effect/src/Effect.ts`, `packages/effect/src/Context.ts`, `packages/effect/src/Layer.ts`.

## How to check

Exercise each declared failure category. Verify retry, refusal, escalation, and uncertain outcomes remain distinguishable. This is our proposed verification, not a quoted procedure.

Continue with [Cleanup can be an idempotent postcondition](/principles/cleanup-can-be-an-idempotent-postcondition), [Pure cores reduce timeline coupling](/principles/pure-cores-reduce-timelines).

Connect this to [the existing rat-stack guidance](https://ratstack.sh/lore/error-model).

Use [the durability skill](/skills/durability) for the full review. Return to [the durability index](/principles/durability).

## Skills
- [Durability starts with a recovery record](/principles/durability)

## Sources
- Wlaschin, Scott. *Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#*. Pragmatic Bookshelf, 2018. [Link](https://pragprog.com/titles/swdddf/domain-modeling-made-functional/). ([b7-domain-modeling-made-functional](/bibliography#b7-domain-modeling-made-functional))
- Ousterhout, John. *A Philosophy of Software Design*. 2018. [Link](https://web.stanford.edu/~ouster/cgi-bin/book.php). ([b10-a-philosophy-of-software-design](/bibliography#b10-a-philosophy-of-software-design))

## References
- [Effect contributors. Effect 4.0.5. Schema.ts](https://github.com/Effect-TS/effect/blob/7f524e25cfb49a71ac39b0f44278d08d40dda5de/packages/effect/src/Schema.ts). Pinned source for our Effect mapping, not a claim from the book.
- [Effect contributors. Effect 4.0.5. Effect.ts](https://github.com/Effect-TS/effect/blob/7f524e25cfb49a71ac39b0f44278d08d40dda5de/packages/effect/src/Effect.ts). Pinned source for our Effect mapping, not a claim from the book.
- [Effect contributors. Effect 4.0.5. Context.ts](https://github.com/Effect-TS/effect/blob/7f524e25cfb49a71ac39b0f44278d08d40dda5de/packages/effect/src/Context.ts). Pinned source for our Effect mapping, not a claim from the book.
- [Effect contributors. Effect 4.0.5. Layer.ts](https://github.com/Effect-TS/effect/blob/7f524e25cfb49a71ac39b0f44278d08d40dda5de/packages/effect/src/Layer.ts). Pinned source for our Effect mapping, not a claim from the book.