Topics on this page

BriteSuite high-level data models


The BriteSuite platform is a SaaS solution with services built to drive business operations through a fully–managed insurance platform. The platform is a single-tenant system—a dedicated deployment environment instance per tenant, with no sharing of data or computing resources except for a small set of infrastructural elements and backend scripts (monitoring, scheduled jobs, and configurations).

BriteSuite comprises a set of RESTful services that enable specific modules that are deployed as serverless lambda functions. Each BriteCore service endpoint is associated with a respective lambda function—modules developed in Python.

This document outlines a high-level description of the BriteSuite data models within each of the main modules.


BriteLines allows insurers to model the fields, rates, rules, and forms associated with the insurance products. Lines may be inherited from templates and versioned by date and jurisdiction.

Line of business

The line of business (LOB) describes a product or set of related products that make up a particular insurance offering. It represents a “type” of insurance. LOBs are the highest hierarchical entity in a Lines configuration.

Examples of LOBs

  • Homeowners – Personal
  • Private Passenger Auto – Personal
  • Farmowners – Personal
  • Standard Fire & EC – Personal
  • Long Haul Truckers – Commercial
  • Commercial Liability – Commercial
  • Cargo – Commercial
  • Cyber Liability – Commercial

Review the BriteLines documentation for more details on this product.

BriteLines data model 

Figure 1 illustrates a high-level overview of the BriteLines data model.

Figure 1: BriteLines data model.

BriteLines uses a core data structures organized in the following manner:

- Lines
    - Risk Types
        - Fields
        - Tables
        - Calculations
        - Line Items

Data is defined in the LOB and later feeds into all other modules within BriteCore such as BriteQuote, BritePolicies, BriteClaims, Reports, and BriteDocs. 


Product describes a particular insurance offering within a LOB. For example, the product HO-Commons can be defined under Homeowners. 

BriteLines has two important functionalities: Inheritance and Versioning. Lines can be straightforward, with just a collection of risk types with a single version, or complex, with risk types inherited across multiple products (inheritance) and changes that exist in multiple versions with different effective dates (versioning).


Inheritance allows models to share common definition ancestors. This allows common data elements to be defined in an upstream template LOB product, then used repeatedly through inheritance into specific LOB products that extend the base product. For example, there might be a Homeowners product that defines 80% of all HO business, but then inherits HO-Common into HO-2, HO-3, and HO-5, each of which introduces new items, rates, and rules.


  • HO-Common
    • HO-2
    • HO-2-MO
    • HO-2-KS
    • HO-2-OK
  • HO-3
    • HO-3-MO
    • HO-3-KS
    • HO-3-OK
  • HO-5
    • HO-5-MO
    • HO-5-KS
    • HO-5-OK

Each line can have multiple products. In the above example, the LOB is Homeowners, with the root product HO-Common and other products HO-2, HO-3 and HO-5 inherited from the HO-Common product. This is handled via the lines.product model.


Line, risk type, and all entities of risk type are bound to a version. A version is composed of a name and an effective date. The effective date tells when a certain LOB, risk type, or entity is going live/is effective from.

Once a LOB or risk type is live, users shouldn’t be able to make changes to it. Instead, users will create a new version with a new effective date and make changes there.

Risk types

Risk type refers to a types of risk that gets insured. Different LOBs target different risks. BriteLines offers risk templates for real-world entities. For example:

  • Auto: Driver, vehicle. 
  • Homeowners: Home, homeowner, swimming pool, shed.

Almost every risk type has a parent. The only risk type without a parent is called the root risk type. Multiple risk types can have the same parent. These sub-risk types are considered the parent’s children.

Each child risk type can also be a parent to other risk types.

A risk type models the fields, rate tables, calculations, and line items that follow a particular type of risk. Lines are parents of risk types.

Risk type data model 

Figure 2 provides a high-level overview of the risk data model.

Figure 2: Risk data model.

Risk types are parents of: 

  • Fields: Describe facts about a risk or pieces of data needed to collect about the risk. 
  • Rates: Rating calculates the premium and fees due on a policy. 
    • Calculations: Advanced tool to rate risks.
  • Coverages: Insures an exposure against a peril. For example: 
    • Collision: Personal Auto coverage that insures property damaged during a collision.


BriteQuote and BritePolicies work together to handle different processes of the policy lifecycle.

