Skip to content

Latest commit

 

History

History
649 lines (450 loc) · 26.2 KB

File metadata and controls

649 lines (450 loc) · 26.2 KB

Prism: Integrated Learning & Network Management Platform

Project Requirements Document

Version: 1.0
Date: July 2, 2025
Author: Development Team
Status: Draft for Review


Table of Contents


Executive Summary

Project Vision

Prism combines two complementary systems—Coterie (network relationship management) and Seeker (personalized learning)—to create a comprehensive solution for managing educational communities from application through alumni engagement.

Business Case

Founders & Coders faces challenges with:

  • Information silos across Airtable, Notion, and Google Calendar
  • Manual management of complex learner-mentor relationships
  • Institutional knowledge dependency on individual staff members
  • Repetitive work in creating personalized learning paths
  • Difficulty tracking progression from applicant to alumni

Solution Overview

An integrated platform that models organizational relationships as a dynamic graph while providing AI-enhanced personalized learning experiences, streamlining workflows for the small permanent team while scaling learning support for cohorts of learners and applicants.


1. Project Scope

1.1 In Scope

Coterie (Network Management):

  • Graph-based relationship modeling for cohorts, people, projects, skills, events, and resources
  • Integration with existing tools (Airtable, Notion, Google Calendar)
  • Permission-based data access and interactive visualization
  • Automated report generation and printable worksheets
  • Alumni tracking and engagement tools

Seeker (Learning Management):

  • Containerized learning environments for applicant workshops
  • AI-powered personalized learning path generation
  • Automated application readiness assessment
  • Dynamic resource curation and skill tracking
  • Progress monitoring and intervention alerts

Shared Infrastructure:

  • Unified authentication and user management
  • Common data models and API layer
  • Integrated analytics and reporting dashboard tied to OFSTED compliance
  • Mobile-responsive web interface

1.2 Out of Scope (Phase 1)

  • Financial management or payment processing
  • Video conferencing or communication tools
  • Third-party job board integrations
  • Advanced AI tutoring capabilities
  • Multi-language support
  • Apprenticeship portfolio generation tools
  • Retrieving & exporting batches of trainee developer profiles for submission to employers

2. Stakeholder Analysis

2.1 Primary Stakeholders

  • Dan Sofer (Executive Director): ROI, strategic alignment
  • Anna Braybrooke (Chief Operating Officer): unified tool access, learner support tracking
  • Jessica Jeffery (Acting Chief Operating Officer & Admin Lead): data access, workflow optimization
  • Staff Apprentices (Regular Platform Users): efficiency, ease of use
  • Learners & Applicants (End Users): learning experience, progress tracking

2.2 Secondary Stakeholders

  • Alumni - Directory access, networking features
  • Partner Organizations - Integration requirements
  • Development Team - Technical feasibility, maintenance

3. Functional Requirements

3.1 Coterie - Network Management System

3.1.1 Core Entity Management

  • REQ-C001: System SHALL support CRUD operations for all entity types (Cohort, Person, Project, ProjectPrimitive, Skill, Event, EventPrimitive, Resource)
  • REQ-C002: System SHALL maintain relationship types: LEARNER_IN, FACILITATOR_OF, LEARNER_AT, FACILITATOR_AT, SUPPORTER_OF, FOCUSSED_ON, HAS_SKILL, REQUIRES, WORKED_ON, INSTANCE_OF, SCHEDULED_AT, LINKS_TO
  • REQ-C003: System SHALL support many-to-many relationships with temporal attributes
  • REQ-C004: System SHALL provide audit trail for all data modifications

3.1.2 Data Integration

  • REQ-C005: System SHALL import existing data from Airtable exports (CSV/JSON)
  • REQ-C006: System SHALL import existing data from Notion exports
  • REQ-C007: System SHALL import events from Google Calendar
  • REQ-C007a: System SHOULD sync bidirectionally with Google Calendar for events
  • REQ-C008: System SHALL provide idempotent migration scripts
  • REQ-C009: System SHALL maintain data integrity across all integrations

