Key Models

This document provides a high-level overview of the key models in the HUVR system and their relationships. To build anything with HUVR, you have to understand the core objects and their purpose. This is not an all-encompassing list -- instead focusing on the most used features.

All API calls require the workspace subdomain assigned to your organization (e.g., https://your-company.huvrdata.app).

Organization & Structure

How companies, users, and assets are organized — and how projects are assigned.

erDiagram
    Company ||--o{ Asset : "owns"
    Company }o--o{ User : "members"
    Company ||--o{ Crew : "has"
    Crew }o--o{ User : "has"
    Asset }|--|| AssetType : "is of type"
    Asset ||--o{ Project : "has"
    Project }|--|| ProjectType : "is of type"
    Project ||--o{ Crew : "assigned to"
    ProjectType }o--o{ AssetType : "applies to"

Project Contents

The data created and managed within a project.

erDiagram
    Project }|--|| ProjectType : "is of type"
    Project |o--o| ProjectScope : "has"
    Project ||--o{ ChecklistInstance : "has"
    Project ||--o{ Defect : "has"
    Project ||--o{ InspectionMedia : "has"
    Project ||--o{ ReportInstance : "generates"
    ProjectType }o--o| ChecklistTemplate : "uses"
    ProjectType }o--o{ ReportType : "has"
    ChecklistTemplate ||--o{ ChecklistInstance : "instance of"
    ChecklistInstance ||--o{ Defect : "creates"
    ChecklistInstance ||--o{ Measurement : "creates"
    ChecklistInstance ||--o{ InspectionMedia : "has"
    Defect ||--o{ InspectionMediaOverlay : "has"
    InspectionMedia ||--o{ InspectionMediaOverlay : "has"
    CML ||--o{ Measurement : "has"
    ReportType ||--o{ ReportInstance : "instance of"

Model Descriptions

Company

An organization that can own assets, employ users, and have crews. Companies can be hierarchical (parent/child) and have a role such as owner, subcontractor, or service provider. The connection to a company plays a large part in data access.

User

A user of the system. Users can belong to companies and crews.

Crew

A group of users. Crews are a convenient way to assign work to a person or team. Crews can be isolated to a specific company (subcontractor crews).

Asset

A physical object that is inspected, repaired, or maintained. Assets use a nesting approach similar to a file system to handle arbitrary organization structures (e.g., a facility contains equipment which contains components). Unlike rigidly defined hierarchy systems (e.g. Complex -> Equipment -> Component), HUVR handles simple and complex hierarchies together. In other systems, assets often correspond to an "equipment table". Assets are owned by a company.

AssetType

Defines a class of asset (e.g., "Pipe", "Tank", "Wind Turbine Blade"). Controls features like CML mode and geographic display.

Project

A core unit of work performed on an asset by a set of users. Projects can represent inspections, repairs, surveys, or any variety of work. Projects have a type, a status (initialized, assigned, in progress, published), and can be assigned to crews and/or a third-party vendor (subcontractor). Projects can be nested (parent/child) to represent work packs.

The contents of a project can include media files, digital forms (called checklists in the API), structured metadata around inspection findings, and detailed measurements for flows like ultrasonic testing (UT). The output of a project is delivered as a report. HUVR supports multiple reports per project.

ProjectType

Defines a class of project and its workflow. Can specify a checklist template, available report types, and applicable asset types. Configuration flags control features like measurements, findings, and report authoring.

ChecklistTemplate

Defines the structure of a checklist (digital form), including sections and line items.

ChecklistInstance

A filled-out instance of a checklist template containing the results of an inspection. The data model consists of a checklist template, a checklist instance, and individual changes (checklist edits). Most commonly connected to a project, but can also exist as standalone forms.

Defect (aka Finding)

For historical reasons, the API refers to findings as defects. The UI and end-user documentation use the term "finding", but the API uses "defect". Defects are structured data that capture the where and what for an asset. They are tied to an asset and sourced from a project, making them useful for tracking the condition of an asset over time. Defects can be linked to a CML and are commonly associated with one or more inspection media files.

CML (Condition Monitoring Location)

A specific location on an asset where measurements are taken over time. In many systems, CMLs are equivalent to "TMLs" (Thickness Monitoring Locations). CMLs have a type (pipe, tank, other) controlled by the asset type.

Measurement

A reading taken at a CML, typically through a checklist. Measurements track values and units, and can include derived calculations such as remaining life.

ReportType

Defines the structure, layout, and content of a report. Project types specify which report types are available.

ReportInstance

A generated report for a project. Reports are dynamically rendered and can be exported as PDF.

InspectionMedia

Media files (images, videos, documents) captured during an inspection. The ability to store an unlimited amount of files organized within an asset hierarchy is a core capability of HUVR. Inspection media is normally added to the system through projects and can optionally be linked to a checklist instance or CML.

InspectionMediaOverlay

An annotation overlay on an inspection media file, used to highlight a defect location.