“The set of principles between two or more intersecting domains is the area of problem space where an architect should focus on. ” – My running thought.
This implies that you should define your principles on a template that is based on a normalized model. How else will you be able to get to the intersection.
A common model used by several frameworks, authors, researchers, consultants and organisations is based upon the pattern [Name – Statement – Rationale – Implications]. Some do away with “statement” as a part in the pattern. These are not patterns that make up good structured principles to build your enterprise reasoning on.
On a high level in the enterprise a principle based on the common pattern described above will probably work very well. On lower levels, closer to the solution domain the act of reasoning about any problem demands a pattern based on a normalized meta-model.
Probably you should only have one level of principles, below that there should be problem specifik patterns to guide the user in selecting the appropriate decision.