Il est possible d'utiliser un jeu de règles de traitement pour plusieurs versions de type d'informations collectées dynamiques. Par exemple, le même jeu de règles de validation peut être utilisé pour plusieurs versions d'un type d'informations collectées. Dans ce cas, le jeu de règles de validation doit factoriser les changements structurels à travers différentes versions dans sa logique.
Par exemple, la version 1 d'un type d'informations collectées peut avoir les deux attributs "authorizedExpense" et "actualExpense". Dans la version 2, l'attribut "actualExpense" peut avoir été remplacé par un type d'informations collectées enfant appelé "Expense". Dans ce cas, la dépense réelle totale doit être calculée en additionnant la valeur des dépenses de tous les enregistrements enfant de type "Expense". S'il existe une validation qui vérifie le montant de dépense réel par rapport au montant de dépense autorisé et que le même jeu de règles de validation est utilisé pour les versions 1 et 2, la logique de validation doit d'abord vérifier l'existence de l'attribut "actualExpense". Ceci est obligatoire car le jeu de règles généré contient des attributs de règles correspondant aux versions 1 et 2.
L'opération isAttributeAvailable() peut être utilisée pour vérifier si un attribut particulier est disponible dans un enregistrement d'informations collectées spécifique. Ainsi, dans cet exemple, le jeu de règles de validation peut vérifier si l'attribut "actualExpense" est disponible dans l'enregistrement en cours de validation. Si ce n'est pas le cas, la logique peut calculer la dépense réelle en ajoutant la dépense provenant des enregistrements enfant "Expense".