BriteQuote includes the three key components:

  • Quote flow
  • Underwriter workbench
  • Quote status tracking

Figure 3 summarizes the policy data and processes. 

Figure 3: BriteQuote and BritePolicies data and process differences.

Review the BriteQuote documentation for more details on this product. 

You can’t instantiate quotes without a LOB definition in BriteLines. BriteLines includes a rating engine, which is a service that evaluates field answers and items (coverages) on a quote or policy and provides a premium.

BriteLines defines all of the data points that will be captured and evaluated during a quote, so it’s important to understand the structure of the LOB before working on building a quoting front end.

The quoting front end won’t interact with BriteLines directly. Instead, the quoting front end will submit requests to BriteQuote, which will communicate with BriteLines to create new quotes for a given line and new risks from a given risk group.

The BriteQuote data model mimics BriteLines product hierarchies and inheritance. Refer to our product inheritance documentation for more information.

BriteQuote data model 

Figure 4 illustrates the BriteQuote data model. 

Figure 4: BriteQuote data model.

Refer to our BriteQuote screen flow documentation for an overview and for a technical deep dive into the BriteQuote screen flow components and configuration, refer to our technical documentation.

BritePolicies data model 

BritePolicies interacts with other products in BriteCore such as BriteLines, BriteQuote, BriteRules, and BriteDocs to allow you to:

  • View policy information, including contacts, insurable risk, coverages, limits, and premiums.
  • View policy transaction history, including when, what, and by whom.
  • Compare transactions; you can view what was changed and the previous endorsement.

Figure 7 illustrates the BritePolicies data model.

Figure 7: BritePolicies data model.

A revision is the foundation of a policy and tracks the changes made to a policy over time, including written premium. The following revision states indicate whether the revision’s information is in effect:

  • Committed: The data associated with the revision is in effect and can be reported on.
  • Open: The data associated with the revision is in progress and, therefore, isn’t in effect and can’t be reported on.
  • Pending: The data associated with the revision is in progress and, therefore, isn’t in effect and can’t be reported on.
  • Archived: The data associated with the revision was at one time in effect and can be reported on.

Refer to our documentation for an overview of the BritePolicies screen flow on how the UI is structured. And for more details on BritePolicies features on our end-user documentation.


BriteClaims enables organizations to manage the full life cycle of property and casualty (P&C) insurance claims from FNOL to settlement. Refer to our BriteClaims documentation for more details on this product. And refer to the BriteClaims screen flow documentation for more details on how the UI is structured.

Figure 9 illustrates the BriteClaims data model.

BriteClaims data model 

Figure 10: BriteClaims data model.

BriteClaims system connects to BriteLines through the data hierarchy and will inherit from BriteLines product and coverage information unique to a line of business. When the FNOL is created and a policy selected, the claims system will know which LOB product configurations (LOB/State) from BriteLines to apply to the claim based on the policy effective date and date of loss.

The BriteLines product information will tell the claim system:

  • Screens that will be presented for the LOB and coverages.
  • Values displayed in drop down lists on these screens (Reference Table configuration).
  • Coverages that can be claimed against.
  • Reserve and payment categories that will be available for each coverage.
  • Correspondence that will be made available.
  • Rules that will be applied.

Product configuration and changes are managed in BriteLines and will be pulled into BriteClaims to minimize configuration in BriteClaims for the support of new product versions. BriteClaims takes a feed from any product configured in BriteLines. If the client publishes a new version of a product, BriteClaims can be configured to recognize that version and can manage unique data elements that may come from that version.

BriteClaims also works closely with the following BriteCore services: 

BriteClaims Financial Modal

The BriteClaims Financial Modal maps any product in BriteLines to the reserve, payment, and transaction setup in BriteClaims. The Financial Modal can be configured to the unique needs of each coverage in a product.


BritePolicy provides a snapshot of policy, coverage, limit, and insured details at the time of FNOL. BritePolicy is attached to a claim at FNOL and imports all information needed to support claims processing.

Mock Policy Modal

The policy information retrieved by BritePolicy is displayed in the claims system during policy validation at FNOL. The policy information is a snapshot of that policy as of the loss date. This module will provide adjusters with the information they need for coverage investigations without having to go to BritePolicy directly.


Any claim event can trigger a rule, which defines the workflow. You can configure rules to be simple or complex depending on your processes.

Refer to our FNOL overview documentation and the BriteClaims Home overview documentation for more details.