Architecture Principle
A durable, agreed rule that constrains design decisions in advance, stated with its rationale and its implications.
Good principles are specific enough to rule things out. "Buy before build for non-differentiating capabilities" rules things out. "We value quality" does not, and is therefore not a principle.
A usable principle has four parts: the statement, the rationale (why this, here, now), the implications (what it forces you to do), and ideally the exceptions process. The implications section is what separates a principle from a slogan — "prefer managed services" implies accepting less control and a vendor dependency, and if the organisation is not willing to accept those, the principle is decoration.
Six to ten principles is a working set. Thirty is a document nobody consults, and principles that contradict each other without a stated precedence are worse than none, because every decision can cite one.