2023-01-13 Meeting Agenda

Tracked down some test data; looked at stat plan
Realization: Using same stat plan as personal auto but 2 columns interpreted differently.
1. Personal has a column for good student discount and for private passenger/penalty points
2. Commercial has two columns for automobile classification/commercial automobile use (line 35)
3. Otherwise they are exactly the same tables
We're looking specifically at Position 34. We have codes 1-5 coming in for Personal Auto, and Codes 1-9 for Commercial. We interpret 1-5 and 1-9 a bit differently. Key difference: Subline 1 is personal auto and Subline 2 is Commercial.
Position 35 - Private Passenger Penalty Points vs Commercial Automobile Use
PA key question: do we want to have a separate policy and a separate claim table for commercial? Or do we want to just have some extra columns and put all the auto in together? This discussion may bridge the gap between AWG and business matters. PA asked James his thoughts:
1. JM: this is half business and half architecture. The two different lines (personal/commercial auto) are fairly similar, but key differences exist. There are two ways to solve it - and no "free lunch":
  1. Multiple disparate concepts can be put in the same table (in the same record) but if we do that, we pick up a sparsity problem - which is - if you have the concept of an auto (and it's insured auto, because auto wouldn't know the concept of personal vs. commercial) - i.e., we've embedded two concepts, here. We have the concept of a covered vehicle, and we have to put attributes in it. A covered vehicle will have a VIN - same for both personal and commercial.
  2. We have numerous non-sparsed columns. They will all be 15-30-80 - things affiliated with the auto itself. At some point we find ourselves with attributes in one or the other that don't apply to both. We might have two attributes that are basically but not completely the same for personal/commercial, and it needs to be filled in differently for each.
  3. We typically say - all things being equal, keep things simple - but embedding in one table is not simple. But neither is making lots of tables simple - they need to be connected.
  4. Most people prefer flatter, wider tables - and one of our guiding principles on openIDL is that we go in this direction unless there is some reason not to.
  5. If the sparsity problem is broad, however, we may want to start breaking up tables in that instance.
  6. Here JM invited thoughts/feedback from the group:
    1. DH: right now we're getting one auto file right now that has both personal and commercial. He is unsure if this lends to one or two tables. The other consideration: as they went through the commercial/personal auto plan, they ended up with many more fields than are available personally. Longer term we will have many in personal that we don't want in commercial and vice-versa.
    2. JM: a business question to ask: -how related are these business concepts, but also: -how many common vs. disparate attributes are there? And architecturally do we spread this out?
    3. DH: Confirmed that the stat file they send to AAIS has both personal and commercial - the reports that they send out are not necessarily the same. They break it up. (SD: there is a field that distinguishes personal from commercial).
    4. PA: called on JT who confirmed - coverage report does have both the personal and commercial on it. (Submitted to NAIC combined for filings).
    5. JM: looking at this philosophically from perspectives of pattern and scale. The problem is that if we look for example at position 34, and only viewed the #s, we would have no idea if a given categorization is personal or commercial. Anytime we have this behavior, where we have to look at another column to understand an initial column, this drives business intelligence (BI) tools crazy, because this is an embedded rule. The upshot of an embedded rule is saving technical space, but the presence of BI tools - looking at one column to grasp another - creates numerous issues for the tools. We generally want to avoid this, but will pick up table complexity as a downshot.
    6. The best option may be to remove as many embedded rules as possible, and pursue building/adding additional tables as an alternate solution. In theory, numerous tables should not pose a problem.
    7. PA: in building extraction pattern, he started off with only personal auto. For a while, they've been talking about doing premium and loss tables. They changed the names however to auto policy and policy claim table.
    8. They currently have an auto policy table and an auto claim table combined. When PA runs his extraction pattern, the first thing that happens: it creates a temporarily table that merges these two together. If we broke commercial out into its own thing it wouldn't really change the extraction or merge process. PA: very much leaning toward breaking commercial out into a separate table.
    9. JM: agreed - his recommendation is pull these out (commercial). Avoid embedded rules which will create much bigger problems later w/slicing and dicing data.
    10. PA: interpretability would be the same; we are eliminating the sparsity. Because after ETL we are abandoning If/then/that and we will be decoding. Once he loads into the table it is no longer positional.
    11. JM: In other words, PA is eliminating the embedded rule issue by introducing the sparsity behavior. PA: by splitting columns, eliminating ambiguity problem. Several options: We can embed the rule, or we can introduce sparsity, or break up the tables (3 basic options). This is a design issue. from a business perspective: we have to say to the business, how many attributes are you going to have? If it's 3 or 4, you live with the sparsity.
  7. JM: should we live with reasonable sparsity? This is a business decision - we should have a threshold however. (No more than a dozen items each?)
  8. PA: wants to revisit this equation next week after he reviews the categorizations and gauges which do or don't apply to sparsity.
  9. PA: wants to ensure that we have the proper raw tables to fulfill our own business needs. If we break out commercial auto into its own entity now, that's an easy move, and will help us avoid problems later on.
  10. JM: agrees that separating them out (bottom up - as we encounter it, we do it) for "cleaner" results. However wants to have the discussion in the case of each line "where do we see this going?" In other words, having a vision discussion (anticipatory).
  11. DH: on the commercial side we aren't necessarily tying a driver to the vehicle. But are insuring the vehicle, not the person (identified through VIN, not DOT #). On personal side, they assign a driver but this is not necessarily how rating is determined/applied.
  12. JM & DH: we are limiting selves to 1 driver/vehicle because of stat.
  13. DH: also keeping personal and commercial separate because of the fact that we have combined ratings.

Discussion items

Time	Item	Who	Notes

Space shortcuts

Page tree

Date

Attendees

Minutes

Discussion items

Action items