Clauses & Checks
How COREY's rule-based model checking works, in plain language.
Checking a model means asking practical questions: "is the required data filled in?", "is this value allowed?", or "is this number within range?". COREY stores those checks as clauses and runs them across the whole IFC model.
For CORENET X workflows, clauses can represent IFC-SG data requirements from an Excel mapping or from your team's own review standard. COREY then shows which elements pass, need attention, or fail, so the team can fix issues before submission.
The building blocks
Rule
One specific check — e.g. 'a wall's fire rating must be filled in'.
Clause
A named group of related rules — e.g. 'Wall data requirements'.
Check result
What COREY shows per element: OK, Warning, or Error.
A clause is just a titled folder of rules. Grouping rules into clauses keeps your checks organised and makes results easier to read ("3 elements failed the Fire safety clause").
Anatomy of a rule
Every rule answers four questions:
| Part | Question it answers | Example |
|---|---|---|
| IFC Type | Which kind of element does this apply to? | IFCWALL (walls) |
| Target | Which piece of information should we look at? | The property Pset_WallCommon › Reference |
| Check | What must that information satisfy? | Must be one of WALL-A, WALL-B, WALL-C |
| Severity | How serious is a failure? | Error or Warning |
Target: where to look
A target is either:
- an Attribute — a built-in field on the element, identified by name (such as
NameorGlobalId); or - a Property — a value inside a property set, identified by the property set
it lives in and its label (such as
Pset_WallCommon›Reference).
Check: what to require
COREY offers three kinds of check:
| Check | Passes when… | Use it for… |
|---|---|---|
| Required value | the field is filled in (not blank/missing) | making sure information isn't left empty |
| Allowed values (enum) | the value is one of a list you provide | codes, classifications, fixed vocabularies |
| Number range | the number is within a minimum and/or maximum | dimensions, ratings, counts |
Any check automatically fails if the value is missing or empty — so "Allowed values" and "Number range" also guarantee the field is present.
Severity: how loud to be
Each rule fails as either:
- Error — a real problem that should be fixed.
- Warning — worth a look, but not necessarily wrong.
When an element breaks several rules, its overall result is the most serious one (Error beats Warning beats OK).
A worked example
Clause: "Wall basics"
- Rule 1 — On every
IFCWALL, the attributeNameis required. Failing this is an Error.- Rule 2 — On every
IFCWALL, the propertyPset_WallCommon › Referencemust be one ofWALL-A,WALL-B,WALL-C. Failing this is a Warning.
Run this against a model and COREY checks every wall. A wall with no name shows an
Error; a wall named correctly but with a Reference of WALL-Z shows a
Warning; a wall that satisfies both is OK.
Demo wall template
The bundled Demo IfcWall template is a small
clause set used for demos and smoke checks. In the Revit sample model it checks
element identity and wall fire-rating metadata.
The demo wall template loaded from the clause workspace quick presets.
Reading the results
After you run validation, COREY:
- Highlights elements in the 3D viewport — one colour for warnings, another for errors — so problems are easy to spot.
- Lets the data table filter by failed clause, so you can review the affected elements in bulk.
- Keeps the selected element synced with the 3D viewport and properties panel.
A validation run against the demo model highlights six flagged wall elements.
Saving and reusing clauses
You can export your clauses and import them later or on another project. This lets a team agree on one standard set of checks and apply it consistently. With the optional backend, clause sets can also be saved as shared templates.
For developers
Clauses are stored as a small JSON document (a version plus a clauses array,
each clause holding rules). The repository includes a starter file,
public/resources/starter-essential-elements.json, and the format is validated
on import. The exact schema and evaluation logic live in src/features/rules.