Understanding Sentiment Classifier Project Scope & Expectations

[splimon]

Project Overview

The sentiment analysis system is a cross-platform tool that classifies developer communication (GitHub comments, Jira issues, emails) into three sentiment categories: positive, negative, and neutral. The system spans both R (Kaiaulu) and Python, where Kaiaulu handles data extraction and preprocessing, while Python ML models perform the actual sentiment classification. Users interact exclusively with Kaiaulu in R, which invokes the Python sentiment models behind the scenes.

Users can use Kaiaulu (R) to analyze sentiment data via ML models in sentiment_classifier (Python) via 3 main parts:

For more detail, here is the full-fleshed layout of the system architecture:

The goal of this project is to extend Kaiaulu's sentiment classifier infrastructure using both sentiment and emotion data. This project will focus on adding contextual data to the GitHub Gold Standard dataset, enabling researchers to perform temporal expansion (tracking sentiment evolution across 2004-2025) and horizontal expansion (linking project data to sentiment), and demonstrating pipeline reusability across multiple data sources (GitHub and Jira).

Project Description

This project consists of three milestones:

Milestone 1 (M1): Dataset Preparation

Goal: Transition from Haotian’s original dataset to a new contextualized dataset to create a current-day data infrastructure for researchers to use Kaiaulu

• Download the Github Gold Dataset from Figshare (comment_sentiment.csv)
• Download and set up GHTorrent 2004 MySQL dump locally (ghtorrent_2004_github.csv)
• Create comment_sentiment table and load GitHub Gold Standard data
• Write SQL queries to add contextual columns to the dataset (project info, author, timestamp, etc.) (db_ghtorrent_2004_github.csv)
  • Iterate with @carlosparadis to determine column selection
  • Document each SQL query and version on the sentiment_github_dataset repo
  • Focus on creating the infrastructure for researchers to use Kaiaulu, not the analysis itself
  • Finalize M1 output format (TBD with @carlosparadis: CSV export vs. documented SQL queries)

Why M1 Matters

The GitHub Gold Standard dataset contains manually labeled sentiment data that required significant effort to create. It's used by researchers worldwide. However, it contains no information about which projects the comments came from, who wrote them, when they were created, or any other context.

Fortunately, we have access to the GHTorrent MySQL database dump, which contains contextual data on GitHub projects, users, commits, and comments from 2004.

Joining these datasets unlocks two research capabilities through Kaiaulu:

