How would you use modern C# pattern matching without turning business rules into a fragile switch expression?

C# can warn about some unreachable or non-exhaustive patterns, especially over closed-looking inputs, but class hierarchies are generally open and new enum values can arrive through versioning or invalid casts. I therefore decide whether unknown means reject, preserve, or use a default; silently mapping it to a normal business case can corrupt behavior. Property access inside patterns may execute getters, so I avoid expensive or stateful getters and do not assume matching is a pure memory operation. In production I extract a named policy when the switch grows, test boundary and overlap cases, and keep rule ordering visible. Pattern matching improves clarity when it describes a stable decision table, not when it compresses several services and side effects into one expression.