BriteCore View Reference – BriteCore Support

Detailed BriteCore View Reference

The views below make up the BriteCore logical layer, which is identical for all sites and drawn from assets_logical_layer. This list may grow with new releases, so this document may include only a subset. For the current full set and field-level definitions, run SELECT * FROM v_logical_catalog; in SQL Editor.

Discovering Views and Fields

Run the following in SQL Editor to list every available view, its fields, data types, and, where available, descriptions:

SELECT *
FROM v_logical_catalog;

You can also select any view under Available Views in the left sidebar to see its fields and types while authoring.

Materialized (m_) vs Logical (v_) Views

m_ (materialized) views store pre-computed results for faster query performance and often take date parameters, such as an “as of” date or a start/end date. They are the primary fact tables for reporting.
v_ (logical) views are computed on demand and provide dimensions, lookups, and enrichment. Use them in JOINs to resolve IDs into human-readable names and attributes.

Simple Reporting Model: Facts and Dimensions

A helpful way to think about reporting is:

Facts are the core business records or measurements you want to analyze.
Dimensions add descriptive context, such as names, dates, addresses, policy types, or agencies.

In most cases, you start with a fact view and join to dimensions only when you need more detail.

(Dimensions: descriptive labels)
v_policy_types v_insureds v_properties v_agencies
\ | | /
\ | | /
\ | | /
+-----------------------------------+
| FACT (anchor) view |
| m_inforce_policies |
+-----------------------------------+
|
| (filters, dates, grain)
v
Report output rows

Rule of thumb: Start with the dataset that matches your business question, then join additional views only when you need more context.

How to Pick a Starting View

Start with an m_ view when you need a performant, date-driven fact table.
Add v_ views for dimensions, metadata, and enrichment.
Define report grain before joining, for example one row per policy, claim, or transaction.

All Materialized (m_) Views (Primary Facts)

View Name	Category	Description
m_accounting_terms	Accounting	Accounting term details and balances (date-range driven).
m_inforce_policies	Policies	Active in-force policies with status and date logic applied.
m_premium_terms	Premiums	Premium term breakdowns by policy and time period.
m_premium_transactions	Premiums	Premium-related transactions, adjustments, and payments.

All Logical (v_) Views (Dimensions and Supporting Data)

View Name	Category	Description
v_account_history.	Accounting	General ledger-style entries showing transaction history.
v_addresses	Core Entities	Normalized address records for contacts and properties.
v_built_measures	Properties	Standardized building data for properties (for example, square footage).
v_claim_change_log	Claims	Historical log of claim modifications and updates.
v_claim_items	Claims	Items associated with claims, such as vehicles or property.
v_claim_payments.	Claims	Payments issued on claims, including loss and recovery.
v_claims	Claims	Master claim records including identifiers and status.
v_claims_contacts	Claims	Relationships between claims and involved contacts.
v_claims_dates	Claims	Date milestones related to the claim lifecycle.
v_claims_perils	Claims	Perils associated with each claim (for example, fire or hail).
v_commission_details	Commissions	Line-item detail for commissions payable.
v_commission_payments	Commissions	Payments made to producers and agencies.
v_contact_relationships	Core Entities	Relationships between contacts.
v_contacts	Core Entities	Contact data for individuals and organizations.
v_counties	Core	County reference data.
v_custom_data	Core	Custom key/value data.
v_dates	Core	Standardized date dimension.
v_files	Core	File attachments such as images or documents.
v_insureds	Policies	Named insureds and associated metadata.
v_json_property	Properties	JSON extraction for property reporting.
v_json_property_item	Properties	JSON extraction for property-item reporting.
v_json_revision	Audit	JSON extraction for revision reporting.
v_json_revision_item	Audit	JSON extraction for revision-item reporting.
v_logical_catalog	Metadata	Technical metadata about views, templates, and logic.
v_losses_incurred	Claims	Calculated incurred loss on claims.
v_mcas_system_tags	Core	MCAS system tags.
v_notes	Core	Internal notes logged in the system.
v_payment_batches	Payments	Grouped payment transactions for processing.
v_payment_methods	Payments	Payment method definitions.
v_payments	Payments	Individual payment records across modules.
v_permission_rules	Security	Permissions and access rules assigned to roles.
v_policy_change_log	Audit	Policy change history.
v_policy_type_items	Policies	Line-level items defined by policy type.
v_policy_type_items_forms	Policies	Policy type item forms.
v_policy_types	Policies	Policy type definitions used across quoting and workflows.
v_policy_types_forms	Policies	Policy type forms.
v_properties	Properties	Property-level data such as addresses and types.
v_properties_contacts	Properties	Properties linked to contacts.
v_property_items	Properties	Items at properties, such as buildings or valuables.
v_recoveries	Claims	Recoverable amounts including subrogation.
v_return_premium	Premiums	Calculated or refunded premium amounts.
v_revision_items	Audit	Item-level changes across policy revisions.
v_revisions	Audit	Master audit records for policy changes.
v_revisions_agencies.	Audit	Agency details tied to policy revisions.
v_revisions_contacts	Audit	Contact data tied to specific policy revisions.
v_roles	Security	User roles and associated metadata.
v_system_tags	Core	System tags for categorization.

Common Join Starters (Expert Patterns)

Use these as starting points when building reports:

Policies: m_inforce_policies -> v_policy_types, v_revisions, v_insureds, v_properties.
Claims: v_claims -> v_claims_dates, v_claims_perils, v_claims_contacts, v_claim_payments
Premiums: m_premium_terms / m_premium_transactions -> v_return_premium, v_account_history
Audit and lineage: v_revisions -> v_revision_items, v_revisions_contacts, v_revisions_agencies

In plain language: start with the main dataset that matches your business question, then join only the supporting views you need.