Phase 1 — Foundation
Constraint Framework
Tell the AI what can never happen — and watch it stop making those mistakes
3 min read · Document 3 of 30
What is this document?
The Constraint Framework lists forbidden states and failure conditions across four categories: architectural, business, data and security. Each constraint is phrased so it can be checked — by a test, a database rule or a review.
It turns the unwritten “obviously we never do that” knowledge in your head into explicit instructions an AI coding agent will respect.
Why does it matter?
- Most AI coding errors are not ignorance — they are the AI filling silence with assumptions.
- A Constraint Framework replaces silence with explicit invariants.
- Every constraint maps to a test, so violations are caught before release.
What's inside?
- Forbidden states — Combinations of data or access that must never exist.
- Failure conditions — What the system does when a dependency or rule fails.
- Enforcement — Where each constraint is enforced: database, API, UI or process.
ArchitecturalBusinessDataSecurity
How CREAH generates it
CREAH builds this document from your Stage 0 answers and interview. Questions that shape it include:
- Which user roles must never see each other’s data?
- What happens to an order if the payment provider times out?
- Which secrets must never reach the browser?
Example excerpt
## Forbidden States
- A user_space account NEVER accesses admin_space routes
- Payment creation and coupon redemption ALWAYS happen atomically
- The AI provider key is NEVER present in client-side code
## Failure Conditions
- If coverage threshold is not met: block generation, ask questions
- If payment fails: retry immediately, never hold a project in limbo