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. 
None defined yet, but there seems to be consensus that ngHurd should be a principle-driven design.
Here is an incomplete list of potential design principles for the ngHurd. It is taken from . I left out some principles I think do not apply or are not in question. Feel free to add more.
- 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.
- 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.
- 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.
-  http://lists.gnu.org/archive/html/l4-hurd/2005-11/msg00120.html
-  EROS: A Principle-Driven Operating System from the Ground Up