Course Content
Level 1 Information Manager – Basics

This video shows how to use QA model checking in the Verify module to confirm deliverables meet requirements before submission. The written guide below explains how to connect model elements to tasks using model rules and task rules, check information properties, and run a self-quality review before marking tasks as complete.

Check your model before you say it is done

Quality assurance works best when it happens before a model is submitted, not after problems have already been passed downstream. The Verify module in Plannerly puts the QA step into the hands of the teams delivering the models. Instead of waiting for a manager to discover that requirements are missing, the delivery team checks their own work against the original scope requirements and fixes issues before anyone else sees them.

The first step is connecting model elements to the tasks they need to satisfy. This is done through two types of rules. A model rule works at the top level: you define a task property (like the element name) and match it to a model property (like the assembly description), and Verify automatically finds every element that matches across the entire model. For example, connecting the task “footings and pile caps” to elements where the assembly description matches might find 38 pile cap elements in one pass. This is the most efficient way to link many elements to many tasks at once.

When a model rule doesn’t catch everything, you create a task rule for the specific items that need a different connection. Rather than linking a single element by its unique ID (which only connects one object), the more powerful approach is to find a property value that groups the right elements together. For concrete stairs, you might match the type name property to “concrete stairs” and Verify finds all nine stair elements automatically. This property-based approach means new elements that match the rule are caught even if the model is updated later.

Once elements are connected, Verify evaluates whether the required information properties are present and complete. If the scope requires tread thickness to have a value, Verify checks every connected stair element and calculates the percentage of information requirements that have been met. If the result shows zero completion, you know the model is not ready for submission. The delivery team fixes the model, re-checks, and only moves tasks from the QA column to complete when all requirements are satisfied. Manual checklist items still play a role alongside automated checks, ensuring that requirements which cannot be verified automatically are still reviewed before handover.

How to run a QA check in the Verify module

  1. Set up a QA column – Manage the Kanban columns to include a QA step before the completed status, so tasks pass through quality review before being marked as done.
  2. Create a model rule – Define a rule that matches a task property (like element name) to a model property (like assembly description) to connect elements to tasks across the entire model.
  3. Review model rule results – Check how many elements were found for each task and whether the required information properties are present on those elements.
  4. Create task rules where needed – For tasks not covered by the model rule, create a task-specific rule using a property value match (like type name) rather than linking individual elements.
  5. Evaluate completion percentage – Review the percentage of information requirements met for each task to determine whether the model is ready for submission.
  6. Fix issues in the model – Where properties are missing or incomplete, update the model and re-check until the requirements are satisfied.
  7. Review manual checklist items – Complete any manual review items that cannot be verified automatically.
  8. Move tasks to complete – Once all automated and manual checks pass, move the task from QA to complete on the Kanban board for managers to review.

What you’ll learn

  • Model rules – How to create top-level rules that automatically connect model elements to matching tasks across the entire model.
  • Task rules – How to create element-specific rules using property values when a model-wide rule doesn’t cover a particular task.
  • Property-based linking – Why linking by property value is more powerful and maintainable than linking individual elements by unique ID.
  • Completion evaluation – How Verify calculates the percentage of required information properties that are present and complete.
  • Self-quality workflow – How shifting QA responsibility to delivery teams reduces waste and catches issues before they reach project managers.

Common questions

What is the difference between a model rule and a task rule?

A model rule works across the entire model, matching a task property to a model property for all tasks at once. A task rule applies to a specific task and lets you define a unique property match for elements that the model rule didn’t catch. Most projects use a model rule as the baseline and add task rules for exceptions. The parameter linking troubleshooting guide helps when rules don’t connect as expected.

Why should I link by property value instead of selecting individual elements?

Linking by property value (like type name equals “concrete stairs”) catches all matching elements, including any that are added when the model is updated later. Linking by selection only connects that one specific element by its unique ID. Property-based rules are more robust, more scalable, and less likely to miss elements as the model evolves during delivery.

What happens if the completion percentage shows zero?

A zero completion result means none of the required information properties are present on the connected model elements. This is a clear signal that the model is not ready for submission. The delivery team needs to update the model to include the required properties, then re-check in Verify. Only when the percentage meets the project’s acceptance threshold should the task be moved to complete.

How does this fit into the ISO 19650 workflow?

ISO 19650 requires that information is checked against requirements before it is shared. The QA step in Verify is exactly this: the delivery team confirms that their model meets the scope requirements before submitting it. This self-quality check reduces the burden on information managers and ensures that shared information is actually fit for its intended purpose.

Explore further

0% Complete

Pin It on Pinterest