Bright — the reinsurance brokerage system

Bright is Nextera’s reinsurance brokerage system. This documentation is written for internal teams — implementation consultants, support, business analysts and new engineers.

Internal documentation

These pages name tables, stored procedures, known defects and security weaknesses. The content comes straight from the code and the database, not from marketing material.

Do not copy the technical sections or the security findings into anything customer-facing.

What to read first

The order that works best depends on your role.

Role	Start with
New engineer	Architecture → Platform conventions → LOV
Implementation consultant	Platform conventions → LOV → Rules engines
Support	Entity lifecycle → Modules
Business analyst	Modules → the relevant module page

What Bright is

Frontend	Angular 19 + Fuse + DevExtreme
Backend	.NET 8 Web API, four projects, raw ADO.NET — no ORM
Database	MSSQL 2022 — 197 tables, 137 views, 247 stored procedures, 67 functions
Functional modules	43
Reference-data screens	38
API endpoints	~592

The business logic lives in the database

Bright uses neither Entity Framework nor Dapper. Every business behaviour — validation, status, premium calculation, journal posting — lives inside stored procedures.

Reading the C# alone will tell you nothing about the business rules. The C# layer only passes parameters and maps results.

The five areas

flowchart LR
    A[Contracts<br/>party and contract data] --> B[Operation<br/>placing risk]
    B --> C[Finance<br/>billing and payment]
    C --> D[Accounting<br/>journals and ledger]
    E[System<br/>parameters and access rights] -.governs.-> A
    E -.governs.-> B
    E -.governs.-> C
    E -.governs.-> D
    D --> F[Report]

Area	What it holds
Contracts	Client, ceding, reinsurer, agent, customer, vendor, policy, treaty, facility
Operation	Request, quotation, proposal, simulation, costing, bordereaux, billing, claim, claim advice
Finance	Invoice, payment, voucher, receipt, instruction, adjustment, tax invoice, batch invoice
Accounting	Journal, ledger, trial balance, period, asset, depreciation, revaluation
System	Parameters, users, access rights, queue, batch, upload

The detail on each module is in Modules.

The conventions that matter most

Four things recur in every module. Understanding them once saves a great deal of time.

Convention	Why it matters
LOV	Two different mechanisms both go by the name LOV. It is the most confusable term in Bright
Entity lifecycle	Status, approval, queue and audit are shared by every module
sp_get	One 535,000-character procedure with 390 selectors serves almost every read
Rules engines	Accounting behaviour is configured in data, not code

The document map

Platform conventions

• Platform conventions — object naming, sp_get, the response envelope
• LOV & reference data
• Entity lifecycle
• User & access right
• Autonumber
• Rules engines
• Slips & templates
• Batch & upload

Modules and flows

• Modules
• Architecture

Before you start

• Reinsurance broking concepts — if terms such as cedant, cession, facultative, quota share or bordereaux are unfamiliar, read this first.
• Getting started — access, environments and navigation.