Principle Rationale
The stated reasoning and implications attached to an architecture principle, without which the principle cannot be applied to a case its authors did not foresee.
A principle without rationale is a slogan. "Prefer managed services" tells nobody what to do when the managed option is missing a feature — but "prefer managed services because our operational capacity is our scarcest resource and we would rather spend it on domain problems" resolves the case immediately.
A usable principle statement has four parts: the statement itself, the rationale, the implications (what it means people must now do), and the exceptions with the process for invoking them.
The exceptions part is what keeps principles credible. A principle with no exception path is either ignored quietly or followed into an obviously wrong outcome, and both damage the whole set.
Two qualities of a good principle: it is directive — it excludes something, so a principle nobody could ever violate is not doing work; and it is contestable — its opposite could reasonably be held by another organisation. "We value quality" fails both.
Keep the set small — five to ten. A list of thirty is not consulted, and principles that are not consulted do not influence decisions, which is the only reason to have them.