The Principle of Least Power
Choose the smallest tool that can handle the decisions you actually need to make.
Use the smallest tool that can do the job, because extra power creates extra ways to make a costly mistake.
Start with the smallest tool that does the job
Arbitrary code, admin access and free-form input let people do more. They also create more ways to make a mistake, hide a problem or change behaviour that nobody expected.
The Principle of Least Power says to choose the least powerful tool that still solves the real problem. Here, “power” means how much behaviour the tool can express.
JavaScript or a rules language?
An operations team needs to configure transaction decisions. If the team can write any JavaScript it wants, a rule can contact other systems, remember information between decisions, run forever or do things the test environment cannot reproduce.
A smaller rules language can allow only the conditions, scores and actions the simulator understands. The team gives up flexibility it does not need, and gains rules it can inspect and test properly.
Where the idea applies
Security. Least privilege follows the same logic. Give someone enough access for the task and no quiet master key.
Law and governance. A regulator with a clear mandate is easier to review because actions outside it are clearly unauthorised.
Product design. Structured choices make outcomes predictable when free text does not change the response. Use free text when the choices cannot capture something that matters.
Make sure the smaller tool fits real work
A tool that is too limited creates exceptions and fragile workarounds, which adds bureaucracy without making the work safer.
Test the difficult cases first. If the smaller tool can handle them, its limits reduce the behaviour you need to understand, audit and change later.