You validate.
You design the creative language.
As Senior Underwriter, you are the gatekeeper of clause quality, the designer of the dimension catalogue, and the custodian of the reference framework. No clause reaches the Actuary without your validation. No reference code, dimension category, or glossary entry exists without your creation.
Your role in the chain
Four roles — one direction. The Senior is both a quality gate and a creative designer.
| Step | Profile | What they do |
|---|---|---|
| 1 | Junior | Writes clause drafts — wording, family, treaty types, dependencies |
| 2 | Senior ← you | Validates clauses. Designs the dimension catalogue (axes + instructions). Maintains the reference framework (families, treaty types, glossary…). Oversees contracts. |
| 3 | Actuary | Builds DAG graphs for validated clauses. Attaches dimensions to nodes. |
| 4 | Manager | Instantiates graphs on contracts. Fills dimension values per node. |
Clauses & lifecycle
You manage the full lifecycle of clauses in the tenant. The Junior creates them; you validate or reject them.
The clause list shows all tenant clauses filterable by status. Click a clause to open its detail panel with three tabs: General (wording, family), Treaty types (which contract types this clause applies to), and Dependencies (relationships to other clauses).
Each clause card displays its identifier CL_NNNN, title, family · status, coloured treaty type pills, and RI terms tags (🏷) with tooltip definitions. This makes it easy to assess clause coverage and glossary tagging at a glance without opening the detail panel.
You can also create clauses directly — use + New clause if you prefer to start from a clean form rather than waiting for a Junior draft.
Validation
Validation is a deliberate, one-click action that unlocks the clause for the Actuary. Only Senior Underwriters can validate.
Before validating, check: wording is complete and unambiguous, family is correct, treaty types are attached, key dependencies are declared. A poorly validated clause will produce a poorly built graph — and the Manager will fill in the wrong data.
Treaty types
Treaty types declare which contract categories a clause applies to. The Manager can only instantiate a graph on a contract that shares at least one treaty type with the clause.
In the clause detail panel, open the Treaty types tab. Select a treaty type from the dropdown and click + Add. Remove types with the delete icon. A clause with no treaty types attached will not be available to any Manager instantiation.
Dependencies
A dependency declares that this clause depends on another clause — for input, as a condition, or as a trigger.
In the Dependencies tab, select a parent clause, optionally a link type (the nature of the dependency), and add a note describing the relationship. This information helps the Actuary understand how to connect graphs via inter-graph links — it is documentary, not technically enforced.
| Link type | Meaning |
|---|---|
| CONDITION | This clause only applies if the parent clause is triggered |
| INPUT | This clause uses a computed value from the parent clause |
| TRIGGER | This clause activates the parent clause |
Dimensions — your creative contribution
Dimensions are the documentary axes that the Actuary attaches to graph nodes and the Manager fills in on contracts. You design them.
Navigate to Dimensions & Instructions in the sidebar. The left panel lists all dimensions organised by category. The right panel shows the selected dimension's details and instructions.
The full chain — your place in it
Creating a dimension
Instructions — the Manager's form
Instructions are the most granular design decision you make. They define exactly what data the Manager enters, field by field.
Think of the instructions for a dimension as the label and placeholder text for a form row. The Manager sees: a numbered badge, your label, and an input field. The quality of your labels determines whether the Manager fills in the right thing without asking for help.
| Instruction type | What it does | Example |
|---|---|---|
| General (first) | Description shown above all fill rows — context and conventions | "Enter monetary values in the contract currency. Leave blank if not applicable." |
| Numbered lines (subsequent) | Each becomes one labelled fill field for the Manager per node | "1. Occurrence limit — 2. Aggregate annual limit — 3. Reinstatement cap" |
Reference tables — overview
These tables are the reference framework that all profiles depend on. You are their sole custodian. Changes take effect immediately across the entire tenant.
| Table | Who depends on it | Impact of a wrong change |
|---|---|---|
| Clause families | Junior, Senior | A renamed or deleted family code breaks clauses that reference it |
| Clause statuses | Senior, all | Wrong status transitions can bypass the validation workflow |
| Clause link types | Junior, Senior, Actuary | A deleted link type breaks declared clause dependencies |
| Treaty types | Senior, Manager | A deleted treaty type removes clause-contract compatibility retroactively |
| Contract statuses | Senior, Manager | A CLOSED status blocks all new instantiations on matching contracts |
| Dimension categories | Senior, Actuary, Manager | A deleted category makes its dimensions uncategorised or inaccessible |
| RI Glossary | All profiles | A deleted term removes it from all clause tag dropdowns |
All reference tables follow the same interface: a list on the left, a form on the right. Click any item to edit it. Use + New to create. The code field is the stable identifier used across the platform. The label is the display name users see.
Families
Clause families group clauses by type — Excess of Loss, Quota Share, Stop Loss, etc. The code is used as a stable identifier throughout the platform.
Navigate to Clauses → Clause families. The left panel lists existing families; the right panel shows the selected entry's code and label. Use + New to add a family. The code must be unique and uppercase (e.g. EXL, QS, SL). The label is the human-readable name.
Clause statuses
Clause statuses define the lifecycle states a clause can be in. The two default states are DRAFT and VALIDATED — do not remove them.
If your tenant requires intermediate states (e.g. UNDER_REVIEW, ARCHIVED), you can add them here. Each status has a code and a label. Only the Senior can transition clauses between states.
Treaty types
Treaty types categorise contracts and clauses. A Manager can only instantiate a clause graph on a contract if they share at least one treaty type.
Navigate to Contracts → Treaty types. Common examples: FAC (Facultative), XL (Excess of Loss), TREATY_XL, QUOTA (Quota Share). The code appears as a coloured badge throughout the Manager interface — keep codes short and meaningful.
Clause link types
Link types describe the nature of a dependency between two clauses. They are documentary — not technically enforced — but guide the Actuary when building inter-graph links.
| Code | Meaning |
|---|---|
| CONDITION | This clause only applies if the parent clause is triggered |
| INPUT | This clause uses a computed value from the parent clause |
| TRIGGER | This clause activates the parent clause |
Add new link types here if your tenant's business logic requires more granular dependency categories. Keep codes uppercase and unambiguous.
Contract statuses
Contract statuses define the lifecycle states for reinsurance contracts. A CLOSED contract blocks all new instantiations — existing instances are preserved.
Default states: ACTIVE, CLOSED. Add intermediate states (e.g. PENDING, SUSPENDED) if your workflow requires them. The Manager sees the contract status label when browsing contracts.
Dimension categories
Dimension categories are the top-level groups that organise the dimension axes you create. They control how the Actuary navigates the dimension picker inside node modals.
By default every tenant has two categories: Context (geographic, temporal, risk axes) and Value (monetary amounts, rates, tables). You can create additional categories if a genuinely distinct dimension family does not fit into either.
RI Terms glossary
A glossary of reinsurance concepts — maintained at the tenant level and visible to all profiles.
The glossary centralises the definitions of reinsurance terms used across the platform. Each entry covers the term and its definition. Terms are used as tags on clauses — visible as badges in the Junior, Senior, and Manager clause lists.
Navigate to Glossary → RI Terms. Use + Term to create an entry. Fill in the term and definition. Existing terms can be edited or deleted — deleting a term removes it from all clause tag dropdowns immediately.
Contracts
The Contracts section gives you full visibility into the tenant's reinsurance contracts and their instantiation status.
You can create contracts, attach treaty types, and monitor which graphs the Manager has instantiated per contract. This is read/write — you are one of the profiles that can manage contracts directly.
Document search
Full-text search across all documents attached to tenant contracts.
Use this section to find specific contractual language across the entire document corpus — useful when reviewing how a clause was worded in a prior contract, or when validating a new clause against precedent.
Maintenance
Cleanup operations for orphan entities created by deletions outside normal flow. Always run the dry-run first.
| Operation | What it cleans |
|---|---|
| S1 | Orphan instruction lines whose parent dimension was deleted |
| S2 | Graphs without a valid associated clause (clause deleted or reverted to draft after graph creation) |
| S4 | Clause-level treaty type attachments pointing to deleted treaty type codes |
| S5 | Contract-level treaty type attachments pointing to deleted treaty type codes |