Canonical sources: Portal philosophy, posture, and language live in
/docs/planning/champion-portal/source/README.md.
Use these sources (includingCHRIST_CENTERED__IDENTITY_STATEMENT.md) when writing specs or user-facing copy. Prefer quoting/paraphrasing over inventing new language.
AI Context Bundle File 2 of 8
Purpose: Consolidate all documented architectural and product decisions to prevent re-litigating settled matters
Authority: Reference this file before proposing approaches that conflict with documented decisions
Last Updated: April 2026
Decision: Design for mobile FIRST, enhance for desktop
Date: November 2025
Decision: Collect minimal info upfront, gather details progressively
Date: November 2025
Email signup flow:
SSO signup flow:
Rationale: Lower friction = higher completion rates.
Decision: One cp_champions table with verification_status enum
Date: November 2025
enum verification_status: {
unverified: 0, # Email not confirmed
email_verified: 1, # Email confirmed, limited access
champion_verified: 2 # BUID linked, full access
}
Rationale: Clean data model. No bottleneck waiting for approval. Status controls access.
Decision: Separate external portal (Alumni Network) and internal portal (Lookup Portal) sharing one database
Date: November 2025
| Portal | Domain | Auth Model | Users |
|---|---|---|---|
| Alumni Network | belmontalum.com |
Cp::Champion (Devise) |
Alumni |
| Lookup Portal | alumnilookup.com |
User (Devise) |
Staff |
Champion Portal tables prefixed with cp_. Alumni master records shared via BUID linking.
Decision: Email verification + Champion verification (separate steps)
Date: November 2025
| Status | Can Do | Cannot Do |
|---|---|---|
| Unverified | Nothing (can’t log in) | Everything |
| Email Verified | Log in, edit profile, browse communities | Directory, message, full participation |
| Champion Verified | Full access | — |
Trust-first access (Phase 9): pre-verification users can browse communities and read content. Contributing requires verification.
Decision: Google SSO implemented; Apple and Facebook considered for future
Date: November 2025
| Provider | Status | Rationale |
|---|---|---|
| ✅ Implemented | Most users, ubiquitous | |
| Apple | Deferred | Required for iOS App Store (future native app) |
| Deferred | Alumni demographic overlap | |
| ❌ Rejected | API limitations + complexity |
Decision: BUID matching done by Engagement Team post-signup
Date: November 2025
Rationale: Alumni rarely remember their BUID. Would create friction. Staff already does BUID matching.
cp_ Prefix for Alumni Network TablesDecision: All Alumni Network tables use cp_ prefix
Date: November 2025
| Prefix | Owner | Examples |
|---|---|---|
| (none) | Lookup Portal | alumni, degrees, users |
cp_ |
Alumni Network | cp_champions, cp_connections, cp_board_posts |
Decision: Split ownership by data type
Date: November 2025
| Data | Owner | Editable By |
|---|---|---|
| Alumni master records | Lookup Portal | Staff only |
| Degree records | Lookup Portal | Staff only (imports) |
| Champion profiles | Alumni Network | Alumni |
| Messages, discussions | Alumni Network | Alumni |
| Connection data | Alumni Network | Alumni |
Key principle: Alumni Network activity does NOT create engagement_activities records. Those remain Staff-managed. Alumni Network tracks its own activity via cp_activity_events.
Decision: Different profile data lives in different places
Date: November 2025
| Data | Table | Who Edits |
|---|---|---|
| Preferred name, maiden name | alumni |
Staff OR Champion (if verified) |
| Staff-uploaded photo | alumni.photo |
Staff only |
| Champion profile photo | cp_champions.photo |
Champion only |
| Bio, employer, title | cp_champions.* |
Champion only |
| Degrees | degrees |
Staff only (imports) |
Critical rule: Staff-uploaded photos NEVER appear in Alumni Network.
Decision: ZIP code is primary location input → auto-populates City, District, Region
Date: November 2025
Rationale: Maximum value with minimum friction.
Decision: Single crm_data_changes table tracks all changes for CRM export
Date: November 2025
Export includes both BUID and BQID (Contact ID) for data team compatibility.
Decision: Alumni must be connected before they can message each other
Date: Phase 10 (January 2026)
Original approach (Phase 1): Open messaging — any verified alumni could message any other.
Revised approach (Phase 10): Connection-gated — send a connection request first, messaging unlocks after acceptance.
Connection request types: Say Hi, Career Advice, Networking
Rate limiting: 10 requests/day for sender; configurable weekly cap for receiver. Pause mode available.
Rationale: Reduces unwanted contact. Creates intentional relationships. Aligns with the portal’s belonging-first philosophy: relationships before transactions.
Exception: Support threads (CL ↔ Engagement Team) bypass connection requirement.
Decision: Per-community boards with threaded comments
Date: Phase 3 (December 2025)
Structure:
Decision: Alumni submit news and event ideas; staff review before publishing
Date: Phase 14 (February 2026)
Flow:
Rationale: Enables alumni contribution while maintaining content quality. Staff gatekeeping ensures brand consistency without blocking alumni voice.
Decision: Career Center is publicly accessible (no login required to browse)
Date: Phase 7 (January 2026)
/careersRationale: Career resources serve as an on-ramp to the portal. Alumni who discover the Career Center may sign up for full access.
Decision: Champion role is unlocked via a self-service quiz, not staff approval
Date: Phase 1C (November 2025), reinforced in Phase 12 (February 2026)
Rationale: If opting in feels like applying, alumni won’t do it. Recognition of existing posture, not a new expectation.
Decision: Phase 10 Connections system replaced Phase 5 Contacts system
Date: Phase 10 (January 2026)
Cp::ChampionContact model deletedCp::Connection model with canonical pair ordering (champion_a_id < champion_b_id)Rationale: Contacts was a bridge feature. Connections + connection-gated messaging creates more intentional relationships.
Decision: Portal serves three concentric engagement tiers
Date: Phase 13 Planning (February 2026)
| Tier | Who | Detection | % of Users |
|---|---|---|---|
| Member | Everyone who signs up | Default | 100% |
| Champion | Completed role quiz | has_champion_role? |
~10% |
| Community Leader | Staff-assigned | community_leader? |
~1% |
Key design principle: Tiers are derived from existing data fields, NOT a new database column. No schema change needed.
Rationale: Creates a visible progression funnel. Members see discovery prompts; Champions see contribution coaching; CLs see community health. Progressive disclosure based on tier.
Decision: Lead with “alumni” and “Bruins” in all external-facing copy; reserve “Champion” for post-opt-in moments
Date: Phase 12 (February 2026)
Previous: Champion-first language (“Join Alumni Champions”, “Welcome, Champion!”)
Current: Alumni-first language (“Your alumni community”, “Connect with fellow Bruins”)
| Context | Language |
|---|---|
| Pre-opt-in, public, marketing | “Alumni”, “Bruins”, “your community” |
| Post-opt-in, dashboard, celebrations | “Champion” used in recognition moments |
| Never | “Champion” as a generic synonym for “alum” |
Rationale: Phase 12 source-alignment review revealed that Champion-first framing felt exclusionary. Alumni-first language makes every alum feel welcome regardless of engagement level.
Decision: Portal should feel like a community, not a corporate tool
Date: December 2025
Decision: Clear visual hierarchy with breathing room
Date: December 2025
text-base (16px) to prevent auto-zoomDecision: Specific terminology for the Alumni Network
Date: January 2026, updated Phase 12 (February 2026)
| Term | Definition | Usage |
|---|---|---|
| Alumni | Singular AND plural; any Belmont grad | Default term for members |
| Champion | An alum who opted in via role quiz | Post-opt-in only |
| Bruin | Any Belmont alum (informal, friendly) | “Connect with fellow Bruins” |
| District | Metro area (user-facing) | NOT “region” in user-facing contexts |