So, we could define some generic rules to be turned on/off and 
tuned/configured.  
 
<jinzhai>
Don't know how configurable and generic is enough :-) 
I would think in Tigerstripe we have a validation framework 
plugin just like the eclipse EMF valiation framework for EMF model validation. 
The framework implements generic rules as well as provides extention point 
for adding/adjusting validation rules.
</jinzhai>
 
 
 Maybe these 
would be part of the profile? Maybe they would be separate. 
<jinzhai>better be separate. at future, a Tigerstripe 
model can be decorated with profile or annotation. The validator should also 
work in annotated model project.<jinzhai> 
Note that the auditors do 
support some extension points to add specific behavior. But maybe we want to 
make it a bit more configurable rather than having users write an Eclipse plugin 
and some Java code.  
<jinzhai>Yes some extension points are needed. 
but in my opinion,  In any case, some specific validation rules are 
unpredictable and possible. They may not be covered in Tigerstripe built-in 
validator. so we should make it possible for users to write 
plugin.</jinzhai>
 
 We are in 
planning phase now... So now is a good time to speak up and propose ideas 
:-). 
Patterns? Single rules? Naming conventions? 
<jinzhai>I'd like to join the 
discussion. 
 
The background is: in TIP we are thinking, 
we hope the Tigerstripe TIP model projects are 
 
1) valid as a standard Tigerstripe model project. 
2) valid when we check it with TIP specific model 
constraints such as
   - an Entity artifacts should not inherit 
from an AssociationClass
   - an 
AssociationClass artifact should not inherit from an 
Entity
   - an 
enumeration should be string-based rather than 
int-based.
   - an 
artifact should not override fields of its supertypes of same package (reason: 
otherwise the generated XSD is not valid do to duplicated 
elements)
   - the 
description of artifacts, attributes etc should not contains rich text (reason: 
the generated XSD may be not well-formed due to rich text in 
xsd:documentation)
   - more 
....
 
and about UI, we hope 
the model validation process is launched and the findings are reported just 
like a standard eclipse valiation process.
 
    I'll 
send you a list of rules for your reference.
</jinzhai>