3.1.3 Query and Visualization

  • REQ-C010: System SHALL support predefined query templates for common use cases
  • REQ-C011: System SHOULD parse free-text queries into graph traversals
  • REQ-C012: System SHALL provide interactive graph visualization with filtering
  • REQ-C013: System SHALL generate printable static reports and worksheets
  • REQ-C014: System SHALL support export to PDF, CSV, and JSON formats

3.1.4 Permission and Security

  • REQ-C015: System SHALL authenticate staff users via Google Workspace OAuth and learners/applicants via email verification
  • REQ-C016: System SHALL restrict administrative functions to verified staff accounts (@foundersandcoders.com domain)
  • REQ-C017: System SHALL implement role-based access control (Staff, Facilitator, Current Learner, Applicant, Alumni)
  • REQ-C018: System SHALL support granular permissions per entity and relationship based on user role and cohort membership
  • REQ-C019: System SHALL provide view-only access for sensitive data

3.2 Seeker - Learning Management System

3.2.1 Personalized Learning Paths

  • REQ-P001: System SHALL generate individualized learning sequences based on skill assessment
  • REQ-P002: System SHOULD adapt learning paths based on progress and performance
  • REQ-P003: System SHALL recommend resources from curated knowledge base
  • REQ-P004: System SHALL track skill acquisition and competency levels
  • REQ-P005: System SHALL provide milestone-based progression tracking

3.2.2 Containerized Learning Environment

  • REQ-P006: System SHALL provide isolated development environments for each learner
  • REQ-P007: System SHALL support multiple programming languages and frameworks
  • REQ-P008: System SHALL automatically provision boilerplate codebases for workshops
  • REQ-P009: System SHALL enable collaborative coding within cohort containers
  • REQ-P010: System SHALL backup and version learner work automatically

3.2.3 AI-Enhanced Features

  • REQ-P011: System SHALL provide AI agents customized for different learning stages
  • REQ-P012: System SHALL generate structured feedback on code submissions
  • REQ-P013: System SHOULD identify learning patterns and recommend interventions
  • REQ-P014: System MAY curate CodeWars kata based on current skill level
  • REQ-P015: System SHALL detect application readiness using automated assessment

3.2.4 Progress Monitoring

  • REQ-P016: System SHALL parse Git commit histories for progress analysis
  • REQ-P017: System SHALL generate narrative summaries of learner development
  • REQ-P018: System SHALL alert facilitators to learners requiring support
  • REQ-P019: System SHALL track completion rates and engagement metrics
  • REQ-P020: System SHALL provide parent/guardian progress visibility (where applicable)

3.4 Regulatory Compliance and Communication

3.4.1 OFSTED Compliance Features

  • REQ-R001: System SHALL track and document learner progress against defined learning outcomes
  • REQ-R002: System SHALL generate evidence portfolios for individual learner achievements
  • REQ-R003: System SHALL compile attendance and engagement metrics for regulatory reporting
  • REQ-R004: System SHALL maintain audit trails for all learner assessment and progression decisions
  • REQ-R005: System SHOULD support customizable reporting templates for different regulatory requirements

3.4.2 Data Export and Documentation

  • REQ-R006: System SHALL export comprehensive learner data in multiple formats (PDF, Excel, CSV)
  • REQ-R007: System SHOULD generate anonymized cohort performance summaries and trend analyses
  • REQ-R008: System SHALL create formatted reports suitable for external stakeholder communication
  • REQ-R009: System SHALL maintain historical data integrity for multi-year regulatory reviews
  • REQ-R010: System SHALL provide role-based access to sensitive regulatory information

3.4.3 Quality Assurance and Monitoring

  • REQ-R011: System SHOULD flag learners at risk based on engagement and progress indicators
  • REQ-R012: System SHOULD track intervention effectiveness and support outcomes
  • REQ-R013: System MAY generate automated compliance checking reports
  • REQ-R014: System SHOULD support comparative analysis between cohorts and time periods
  • REQ-R015: System SHALL maintain documentation standards required for external audits

