Separation of mechanism and policy

we can change the behaviour of the system. Further, in cases where a wide or variable range of policies are anticipated depending on applications’ needs

The system (mechanism) should provide basic capabilities for doing something, but it should not decide how or when to use them — that’s left to policy.

Why separate them?

• Flexibility: You can change the policy (the rules) without redesigning the mechanism (the system tools).
• Reusability: The same mechanism can support many different policies.
• Adaptability: Different applications or users might need different policies, but they all use the same mechanisms underneath.

In computer systems

• Mechanism: The operating system provides low-level functions like scheduling, resource allocation, and permissions.
• Policy: The administrator or user decides how to use these mechanisms — e.g., which processes get more CPU time, or which users have access to files.

How to think of it normally

Imagine you’re designing a system:

• Mechanism: “I’ll build functions that can pause, resume, or stop a task.”
• Policy: “I’ll decide when to pause or stop tasks — maybe based on time, priority, or user input.”