At Accentient, we are always running into clients who need to implement a methodology, and have it checked for 'correctness' as time goes along.  With TFS, as it stands, correctness checks need to be made in one of three ways:

1)  TFS has a built in checking mechanism.  This generally occurs INSIDE a work item.  For instance, Field A can only be changed by a Project Manager.  This is the BEST mechanism, since you can ensure validity prior to committing the work item changes to TFS.

2)  Listen to the available events (Work Item Save, for instance), and react to the event.  This is possible when we're doing things like ensuring that every "Requirement" has an associated "Risk" associated with it (mandatory for regulatory compliance in health care research).  This is a GOOD mechanism, as the project may go out of compliance, but the violation is noted immediately.

3)  Verify the model at periodic intervals, either on demand or scheduled.  Here you would simply use automation to query TFS and ensure compliance with the methodology.  This is a SO-SO method, since the project goes in an out of compliance throughout the project lifecycle.

Some people may claim that Check-in Policies may be used to ensure client-side compliance.  That is true, but only to a limited degree.  The check-in policies are run only when something is being checked into TFS, not when a work item is saved.

Another claim may be that we could use VSIP to extend Visual Studio.  This is indeed the case, and would provide the greatest amount of validation, however, in most cases not everyone who interacts with TFS is using VS2005 - some use Project, Excel, Word, Outlook, TeamPlain, TeamPrise, etc.

So, what I'd personally like:

1)  Events around everything that happens in TFS, including very granular things like a Work Item get.  I know this may have performance implications, but a big, hairy warning could be affixed to the VSIP SDK, and we could extend at our own risk.  In a vast majority of the cases I work with, the machines used to power TFS are so much in excess of recommended load that I have, literally, gigabytes of memory and maybe 50-75% of the processor to play with.

2)  Client side Work Item Check-in Policies.  Let me interrupt, on the client-side, a work item save and do validation before I allow it to be committed to the server.

3)  An SDK or a prebuild web service, if you will, that I can install that will 'catch' the thrown events, and translate them into something intelligible, like a clean object.  

Over the course of the next few weeks, I'll be posting more about thoughts of validating and enforcing methodologies using TFS.