I’ve watched teams argue about rules versus models as if one approach is “more modern” than the other. Engineers like rules because they’re deterministic and easy to explain. Data scientists like models because they can optimize outcomes and adapt. In practice, I’ve seen organizations get into trouble both ways: rules that are safe but slow to respond to reality, and models that are powerful but occasionally violate constraints everyone assumed were non-negotiable.
What seems to drive confusion is that rules and models often serve different jobs. Rules are great when the decision needs to be consistent, auditable, and defensible — especially when the cost of being wrong is high. Models are great when the decision benefits from learning — when patterns change, when optimization matters, when the “best” choice depends on behavior and context. When those two worlds collide, it can feel like the organization is stuck: compliance wants certainty, product wants competitiveness, and no one owns the full trade-off.
The approach I’ve seen work is less about picking one and more about sequencing them. Rules set the boundaries. Models operate inside them. Exceptions get routed to humans. Over time, the guardrails can evolve — but in a visible way, with accountability. That doesn’t eliminate tension, but it turns tension into a managed design decision instead of a constant tug-of-war.
If there’s a single test I’ve found useful, it’s asking: what’s the irreducible constraint here, and what’s the part we actually want to optimize? That one question tends to calm the debate and clarify the architecture.
Leave a Reply