# Design Principles
A design principle is a test that lets us **reject** things. Hopefully, when combined with other design principles, it forms a basis for making coherent and consistent decisions about design goals and system features. [1]
## Stated design principles
None defined yet, but there seems to be consensus that ngHurd should be a principle-driven design.
## Potential design principles
Here is an incomplete list of potential design principles for the ngHurd. It is taken from [2]. I left out some principles I think do not apply or are not in question. Feel free to add more.
### Principles from the Multics Project
* _Economy of mechanism_: Keep the design as simple as possible.
* _Fail-safe defaults_: Base access decisions on permission rather than exclusion.
* _Least priviledge_: Components should have no more authority than they require.
* _Least common mechanism_: Minimize the amount of shared instances in the system.
### Commonly accepted principles
* _Separation of policy and mechanism_
* _Least astonishment (also known as principle of least surprise):_ The system�s behavior should match what is naively expected.
* _Complete accountability_: All real resources held by an application must come from some accounted pool.
* _Safe restart_: On restart, the system must either already have, or be able to rapidly establish, a consistent and secure execution state.
* _Reproducibility_: Correct operations should produce identical results regardless of workload.
### Principles specific to EROS
* _Credible policy_: If a security policy cannot be implemented by correct application of the system�s protection mechanisms, do not claim to enforce it.
* _Explicit authority designation_: Every operation that uses authority should explicitely designate the source of the authority it is using.
* _Relinquishable authority_: If an application holds some authority, it should be able to voluntarily reduce this authority.
----
See also:
* [1]
* [2] EROS: A Principle-Driven Operating System from the Ground Up