3.5 Integrated Platform Features

3.5.1 Unified User Experience

  • REQ-I001: System SHALL provide single sign-on across both systems
  • REQ-I002: System SHALL maintain consistent UI/UX patterns
  • REQ-I003: System SHALL support responsive design for mobile and tablet
  • REQ-I004: System SHALL provide unified navigation between Coterie and Seeker
  • REQ-I005: System SHALL maintain user context when switching between systems

3.5.2 Data Synchronization

  • REQ-I006: System SHALL sync user profiles between Coterie and Seeker
  • REQ-I007: System SHALL propagate skill achievements from Seeker to Coterie
  • REQ-I008: System SHALL update relationship status based on learning progression
  • REQ-I009: System SHALL maintain data consistency across both systems
  • REQ-I010: System SHALL provide conflict resolution for data discrepancies

3.5.3 Analytics and Reporting

  • REQ-I011: System SHALL generate cross-platform analytics dashboards
  • REQ-I012: System SHALL track learner journey from application to alumni
  • REQ-I013: System SHALL provide cohort performance comparisons
  • REQ-I014: System SHALL identify successful learning patterns for optimization
  • REQ-I015: System SHALL generate executive summary reports for stakeholders

4. Technical Requirements

4.1 Architecture Requirements

4.1.1 Technology Stack

  • REQ-T001: Backend SHALL use Deno runtime with Oak framework
  • REQ-T002: Database SHALL use Neo4j for graph operations
  • REQ-T003: API SHALL implement GraphQL with REST fallbacks
  • REQ-T004: Frontend SHALL use SvelteKit with XState for state management
  • REQ-T005: Styling SHALL use Tailwind CSS utility framework
  • REQ-T006: Authentication SHALL use Auth.js with Google OAuth for staff and email verification for learners/applicants

4.1.2 Performance Requirements

  • REQ-T007: System SHALL support 50 concurrent users
  • REQ-T008: Page load times SHOULD NOT exceed 3 seconds
  • REQ-T009: Graph queries SHALL return results within 5 seconds
  • REQ-T010: File uploads SHALL support up to 50MB
  • REQ-T011: System SHOULD maintain 99% uptime during business hours

4.1.3 Scalability Requirements

  • REQ-T012: System SHALL support horizontal scaling for web servers
  • REQ-T013: Database SHALL support clustering for high availability
  • REQ-T014: File storage SHALL use cloud-based solutions (S3/GCS)
  • REQ-T015: CDN SHALL serve static assets globally
  • REQ-T016: System SHALL handle 10x current user base without architecture changes

4.1.4 Security Requirements

  • REQ-T017: All data transmission SHALL use HTTPS/TLS 1.3
  • REQ-T018: Staff authentication SHALL use Google OAuth; learner authentication SHALL use secure email verification
  • REQ-T019: API endpoints SHALL implement rate limiting
  • REQ-T020: User input SHALL be sanitized and validated
  • REQ-T021: System SHALL implement CSRF protection
  • REQ-T022: Audit logs SHALL be maintained for all data access

4.2 Development Requirements

4.2.1 Code Quality

  • REQ-D001: Code coverage SHALL exceed 90% for critical paths
  • REQ-D002: All code SHALL pass TypeScript strict mode compilation
  • REQ-D003: ESLint and Prettier SHALL enforce consistent formatting
  • REQ-D004: All functions SHALL include comprehensive JSDoc documentation
  • REQ-D005: Integration tests SHALL cover all API endpoints

4.2.2 Development Workflow

  • REQ-D006: GitHub Actions SHALL automate CI/CD pipeline
  • REQ-D007: Pull requests SHALL require code review approval
  • REQ-D008: Automated tests SHALL run on every commit
  • REQ-D009: Staging environment SHALL mirror production configuration
  • REQ-D010: Database migrations SHALL be reversible and tested

