The boundaries that stop the wrong thing from shipping.

A boundary says what must not be built. “Never complete setup on behalf of the user.” “Don’t add steps to the activation flow.” “No feature ships without an empty state.” These are the rules that protect the product’s soul from a hundred small, locally-sensible decisions.

Directional principles say what to build toward. “Prefer existing component patterns.” “Pre-fill from existing data where possible.” Standards say how. “Keep interaction under 200ms.” “Screen-reader labels on every action.”

All three matter. Boundaries matter most — because they’re the ones you almost never write down, and the ones that most often get violated by people trying to help.

Hard. Non-negotiable. If a proposal violates it, it doesn’t ship until you review. This is the setting for boundaries you’d quit over.

Soft. Advisory with teeth. The builder sees the flag, reads the reasoning, and decides whether to revise or proceed. You’re not in the loop unless they escalate.

Advisory. Guidance. Shown for awareness. No friction on violation.

The severity tells a builder — or an agent — whether to proceed, pause, or escalate. Ambiguity about which rules are non-negotiable is the main thing you’re buying your way out of.

Some principles apply everywhere (“every form has an empty state”). Others apply only inside a specific investment area (“within Activation Flow, don’t complete steps on behalf of the user”). Clavero tracks scope so an agent working in Enterprise Readiness doesn’t get blocked by a rule that only applies to Activation Flow.

The same principle catalogue is read by the compliance check, surfaced in the team onboarding view, and referenced by every decision in the log. You write it once. It shows up wherever someone needs to know what the rules are — which, in a team of thirty, turns out to be constantly.