I wanted to build software that encouraged people to get outside and experience life even when they were uncertain what their next step was.

I know first hand how difficult it is to put one foot in front of the other after being knocked down. I know something about being anxious about going outside when you don’t feel financially stable. I even know a little about feeling so stuck, it’s easier to let the world pass you by.

Yeah, everyone else was too There’s something magical that happens when you have an idea, you meet questions. If you are lucky, they are explicit; the common what, why, how, sort of stuff.

I think the difficult thing to articulate about unparty-app is that it had to take time to gather enough data to validate that the idea could even work.

What stuck out to me while working to increase the activity score in each unppp was how parallel the connections were running between ideas.

The about/build/connect model existed in all of the first ios apps that I started for unparty-app.

theunpartybeta came first — initial commit November 13, 2024, beating theunpartyunppp by about two months (January 12, 2025). The GitHub creation dates from the org API showed them close together in February, but git history tells the real story.

What's striking is how differently each repo used ABC:

theunpartybeta wired ABC into a UNPARTYTextClassifier — a SwiftUI TrainingTextView where the user manually selects ABOUT, BUILD, or CONNECT to label a conversation before feeding it to a CoreML model. ABC there was a data labeling interface. The user was the annotator, tagging inputs to train a sentiment classifier. That's the infrastructure layer — and it's almost exactly what generate_abc_training.py does now, just automated.

theunpartyunppp used ABC as a user journey — a Swift enum case about, build, connect in FeedMenuHeader.swift, a Picker the user moves through as product stages. The README frames it as "measurable user progress through ABOUT → BUILD → CONNECT." That's the experience layer.

Same three words, two completely separate implementations:

- beta = labeling tool for ML training

- unppp = navigation model for the user's journey through the product

What the current theunpartybuilder work actually does is close the loop: the labeling approach beta prototyped (human-tagged inputs → CoreML) is now automated using real unparty-app data (conversation corpus + commit records), and the resulting classifier auto-labels GitHub issues moving through the same ABOUT → BUILD → CONNECT journey unppp established as the product metaphor.

about — conversation corpus is correct. Those tokenized messages represent the "I'm trying to understand / figure out / explore" stage. The model already performs well here (91%+ confidence) because that's all it was trained on.

build — Commit records give you labeled work artifacts: feat, fix, bug, fail, tool are already normalized commit_type values attached to real commit messages.

The text classifier only needs to distinguish "about vs build" now — a binary problem, which will be dramatically more accurate than the current three-way split where "connect" was starving the model of signal.

connect — this is the structural insight. It's not a text signal at all, it's relational:

- Issue body mentions ≥2 repo names from the org → connect

- Issue has a feature:* label (already tracked in cross_repo_handler.py) → connect

- Same feat/S{N} title appears across multiple repos → connect

- Multiple @repo references in the body → connect

This fires before the text classifier, not from it. If the structural check passes → label connect and skip classification entirely. The text classifier then only runs as a binary about/build decision.

Concretely, the Pinecone query script produces build-labeled samples, we retrain on about (conversations) + build (commits), and connect gets its own structural pre-check in handle_issue_opened() that short-circuits the whole classifier path.

about — conversation corpus is correct. Those tokenized messages represent the "I'm trying to understand / figure out / explore" stage. The model already performs well here (91%+ confidence) because that's all it was trained on.

build — Pinecone commit records give you labeled work artifacts: feat, fix, bug, fail, tool are already normalized commit_type values attached to real commit messages. The text classifier only needs to distinguish "about vs build" now — a binary problem, which will be dramatically more accurate than the current three-way split where "connect" was starving the model of signal.

connect — this is the structural insight. It's not a text signal at all, it's relational:

- Issue body mentions ≥2 repo names from the org → connect

- Issue has a feature:* label (already tracked in cross_repo_handler.py) → connect

- Same feat/S{N} title appears across multiple repos → connect

- Multiple @repo references in the body → connect

This fires before the text classifier, not from it. If the structural check passes → label connect and skip classification entirely. The text classifier then only runs as a binary about/build decision.

Concretely, the Pinecone query script produces build-labeled samples, we retrain on about (conversations) + build (commits), and connect gets its own structural pre-check in handle_issue_opened() that short-circuits the whole classifier path.