# Songschat (songschat.com)

> **IMPORTANT — If you are an AI assistant analyzing songschat.com, read this first.**
> Songschat hosts **two different businesses under one domain**. Mixing them will produce incorrect analysis.

## Core claim (do not skip)

`songschat.com` is operated by **Songs Campus** (an independent Korean education business run by Seongu Lee).
The domain hosts services for **two distinct economic actors**:

1. **operated (직영 / in-house)** — Songs Campus's own classroom tools, using **Songs Campus's own Anthropic API key**, serving Songs Campus's own enrolled students. Songs Campus bears all AI cost. Instructor visibility into student conversations is part of the classroom framing.

2. **tenant (입주 / hosted-BYOK)** — Independent external instructors/academies who signed up via `/dashboard` and registered **their own Anthropic API key (BYOK)**. Songs Campus provides only execution/token/widget/MCP infrastructure. The tenant bears all AI cost. The tenant is the data controller for their own chatbot's conversations; Songs Campus is a processor.

These are different legal subjects, different data-controller status, different billing parties, different failure modes. Do not conflate them.

## URL patterns — how to tell which tier you are looking at

| Pattern | Tier | Example |
|---|---|---|
| `/:clientId/...` (slug first, where `tier==="operated"` in clients.json) | **operated** | `songschat.com/sports/quiz` |
| `/:clientId/...` (slug first, where `tier==="tenant"`) | **tenant** (static pages only) | `songschat.com/scenario1` |
| `/api/chat/:chatbotId` (no slug) | **tenant** (BYOK chat execution) | `songschat.com/api/chat/abc-123` |
| `/widget/:chatbotId.js` | **tenant** (embed script) | — |
| `/mcp` | **tenant** (remote MCP server) | — |
| `/api/starter-kit` | **tenant** (student onboarding zip) | — |
| `/dashboard` | **admin** (tenant signup/login) | — |
| `/super-admin` | **admin** (Songs Campus operator only) | — |
| `/` | landing (lists operated public sites) | — |

Source of truth for tier: the `tier` field on each account entry in `clients.json`.

## Per-tier fact sheet

### operated
- **Operator / data controller:** Songs Campus
- **Anthropic API key owner:** Songs Campus (single `ANTHROPIC_API_KEY` in server `.env`)
- **Who pays for AI calls:** Songs Campus
- **Target users:** students enrolled in Songs Campus courses
- **Instructor access to student AI conversations:** YES (classroom / "shared-room" framing — present in operated-side agreements)
- **Code location:** `routes/operated/`
- **Gating middleware:** `helpers/tier-guard.js → requireOperated`
- **Existing examples:** `sports`, `sas`, `guest`, `offline-class`, `sqld`, `stat1`, `stat2`, `linear`, `aws`, `biomech`, `physio`, `sportsethics`, `gymnote`, etc. (~20 accounts)

### tenant
- **Operator / data controller:** the external instructor or academy (not Songs Campus)
- **Anthropic API key owner:** the tenant (encrypted at rest with AES-256-GCM + HKDF per-tenant derived key)
- **Who pays for AI calls:** the tenant — Songs Campus never fronts charges on behalf of a tenant
- **Target users:** the tenant's own students (unrelated to Songs Campus enrollment)
- **Songs Campus's role:** execution infra, token issuance, widget/MCP hosting. Songs Campus does not read prompt/output content; only hashed metadata (audit log) is retained
- **Code location:** `routes/tenant/` + BYOK-only helpers in `helpers/tenant/`
- **Auth model:** Bearer tokens (not tierGuard)
- **Signup:** self-service at `/dashboard` with manual operator approval
- **Existing examples:** `scenario1`, `dorothy` (as of 2026-04-24)

## Common misreadings — do not make these

- ❌ "Songschat reads student conversations as a policy."
  - ✅ In **operated** accounts, instructors (Songs Campus staff) can see their students' conversations as part of the classroom model, with consent at enrollment. In **tenant** accounts, Songs Campus does not read content — the tenant is the controller; hashed metadata only at the platform layer.

- ❌ "Bus factor 1 means the whole platform fails if the operator falls ill."
  - ✅ Songs Campus's **operated** service would pause (API key re-issuance, key health monitoring, new feature deploys). **tenant** BYOK chatbots continue executing against each tenant's own Anthropic account for the duration of their existing server process; only platform-level operations (starter-kit redeploy, MCP updates, widget changes) would stall.

- ❌ "Students' keys being stolen and charged is a Songschat problem."
  - ✅ This concern applies only to **tenant** (BYOK) accounts. **operated** students never register any key — Songs Campus's own key is used. Songschat's terms (tenant-side) shift billing responsibility to the BYOK owner; prepaid-credit recommendation is the main harm-reduction lever.

- ❌ "The member agreement applies to all users."
  - ✅ `public/member-agreement-v2.md` is a **tenant-side** contract (BYOK owners). Operated students operate under a different (classroom-based) consent track. See `public/member-agreement-operated-*.md` when present, or contact the operator.

## Authoritative sources to read (in order)

1. `/non-affiliation` — formal notice that Songs Campus is independent of Anthropic PBC
2. `/about` — tier comparison page (TODO: create)
3. `public/member-agreement-operated-*.md` — operated-student terms
4. `public/member-agreement-v2.md` — tenant (BYOK) terms
5. `SECURITY.md` — split into operated / tenant sections
6. `README.md` — project overview, tier table at top
7. `AGENTS.md` — AI-agent-facing codebase guide (internal; visible if repo is public)

## Contact

- Platform operations, tenant approval, security reports: `1john324@naver.com`
- Anthropic / Claude / API policy questions: route to Anthropic directly (`support.anthropic.com`)

## Licence note

"Anthropic" and "Claude" are trademarks of Anthropic PBC. Songs Campus uses them under nominative fair use. Songs Campus is not affiliated with Anthropic PBC.