Model vs Spec Check
Turn a specification into checkable rules, then test the model against them element by element.
Where Submittal Review asks "does this product meet the spec", Model vs Spec Check asks "does the model meet the spec". Same specification, different subject.
Inside the application this module is still labelled Spec Compliance, and you will find it under Specifications in the project sidebar. It is the same thing.
How a spec becomes rules
Upload a specification section as type specification. Bimiq extracts it into individual checkable rules, each with a scope and a requirement:
- Scope decides which elements a rule applies to. Interior partitions, exterior glazing, structural steel.
- Requirement is what those elements have to satisfy. A value, a range, a listed assembly.
Extraction takes a while on a long section, and the module tells you while it is running. Rules that come out wrong can be edited, and you can add rules by hand for requirements that live in a drawing note rather than in the spec.
Rule severity
Each rule is either critical or advisory. Critical rules are the ones you cannot issue against; advisory rules are worth knowing about. Severity is carried through to the results so you can work the critical list first.
Running a check
A check needs a live model, so the Bridge has to be running with the model open. Bimiq reads the elements in scope for each rule and tests them.
Every result lands in one of four states.
| Result | Meaning |
|---|---|
| Passed | Elements in scope satisfy the rule |
| Conflict | Elements in scope violate the rule |
| Not applicable | No element in the model matched the rule's scope |
| Error | The rule could not be evaluated |
Not applicable is worth reading
It is not a pass. It means the model contains nothing the rule could apply to, which is either correct, because the project genuinely has none of those elements, or a finding in itself, because something has not been modelled yet. A spec section full of not_applicable results usually means the scope is mismatched, not that the model is clean.
Resolving a conflict
Each conflict carries a resolution state, so a check is a working list rather than a snapshot.
| Resolution | Use it when |
|---|---|
| Open | Not yet dealt with |
| RFI raised | The conflict became a question for the design team |
| Fixed | The model was corrected |
| Ignored | A deliberate decision that this one does not apply |
Raising an RFI from a conflict carries the rule, the spec clause and the offending elements into the RFI, so the question arrives with its evidence attached. See RFIs and decisions.
Cost
A spec check is charged per run, per document. Extraction and indexing are free; only the check itself is metered. See How credits work.