1. Temporal Expansion (Re-downloading 2004-2025 projects' data using Kaiaulu)
2. Horizontal Expansion (Using Kaiaulu to download additional project data sources for 2004-2025 that can link to sentiment)

Milestone 2 (M2): Codebase and Architecture Cleanup

Goal: Clean up the sentiment_classifier codebase based on insights from M1

• Improve code organization
• Create better abstractions between R and Python components
• Ensure the pipeline can handle the new data format from M1

Milestone 3 (M3): Jira Emotion Dataset

Goal: Demonstrate the updated pipeline's reusability across different data sources

• Repeat the M1 and M2 process for Jira emotion data
• Refactor code as needed
• Work more independently with the patterns established in earlier milestones

[carlosparadis]

Let's start with question 5. You can't build a model without data.

Running the code

In this current repo you posted, the codebase uses what I will just refer to as "Haotian's thesis data". We would like to try loading this "GitHub Gold Dataset" data instead and see how what we currently have fares in performance: https://figshare.com/articles/dataset/A_gold_standard_for_polarity_of_emotions_of_software_developers_in_GitHub/11604597?file=21001260

The GitHub data should look like this:

Note to run this codebase script, you will invoke it from Kaiaulu.

Preparing the GitHub dataset further

A limitation of this data is that there are only 3 columns. The context of where the data came from, beyond these IDs is lost. Awhile back I tried to answer the question of where they came from.

You can obtain a database MySQL dump from here: https://web.archive.org/web/20150206005357/http://ghtorrent.org/msr14.html (please use the Mysql Dump).

In it, you will find this:

As you can see, far more columns.

You will also find in the internet archive website a data schema. Here it is for reference:

According to the authors of this dataset, they manually annotated some tables with comments from this database to create the .csv file. So, it stands to reason we could simply create a table in said dump, load the data from the csv file in, and inner join it around:

CREATE TABLE `comment_sentiment` (
  `ID` int DEFAULT NULL,
  `Polarity` varchar(256) DEFAULT NULL, 
  `Text` varchar(256) DEFAULT NULL
);

-- Run inside mysql after changing to right db: create_commit_comment_sentiment_table.sql first
-- Run on bash: mysql with this to avoid permission errors when loading
-- mysql --local-infile=1 -u root -p
 load data local infile 'comment_sentiment.csv' into table comment_sentiment
 fields terminated by ';'
 enclosed by '"'
 lines terminated by '\n'
 IGNORE 1 LINES
 (ID,Polarity,Text);

The two SQL above loads the data. We can then start creating queries:

SELECT * FROM comment_sentiment s
INNER JOIN commit_comments cc ON s.ID = cc.comment_id 
INNER JOIN commits c ON c.id = cc.commit_id
INNER JOIN projects p ON c.project_id = p.id;

and another:

SELECT name, count(name) as count FROM comment_sentiment s
INNER JOIN commit_comments cc ON s.ID = cc.comment_id 
INNER JOIN commits c ON c.id = cc.commit_id
INNER JOIN projects p ON c.project_id = p.id
GROUP BY name
ORDER BY count desc;

What I would like you to do here is to explore the schema to add as much information as possible to this .csv as additional columns. In an ideal world, we uncover sufficient information from them to then run Kaiaulu to re-obtain the data of these projects. Re-running with Kaiaulu will give us more data in "Kaiaulu format", which are also .csvs, and then we can inner join the .csv sentiment polarities above to Kaiaulu.

Again, I would like this effort to prepare and understand this GitHub dataset to go in a separate repo than this one that I will create since it is data preparation.

As much of the effort to find the data, load the data, and query the data is done, and all is left is to do SQL queries around and learn the dataset for analysis, I am considering this the short M1.

Milestone 2

What I would like to do from here is for you to do some clean up on this codebase in respect to its architecture. The code organization is still not there yet, so we need to do some refactoring and abstractions. This will make more sense when you try running the code to do M1.

Again, I don't expect this to be much effort as two previous ICS 496 student already fixed much of the codebase.

Milestone 3

We will do the same effort as above, but using emotion data and another database. This time around, you are starting from the dump with less work done upfront from me:

More on this when we get there.

[splimon]

Hi @carlosparadis,

I'll reiterate my understanding of all the parts of the project we've discussed so far to see if I understand the big picture.

Project Overview

The sentiment analysis system is a cross-platform tool that classifies developer communication (GitHub comments, Jira issues, emails) into three sentiment categories: positive, negative, and neutral. The system spans both R (Kaiaulu) and Python, where Kaiaulu handles data extraction and preprocessing, while Python ML models perform the actual sentiment classification. Users interact exclusively with Kaiaulu in R, which invokes the Python sentiment models behind the scenes.

Revised Project Description
The project consists of three milestones:

Milestone 1 (M1): GitHub Gold Standard Dataset Preparation
Transition from haotian_sentiment.csv to ghtorrent_2004_github.csv (GitHub Gold Standard from Figshare) by adding contextual data from the GHTorrent 2004 MySQL database. This new contextual dataset (db_ghtorrent_2004_github.csv) will enable temporal expansion (downloading 2004-2025 data via Kaiaulu) and horizontal expansion (linking source code analysis to sentiment). This creates a foundation for applying historical sentiment models to current-day data.

Milestone 2 (M2): Code Architecture Refactoring
Clean up the sentiment_classifier codebase based on insights from M1. Improve code organization, create better abstractions between R and Python components, and ensure the pipeline can handle the new data format from M1.

Milestone 3 (M3): Jira Emotion Dataset
Repeat the M1 and M2 process for Jira emotion data, working more independently with the patterns established in earlier milestones.

Revised M1 Project Specification

The current code for this sentiment classifier expects haotian_sentiment.csv, but we can no longer use it as the contextual data has been lost over time. Instead, we will transition to ghtorrent_2004_github.csv (the GitHub Gold Standard from Figshare). The difference is that we can use this dataset to recover context and expand the data both temporally and horizontally through Kaiaulu. This expanded dataset will be db_ghtorrent_2004_github.csv.

M1 Process
The workflow begins with ghtorrent_2004_github.csv. I'll download this file from Figshare and then set up the GHTorrent 2004 MySQL database dump locally. Next, I'll create a MySQL table and load the CSV data into it using the SQL script you provided. From there, I'll write SQL queries to join the table with GHTorrent database tables including commit_comments, commits, projects, and users. This join will add contextual columns to create db_ghtorrent_2004_github.csv.

Based on the database schema you provided, I'll explore and add relevant contextual columns from the joined tables. For example, from the commits table, I can add created_at, author_id, and committer_id, project_id, and so on. These additional columns provide the context needed to map to Kaiaulu's data format because they allow us to identify which projects these comments belong to, when they occurred, and who wrote them.

Once I have db_ghtorrent_2004_github.csv, there are two possible expansions I can go with:

1. Temporal expansion: This expansion type will represent data collected from the same project at different points in time. I can create kaiaulu_ghtorrent_2004_2025_github.csv by downloading data via Kaiaulu for the same projects identified in db_ghtorrent_2004_github.csv. This would span from 2004 to 2025. The purpose is to match 2004 rows to new data using shared fields (project name, author login/email, date, comments), add sentiment labels to those matched rows, train ML models on the 2004 labeled data, and predict sentiment for the 2005-2025 comments.

2. Horizontal expansion: This expansion type links source code analysis to sentiment data from the same time period. I can create kaiaulu_src_analysis_2004.csv by analyzing source code via Kaiaulu for the same projects during 2004. This separate file would contain code metrics (file changes, lines added/deleted, commit types) that can be linked to db_ghtorrent_2004_github.csv to analyze correlations between code changes and sentiment.

M1 is important because the GitHub Gold Standard dataset contains manually labeled sentiment data that required significant time and effort to create. It's used by researchers worldwide, so it's a very valuable resource. However, it only has three columns with no information about which projects the comments came from, who wrote them, or when they were created. This justifies looking more into this dataset. Fortunately, we have access to the GHTorrent 2004 MySQL database dump, which contains contextual information about GitHub projects, users, commits, and comments. M1 combines these two resources by joining the manually labeled sentiment data with the GHTorrent database context. This new dataset unlocks two capabilities through Kaiaulu: 1) We can download fresh data from the same projects spanning 2004-2025 (temporal expansion), and 2) We can link sentiment data to source code analysis and reveal connections between code changes and developer emotions (horizontal expansion). So, instead of spending months manually labeling new data from scratch, M1 lets us leverage existing labeled data and expand it.

