Friday

Friday is an AI agent platform with two clear product paths:

1. Personal Plan for individual users
2. Campus Plan for colleges and institutions

This repository now reflects that split across product, onboarding, memory, and operating model.

Product Model

Personal Plan

• Paid self-serve plan
• One-click installer
• No desktop app required
• Local setup for config and memory
• User-managed data ownership

Campus Plan

• Institution-led onboarding
• Centrally hosted deployment
• No per-student installation
• Channel-based access (web, email, WhatsApp, and approved campus channels)
• Policy, role access, and memory managed by the institution

Core Principle

The system must keep the experience explicit:

1. Personal means self-serve local install and local control
2. Campus means centralized hosting, governance, and managed access

Onboarding Flows

Personal Onboarding

1. User registers and pays
2. User downloads one-click installer
3. Installer creates workspace, config, and memory structure
4. User completes first-run setup and model choice
5. User operates from local environment

Campus Onboarding

1. College lead submits interest form
2. Discovery and policy alignment are completed
3. Department scope and pilot plan are finalized
4. Central deployment is configured
5. Students and staff access through approved channels

Memory Architecture

Personal Memory

• Default storage is local
• Config, memory, and session cache live in user environment
• Optional cloud sync can be added later
• User owns and controls data

Campus Memory

• Uses centralized backend memory service
• Scoped by tenant and user identity
• Isolated memory boundaries per user
• Institutional retention, audit, and policy controls

Suggested key shape:

• tenantId:userId:memoryKey

WhatsApp and Channel Clarification

For campus mode:

• WhatsApp, email, and web are access channels
• They are not the persistent memory layer
• Backend resolves tenant and user on each request
• Backend loads policy + memory context before responding

Department Copilot Model

Campus deployments should use one copilot per department.

Benefits:

• Stronger policy and ownership boundaries
• Consistent responses in domain context
• Easier routing, memory scoping, and escalation
• Better scalability across large institutions

Example department copilots:

• CSE
• ECE
• Mechanical
• English

Model Strategy

Personal

1. Managed default model
2. Bring-your-own-key provider mode
3. Advanced self-hosted mode

Campus

1. Institution-approved cloud model list
2. Institution-managed keys
3. Optional private/self-hosted models where required

Website and UX Direction

The UI should keep both conversion paths visible and distinct:

1. Personal path: direct payment and installer funnel
2. Campus path: contact/demo and deployment funnel

Key pages:

• Home
• Personal
• Campus
• Pricing
• Register
• Contact Sales
• Security
• Privacy
• Terms
• FAQ

Documentation Source

This README is aligned with:

1. Luna/docs/SORA_PROJECT_WEB_UI_BRIEF.md
2. Luna/docs/SORA_PERSONAL_CAMPUS_ONBOARDING_AND_MEMORY.md

Current State

The repository branding and product direction are now aligned to Friday.

If needed, next steps are to implement:

1. Phase 5 production hardening
2. Database-backed campus memory service
3. Full policy and observability rollout