5. Integration Requirements

5.1 External System Integration

5.1.1 Google Workspace

  • REQ-E001: Calendar events SHALL be imported from Google Calendar
  • REQ-E001a: Calendar events SHOULD sync bidirectionally
  • REQ-E002: User authentication SHALL use Google OAuth
  • REQ-E003: Drive integration SHALL support file sharing
  • REQ-E004: Gmail integration SHALL enable notification delivery

5.1.2 Airtable Integration

  • REQ-E005: Existing Airtable data SHALL be importable
  • REQ-E006: Key fields SHALL sync bidirectionally where appropriate
  • REQ-E007: API rate limits SHALL be respected
  • REQ-E008: Data mapping SHALL be configurable

5.1.3 Notion Integration

  • REQ-E009: Notion pages MAY be importable as resources
  • REQ-E010: Database exports MAY be processable
  • REQ-E011: Notion webhooks SHALL trigger data updates where available

5.2 Internal System Integration

5.2.1 Data Flow

  • REQ-I020: Learning progress SHALL update network relationships
  • REQ-I021: Network changes SHALL trigger learning path adjustments
  • REQ-I022: Skill assessments SHALL inform both systems
  • REQ-I023: Event scheduling SHALL coordinate between systems

6. User Stories and Use Cases

6.1 Permanent Staff Stories

As Jessica (Operations Manager), I want to:

  • View consolidated information from all tools in one dashboard
  • Generate reports without manually compiling data from Airtable, Notion, and Calendar
  • Set up new cohorts efficiently with proper resource linking
  • Track institutional knowledge and identify documentation gaps as the organization grows

As Anna (Chief Operating Officer), I want to:

  • Access all learner information without switching between multiple tools
  • Track learner wellbeing indicators and support interventions across cohorts
  • Create formatted reports for stakeholders, external communications, and regulatory requirements
  • Manage user access and permissions from a central location
  • Monitor learner engagement patterns to identify those needing wellbeing support
  • Maintain accurate records as learners progress through different program stages
  • Generate comprehensive documentation for OFSTED and other regulatory bodies

As Dan (Executive Director), I want to:

  • Understand organizational patterns and performance trends across cohorts
  • Make data-driven decisions about program improvements
  • Ensure sustainable knowledge management as the team grows
  • Maintain visibility into all aspects of operations without micromanaging

6.2 Staff Apprentice (Facilitator) Stories

As a Staff Apprentice facilitating cohorts, I want to:

  • See all my current learners and their progress in one view
  • Access session plans that automatically link to cohort requirements and learner needs
  • Identify learners who need additional support based on engagement and progress
  • Share resources and insights that become available to future facilitators

6.3 Learner Stories

As a Current Learner, I want to:

  • Follow a personalized learning path adapted to my pace and learning style
  • Understand how my current skills connect to upcoming projects and career opportunities
  • Access curated resources relevant to my current learning stage
  • Track my progress and see milestone achievements clearly

As an Applicant, I want to:

  • Understand exactly what skills I need to develop for successful application
  • Access workshops and resources that prepare me for the FAC program
  • Receive feedback on my code and clear guidance for improvement
  • Know when I'm ready to submit my application with confidence

6.4 Alumni Stories

As an Alumnus, I want to:

  • Maintain connections with my cohort, facilitators, and the FAC community
  • Contribute back by mentoring current learners in areas where I have expertise
  • Access continuing education resources and updates about program evolution
  • Represent FAC effectively in my professional network

7. Success Criteria

7.1 Stakeholder Satisfaction Metrics

7.1.1 Core Staff Satisfaction (Dan, Jessica, Anna)

  • Operations Efficiency: Jessica reports significant reduction in time spent searching for learner information across multiple tools
  • Administrative Streamlining: Anna reports consolidated workflows replacing previous multi-platform processes, with improved learner wellbeing tracking capabilities
  • Regulatory Compliance: Anna reports streamlined OFSTED preparation with automated evidence collection and reporting
  • Strategic Oversight: Dan reports improved visibility into cohort performance and organizational patterns
  • Data Confidence: All permanent staff express confidence in data accuracy and completeness for both internal and external reporting

