The Foundation · B

The 5 Load-Bearing Pillars

Five hard architectural commitments everything else depends on. The build order is derived from their dependency chain.

P1Identity spine — one member, one join key

One member record. One identity provider. The IdP's stable subject id (sub) is the join key across every surface. Every first-class object (post, thread, message, enrollment, event RSVP, media upload, AI query) carries a foreign key to that member. Tier is an attribute on the member, read everywhere, re-implemented nowhere.

One login across all surfaces — a single sign-on against our own identity provider, which brokers social login and mints our own roles/tiers (a pure third-party login can't). The upgrade over "just use a social login now": we own the identity so we can own the tier.
The learning core already has real local auth (username/email + argon2 + email-verify + reset + 4 roles) — the spine wraps and federates it; the IdP becomes the source of truth for sub. Missing pieces (SSO, social login, MFA, rate-limiting) are what the IdP adds; small high-value gaps go upstream.
This pillar anchors the E3 security/login audit — the first real work is auditing the current posture, then designing the one-identity model on top.

invariant There is exactly one member identity. No surface invents its own accounts. A member is the same member on every surface, and their tier travels with them.

P2Shell + design system — one app shell, one component language

One application shell and one component/token system. Every surface — home, boards, courses, events, DMs, admin — is assembled from the same parts. Tier-gating and choose-your-own-home live in the shell, so no surface re-implements "is this member allowed to see this?" or "where does this member land?"

The shell owns global nav, the surface switcher, tier-aware rendering (locked states, upgrade prompts, gated regions), the member menu, notifications, and the choose-your-own-home landing preference.
The design system owns tokens (color, type, spacing, radius, elevation, motion), the component library (feed card, thread row, message bubble, event card, course tile, media player, member chip, tier badge, lock/upgrade affordance), and two-theme discipline (light + dark, both first-class).
The learning core is branded fully through its themeable template layer (site name/logo/colors as data/config, not a fork) → learners never see the upstream product's identity, and we pay zero merge tax. Community/realtime/AI surfaces render from the same token set.

invariant A member cannot tell where one service ends and the next begins. One shell, one token set, one visual system across every surface.

P3Content / interaction model — the first-class objects

A single, explicit object model. These are the nouns the entire platform is built from; every feature is an operation on them, and the AI index reads all of them.

Member ──has──▶ Tier (attribute) ├─ enrolls in ──▶ Course ──▶ Section ──▶ Resource / Evaluation ──issues──▶ Certificate ├─ posts ──▶ Thread ──in──▶ Board (public | member | inner-circle | cohort) ──▶ Post ├─ sends ──▶ Message ──in──▶ DM / Group DM ├─ RSVPs ──▶ Event ──▶ Recording ──▶ Media ──▶ Board Thread ├─ uploads ──▶ Media (self-recorded video | audio | external embed) └─ queries ──▶ AI-Index (permissioned view of ALL of the above)

Native from the learning core: Member, Course→Section→Resource, Evaluation/question banks, Certificate (PDF+QR+recert), roles, a course-attached forum + announcements + blog.
Ours to build (the gap): a global board/space model, member directory, feeds/follows, member↔member DMs / group chat, events, notifications, real-time/presence, forum tags. This is E4/E5.
Cohort has no native object — modeled as a time-limited course instance + a cohort board scoped to that cohort's members.

invariant Every object FKs to a Member and carries a tier-visibility. Nothing is "outside" the model — including AI queries, which are logged objects too.

P4AI as a first-class service — permissioned index + agent runtime

AI is a service the whole platform calls, not a feature bolted onto one screen. Two halves:

A permissioned index over all content (courses + boards + events + media transcripts + the member's own history), powered by the governed knowledge brain. Every retrieval is filtered by the querying member's tier — the same tier attribute from P1, applied at retrieval time.
An agent runtime for reasoning-heavy flows, run as governed headless agents on the agent-governance plane (curate the home, "talk to the platform", synthesize a thread, draft a course) — with audit trails, not inline prompt calls.

The four AI surfaces this powers: AI-curated home (the moat) · AI tutor (retrieval-grounded, tier-scoped) · AI authoring · conversational data layer ("talk to the platform").

invariant The AI never returns content the member's tier cannot see. Permission is enforced at retrieval, not filtered after. Every AI action is a logged, governed object.

P5Service topology on dedicated iron — own the box

Own, dedicated server(s) — not shared containers on the general estate box. The earlier "reuse the VPS" lean is superseded by the grown ambition: this platform gets its own iron so its load (live-event video spikes, AI inference, realtime) never competes with the rest of the estate.

One ingress, one identity. All services behind a single reverse-proxy and the single IdP: learning core · community · realtime · AI · identity provider · stores.
Stores: a relational store · a cache + session store (flips on caching + shared sessions + rate-limiting) · an object/media store (delivery decoupled → a paid video host is a URL repoint) · the AI index store.
Estate-native ops from day one: service-entity registration, observability into the estate telemetry backend, self-hosted deploy over the tailnet (no metered CI), backups, the incident/alert floor.

invariant One ingress, one identity, dedicated iron. Every service is a governed estate asset with a deploy contract, a smoke check, a backup, and an owner.

Build order (foundation-first)

1. IdP + identity spine (P1) → 2. Shell + design system (P2) → 3. Content model (P3) └ everything FKs to member └ every surface renders from it └ objects features act on 4. AI service (P4) → 5. Messaging / realtime → 6. Tiers + payments → 7. Polish Learning core stands up early in parallel (proven, forked) and is FEDERATED into step 1, not rebuilt.

← Vision · index · next: Tiers & Walkthrough →