The AI model that doesn’t exist yet

You’re staring at a spreadsheet at 2am. Column A: young people who need mentors. Column B: professionals who could help. Column C: empty. No institution will match them because the problem is too specific, too unprofitable, too messy. So you train the model yourself.

This is simply what happens when you refuse to wait for someone else to solve the problem. Arts Emergency did it for arts mentorship. You can do it for whatever niche your spreadsheet tracks.

---

The gap no one else will fill

Arts Emergency started with a spreadsheet. Young people from working-class backgrounds wanted mentors in the arts. No university, charity, or edtech startup would build this. The matching criteria were too precise: pair 16–25-year-olds with professionals who shared their background, not just their industry. Existing systems failed 100% of the time. So they built their own.

In machine learning terms, this is negative sampling. You’re looking at photos of people who look like you but never include you. That data doesn’t exist in public datasets. The people Tim Denning calls “losers” don’t appear in click logs. If you want a model that serves them, you have to over-sample for them. No one else will bother.

The requirements:

• Task: Match mentees to mentors based on shared background, not just skills.
• Input: Structured profiles (age, location, interests, barriers faced).
• Output: Pairings with less than 10% dropout in the first month.

The real challenge is straightforward engineering. The critical gap is data that reflects the actual lives of the people you’re trying to help.

---

Why big tech won’t solve this

Fine-tuning tokens are cheap. Collecting the right data isn’t.

Arts Emergency’s early data was labeled by volunteers. That’s the kind of “messy” annotation big labs outsource to low-context vendors. Google’s Universal Sentence Encoder won’t help here. Neither will OpenAI’s fine-tuning API. The data doesn’t exist in their training sets because the use case isn’t profitable.

The “losers” framing is practical, not cynical. If your model serves a population that doesn’t show up in click logs, the model won’t exist until you collect the data yourself. Cloud providers optimize for scale, not specificity. They’ll give you 10,000 generic mentorship pairings before they’ll give you 100 that reflect the reality of someone who grew up on a council estate.

---

The real costs most people ignore

Here’s the math no one talks about:

| Cost Type | Arts Emergency’s Number | Your Equivalent | |--------------------|-------------------------|-----------------| | Cloud credits | £0 | $500–$5,000 | | Volunteer hours | ~1,200/year |? | | Dropout rate | 23%/year (mentors) |? |

Assuming you’re not lucky enough to get free GPU time.

Volunteer hours are the real bottleneck. Arts Emergency needed ~1,200 hours/year of human-in-the-loop work. That’s ~30 full-time days. Not all of it was labeling: some was cajoling, explaining, and keeping people motivated. The dropout rate for unpaid labelers after six weeks? High enough that they had to design the system to survive it.

Hidden cost: maintaining the social graph that keeps annotators motivated. Arts Emergency’s solution involved shared ownership. The spreadsheet wasn’t just data, it was a communal artifact. This is a social decision, not a technical one.

---

Decisions that look technical but are actually social

Your license choice reveals who you trust to keep the model alive.

• MIT: You want adoption, even if someone else profits.
• AGPL: You want control, even if it means fewer users.
• Shared Google Sheet: You want interpretability, even if it means zero scalability.

Arts Emergency chose the shared Google Sheet. Zero inference cost, 100% interpretability. The trade-off: no automation. But automation wasn’t the goal—trust was.

Fine-tuning vs. retrieval-augmented generation (RAG) is another social decision.

• Fine-tuning: The social contract gets buried in weights. Future maintainers won’t know why the model makes the decisions it does.
• RAG: The social contract stays visible. The retrieval database is human-readable. Future maintainers can update it without retraining.

Arts Emergency didn’t use either. They used a shared document with read-only links. The “model” was the schema, not the weights.

---

What the demo videos never show

Drift

Arts Emergency saw 23% churn in mentors per year. The model’s performance decayed as the volunteer base changed. The first version over-weighted “went to the same university” because the early mentors had. Most applicants hadn’t. The model failed silently until someone noticed the dropout rate climbing.

Spurious correlations

Early versions of the matching algorithm prioritized shared hobbies. Turns out, “likes reading” is a terrible predictor of mentorship success. The model was optimizing for noise, not signal. Fixing it required collecting more data—specifically, data on what didn’t work.

Cold-start problem

The first 50 users had to be manually recruited. No organic growth until the model hit critical mass. This is a social challenge, not a technical one. The model can’t bootstrap itself.

---

The handoff problem: when “you” becomes “they”

Arts Emergency’s shift from founder-led to community-led governance was deliberate.

1. A constitutional document outlining roles and responsibilities.
2. Rotating stewards to prevent burnout.
3. A veto mechanism for major changes.

In ML terms: the model weights are static. The inference stack—who calls the API, who moderates outputs, is dynamic. If the model’s value depends on serving an unprofitable segment, the handoff must include a funding stream: grants, donations, or cross-subsidy.

The “losers” framing is also about who maintains the model, not just who it serves. If the population you’re serving can’t afford to keep the model alive, the handoff fails. Arts Emergency’s solution? Make the model cheap enough to run that the next person sitting alone at 2am can afford to retrain it.

---

What actually survives

Arts Emergency is 7 years old. Over 3,000 mentor-mentee pairs. The technical artifact that outlasted everything else? The spreadsheet schema, not the trained weights.

The lesson: the model’s persistence depends on how cheaply it can be re-trained by the next person working late. The weights are temporary. The social contract is permanent.

---

How to build your own

Spec

Write the one-sentence use case no existing model satisfies.

Data

List the exact counterfactuals you need to collect. Estimate volunteer hours. Arts Emergency needed ~1,200 per year. What’s your number?

Architecture

Choose between fine-tuning, RAG, or a shared document. Each encodes a different social contract.

• Fine-tuning: Fast, but opaque.
• RAG: Slow, but interpretable.
• Shared document: Zero inference cost, 100% interpretability.

Failure budget

Define the maximum acceptable error rate and the volunteer churn rate that breaks the system. Arts Emergency’s breaking point was 23% per year.

Handoff

Name the first three people who will inherit the model. What’s the recurring cost you’re willing to cover? Arts Emergency’s answer: enough to keep the spreadsheet alive.

---

The model that doesn’t exist yet won’t be built by a hero. It’ll be built by someone who stares at a gap at 2am and decides to fill it, one volunteer hour, one counterfactual, one social contract at a time. The real question is whether you can keep it alive, not just train it.

Sources

• Arts Emergency: 'Sometimes if you want something to exist ...
• An Existential Guide to: Making Friends - The Shadowed Archive
• How LOSERS Are Created And How To Avoid Becoming One