7.1.2 Facilitator Satisfaction (Staff Apprentices)

  • Workflow Improvement: Facilitators report streamlined session planning and learner tracking
  • Information Access: Quick access to relevant learner history and skill progression
  • Reduced Friction: Less time spent on administrative tasks, more time on teaching and mentoring
  • Collaborative Features: Effective knowledge sharing between current and former facilitators

7.1.3 Learner and Applicant Satisfaction

  • Learning Experience: Current learners report clear progression visibility and relevant resource recommendations
  • Application Process: Applicants report understanding of requirements and preparedness for success
  • Progress Tracking: Users can easily see their skill development and achievement milestones
  • Resource Access: Curated, relevant resources reduce time spent searching for learning materials

7.2 System Adoption and Reliability

7.2.1 Usage Patterns

  • Consistent daily usage by all permanent staff for core workflows
  • Regular engagement from staff apprentices for facilitator tasks
  • Learner self-service for progress tracking and resource access
  • Minimal support requests related to basic platform functionality

7.2.2 Data Quality and Integration

  • Successful consolidation of existing Airtable and Notion data
  • Reliable synchronization with Google Calendar for event management
  • Maintained data consistency across all integrated systems
  • Accurate representation of complex learner-cohort-facilitator relationships
  • Comprehensive evidence trails suitable for regulatory review and external audits

8. Risk Assessment and Mitigation

8.1 Technical Risks

8.1.1 Data Migration Risk

Risk: Legacy data corruption or loss during migration
Probability: Medium
Impact: High
Mitigation: Comprehensive backup strategy, phased migration approach, extensive testing on copies

8.1.2 Integration Complexity

Risk: Third-party API changes breaking integrations
Probability: Medium
Impact: Medium
Mitigation: Abstraction layers, fallback mechanisms, monitoring and alerting

8.1.3 Performance Bottlenecks

Risk: Graph queries becoming slow with large datasets
Probability: Low
Impact: Medium
Mitigation: Query optimization, caching strategies, database indexing

8.2 Organizational Risks

8.2.1 User Adoption

Risk: Staff resistance to changing established workflows
Probability: Medium
Impact: High
Mitigation: Close collaboration with Jessica and Anna during development, iterative feedback integration, gradual feature rollout with fallback to existing tools

8.2.2 Scope Creep

Risk: Requests for additional features delaying core functionality
Probability: High
Impact: Medium
Mitigation: Clear requirement boundaries with Dan, regular stakeholder check-ins, documented change request process for the small team

8.2.3 Knowledge Transfer

Risk: Over-dependence on single developer during apprenticeship period
Probability: Medium
Impact: High
Mitigation: Comprehensive documentation, code review with experienced staff, gradual knowledge sharing with other apprentices

8.3 External Risks

8.3.1 Vendor Dependency

Risk: Critical third-party service discontinuation
Probability: Low
Impact: High
Mitigation: Multi-vendor strategies, open-source alternatives, data portability


9. Implementation Timeline

The project will be delivered across four phases over 12 months:

  • Phase 1 (Months 1-3): Core foundation with CLI tools and basic API
  • Phase 2 (Months 4-6): Seeker features with AI integration
  • Phase 3 (Months 7-9): External integrations and production readiness
  • Phase 4 (Months 10-12): OFSTED compliance and regulatory communication tools

9.1 Phase 1: Foundation (Months 1-3)

Milestone 1.1: CLI-First Graph MVP (Month 1)

  • Graph schema implementation
  • Basic CRUD operations via CLI
  • Data migration scripts
  • Unit test suite

Milestone 1.2: GraphQL API Layer (Month 2)

  • REST/GraphQL API development
  • Authentication integration
  • API documentation and testing

