Check with Assure

What Assure checks

Assure is where a project's models are checked. Open it from the left rail. The page has three tabs.

Quality Intelligence runs ZEROBiE's own rule catalogue against the model and lists what it finds, grouped by severity: Critical, Warning and Info. IFC Validation checks the file against buildingSMART's published IFC rules. History lists the analysis runs recorded for the model.

Choose the model to look at with the model selector at the top of the page. If the project has no models yet, Assure says so and sends you to the Files page to upload one.

Running an analysis

Choose the model, choose a rule set in the Rule set control, and press Run Analysis. Project default uses the rule set the project has marked as its default. The analysis is queued and the page follows its progress; you can leave the page and come back.

More actions, beside the button, lets you cancel the later stages of a running analysis. Work already submitted may still finish, and results that have completed are kept. Retry conformance only runs the IFC validation stage again without repeating the rest.

Owners and editors can run an analysis. A viewer can read the results.

Assure opens on the last completed run of the model chosen. Under the title, one line states which file, which revision, when the run completed as a date and time, and whether that revision is current or has been superseded. A model with no completed run says so and lists the project's models to analyse. Assure is entered from the left rail; the Files page carries no Assure control.

Reading the standard score

The standard score summarises the Quality Intelligence results for the model in one figure with a band. The panel shows the score, the band and the headline; the method is not printed beside them. Click the score to open its explanation, which shows how it was worked out: the rules that applied, how many found something, the weight each severity carries, the arithmetic, and the rule that sets the band.

The severity tiles under the headline show how many problems each severity has. A tile reads model-level when its problems are findings about the model as a whole rather than about particular elements.

Under the run line, Run details is a closed section that holds the run's identifier, the full content hash of the model, the rule set and catalogue versions, the validation service version, the scoring policy and the duration. Open it to read or select any of them, and use Copy run details to copy them all.

A model that has never been analysed is not scored. It is shown as not scored, never as zero. Always read a score together with its rule breakdown: the figure alone does not say which rules produced it.

A run recorded under the earlier scoring policy, tobie-score-v1, shows no number. That policy counted every occurrence of a problem, so its figure is not comparable with a current score; the page, the explanation and the exports say so where the number would be. Its band and headline still stand. Run the analysis again to score the model under the current policy.

Working through findings

Each rule that found something has a rule card. Click a rule card to expand it and see its findings, then click a finding to open its detail panel. A severity group is open by default only when it holds an open problem; a closed group still shows its count. Whether you open or close a group is remembered for the rest of your session.

The table of a rule's findings shows the element, the status, the assignee and the due date. A File column appears only when the findings come from more than one file. The Up and Down arrow keys, or K and J, move between findings, and Enter opens the one in focus.

The inspector shows the affected element in 3D with the rest of the model ghosted around it. The identifier block beside a finding lists the identifiers that element actually carries - its Object ID, its IFC ID, and the identifier its authoring tool assigned where the export carried one - and Copy identifiers copies them. The tool the file was exported from is named once, in Run details. It stays at the top of the right column while the finding's panel scrolls beneath it. When the selected element has no geometry of its own, such as a space, a relationship or a property definition, the inspector says so in the viewer's place and names the entity; the finding is read and acted on as any other.

Under a finding's history, Evidence is a closed section that holds the rule as the checker stated it, its expected value where that is a fragment, and the observed trace, copyable; a long trace is cut at 500 characters there. The JSON export carries all of it whole.

G switches the ghosting, F fits the view to the selection, and the square bracket keys step through the elements of the selected finding. V opens the finding in the full 3D viewer. Element history opens the selected element's own page.

Findings that an earlier run raised and this run no longer finds are listed as resolved since the last run. A finding is not marked as fixed by hand: it is resolved when a later analysis no longer finds the problem. Waiving, described below, is how you set a finding aside yourself.

Acting on a finding

A finding's actions are the same from its row, its right-click menu and its detail panel: Inspect, Open in 3D Viewer, Copy IDs, Waive and Select for export. Apply fix appears only for a finding that has a fix to record.

Waive opens a dialog that asks for the reason, which is recorded with your name. A finding that is already closed cannot be waived. Only a nominated approver may waive a critical finding; a project owner nominates approvers in the members dialog. If an action is refused, the control says why.

IFC Validation

The IFC Validation tab shows the result of checking the file against buildingSMART's published IFC rules, with the date and time of the check, the file's schema and its entity count. Run details, a closed section under them, holds the ruleset version, the run's identifier, the full content hash, the validation service, the duration, the file's name, size and date, and the coverage by rung: how much of each layer was evaluated. Search by rule identifier or title, and filter by verdict, to find a rule.

The rules are listed by rung, and each rule is a step: its identifier and how many occurrences it has are stated before you open it, and opening it lists the occurrences, each one action from its element. A rung is open by default only where a rule failed or raised a warning; a closed rung still shows its counts, and what you open stays open while you switch tabs.

A validation result is a statement about the file. It does not say that an appointment's information requirements were met.

Workflow: review a model before handover

Before you begin, upload the intended revision to the project. An owner or editor can run the analysis; a viewer can inspect the results. Agree which project rule set should be used before starting.

1. Select the model and rule set, then choose Run Analysis. Wait for the completed report and check its file, revision and absolute date and time. If the report says the revision is superseded, decide whether you need a new analysis before using it for the handover.
2. Review the Critical findings, then Warning and Info. Open each relevant rule and finding. Read the observed evidence and affected identifiers; use the inspector to locate the element when geometry is available. A finding without a viewable element still needs review.
3. Check the rules that did not run. Their reasons identify missing configuration or evidence; they are not passes. Review IFC Validation separately from Quality Intelligence because they answer different questions.
4. Export the report or selected findings for the receiving team. Open Run details when preparing a screenshot that leaves the project so the ruleset context accompanies the result. Use the full JSON export when the team needs an evidence trace that is shortened in the panel.

The outcome is a recorded analysis and a set of issues to coordinate. It does not approve or publish the file, and it does not establish that all appointment requirements have been met.

When an analysis does not give an answer

No completed run means there is no completed report to interpret. Not scored means no score is available; it does not mean zero quality. A rule listed as not run has not established a pass or a failure.

An unavailable validation service has not established that the IFC is invalid. Read the reported reason and use Retry conformance when the service is available again. Keep completed Quality Intelligence results distinct from the missing validation answer.