[Cyber] Do not include implicit business logic in the schema design

[SeanHalversonGW]

Description

• Encoding business logic in a column is a practice best avoided. For example, the coverage columns ask for monetary values, but then use 1 to mean coverage is included if there's no sublimit/deductible.

Reasons for change

My guess is that this idea grew out of the sort of convention that often appears on coverage forms. The idea being there is often only coverage for line items which show premium, or a non-zero value on those forms. So just as nominal placeholders are used to indicate there is coverage, it appears that idea is being used for the schema design.

I could be wrong on my guess, but I do see the importance of getting an affirmative answer to coverage questions.

A better design could use binary variables to indicate when there is coverage and leave the limits and deductibles solely for the purpose of representing a monetary coverage-impacting value. Explicit is better than implicit or quasi-implicit.

A question I have as well is, if blank or zero indicate absence of coverage, what does a value of null mean? Null is roughly equivalent to blank from an Excel standpoint, but from a database design one it is quite different.

[johcarter]

@SeanHalversonGW I tend to agree, and also mixed meaning fields are not in the style of the rest of OED. I'm assuming you're referring to the Cyber coverages here?

We are currently reviewing Cyber v1 for more alignment with OED for property and this is one of the things under consideration. Thanks for raising the issue. We welcome anyone else's opinion for introducing separate binary fields to indicate inclusion/exclusion for financial coverages.

[SeanHalversonGW]

Hi Joh, Correct, I had only been reviewing the Cyber coverages portion of the framework. Is there any sort of documentation which summarizes the review and how you're aligning cyber and property? Would be interested to have a look at that as I have a background in both LOBs. Best, Sean

…

On Wed, Mar 6, 2024 at 9:21 AM johcarter ***@***.***> wrote: @SeanHalversonGW <https://github.com/SeanHalversonGW> I tend to agree, and also mixed meaning fields are not in the style of the rest of OED. I'm assuming you're referring to the Cyber coverages here? We are currently reviewing Cyber v1 for more alignment with OED for property and this is one of the things under consideration. Thanks for raising the issue. We welcome anyone else's opinion for introducing separate binary fields to indicate inclusion/exclusion for financial coverages. — Reply to this email directly, view it on GitHub <#173 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCR3VE46NEYREQH7US3FM4LYW4X53AVCNFSM6AAAAABB67MWG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBRGEYTIMZZGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[MattDonovan82]

@SeanHalversonGW we are just in the process of reviewing and updating the cyber schema to align with OED as Joh says which will be released as part of OED v4. We will add the updates to cyber in the coming weeks for your review and feedback before releasing v4.

[aiste-kalinauskaite]

It is worth aligning OED non-property schemas with OED property as much as possible, following the same logics for naming conventions, adding pre-defined values, having ranges set-up, etc.

[johcarter]

Yep totally agree. We are just finalising aligned cyber and liability specs for technical working group review shortly @aiste-kalinauskaite @SeanHalversonGW

[johcarter]

Hi @SeanHalversonGW here are the detailed proposals for the Cyber1 spec, in particular see the introduction of the PolCoverage field which indicates which coverages are included, instead of using 1's and 0's in the deductible/limit fields.

The spec will be integrated into the main OED property spec in v4, please see #182 for more information

Please feel free to provide feedback or suggest improvements

thanks
OED_Cyber_Data_Spec_integrated_v1.xlsx

[MattDonovan82]

@SeanHalversonGW anymore comments on this?

[SeanHalversonGW]

Nothing more to add. Thanks all.