Milestone 1.3: Basic Web Interface (Month 3)

  • SvelteKit frontend setup
  • Selector-driven UI for network browsing
  • Basic CRUD operations through web interface

9.2 Phase 2: Core Features (Months 4-6)

Milestone 2.1: Advanced Querying (Month 4)

  • Free-text query parsing
  • Interactive graph visualization
  • Export and reporting functions

Milestone 2.2: Seeker MVP (Month 5)

  • Containerized development environments
  • Basic personalized learning paths
  • Progress tracking infrastructure

Milestone 2.3: AI Integration (Month 6)

  • AI agent implementation for learning guidance
  • Automated assessment systems
  • Resource recommendation engine

9.3 Phase 3: Integration and Polish (Months 7-9)

Milestone 3.1: External Integrations (Month 7)

  • Google Calendar bidirectional sync
  • Airtable/Notion data integration
  • Email notification system

Milestone 3.2: Advanced Features (Month 8)

  • Alumni tracking and engagement tools
  • Advanced analytics dashboard
  • Mobile optimization

Milestone 3.3: Production Readiness (Month 9)

  • Performance optimization
  • Security hardening
  • Documentation and training materials

9.4 Phase 4: Regulatory Compliance and Communication (Months 10-12)

Milestone 4.1: OFSTED Compliance Framework (Month 10)

  • Regulatory reporting templates and automated data collection
  • Learner progress evidence compilation and documentation systems
  • Quality assurance metrics tracking and outcome measurement tools

Milestone 4.2: Advanced Reporting and Export Capabilities (Month 11)

  • Comprehensive learner journey documentation with evidence trails
  • Customizable report generation for different regulatory requirements
  • Automated compliance checking and gap identification systems

Milestone 4.3: Communication and Review Tools (Month 12)

  • Stakeholder communication dashboards with filtered views for different audiences
  • Historical trend analysis and comparative cohort performance reporting
  • External audit trail support and documentation export capabilities

10. Resource Requirements

10.1 Development Team

  • Primary Developer (Apprentice): Full-stack development, architecture decisions, project leadership
  • Development Support: Mentorship from experienced staff and external consultants as needed
  • Stakeholder Involvement: Regular input from Jessica (operations) and Anna (administration)
  • Technical Review: Code review and guidance from Dan and external technical advisors

10.2 Infrastructure

  • Development Environment: Local Docker setup, staging servers
  • Production Environment: Cloud hosting (Deno Deploy, Vercel), managed Neo4j
  • Monitoring and Analytics: Application monitoring, user analytics
  • Backup and Security: Automated backups, security scanning

10.3 Third-Party Services

  • Authentication: Google Workspace OAuth for staff, email verification service for learners
  • Database: Neo4j Aura or self-hosted cluster
  • File Storage: Google Cloud Storage or AWS S3
  • Email: SendGrid or similar service
  • Monitoring: Sentry for error tracking

11. Acceptance Criteria

11.1 System Acceptance

  • All functional requirements implemented and tested
  • Performance benchmarks met under load testing
  • Security audit completed with no critical vulnerabilities
  • Data migration completed with <0.1% data loss
  • User acceptance testing completed with >90% satisfaction

11.2 Go-Live Criteria

  • Production environment deployed and monitored
  • Staff training completed for all user roles
  • Documentation finalized and accessible
  • Support processes established
  • Rollback plan tested and available

12. Appendices

The following appendices are planned for future versions of this document and do not yet exist:

  • Appendix A: Data Schema Definitions - Detailed entity and relationship specifications for graph database
  • Appendix B: API Specifications - Complete GraphQL schema and REST endpoint documentation
  • Appendix C: Integration Specifications - Technical details for third-party system integrations
  • Appendix D: Security and Privacy Compliance - GDPR compliance measures and data protection protocols
  • Appendix E: Disaster Recovery Plan - Backup procedures and system recovery protocols

Document Control:

  • Next Review Date: TBD
  • Approval Required: Dan Sofer, Jessica Jeffery
  • Version History: TBD