It is probabbly wise to remember domain rules in the database when considering Intent Insurance.

A common scenario for a check constraint is to ensure the range of values in a field in cases where no foreign key constraint is available to constrain the values.  The typical example is the case of a [State] field, where a check constraint on the table may look like:

[State] IN ('NSW', 'QLD', 'VIC', 'ACT', 'TAS', 'NT', 'SA', 'WA')

To contrast this with the foreign key constraint, you may be guided by personal taste or circumstance to not create a lookup table of States since it is not expected to change any time soon and would then require a JOIN every time we needed to see the State with any address. 

Now to the point of the post, I just came across an example that is worth mentioning.  Consider the following simple and neatly anonymous table of clients:

Imagine a business rule exists as follows:

• If this client is known to us by an online referal, they must have an email address
• Any client, online referal or not, can have an email address

You would naturally expect this rule to exist programatically in the presentation tier.  The Intent Insurance mindset would then be to also add a check constraint to the table:

([online_referal] = 0) OR ([online_referal] = 1 AND [email_address] IS NOT NULL)

And there you have it, in one line another little parachute in the application asserting your intent.  Sleep a little easier tonight