Purpose

Validate an iModel class to ensure it meets schema expectations and will be processed correctly by downstream tools.

Preconditions

• You are signed in to the application and have the app UI open.
• An iTwin and iModel are selected in the app (validation runs against the selected iModel).
• A validation configuration is available (selectable from the Validation page); create one using the app's configuration UI if needed.
• A changeset is selected when you intend to run instance-level validation (Validate tab uses the selected change set).
• You have read/query access to the iModel (the app executes queries against the selected iModel to evaluate rules).

Actions

1. In the app UI choose the target iTwin and iModel using the top bar or selector.
2. Open the Validation page (Dashboard → Validation).
3. From the Validation page pick a validation configuration in the Config selector. If none exist, create or import a configuration using the Configs UI.
4. Select the desired changeset (change set selection is required for instance-level rule execution).
5. Switch to the Validate tab.
6. Select the base configuration. 6.1 Any changes made to the configuration can be saved locally as part of the FREE license. They will be reloaded when you select the same iModel 6.2 You can only publish to a central store if you have a PUBLISH entitlement
7. Select a class to VALIDATE 7.1 You can IGNORE a class if you do not care what is in the class and do not want it to contribute to the overall digital-index score 7.2 A class should generally contribute 100% to the digital-index score, but some classes such as Generic.PhysicalObject should be considered to be bad modelling objects and as such should reduce the digital-index score (preferably not contribute) and therefore you should set the index to 0 or at least less than 100.
8. When you have configured all classes with the corresponding scores the Overall Index will reflect the individual values
9. You can always SAVE the updated configuration, which will store local edits

Notes

• The app's Validation UI executes queries directly against the selected iModel/change set; make sure you are pointing at the correct iModel and change set before running rules.
• Typical workflow: validate schema definitions first (Schema/Classes tabs), then run instance-level rules against a representative change set.
• Publishing results requires the appropriate license/entitlement in the app.
• To validate properties in a class, ensure the class configuration is SAVEd or PUBLISHed
• if the notification marker is ORANGE then this indicates the edits are NOT SAVEd or PUBLISHed. (The location information will display IMODEL rather than BOTH)
• You can view the contents of the Class by using the iModel Console action button
• You can Add a class into the configuration for those classes you expect, but are not part of the current iModel

Troubleshooting

• If rule execution fails, confirm the selected iTwin/iModel/change set are correct and that you have permission to run queries against that iModel.
• If rule types fail to load, reload the Validation page and ensure your session is authenticated.
• If results are missing or appear inconsistent, check for locally saved rule sets in your browser and confirm you are using the expected configuration.
• Warnings returned by the validator do not always block downstream processing — review and document accepted warnings.