One of the first tasks for an inspection team is to decide just what it is going to inspect. Real life instances of the products under consideration are diverse in version, configuration, customization, and local enhancements and extensions. These are what the real world user experiences and interacts with.
While it is true that the target environment for component development should be the head end of the main development trunk of each product, it may not be the appropriate target for the inspection process. There is likely much to be learned from the existing local deployments. For example, in the uPortal realm, the inspection team must ask: "Can we learn everything we need to know from a laboratory demonstration version of uPortal3 - which doesn't match any production implementation - or should we extend our exploration to instances of the product that people are actually using?"
It may be that the real inspection target needs to be a composite, covering a number of typical implementations, making the assumption that some usability/accessibility problems are revealed only in actual operational services built from the product. It may turn out that the inspection team can express their results using a single non-production baseline instance of a product - this would be ideal. But it is likely that they will have to examine real operational instances to determine if their baseline instance is representative. To make an analogy: the target instance will be demonstrably representative of real-world environments, in much the same way as a persona is representative of a user population.
Whatever the selected as the inspection target, it should allow for the following:
These observations suggest that there must be a certain stability to the target as the Fluid project progresses. We will need to show achievement against a meaningful baseline.