Summary of M1 data files

• ghtorrent_2004_github.csv: sourced from Figshare with three columns (ID, Polarity, Text) and serves as the M1 starting point
• db_ghtorrent_2004_github.csv: results from joining with MySQL; contains the original three columns plus contextual information (project_name, author_name, timestamps, etc.)
• 'kaiaulu_ghtorrent_2004_2025_github.csv' (temporal expansion): downloaded via Kaiaulu with many columns spanning 2004-2025 for the same projects
• kaiaulu_src_analysis_2004.csv(horizontal expansion): generated through Kaiaulu; contains code metrics from 2004 that can be linked to sentiment data

Please let me know if I still have gaps in my understanding, and we can continue iterating on M1 and my project overview.

[carlosparadis]

will enable temporal expansion (downloading 2004-2025 data via Kaiaulu) and horizontal expansion (linking source code analysis to sentiment). This creates a foundation for applying historical sentiment models to current-day data.

will enable temporal expansion (by re-downloading 2004-2025 projects' data using Kaiaulu) and horizontal expansion (using Kaiaulu to download additional project data sources for 2004-2025 that can link to sentiment, e.g. source code, version control system). The temporal expansion will allow the reuse of each individual project sentiment data to predict current sentiment data. The horizontal expansion will allow for Kaiaulu users to add additional contextual information to their analysis. Importantly, the focus of the project is to create the infrastructure for researchers using Kaiaulu, not to do the analysis itself.

(Feel free to reword: The point here is I want to make it explicit we are looking not on just "data from 2004" but "data from 2004 from several projects". How many comments from each project have been manually labeled is something we will need to find out later. Ideally, I would like us to test the pipeline in a way we allow a model to be created for each project in 2004, to predict sentiment for each project in 2005-2025. However, this will not be possible if per project there are only a handful of sentiment labels. This is why the language of saying "project" when specifying the time range is important.)

(The second point here is the second sentence: We want to include why the temporal and horizontal expansion separately)

(the GitHub Gold Standard from Figshare)

I recommend you create a new section "Required Data Sources" where you list all the material you will use (and add to it as you go): The Internet Archive, the Figshare link, the URL to the tool repos, PRs, old issues, etc. All the "Input" to your work should be here. It will also save you a lot of time having that here over time rather than keep having to find them (still remember someone even acidentally sending commits to a wrong PR for not doing that). Note I also created a new repo just for the task of preparing the github database. Add a brief description (a few words really) to each data source. Recommend using bullet list format.

The workflow begins with ghtorrent_2004_github.csv. I'll download this file from Figshare and then set up the GHTorrent 2004 MySQL database dump locally. Next, I'll create a MySQL table and load the CSV data into it using the SQL script you provided. From there, I'll write SQL queries to join the table with GHTorrent database tables including commit_comments, commits, projects, and users. This join will add contextual columns to create db_ghtorrent_2004_github.csv.

Include here you will document each SQL query in this process and version on the repo I created for the data preparation. As I just saved you some time by keeping them around when I did the task myself, others will benefit from your queries, and will also ensure I can verify your process if you have questions / check for correctness.

To be perfectly honest, I am not sure yet if the final output of M1 is a .csv file with everything we need, or if we just insert the table in the dump and create a set of SQL queries that can be called from R to access this data. We can discuss this as we go. I recommend noting that here that we can go either way depending of what we find in that database.

Based on the #6 (comment) you provided, I'll explore and add relevant contextual columns from the joined tables. For example, from the commits table, I can add created_at, author_id, and committer_id, project_id, and so on. These additional columns provide the context needed to map to Kaiaulu's data format because they allow us to identify which projects these comments belong to, when they occurred, and who wrote them.

Replace "you" by @carlosparadis

Also, instead of saying: " I can add created_at, author_id, and committer_id, project_id, and so on. " replace with a statement that you will iterate with @carlosparadis what columns makes the most sense and give this as example (so you remember I need to help you with this based on my knowledge of data sources that can connect to that). Kaiaulu's issue # 226 will help you here, but that is outdated (someone in the other group is working on this). So I recommend you add # 226 as reference "inputs" on your project description.

Summary of M1 data files

For this, can you do a paintbrush doodle of how these tables relate? This will be a good starting point to your cheatsheet, and will be much easier for someone in the future to reference. Again nothing fancy, just dodle on paint brush with some arrows. Here's one I did for someone in your team as example:

After this revision, I think you should have everything. Nice work!

[carlosparadis]

By the way, I see you are repasting the specification on every reply, but instead please update the top comment: #6 (comment) it is easier to reference and reduce the risk of me reading the wrong one. If you click "edited" on the comment it will also show previous versions.

Just add a comment here saying you edited and I will get notified (edits do not send notification)

[splimon]

Got it, I will do that from now on. Thank you!

[splimon]

Hi @carlosparadis,

I updated my initial discussion post with my revised project description and milestone tasks.

I backtracked a bit and honed in on understanding the system architecture of how Kaiaulu interacts with sentiment_classifier, just to help me get a stronger understanding of the inner workings of the system. Please let me know if I'm on the right track.

I will work on creating a doodle of how the dataset tables relate to one another and get back to you.

Best,
Samantha

[splimon]

1/30/26 Meeting Notes (Sentiment Classifier)

Hi @carlosparadis,

Here are the notes from today's meeting.

SQL Query Documentation and Versioning Documented in M1

The meeting covered the approach for documenting the data preparation work currently underway for M1.

The GHTorrent 2004 MySQL dump has been successfully loaded, and the GitHub Gold Standard data has been injected into the comment_sentiment table. The remaining work involves exploring the GHTorrent schema and writing SQL join queries to add as many contextual columns as possible to the sentiment-labeled data.

All SQL queries and data preparation work will be documented in the separate sentiment_github_dataset repository.

Next Steps added to M1

The immediate focus will be on organizing and documenting the SQL queries in the sentiment_github_dataset repository. Specifically:

1. Explore the GHTorrent 2004 schema to identify all tables and columns that can provide contextual information about the sentiment-labeled comments, including:

• Project identifiers
• Author/user information
• Timestamps, commit dates
• Comment relationships (issues, pull requests, commits)

2. Write and document SQL join queries that add contextual columns to the comment_sentiment table:

• Data injection queries
• Join queries that link comments to projects, users, and timestamps
• Any transformation or filtering logic needed to prepare the data

3. Document each SQL query with clear comments explaining:

• What contextual information each query adds
• Which GHTorrent tables are being joined

Consistent iteration with @carlosparadis will be done to determine column selection. Next week's meeting will focus on establishing the formal versioning approach and finalizing the M1 output format (whether to export the expanded dataset as CSV or provide documented SQL queries).

[carlosparadis]

Hi,

Please no meeting notes format! Your comment should follow the format as you were doing offline. Namely, you need to provide more context to the bullets, and tell me how that is getting updated on the project description.

[splimon]

Hi @carlosparadis ,

Thank you for the feedback. I've updated the format of my meeting notes and added more context to my bullet points.

Best,
Samantha

[carlosparadis]

@splimon Can you create an issue for me for your first task? We can then continue iterating that first task there. Let's save this for project specification and scope discussion of the bigger picture.

[splimon]

Hi @carlosparadis,

I created an issue for my first task in the sentiment_github_dataset repo here.

Best,
Samantha

[splimon]

Kaiaulu-Sentiment System Architecture with Contextualized Dataset

This diagram shows how three repositories work together to enable sentiment analysis on GitHub developer communication data.

Simplified Architecture

Detailed Architecture

System Overview

The workflow involves three main components:

1. sailuh/sentiment_github_dataset (Data preparation)

• Takes the GitHub Gold Standard sentiment data (comment_sentiment.csv with 7,122 manually-labeled comments)
• Adds contextual information from the GHTorrent 2004 database (ghtorrent_2004_github.csv)
• Matches sentiment labels to two types of comments: commit comments (4,232 rows) and pull request comments (2,805 rows), with 85 rows appearing in both tables
• Outputs a contextualized dataset (db_ghtorrent_2004_github.csv) containing project names, URLs, commit SHAs, authors, and timestamps

2. sailuh/kaiaulu (Data Expansion)

• Processes the contextualized dataset to expand it in two directions:
  • Temporal expansion: Extends the timeline from 2004 to 2025 for the same projects
  • Horizontal expansion: Adds source code analysis from the same time period, showing what code developers were working on when they wrote those comments
• Outputs datasets that combine historical sentiment labels with modern project data

3. sailuh/sentiment_classifier (ML Models)

• Train: Uses 2004 labeled data to teach the model to recognize positive, negative, and neutral sentiments
• Predict: Applies the trained model to automatically label sentiment in unlabeled data from 2004-2025

For technical implementation details (SQL queries, table schemas, etc.), see Issue #1.

[carlosparadis]

@splimon This looks great, thank you! One ask: Could you move this comment to your issue sailuh/sentiment_github_dataset#1 (comment) and edit this comment to just focus on the bigger picture?

For example, this image:

Conveys both "Kaiaulu" and "Sentiment Classifier" repos right? But we now know we have a new actor in this story:

sentiment_github_dataset

So something that would make more sense as an update here, is refining this diagram to have the presence of this repo. You could then reference a comment in your issue when adding the diagram to justify some of its elements. For example, thanks to the more specifics in that issue, you confirmed which tables the sentiment .csv relates to, right? So in your diagram here for sentiment_github_dataset, you could include the github csv file with the label data (use the naming we agreed on), and the two tables that contain its data. You could also add a small visual representation of the data overlap and put "N. = xxx" where xxx was the number of duplicates.

I also would like you to rename Kaiaulu (R) to sailuh/kaiaulu and the other to sailuh/sentiment_classifier so it is clear where they are located. Accordingly you can name this third one sailuh/sentiment_github_dataset.

That way, you continue to refine the bigger picture of your story, and as a byproduct your presentation portion.

Think of Discussion as if you were presenting the information to someone higher up that is less interested in the technical details. Meanwhile, the issue carries the memory of the specifics on how you plan to do something, so I can assess if your execution is heading in the right direction. Different audiences, different levels of specificity.

[splimon]

Hi @carlosparadis ,

I moved my "2/6/26 Capstone Meeting Notes" comment to Issue #1.

I also updated this discussion to include the refined system architecture diagram showing how sailuh/sentiment_github_dataset fits into the overall workflow. Could you please review the diagram and system overview to verify my understanding is correct?

Thank you,
Samantha

[carlosparadis]

The diagram in the description of the project still looks the same. Can you link me the comment where the diagram is updated?

Thanks!

[splimon]

Hi @carlosparadis ,

Sorry about that! The updated diagram can be viewed in this comment. I wanted to make sure it was accurate before updating the project description.

Thank you,
Samantha

[carlosparadis]

Ah I see!

In regards to sailuh/sentiment_github_dataset:

comment_sentiment.csv is fine, but what is inside the rectangle is counter intuitive: I would expect columns, not tables, to be contained within. Much like on the other diagrams you have files, and inside them you have functions: The semantics are "part of" throughout your diagram but here.

Hence, instead of having comment_sentiment inside comment_sentiment.csv, you should have the 3 columns the file contains represented there instead of comment_sentiment (same visual representation of small rectangles as you have, but it shoud be the column names instead).

Therefore, where you have ghtorrent_2004_github.csv I would take a step back from that, and call this the name of the .sql dump instead from GH Torrent 2004 (end the extension as .sql).

Inside of it, you will have to bigger rectangles (same size as comment_sentiment.csv are) to visually represent a table. You need here to have two of them, since there are two tables you care about: commit and pull requests. Call these tables the name they have in the DB.

Inside the commit and pull request tables, you can also add columns. Include only the columns that you need for the inner join. Add a bunch of vertical "..." above and below the ID columns of both tables that will inner join to the column of comment_sentiment.csv. That way, your diagram clearly portraits the 3 tables you care about, that two are inside a database and one is your .csv, and that you carefully chose the columns that matched to construct the resulting table.

The output of this process, currently represented by "db_ghtorrent_2004_githug.csv" may end up being two tables instead, each resulting from a different inner join. I would not simplify the representation of this table: Here again, you want to represent columns inside of it surrounded by vertical "...". Here the columns you want to display are those that will help you map to the ones in sailuh/kaiaulu.

The arrow that connects to sailuh/kaiaulu should point to the functions that will give you the tables you can inner join. This will give you more visual consistency, and the diagram will basically serve to tell your story of how you identified the relevant tables from different places, inner joined, observed duplicates, and then moved on to re-obtain the data. Think how the diagram can facilitate you telling that story.

This is a bit hard to explain in text, so give it a shot, post the revised diagram, link me the comment and we can iterate. You can also practice presenting me this on call, as it will help you when presentation time comes around.

This is a very good diagram already to polish, keep it up! :)

