Welcome to the buildingSMART Validation Service Docs!

• User Guide
  • Introduction
  • Using the Validation Service
    • Logging In
    • File upload
    • File processing
    • Results
      • Color codes and icons
  • Understanding the validation process
    • STEP Syntax
    • IFC Schema
      • Schema Version
      • Schema Compliance
    • Normative Checks
      • Implementer Agreements
      • Informal Propositions
    • Additional, Non-normative Checks
      • Industry Practices
      • buildingSMART Data Dictionary (bSDD) Compliance
• Developer Guide
  • Application Structure
    • System Architecture
    • Submodules
    • Running Validation Checks
  • How to start?
    • Option 1 - Run minimal set of services via Docker Compose (easiest to run)
    • Option 2 - Local debugging + infrastructure via Docker Compose (easiest to debug)
  • IFC Gherkin rules
    • Usage as part of buildingSMART validation service
    • Making changes
    • Command line usage
  • Detailed Information for Normative Rules
    • 1. Branch creation
    • 2. Rule development
      • 2.1) Write feature files (gherkin rules) for IFC
        • Naming convention for feature files
        • Mandatory content
        • Mandatory Given(s)
        • Optional content
        • No spaces between steps
        • Watch out for extra blank spaces
        • Do not use punctuation at the end of the steps
        • Be careful when typing parameters. They are case-sensitive!
        • Must vs Shall
        • Verbs for IFC relationships
        • Reference for schema versioning
          • Valid (active, not withdrawn or retired) Schema Versions
      • 2.2) Write python steps
        • Naming convention for python files
        • Steps parametrisation
        • Step re-use
        • Do not use “when” or “And” keywords
        • Use of existing IfcOpenShell APIs
      • 2.3) Write unit test files
        • Naming convention for unit test files
        • Content of the unit tests subfolder
        • Number of unit tests required
        • Table template for unit test files
    • 4. Assign a reviewer to the pull request
    • 5. Review the pull request
    • 6. (optional) Fix the rule according to feedback from reviewer
    • 7. Approve and merge the pull request
    • Appendix
      • Error Codes
        • Notes
  • Functional parts
    • Catalog
  • A deep dive into gherkin rule implementations
    • Decorator
    • Context stacking
    • Validaton Outcomes
• Reference Information