2022-11-14 Architecture WG Meeting Notes

Ken - Updates on POC Scope Page
Ken - demo of the ND POC end to end which may help reinforce understanding of its role/functionality
Ken: Next section of the work - communication/the “control module”.
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)

Requirements page: what should be part of technical POC vs. not. High-level scope items/accept. criteria/detailed req. #s - 2 wk. turnaround.
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.
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
PA: Senofi techs got PA set up with Test Net from LF.

Time	Item	Who	Notes

Home

2022-11-14 Architecture WG Meeting Notes

Date

Attendees:

Agenda:

Notes:

Documentation:

Notes: (Notes taken live in Requirements document)

Recording: