Since I can't recall what format the use case needs to be provided in, I'll just put it in an email for tomorrow's discussion. Here is a summary of what I'd like to see from the Activity Instance schema. It's a bit high level, but we can go into more details as time goes on. High level use case: want to be able track a job (and its attributes) throughout it's entire life cycle. It is very useful to be able to see various bits of information about a particular job (an activity instance) at various phases within its lifecycle. Different types of information are particularly relevant at different points in the job lifecycle, and the information can be used for various activities such as job monitoring, system diagnosis, and capacity planning. The types of information that should be tracked are as follows: - the point at which an activity has been submitted (and the parameters that were provided at submission) - any state changes that occur. This would include the time of the change, the old state, and the new state. - information about the activity being forwarded from one scheduler to another (pertains to meta-scheduling and peer scheduling use cases) - some report of resources consumed by the job both during the run time of the job, as well as a final "accounting" record that summarizes the job resource usage User roles: end users monitoring job progress and history, administrators who want to diagnose exceptions within the system, and those who want to use this information for capacity planning. Access mechanism: would like to be able to have access to these records during job runtime by querying the BES (for example) and would like to be able to examine a file that contains activity records -- Chris