Page Comparison

View file
name GMT20221114-193529_Recording_1920x1080.mp4 height 250

Date

14 Nov 2022

ZOOM Meeting Information:

...

Meeting ID: 790 499 9331

Attendees:

Peter Antley

Ken Sayers 

Jefferson Braswell 

Nathan Southern 

Ash Naik 

Dale Harris 

James Madison 

Yanko Zhelyazkov 

Tsvetan Georgiev 

David Reale

Agenda:

1. Ken - Updates on POC Scope Page
2. Ken - demo of the ND POC end to end which may help reinforce understanding of its role/functionality
3. Ken: Next section of the work - communication/the “control module”.
4. Catch up our documentation on status of design

Notes:

•  Notes included in Architecture Definition Workspace doc

Minutes

NS began with LF Antitrust Statement

KS: POC Scope Page - Updates - as discussed last week (TSC)

1. Requirements page: what should be part of technical POC vs. not. High-level scope items/accept. criteria/detailed req. #s - 2 wk. turnaround.Image Added
2. Demo of ND POC
   1. Some related questions have arisen based on onboarding dates for stakeholders. Want to see end-to-end process of data call
   2. About to start connecting to carriers for ND POC and will start doing Dec. data call for uninsured motorists
   3. Walkthrough of flow will illustrate the steps involved - what data goes in and comes out 
   4. Process
      1. Carrier - wants to identify who is uninsured. 
      2. Scope for POC - carriers provided VINs to system to upload one day during a month x number of VINs insured, into their node; then DOT does likewise, uploading reg'd VINs. Carrier and analytics node each have one set of data. Carriers can provide raw data or previously hashed values. DOT creates data call to request VINs from carriers and compares that against hashed other set of data and compares #s etc. and evaluates results. All matches considered to be insured.
3. Three things underway
   1. POC Scope
   2. Capturing of progress in the wiki (e.g., postgreSQL, etc.)
   3. Data module (presented illustration) discussed - now we're talking about openIDL Control Module. Component where we put in data call, communicate w/other carriers, control process. But doesn't hold any data - more a place that we pass through. Doesn't run extraction itself. How we run this: our next discussion point. Allows interfacing of users/carriers/clients into network for control/communications. 
      1. First activity to describe module: white/black box - what is it doing from the outside's perspective? e.g., requesting data, allowing for mgmt of data calls, etc. what is the functionality it is fulfilling? What is the scope of its functionality? (We can subsequently discuss internal components). Application + connection to network parts of control module. Functionality" (Network underpinning communication between all modules). Both peer-to-peer and a central mechanism.
      2. Application Layer
      3. Control Module Functionality
         
         1. Crud data calls (requests from DOI to carriers)
         2. Likes and consents
         3. Requesting extraction of data
         4. Requests extracted data
         5. Transport extracted data to analytics node
         6. Provide analytics for final release consent
         7. All access to ledger happens here
         8. Interacts with communication mechanism
         9. This is where we will have our peer that connects to the blockchain network.
      4. Analytics Module functionality
         1. Determine carrier percentage of report
         2. Enable second consent
         3. Create report
         4. Combine results
         5. No access to ledger
         6. In ND case - comparison with registered VINs
         7. Gets results from each one of the consenting carriers - pulls together into a report
         8. Fundamentally just a service provider for providing reports
         9. Should just know where the data is and what kind of report to run
      5. Development of Extraction Pattern
         1. Local machine with access to the system 
4. PA: Senofi techs got PA set up with Test Net from LF.

Documentation:

...