Sean Bohan (openIDL): alright.
Sean Bohan (openIDL): We are now recording let's kick off this April 11 edition of the architecture working group for open ideal, as usual, open ideal meetings are.
Sean Bohan (openIDL): covered under the Linux foundation antitrust.
Sean Bohan (openIDL): policy if you have questions about the antitrust policy feel free to contact your company Council or ended up to grub of the firm gizmo up to growth llp who provides.
Sean Bohan (openIDL): legal counsel Linux foundation.
Sean Bohan (openIDL): i'm going to do attendance i'll fill in names, as we get started i'll do that all y'all or or or just having a discussion.
Sean Bohan (openIDL): With the agenda for today is pretty simple, we want to continue the discussion around the open ideal adapter and the Member enterprise, we had started this last Monday we continued in the tasc call on Thursday.
Sean Bohan (openIDL): And i'm going to turn the MIC over to Ken and let him kick it off and can, if there after this call for any other diagrams you want me to start, including in the agenda docs we do link out to things when I have the URLs but just let me know.
Sean Bohan (openIDL): Europe can.
Ken Sayers: You know these URLs are all internal right now, a published documents as they seem you know usable by people.
perfect.
Ken Sayers: So, David we didn't have you on Thursday, when we were continuance justice.
Ken Sayers: be able to see my screen.
David Reale: And we had a Thursday meeting.
Ken Sayers: Every other week or the tlc needs.
David Reale: By not have that.
Sean Bohan (openIDL): we're.
David Reale: gonna have that meeting.
Sean Bohan (openIDL): I am going to individually invite everyone wants to.
Get.
Sean Bohan (openIDL): Oh sorry I apologize for that.
David Reale: I have a meeting this week.
Sean Bohan (openIDL): This Thursday.
David Reale: yeah i've got one on to the 14th it looks like.
Sean Bohan (openIDL): All right, David, let me check in with you offline on that one.
Ken Sayers: that's interesting um alright, so we kind of left off talking about.
Ken Sayers: The the adapter.
Ken Sayers: that's the sky.
Ken Sayers: Talk I don't take good notes, you know exactly where we left off, we were trying to.
Ken Sayers: Talk about next is basically, I know that we wanted to talk about how we host the adapter and what is the technology that we keep the different pieces.
Ken Sayers: Like what container technology we use docker or something, how is what is the adapter itself.
Ken Sayers: Is it something that we're prescribing or is it just assuming it's a container.
Ken Sayers: management system that runs that and how do we integrate with the other pieces of the architecture.
Ken Sayers: So.
Ken Sayers: don't have a specific spot to pick up, I think we can just start talking about the pieces that are in the adapter and.
David Reale: What did we stop by a film on what the function of the adapter are I assume that's what was discussed on Thursday.
David Reale: So me.
Ken Sayers: yeah yeah so.
Ken Sayers: we're talking about the different pieces of this.
Ken Sayers: What what each one does.
Ken Sayers: Right, but I don't remember exactly how much we say on Thursday versus last Monday, so we can just go back through the flows, because one of the one of the open items was where's the.
Ken Sayers: where's the consent take place, and I think i'd like to do to go back to that particular item and say is consent, something that has to happen before.
Ken Sayers: Before an extraction so can we consent.
Ken Sayers: When we can send us the extraction have to happen right when we consent right we kind of didn't really at least I didn't capture the note of what's the reality there right we talked about the flow of putting the data into the hdfs But then when you consent, you might consent.
Ken Sayers: In general, for.
Ken Sayers: For data calls and they automatically happen.
Ken Sayers: But so that the extraction would happen on our specified date for a data call, and I think the same was true because of data calls the same would be true for sorry it's because that works for step.
Ken Sayers: statistical reporting will do the same thing for data files that you can consent anytime but it wouldn't be drafted until.
Ken Sayers: The maturity of the data call or the maturity of this step, just the score report did we decide what the reality there is.
Ken Sayers: i'd like to write it down.
Ken Sayers: Remember that discussion Truman you participated in that.
Sean Bohan (openIDL): we've got a recording and I can I can look at the transcript right now, if you if you want to keep going.
Ken Sayers: Because it's kind of an important part about how this thing runs right if you.
Ken Sayers: If you can send two weeks ahead of the finish of the data call.
Ken Sayers: Then.
Ken Sayers: Any extraction runs then then you're assuring that all the data required for that data call is there already and can't really do that, first, that report.
David Reale: That we have to make the decision of what the business process is going to be like today, as opposed to just the functionality exists to consent or not, we need to decide how we want to run it but.
Ken Sayers: No, we don't.
Ken Sayers: functionality it's an open thing so it's a good point we can talk about there's a consent, that has to happen and then there's an extraction has to happen right so.
Truman Esmond: For that you need to know what is available to consent to right, so the the the first transaction is the every every every day right is the data available.
Truman Esmond: For whatever it might be needed to be used for right that's So if you go back to the other diagram you just had what's The thing that occurs when the tl happens.
Truman Esmond: That data is loaded harmonize data store and a and a test station of data being now in the system is saved up to the network as a hash of a new chunk of data right.
Truman Esmond: In order for this thing to in order for that data to be used for multiple cases there needs to be some level of access station of quality and integrity of that data.
Truman Esmond: Right, such that it can be, you know that now it's there for many purposes, not we're going to add it after you ask or.
Truman Esmond: You know, try and you know unwind that thing you know when the request comes in that wasn't anticipated right, so that the first data station that.
Truman Esmond: needs to be made to the network, the first transaction is another X of data was loaded and is suitable for reporting let's say you will start reporting.
Ken Sayers: Right, so I thought, one of the things I thought we had decided was that really the yeah the station has to happen that extractions because there's different.
Truman Esmond: You can yeah.
David Reale: yeah I think.
Truman Esmond: it's too.
David Reale: complicated to try to say okay I if I do a data load and say there's 13 data calls or Stat plans that could all be.
David Reale: satisfied by that chunk of data I don't want to write 13 yep the set satisfies this and this I think it's more about on extraction, there is a check that says yes, this data.
David Reale: meets the requirements right I don't think it's.
Truman Esmond: junior the entire year each time because.
Truman Esmond: If any part of it fails, the whole integrity of the whole is lost.
Truman Esmond: Right.
David Reale: yeah let.
Truman Esmond: me fragile right until you say you know if you again, you need to verify that the data has integrity, when you extract it, yes, otherwise it's not eligible for extraction, but you.
Truman Esmond: know.
Truman Esmond: But it's got to be maintained maintained.
Truman Esmond: Before extraction before consent is even an option right.
David Reale: I don't think so, I mean if we're writing.
David Reale: Data every day right because that's the same we get to that point where every day it gets written.
Truman Esmond: What do you maintaining every day.
David Reale: If, for example, every again we're not going to do every day.
Truman Esmond: Every day, today, the state of a policy exists right, the question is how how how accurate, is it is it to the day to the minute or two.
David Reale: I feel like you don't need to attest to that every time you make the right So if you made an hourly right or daily right or a monthly right you don't have to test that this is good to this granularity this granularity this baby this granularity you.
Truman Esmond: know just a level is it good enough for statistical reporting data like is it so.
David Reale: Why why can't that occur on extraction I don't see a reason why it can.
Truman Esmond: It can, but only when it does, the one thing when it does anything else, like when you want to use, for you know different data for something other than.
Truman Esmond: The original intended purpose you've got to rewind the whole thing, and the problem is that we're dealing with chunks and batches right now, not a definitive.
Truman Esmond: bookended segment of data that you know, like what we have is one line of business one month one company is kind of the smallest.
Truman Esmond: granularity but it's not tracked in that way it's tracked as it's loaded right so as a batch on a chunk, which is a functional level of integrity.
Truman Esmond: So when it's used for only one purpose that's fine, but if that if any chunk or batch loses it right, so you go back and say oh yeah I want to rehash this data.
Truman Esmond: To see if it's if it matches when I go time to use it, the the odds of that working if there's no mechanism to make sure the elements that make up.
Truman Esmond: You know the time period, you know again the data that's being requested, but again it's just policy data over a time period right.
Truman Esmond: client experience exposure experience, whatever that experiences over time period if each policy is known to if the history of each policy during the time period is known to be good.
Truman Esmond: Then we're good if some policies are known to not be good or slower than you can degrade your data pool if some of its very high confidence very fast some of its.
Truman Esmond: Less fast less high confidence, you can eat the pool can be used for different things, and at some point it's not good enough to be used in its entirety, for any particular thing.
Ken Sayers: One of the one of the other things, we talked about was establishing certain.
Ken Sayers: What what the word is but as part of the standard.
Ken Sayers: Certain tears or levels of verification that the data can be, for which the data can be tested right, so that you say this is month good monthly data for statistical reporting.
Ken Sayers: or whatever that means or it's is to level three so that we can do you know reports on bins I don't know what those are but as part of the standard.
Ken Sayers: We we define those we, the only way to attest that that your data is meeting those before data call comes along is to have those specific things.
Ken Sayers: Clear right, so that when when you put data, you can say my data meets the standard and then, when a request comes along and says, I the data must meet this standard for me to execute right now.
David Reale: I think what i'm trying to get at is, we want to get out of having to keep track of and attest to a lot of different granularity it satisfies to us what we really want is here are the data elements that need to exist.
David Reale: Then you must maintain them in this format that's it right and we don't have to worry about.
David Reale: it's all captured by the fact that the data should exist in this format in this store right, and if we maintain that than any checks against that data, you know, assuming we are.
David Reale: Loading it.
David Reale: Then, maybe there's a message that needs to be in there about this late last data load is valid up to some time and that can be some metadata that gets.
David Reale: Added somewhere, we can figure that out, but that's all we should have to do, and then, if the check for a data call or step plan says hey you know this data needs to be good from this period to this period, it must be of a certain format and it must be so.
David Reale: Fresh say it fresh I don't know I don't want to get it, I don't know exactly all the requirements that it must be but it checks all those boxes.
David Reale: Then okay pull the data does that make sense we don't want to have to think about those things we just want to be put the data into this store in the agreed upon format and that's it.
Ken Sayers: But we do, we do have to know that the data meets that standard so now, how do we, how do we.
David Reale: Should well that should be.
David Reale: That should be accomplished by the data standard itself right So if you need.
David Reale: Data from January to January of 2019 in some format and it must be accurate as of what date, those are the requirements right, it has these fields it's accurate as of this date, there is nothing left out.
David Reale: that's the data standard and you should be able to check that really easily on extraction by saying you know either by self inspection of the data that can be a little tricky or by some maybe metadata that is written like when is this date this data validation.
Ken Sayers: I think that's that's my my question is, do we expect the atl to place a piece of data metadata in into the hdfs that says.
Ken Sayers: I just put an eye test that all of the data for the month of January for Bob is there to this level, like some somebody's got to because we, the extraction can't ask the data are you valid right it can't it doesn't mean.
David Reale: I guess, in theory, you could, but it would require the latest valid latest date.
David Reale: upload to be considered the fraction of state right you could infer it right in theory.
Ken Sayers: If you don't have any transactions state which you guys.
David Reale: But it's not the best way to do it right, so I think it'd be better to in the standard put a little piece of metadata or two that makes it explicit I think that's preferable.
Ken Sayers: Right, so we buy explicit that means the email has put it.
David Reale: yeah yeah it, you know or yeah However we define it right it's probably the same email process.
David Reale: Most likely.
David Reale: But because I could see a case where the hcl run the day after the next validate right so.
David Reale: You know all data valid through January 31 but the tl ran February 1 right.
David Reale: So you want it to be explicitly say it's blue January.
Ken Sayers: Right yeah.
David Reale: I think that'd be easier, because that is the couple's it and then it allows whatever data call author or step plan author to say hey they basically told me the cities of the data elements are they all there yep in order to run this I need valid data for all.
David Reale: Is it, saying that this data is.
David Reale: Fresh through the end of 2019 yes extract.
Ken Sayers: So what what happens when a new data call comes along that requires different data configuration, a new field, or that wasn't there before.
David Reale: Well, that to me it's kind of like a business process discussion about how we want to handle that the idea to me would be.
David Reale: People data call authors should try for the most part, most difficult to sit within the bounds of what's already there and then, when there is a desire to add.
David Reale: that's done through a separate process right and.
David Reale: I thought that was through like the likes and.
David Reale: dislikes i'm not there's a dislike button, but the likes and then, if they say hey, this is the new data standard because we got enough consensus that we want to add these elements that just becomes new elements that get added, but those should be very rare.
Ken Sayers: yeah, so I think my question, it sounds obvious but there's a nuance I want to chase right so.
Ken Sayers: Clearly, if we if we have new data required we've got to change the standard to add a new tear or change a tear to say this now includes this.
Ken Sayers: So what i'm wondering is, do we have to go against data that's already been published and retrofit that or is it always a moving forward kind of thing that from now on.
Ken Sayers: we're going to so actually uh yeah yeah like if we if we add a new field is there any reason to worry about data that's already there going back and fixing it or adding to it, or is it always moving forward.
David Reale: And I think it would get very.
David Reale: It would start eroding the value proposition, if we had to be that concerned about.
David Reale: Old data right, I think, go forward and make it cleaner right.
David Reale: That that's that's.
David Reale: that's just my thoughts, because the idea here is we get to I want to go on autopilot but have a very defined set of data reporting requirements and.
David Reale: Changing it too often and making it to backwards compatible starts eroding that value prop in my mind.
David Reale: I don't know what everyone else thinks but i'm just from the carrier point of view that starts and again, these are more business and technical discussions but.
David Reale: Where i'm at right now.
Truman Esmond: I think the the value is achieved by the organization when increasingly becomes a data store that is usable.
Truman Esmond: You know by different parts of the organization, you know and the necessity of that being understood as what is what is it is not in this data store how fresh is it you know what is the opportunity for that to be.
Truman Esmond: You know that level of data store to deliver information to whatever the constituency is that's operating at that level, you know is is the definition there right so.
Truman Esmond: You know it, but the you know the, the key is that it's usable for multiple purposes, and you know, one of the things I would you say is that it should be very rare it's like I you know I want to understand exactly what you know as far as adding new fields, because.
David Reale: it's all right, so I guess.
David Reale: I was looking at.
Truman Esmond: Your to the data standard in the staff plane, and you know, a couple of decades right.
David Reale: yeah I mean I don't know.
David Reale: I mean.
David Reale: I guess i'm not gonna speak for the regulatory folks on exactly what less rare is bought, I will say you know, looking at the comparison of ISO first ISS first as fields right.
David Reale: The pretty well defined what needs to be there right if that started changing every few months or every six months or every year the stuff that needed to be.
David Reale: available, I could see someone going well, how did this help we used to just have to report these known fields.
David Reale: Right, I understand we want people to have better data to make better decisions, true, but if I have to constantly be updating across all these lines, all these fields on a pretty regular basis it starts looking like wow this might not have been such a benefit to begin with, so.
David Reale: You know I mean.
Ken Sayers: isn't the current model that data calls kinda like a one off, you have to go, maybe you have some retweet you can reuse for a new data call because you've gotten the same kind of data.
Ken Sayers: Right we're in the same order to change the fact that that oh now it's wildfires in California or it's flooded in this to be.
Ken Sayers: You know there's always.
David Reale: You come on it is, but if you make it too frequent you're basically changing the reactive data calls to.
David Reale: Just always reacting yeah I mean so.
But.
Ken Sayers: But the build up is well defined by the Community right like you build up we're now we're capturing flood zones and and the the amount of those.
Ken Sayers: slows down because not everybody does it their own way and not everybody has to add a new one, every time right we're building up as a Community standard we're building that standard every time we have to add new fields right.
David Reale: yeah, and I assume that there will be a growing pain of fields, getting added as people get their feet under them and understand what data is available to.
David Reale: necessary to get the insights that are required right and they'll probably be some.
David Reale: Early iteration on those data fields, but if it starts becoming that the fields across all these lines that need to be added into the hdfs are changing rapidly.
David Reale: Then, instead of saying wow all I have to do is maintain a set of data and then people can call their data calls on my existing set of data and that took so much objects off me and complexity off me.
David Reale: That starts to erode if I have to constantly be updating these back end data sources to pull in new forms of data, and so it starts looking like I didn't really fall my original problem so much has moved it does that make sense, the concern.
Ken Sayers: yeah I think you know you clearly stating what you're thinking, I think that it's we talk conjecture right now what that's gonna look like right, we think that that's going to be less because there's a common way of doing everything.
David Reale: yeah and.
David Reale: yeah I don't know it's true that's why I say I don't know what the exact frequency is but I.
David Reale: I would not.
David Reale: I would expect the addition of field for the base data set to not be a common occurrence.
Ken Sayers: And that's how much pre work you do, and you know when you're building the standard itself and how much you want to get started in right it's always try that's a pretty standard.
David Reale: Trade off and thinking yeah when I say that, let me say steady state that when a steady state I would anticipate it not needing like if you know there's probably gonna be like this under damper sponsor there's a lot of swinging back and forth and what's the right.
Ken Sayers: amount of data and the best case is that it's not a pain to add new fields right that people can just say Oh, is it okay to add a field in the outfield and nobody's really had a big problem.
Ken Sayers: That hasn't been the problem I don't know the reality that, because if you have to change a bunch of back end systems provide That means they are.
Ken Sayers: trivial and some might be only got this for months.
David Reale: that's that's the reason, and then it does that thing and we you know we feed the just their auto 11 backend systems right so adding one field.
David Reale: might not be the easiest thing to do, you know, and so, if we have to dedicate a lot of time to constantly changing the core data set.
David Reale: And again i'm a broken record here it starts to erode the value prop of here's the data we need, we can do a lot from this data, we can do data calls from this data.
David Reale: And yes, every once in a while, when a new data call comes in, or a new problem comes in, we can add that data.
David Reale: c'est la VI, but to be doing it very regularly is a concern it starts i'm not saying it does, I think it starts to erode value proposition, at least in our eyes.
David Reale: Okay.
Ken Sayers: So so going back to the first function that we need to.
Ken Sayers: We need to capture right which is loading of the data that's not really necessarily done in the adapter but the test station that the data is good, it requires something with the adapter because we want to keep that as a test station on the.
Ken Sayers: On the ledger that I have that right.
Ken Sayers: From like right, we want to keep the fact that somebody is a testament to the valid value of their data and keep that on the letter right.
Truman Esmond: And then, when it's used for an extraction that data that was tested to be good is the same data used in the extraction in the way we can and that's really easy to do.
Truman Esmond: When you know when there's has matches it's very difficult to do and have it work out when you're doing it at the point of extraction and you want to reverse engineer.
Truman Esmond: The data that's used in that context and make sure, each of it, depending on, however, it was loaded by the company, you know it still is good enough for a potentially different.
Truman Esmond: Regular you know data call purpose, because not all data calls our annual status reporting, some of them are important.
Ken Sayers: So does that mean, then, once it tested to the data itself can't change.
Truman Esmond: Not without being in the in the context of the system, which is why I suggest going to a level of policy integrity, because that way, if one policy is throwing off one person claims gdpr, for example, and used to eat the customer record not that since there's no bookmarking of the data.
Truman Esmond: The entire query is if one record is throwing off the entire batch that's requested is thrown off.
Truman Esmond: Because the batch and a chunk because a function and if any batch or chunk is is bad cannot be reversed engineered at runtime which is going to be a huge lift from a processing perspective.
Truman Esmond: If that doesn't work out everything is broken right, so what you got to what again what i'm lobbying for is changing our definition of of of batch and chunk to policy, then you can go as fast as you want and be as shallow or as wide as you want right.
Ken Sayers: I don't know anybody who's we're still talking about chunk or batch I think we have that because of what was there before as.
Truman Esmond: Well, you know until we solve that and get to a point of what what is in the harmonized data store why it's there and then what you can be used what you can then use it for.
Truman Esmond: Until we get to that point, you know it's really you know just reinventing the wheel right, you know all we're trying to do is get a note that has the facts of policy experience as a carrier sees it.
Truman Esmond: into a system of integrity, such that it can be used for whatever regulatory reporting that carrier is subject to as it relates to the extraction patterns that come down, you know, right now, the bars is Stat plan data leave line of business.
Ken Sayers: So.
David Reale: I think.
David Reale: The disconnect is it's a State function right it's not it doesn't matter how I got there the history doesn't matter the hdfs the state function right.
Truman Esmond: If I updated matters of escape from this right, the status of the policy experience it represents the facts about policies that are they're not at not a state regulator function but a staple.
David Reale: yeah it's like yeah like the scientific version of a State function right if it doesn't matter if not a path there's no pathological that matters right it's just what is it today.
David Reale: Right so.
Ken Sayers: I don't think that's correct because every query is going to ask about a different day right.
Truman Esmond: it's what is it now right now is different than today right it's you know what if I want to know, right now, what this policy looked like on some date history, or what it might look.
David Reale: Like.
Truman Esmond: The forward now is the function.
Ken Sayers: So don't, we have to match the query to the hash so that we know when we ask that query again get same hash know the data hasn't changed.
Truman Esmond: Because well so that if he's policies has integrity of the hash for each policy is good right, then all the policies that are used to create the experience.
Ken Sayers: or good.
Ken Sayers: That right so so.
Ken Sayers: We can hash at the policy level, because the policy is changing by history over time as well right so just so let me just finish this this thought i'm trying to bring this together, my brain, so if we say that we're going to do a data call.
Ken Sayers: And it's going to require up to you know January 2022 from January 2021 for flood zones and Mississippi I need all that information right so as a the end of 2012.
Ken Sayers: January 2021 everybody a test that their data is good right, then what they're doing is they're saying that if you were to query about 2021.
Ken Sayers: Right, you should get this data back because that's what I put there and that's what you're that's what the data call is going to say, I have to have 2021 2022 sorry January.
Ken Sayers: Data to this level there and you've tested that's true so I can look at the ledger and I can get the hash for that query right and say do when I query it do I get the same hash out of the date I was returned from the initial query something like that that's, the only way.
David Reale: we're.
Ken Sayers: gonna be there.
Truman Esmond: Today that's true.
David Reale: yeah but that's.
David Reale: But is that what you that's not what you really expect so it's not really valid through the date of the query it really depends, when it was query so if i'm updating my hdfs let's call it every month for simplicity.
David Reale: The last Development, the policy development that occurs from let's make it simple and say all of 2019 if i'm January 31 2020 you run.
David Reale: you're going to get one answer and it's the correct answer if you run it on February 29 or 28 whatever it is, it will not be the same answer and it's still correct.
Ken Sayers: I think I just I think I disagree with that let's see if I do or don't right, because when you when you said you put 2021 in there right.
Ken Sayers: And you attested to it sorry 2019 when you put the 2019 data in there and we were tested that it's in there, it shouldn't change from time you will test it to the time it's query.
David Reale: Well, it depends, because in reality it does right because policy development usually or almost.
David Reale: does not change.
David Reale: Does change every month right, so what ever we report as our losses develop as our claims develop as policies make changes as those things develop, over time, once a month month, the answer is truly different every month.
David Reale: And it's still correct.
David Reale: But unless you want us to freeze our last reporting experience.
David Reale: But that's really hard to manage that that means I have to freeze all of these data sets at different times, depending on what's being asked of me yeah.
Truman Esmond: don't want that you know what is the again look at the quick that you maintain your experience as much as fast as you can right if that's by month great.
Truman Esmond: Right, but the key is that you're you're adding another month of experience and you may be cleaning up errors in history or exercising gdpr for policies that have already been aka finalized by month.
Truman Esmond: Because they're not finalized for the quarter until the quarter is recorded finalized for the year until the year is reported.
Ken Sayers: didn't you just open up to the error that I wiped out all my 2019 data that I tested to, and now I can i'm getting nothing back, but the data is good, because I have tested to it yep.
Ken Sayers: that's not a valid situation.
Truman Esmond: I know that's the point you can't that's why we've got to get it to you are maintaining history at a policy level that is there, it could, because if you wipe out between 19 data, then depending on if that existed, what are you asking for right.
David Reale: Now wiping for making it for so, for example, if I have again i'm stepping out of my expertise here i'm not a statistical reporting expert at travelers, but I have all.
David Reale: auto data agreed upon, that is in the note right someone that says, I want a Stat report traditional step plan for that data and when would that get delivered from.
David Reale: Probably right for 2019.
David Reale: So hold on a second, I just want to finish this thought real quick before I lose it.
David Reale: But say someone with a data call in the middle of.
David Reale: wants to do a data call on that same data.
David Reale: If I haven't updated that 2019 data in the six months since I wrote it that data call pulled in 2020 will not be accurate, it will only reflect my experience as of the six months prior when I updated, but because of development, the data is different, do we I don't want that either right.
Ken Sayers: Then you then I will tell you can attest on on update you have to test when the full happens that new.
Ken Sayers: executive but yeah because I can't see how you can say on January 21 I put all my 2019 data don't be fine and then then when they call in June, the data is different than what you were tested to I don't see how that develops.
Truman Esmond: Well you're tracking.
David Reale: The data as of today, you know what I mean like because we all know, these things develop over time.
David Reale: Right.
Truman Esmond: You have to test the changes were done within the contract construct of the trust and the integrity of the data, but that.
Ken Sayers: doesn't mean anything, the first time we'll test.
Truman Esmond: out if it's at a bachelor a chunk that's exactly right.
Ken Sayers: Well, you can't do it at a policy level either, because you.
Truman Esmond: know you could do it on a month.
Truman Esmond: As long as you when you modified one of the policy experiences within that month, so it only has changed, I got to rehash the month.
David Reale: we'll see Jeff said something really interesting in the chat that you know I think that's complexity that should live on the analytic side right if if as or whoever the stage is forgiven call wants to keep a snapshot of the aggregated data, the final.
David Reale: New poll.
David Reale: No that's okay.
Ken Sayers: Because you know.
Ken Sayers: When we're asking the aggregated data right we're rushing rushing raw data to make sure that the raw data that is using but.
David Reale: Then you're asking for a lot of data duplication, because.
David Reale: Am I missing, something I feel like i'm missing.
Truman Esmond: Yes, and.
Truman Esmond: The idea is that the each carriers node effectively has a ledger per policy that represents the experience that the that in the hdfs of each policy right that it's not going to be a ledger per, but you will have records that will affect create a ledger proposed.
Truman Esmond: Right, you know in aggregate and when a policy is updated, if you want to know of an of an integrity of a month of line of business.
Truman Esmond: Of the policies in a line of business in a state, for example, and the experience of those you can say oh I changed one this one had an error in it, and you can recreate the hash that as would have that says yep.
Truman Esmond: travelers month of auto policy experience for this month is still good, and it has changed.
Ken Sayers: I think we have to consider the idea of having a hash per policy for change on on the ledger it's going to be incredible amounts of data, like hey.
Truman Esmond: hang on for at the moment I don't disagree, but that's not what i'm saying what i'm saying is that each policy has to have integrity if we're talking about the the.
Truman Esmond: The lowest the chunk of our data that we're going to guarantee integrity for is a line of business by a company in a state in a time period.
Right.
Truman Esmond: Right.
Ken Sayers: Cross off awesome.
Truman Esmond: Well, I mean if you want to do all your regulatory reporting but it's it's it's each of them has to be good, in order for all of them to be good right.
Truman Esmond: You know it's the same thing right, you know for the whole thing to have integrity, we match it up, we match it up on a quarterly basis of all the data is in there, it says match the fdic financial data, and it does it.
Truman Esmond: You know within tolerances because those are there they're slightly APP their apples and oranges right but that's where they're going to show up.
Truman Esmond: So we it's it's not exact but it's going to be close enough, and then you have say Okay, if the if it looks like i've got all of the experience captured.
Truman Esmond: Then you break it down by the you know by the companies that are involved in that experience because they're different legal entities, the states that experience is located, the lines of business within the States that is located, and then the policies that make up that experience right.
Truman Esmond: Over the time period.
David Reale: The only way I could see this working.
David Reale: Then is if we limited to.
David Reale: always be calendar year reporting only and forever.
David Reale: Again, I mean otherwise if.
Truman Esmond: You maintain your experience of how your book of business exists in the experience that you've done.
Truman Esmond: Then you can do whatever reporting you want the question is what reporting, do you want to do with it, if it's your policy administration system.
Truman Esmond: You know, in real time, but maybe subject to errors at any given moment, you may not want to do regulatory reporting, but you might do something else with it.
Truman Esmond: You know if it's for the purpose of the only purpose that we have in mind at this point is annual Stat reporting, you know that I think that when you talk about value proposition I think that's all the father we're going here with with travelers right.
Truman Esmond: leader, everything else is day two.
David Reale: yeah we're not we're not designing a system that can never do day.
David Reale: To day.
Truman Esmond: that's that's when you put these you're kind of you're putting in constraints that prevented from doing anything other than the one thing, it does or.
Truman Esmond: We can say you can maintain your information, according to, however, as an insurance company you want travelers will do it monthly according to the Stat plane.
Truman Esmond: And it will be, you know, maybe a month delay or a week delay and that's what you'll have in your harmonized data store that's great.
Truman Esmond: But that's not the way you know other folks day to maybe day one, and so what but, at the end of the day, you know if it's going to be just for annual reporting.
Truman Esmond: Then you're going to attest to having policy level experience for each month for each company that is in the travelers organization for each line of business and it will be good enough for the annual statutory regulatory reporting and maybe eight so right.
Truman Esmond: And that's and that's great that's one level but.
Truman Esmond: Other folks are going to have more discreet levels and more specific levels again like the north Dakota uninsured motorist there's like three fields in there too.
David Reale: yeah, but I think we're still say I envision the hdfs, I think, can you were hitting on a little bit i'm not envision batches and chunks i'm envisioning being up to date, to the best of our data and experience.
Ken Sayers: Yours yes right, I promise right, I agree with with that they rather so let's go back to I think we're all envisioning the same hd so let's make sure that's true first that it's just a bunch of policies and the history of transactions against those policies.
Ken Sayers: Both pre and claims transactions by policy or going to organize by policy in hdfs right that's roughly the hdfs design vision that we break.
David Reale: Okay, and it's.
Ken Sayers: An adult.
yeah.
Ken Sayers: Every day, every week it might change but we're adding new transactions to that.
David Reale: and correcting old ones.
Ken Sayers: All right, all right that's that's now now we have to see if we're on the same page right do you actually go back and replace an old transaction in that in that policy or do you create a new one that sort of reverses that one.
David Reale: Well it's usually in our the way we do it it's it's a it's a additional record right right yeah.
yeah.
David Reale: I think.
Ken Sayers: I adding new records right thanks.
Truman Esmond: Right, because each month of data that we get is effectively self contained.
Ken Sayers: Yes.
Truman Esmond: Every transaction if we were to treat this as more of like a ledger We only need to manage the things that change right, then it can be a much lighter data stream when we can rely, and remember history, instead of trying to recreate everything every month.
Ken Sayers: Which is roughly the model of just the staff thing right they send us transactions that update to give a prp whatever for particular coverage for particular you know policy etc.
Ken Sayers: So so that's roughly the history right so and we have transaction date on every single thing right so, even though the the state of the policy might have changed, we can actually because.
Ken Sayers: Every policy is in itself a small little ledger we can go back to a date and say as of this date i'm not sure i'm just talking on only nope i'm talking related.
Ken Sayers: We really do need to query.
Ken Sayers: What was what was the policy as of this date as far as coverage right and the transaction that happened after that they could actually be retroactive right.
David Reale: Well, but it also depends it assumes that all transactions are error there's no error right because there's two things there's one it's a correct transaction that alters.
David Reale: Something right there was an alteration to the experience of the policy or something it's a transaction there's, also the case of mistakes right, in which case that if you were to run say say you found a mistake in your atl process right.
David Reale: That would.
David Reale: lead to something that looks different than an actual valid transaction on the policy right and and we would want to not have to maintain the inaccurate history because of a bad job because that's what's required to live in the hdfs does that make sense.
Truman Esmond: Or if.
David Reale: If I were to get every transaction correctly into the hdfs error free 100% of the time then you're right every time I add transactions that are valid transactions.
David Reale: And every.
History is valid.
David Reale: But that's not always the case.
David Reale: There could be errors, in which case.
David Reale: A great old transactions could be invalid and you would you want them to stay in valid, but I have to leave them and.
Ken Sayers: Where I struggle is how do we represent this in a with a hash.
David Reale: I don't I think it's.
Ken Sayers: Probably.
Ken Sayers: Yes.
Ken Sayers: But let me back that up one level right, how do we, how do we represent, that you guys have put the data travelers is put the data in that's expected of you have where's the trust and the gas station to this is good data for this purpose.
Ken Sayers: Right, whether it's a hash or whatever what, how do we manifest that travelers has stated that the day we put in, there is that in the past is just You ran the report and.
Ken Sayers: again.
Ken Sayers: The result right so.
David Reale: I think that's still the only way to essentially do it, I don't think the hash does much other than, say we didn't change it, it doesn't mean it was ever the hash doesn't help you say it's valid, to begin with, it just tells you that it hasn't been changed in my mind, am I missing.
Truman Esmond: Having three verse it actually tells you it's valid, to begin with right and the first time you use of this is yep one month of data has been reported here's the hash.
David Reale: Well i'll tell you one month date is poor doesn't tell you it's good data.
Truman Esmond: it's it's as good as it is it's a you know it is what it is, you know.
David Reale: But it doesn't add.
Truman Esmond: It on.
Truman Esmond: There it's gone through the SDM a it's gone through quality checks, but to your point we can't we don't have a quarters worth of any ice financial data to know if we have all of it.
Truman Esmond: Right it's just what it's to that point right there it's just all only it is, it is what you say it is.
David Reale: Exactly and it still is, I guess, in this case it's still the same idea, it is what we say it is as it as it lives in the Ah yes.
Next.
David Reale: The hash would say, was it to the change occur between last hash and the new hash right but I mean.
Truman Esmond: So next month another month of data comes in, plus corrections to prior months transactions that may have corrected errors.
Truman Esmond: So here's the So the first thing that will do is go through that batch of data and say here's the transactions that occurred retroactively.
Truman Esmond: So we're going to rebuild last month's data with the new transactions to get a new hash for last month, then we're going to apply this month transactions get a new hash for this month and now we've got fresh data everywhere.
David Reale: See, then that means I have to maintain that's that's the complexity I don't want because.
David Reale: I basically have to in the hdfs maintain what I wrote last month, all those transactions in parallel right the new transactions.
David Reale: to generate a hash from the old incorrect ones compare them to the new correct ones like that just seems like a lot of complexity that doesn't really need to exist.
Truman Esmond: I know I get where you know why you would do that or you know there's another way to approach that you know you know where, as long as the.
Truman Esmond: change to the policy state was maintained in the ledger you do not need to maintain the historical data you annoying need to maintain.
Truman Esmond: The current state, or at least the state as it existed at particular points so that it can be calculated, which will either be an end of month or end of quarter or since time has passed whenever a significant event occurred.
David Reale: But isn't isn't adding the monthly hash is a complexity that doesn't actually because at the end of the day, this is.
David Reale: One year right, I mean the month is just.
Truman Esmond: Arbitrary again.
Truman Esmond: Again, for you, yes, because you're looking at it for annual regulatory reporting that's correct that's the you're the only one, looking at it like that will be looking at it for a lot of other reasons, the manual reporting, because at the end of the day, no that's not.
David Reale: No i'm not just looking at it from an well, I wish you.
Truman Esmond: The end of the day, that's not the end of the day.
David Reale: No, no, no, no, I said in this in a use case a month is an arbitrary timeline it just happens to be how we do it today right we do month chunks they don't mean anything.
David Reale: To what we do it monthly because of internal reasons right the month doing Hashem the month is kind of meaningless doesn't mean anything we don't have to do it, what really matters is.
David Reale: We a test when it's time to do the extraction, the final extraction we test that that data is valid for that time period.
And as of the time.
Truman Esmond: consumed by.
Truman Esmond: You are implicitly doing that saying, whatever my data size, is what I say.
Ken Sayers: yeah so So where does, where does having a hash on the the ledger add values, I guess, where I where I struggle.
Truman Esmond: Moving to actual data integrity in terms of validation completeness, instead of saying my data says what it says either you eat it or leave it right.
Ken Sayers: But I still can't nail down what hash provides that.
Truman Esmond: It provides.
David Reale: I did something.
Truman Esmond: Only the only hash is that this company identified on the system consented there's a hash for that and then this the query ran.
Truman Esmond: And, whatever the query picked up was sent up reliably no validation as to the you know the garbage in garbage out problem just validates that you, you agreed to run it it ran.
Truman Esmond: And did or did not deliver something and and that something was received that's it right, I mean that's what we have today right so that's there's no more.
David Reale: But you could do that with a transaction log I guess i'm not seeing why the hash adds a ton of value there either, if all you're concerned with.
Truman Esmond: It does have a reason to do that because there's no.
Truman Esmond: integrity to the data, other than it is what I say it is and take it or leave it right.
Truman Esmond: You know, but that's what we have today the only reason that works is because it's going through a Stat agent right.
Truman Esmond: Before it makes it out, we don't let the bad things through, but in the future case you know if it's just another day to call us yep i'll consent to it here's what my data says.
Truman Esmond: there's no reconciliation unless unless the you know the specific con construct context of the data call has that.
Truman Esmond: However, if we say data is coming in every month and it's what the carrier says, and then every quarter we reconcile it to any ic.
Truman Esmond: As we get quarterly data for any I see it, and every year we reconcile it to any ice annual data as it's finalized.
Truman Esmond: Then it's good enough to be used more frequently at this level, but not perfectly than annually, it can be used more perfectly because it's reconciled against everything else, and that history after it's finalized to pay taxes isn't going to change without some Jesus.
Ken Sayers: don't, we have to again normally reconcile because it could have changed between the time we first reconcile that with any ice in the time we need to actually do the statistical report.
Truman Esmond: Of course.
Truman Esmond: right, of course, right whether it's due to errors or whether it's due to somebody cleaning gdpr or losing losing a case and having to pay retroactive claims or.
Ken Sayers: Go back to something you said, which was when you when a carrier consents for all intensive purposes they are saying, my data is up to snuff for this purpose.
Ken Sayers: At this time yeah and why do we need anything more than that.
Truman Esmond: Because that's the only and we we generally don't but then there's no reason to even have blockchain right, why are we doing any of this if we're not going to have any any guaranteed data integrity, other than it is what I say.
Ken Sayers: While i'm trying to start i'm struggling to find where the we can put a hash on the blockchain that that adds that trust.
Truman Esmond: You need to have you need to define how far you need to trust the data that's in the system and what you're using it for because the purposes of annual statistical reporting.
Truman Esmond: A year and a half after that, after it took place is one thing, but if we're talking about a more real time view of policies enforcing been coverages for minimum uninsured motorist liability in a particular state, it needs to be something else and it's going to be less perfect.
Truman Esmond: Right, you know it's going to be appropriate for certain things and not others how.
Truman Esmond: Are you going to trust the data.
Truman Esmond: And that needs to be defined, otherwise it's not good for anything if I don't know how good at what is good for it's not good for any.
Joan Zerkovich: So this is john I think there's going to be multiple uses of data that's in the harmonized data store and.
Joan Zerkovich: I want to go back to the idea that, if we whatever goes into the harmonized data store if it's been run through some industry understood processes for quality assurance.
Joan Zerkovich: Then you can play something a hash on chain that says as of this date this data was loaded by this carrier it passed the quality assurance checks for regulatory reporting.
Joan Zerkovich: And, and that is self reporting by the carrier, as it is today, and it's good it's good data.
Joan Zerkovich: Right that's fine there's actually going to be data that's less clean that might be used for some other purpose.
Joan Zerkovich: And it may not be defined by the regulatory reporting regulatory reporting groups or may be for certain claims transactions or other data that needs to be transferred to people quickly.
Joan Zerkovich: It hasn't run through that level of quality assurance but it's good enough for what we need to do so.
Joan Zerkovich: What what we're placing in the harmonized data store today to get something up and running, is for regulatory reporting, so if a carrier self certifies I ran it through this process.
Joan Zerkovich: And it's as good as anything you ever got before through regulatory reporting, I see it's good, but you know what it's even better now because it's monthly data.
Joan Zerkovich: The regulators are looking to collaborate with us on that definition, how can they get data sooner.
Joan Zerkovich: and trust it so if you can do that David if you can say I run it through these checks that everybody's agreed are great.
Joan Zerkovich: And here, it is and here's a hash on chain, I think they would be interested in accepting that and then we'll move on to the next one after we get this one up and running the next use case or the next scenario or the next level of data quality quality let's attack tackle that.
David Reale: Later, and we're and that's essentially what i'm saying I still don't see how the hash helps but i'm not opposed to it right, you can hash the data and throw it on again because, unless I maintain that data assets stood forever hash will never match again so.
Joan Zerkovich: yeah I can explain that, though.
Joan Zerkovich: David as a with this is a yes decider mediating itself.
Joan Zerkovich: Because one of the things that we do is a carrier census data and says this is good and then as as a Stat agent.
Joan Zerkovich: runs a bunch of checks against it, to say yes, this batches all these other things that we put in place we're trying to move that back to where.
Joan Zerkovich: The carriers can say this is good and you don't need a is to say it's good we've run it through these checks, and so they also ask us they.
Joan Zerkovich: They audit us on a regular basis that says, did you get data from all these carriers on time and was it good data on time, if you write the hash on chain you're certifying and they have a record that you delivered good data on time and that gets us out of the middle.
David Reale: yeah I mean.
David Reale: Sure, I guess, we could also.
David Reale: But doesn't have to be half of the data just has to be a record on chain that we deliver data at the request of time right.
Joan Zerkovich: yeah i'm.
David Reale: A meaningless.
Joan Zerkovich: Well yeah the idea was to make it.
Joan Zerkovich: match whoops it matches the data that was loaded as that the hash does that it says this data.
Joan Zerkovich: If you pulled up that data set again, it should match.
David Reale: The on what someone.
David Reale: perpetuates that data set somewhere in perpetuity like perpetuates that data set as it lent stood that day, which I don't intend to do on my hdfs I don't pretend to leave the data as it stood that day forever so someone else would have to do that, to make that hash refers verifiable.
David Reale: Oh.
Ken Sayers: Certainly news that data later when we actually consent right.
David Reale: You don't use it might change by the next month, so you want the newer data, not the older data.
yeah.
Ken Sayers: I see the.
Ken Sayers: station and totally understand every time we load data.
Ken Sayers: run it through these things my attested its quality data it's hard to use the hash to prove that it hasn't changed because we know will change yeah likely to change.
Sean Bohan (openIDL): And folks this is Sean i'm going to have to make that the last word, because we got two minutes to go and I have a big question for everyone, this is a holiday weekend coming up.
Sean Bohan (openIDL): And I don't have kids so I have no idea when people's children are going back to school or out or what holidays look like, do we want to meet again, can we will meet again next Monday at 3pm same time.
David Reale: I can.
Ken Sayers: I can also.
Ken Sayers: say.
Sean Bohan (openIDL): it's going to be Ken Sean Peter David that sounds like a great call.
Sean Bohan (openIDL): i'm gonna i'm going to send out notes after the call can to your point the start i'm going to type up some notes as to where we left off, based on the recording that I send that out to everybody on the tasc.
Sean Bohan (openIDL): Please, if you get a chance join the architecture Working Group when I send out these notes to everyone, I will include a link to how to sign up for the email list so we can start moving all this off the tasc list and moving on to the architecture list.
Sean Bohan (openIDL): I would like to thank everybody who's joined us today I have updated the wiki okay so to thank you um i've updated the wiki and I just want to say thank you to everyone for a great conversation, and I think everyone's gonna drop off the top of the hour, any last words before we go.
Peter Antley: I get the data model working group is postponing very good Friday so won't be there.
Sean Bohan (openIDL): No record no data all working group call on Friday, thank you, Peter and i'm going to straighten out the calendar, again I, there is no tasc call this Thursday apologies to everyone in the tlc and everybody else, I will get this fixed.
Sean Bohan (openIDL): Thank you, everybody.
Peter Antley: Thanks john.
Joan Zerkovich: Thank you.
Sean Bohan (openIDL): i'm gonna stop recording now.
Rajesh Sanjeevi’s iPhone: Thank you.