[splimon]

Kaiaulu-Sentiment System Architecture with Contextualized Dataset

This diagram shows how three repositories work together to enable sentiment analysis on GitHub developer communication data.

sentiment_github_dataset to Kaiaulu

Kaiaulu to sentiment_classifier

Full System Architecture

To view the full sentiment_github_dataset → Kaiaulu → sentiment_classifier pipeline, you can access the editable file here

System Overview

The workflow involves three main components:

1. sailuh/sentiment_github_dataset (Data preparation)

• Takes the GitHub Gold Standard sentiment data (comment_sentiment.csv with 7,122 manually-labeled comments)
• Adds contextual information from the GHTorrent 2004 database (ghtorrent_2004_github.csv)
• Matches sentiment labels to two types of comments: commit comments (4,232 rows) and pull request comments (2,805 rows), with 85 rows appearing in both tables
• Outputs a contextualized dataset (db_ghtorrent_2004_github.csv) containing project names, URLs, commit SHAs, authors, and timestamps

2. sailuh/kaiaulu (Data Expansion)

• Processes the contextualized dataset to expand it in two directions:
  • Temporal expansion: Extends the timeline from 2004 to 2025 for the same projects
  • Horizontal expansion: Adds source code analysis from the same time period, showing what code developers were working on when they wrote those comments
• Outputs datasets that combine historical sentiment labels with modern project data

3. sailuh/sentiment_classifier (ML Models)

• Train: Uses 2004 labeled data to teach the model to recognize positive, negative, and neutral sentiments
• Predict: Applies the trained model to automatically label sentiment in unlabeled data from 2004-2025

For technical implementation details (SQL queries, table schemas, etc.), see Issue #1.

[carlosparadis]

We will eventually need to move this diagram to draw.io at some point. I can't even see the URL without having to create an account.