Level 2 — Assessment: Meridian Specialty Lines¶
For the Candidate¶
The Level 2 assessment is your completed Meridian Specialty Lines configuration, as specified in the Level 2 Brief. There is no separate written exam — your configuration files, DynamoDB specification document, and PDE demonstration together form the assessment.
Your assessor will work through the marking guide below with you in a structured review session. Allow approximately 90 minutes for the full review and demonstration.
Assessment Structure¶
| Component | Format | Time |
|---|---|---|
| PDE demonstration | Live walkthrough — assessor observes | ~40 minutes |
| Configuration file review | Assessor reviews files, asks questions | ~35 minutes |
| DynamoDB specification review | Assessor reviews written document | ~15 minutes |
PDE Demonstration Script¶
The assessor will ask you to perform the following scenarios in sequence. Do not prepare pre-bound submissions — all scenarios must be run live from a blank state.
Scenario 1 — Property STP with referral (20 minutes)¶
- Log in as an Underwriting Assistant
- Create a new Property submission with these values:
- Insured:
Apex Industrial Holdings - TIV: USD 12,500,000
- Occupancy:
Industrial - Year Built:
1968 - Prior Loss History:
Flood damage 2019 — $450,000 loss - Country:
United Kingdom
- Insured:
- Confirm the sanctions check runs automatically on creation
- Confirm the auto-appetite check passes (UK is not excluded, year built is 1968 which is after 1950 — appetite should pass)
- Log in as an Underwriter
- Push the asset schedule to the rater and confirm the premium is returned to the submission
- Confirm the submission enters referral status (TIV > $10m, Occupancy = Industrial, Year Built < 1975, and prior loss history all trigger referral)
- Confirm the referral email notification is recorded (in PDE this may be a log entry — confirm with your trainer what observable evidence is expected locally)
- Log in as a Senior Underwriter
- Approve the referral
- Bind the submission — confirm the Policy Schedule and Referral Summary documents are generated
- Confirm the submission reaches bound status
Pass criteria: All 12 steps complete without errors. Referral triggers on at least one of the four conditions. Documents generated at correct points.
Scenario 2 — Property STP straight to bind (10 minutes)¶
- Create a new Property submission with these values:
- Insured:
Greenleaf Office Park - TIV: USD 4,500,000
- Occupancy:
Commercial - Year Built:
1995 - Prior Loss History: (leave blank)
- Country:
United Kingdom
- Insured:
- Log in as an Underwriter
- Push to rater, receive premium
- Confirm the submission does not enter referral — it should be quotable and bindable directly by the Underwriter
- Bind at USD 4,500,000 — confirm the Underwriter's authority limit allows this
- Confirm Quote Slip and Policy Schedule are generated
Pass criteria: No referral triggered. Underwriter can bind. Both documents generated.
Scenario 3 — Authority limit enforcement (5 minutes)¶
- Create a new GL submission:
- Insured:
Riverstone Logistics - Limit of Liability: USD 750,000
- Jurisdiction:
UK
- Insured:
- Log in as an Underwriting Assistant
- Attempt to quote — confirm the platform prevents it
- Log in as an Underwriter and attempt to bind at USD 750,000 — confirm the platform prevents this (exceeds Underwriter's authority)
- Confirm the Underwriter cannot bind — platform enforces the limit
- Log in as Senior Underwriter and bind — confirm this succeeds
Pass criteria: Underwriting Assistant blocked from quoting. Underwriter blocked from binding above their limit. Senior Underwriter can bind.
Scenario 4 — Property MTA (5 minutes)¶
- Find the bound submission from Scenario 2 (
Greenleaf Office Park) - Initiate an MTA as an Underwriter
- Amend the Total Insured Value to USD 5,500,000
- Confirm the asset schedule is re-pushed to the rater and a new premium is returned
- Bind the MTA
Pass criteria: MTA workflow available on a bound Property submission. Rater re-invoked on TIV change. MTA reaches bound status.
Configuration File Review¶
The assessor will review your submitted configuration files against the checklist below.
Repository structure¶
| Check | Expected |
|---|---|
| No orphaned base repository files present | No master_submission_config.json, dec_submission_config.json, dua/ directory, DUA-CH.json |
| Action files follow naming convention | pr-open-market-actions.json, gl-open-market-actions.json |
| Business class files present | PR.json, GL.json only |
| Rating config in correct location | rating/config/pr/ and rating/files/pr/ |
be_config.json¶
| Check | Expected |
|---|---|
| DUNS number | urn:duns:519274061 |
| No credentials present | No API keys, secrets, or tokens |
| Both currencies configured | USD and GBP |
| Three roles defined | underwriting_assistant, underwriter, senior_uw |
| Authority limits correct in both currencies | USD 500k/5m, GBP 400k/4m per role |
| No feature switches duplicated from DynamoDB | Feature switch values not hardcoded in S3 |
Property action file¶
| Check | Expected |
|---|---|
initialPipeline order correct |
appetite → sanctions → clearance → structured_quote → referral check → bind |
| Sanctions is step 1 or 2 | Yes |
| No hardcoded environment URLs | All endpoints use ${clientRestBaseUrl} or similar variables |
subStatusPipelines entries |
At minimum: STP_QUOTE, STP_REFERRAL |
statusMappings in sync |
Every subStatusPipelines entry has a corresponding statusMappings entry |
completionPipeline defined |
References PR bind pipeline |
| MTA pipeline defined | Yes — re-invokes rater on TIV change |
Referral pipeline¶
| Check | Expected |
|---|---|
| Referral pipeline exists | pipelines/pr_referral.json or equivalent |
| Approve path defined | Pipeline steps for approval outcome |
| Decline path defined | Pipeline steps for decline outcome |
| Email notification step present | Step calling client-rest for referral email |
Email step uses ${clientRestBaseUrl} |
Not hardcoded |
GL action file¶
| Check | Expected |
|---|---|
| Sanctions is step 1 or 2 | Yes |
| Manual quote step defined | No rater invocation |
validate_user_authority on bind |
Yes |
completionPipeline defined |
References GL bind pipeline |
Rating configuration¶
| Check | Expected |
|---|---|
WB_TO_RATER configured |
Push step with correct field mappings |
RATER_TO_WB configured |
Pull step returning premium to submission |
| Asset mapping fields match rater column names | Assessor to cross-check against provided rater Excel |
| No SharePoint site IDs hardcoded in S3 config | Site IDs referenced via DynamoDB variable |
| Asset fields match the PR business class | No fields from other classes |
Document generation¶
| Check | Expected |
|---|---|
| Quote Slip triggered from pipeline step | Yes — not from status change |
| Policy Schedule triggered from pipeline step | Yes |
| Referral Summary triggered from pipeline step | Yes — triggered when referral status entered |
| No hardcoded environment values in templates | Yes — all dynamic values via Handlebars |
| Each template contains minimum required fields | Insured name, class, dates, financial figure |
DynamoDB Specification Review¶
The assessor will review the candidate's written DynamoDB specification document against the following.
| Check | Expected |
|---|---|
| Spec is written as a DevOps-addressable document | Clear instructions, no assumed knowledge |
| All three environments covered | Dev, UAT, Prod |
| SharePoint site IDs specified per environment | Dev and UAT values present; Prod marked as TBC |
| Rater file names specified per environment | Per the brief |
| Email notification config block specified | tenantId present; clientId and clientSecret marked as TBC — to be provided by Meridian IT |
| AWS API Gateway URL placeholder included | Marked as "to be provisioned by DevOps" |
| No credentials included in the spec document itself | Credential fields are placeholders only |
customerImplementationDir value specified |
meridian |