Roadmap
Development progress, architectural milestones, and future goals for the Faculytics platform.
This roadmap tracks the implementation status of the api.faculytics backend against the product direction. It reflects the checked-in develop branch as of 2026-04-12.
Project Vision
Provide a robust, analytics-driven bridge between Moodle learning environments and institutional assessment workflows, enabling data-informed decisions through synchronized academic data, asynchronous AI enrichment, and structured feedback collection from direct submissions and file-based ingestion.
Status Snapshot
| Phase | Status | Notes |
|---|---|---|
| Phase 1. Foundation & Core Synchronization | Complete | Core auth, Moodle sync, hydration, scheduling, and resilience are in place. |
| Phase 2. Questionnaire & Ingestion Engine | Mostly complete | Questionnaire management, draft/submit flows, and CSV ingestion are live; self-serve file mapping is still pending. |
| Phase 3. AI & Inference Pipeline | Mostly complete | End-to-end pipeline is shipped; production worker rollout and operator monitoring remain open. |
| Phase 4. Analytics & Reporting Infrastructure | In progress | Materialized-view analytics, faculty reports, and PDF export are live; Excel export and long-term analytics scaling remain open. |
| Phase 5. Governance & Ecosystem | In progress | Scoped access, admin tooling, audit logging, and audit query endpoints are implemented; finer-grained permissions and ecosystem integrations remain open. |
Cross-cutting platform capabilities already present in the codebase but not treated as separate roadmap phases include Redis-backed caching and throttling, structured health checks, request-scoped CLS metadata, and the authenticated ChatKit endpoint.
Phase 1: Foundation & Core Synchronization
- Identity Management: Moodle-integrated JWT auth with local access and refresh tokens.
- Hybrid Authentication Strategy (FAC-34): Priority-based login strategies support both local credentials and Moodle SSO.
- Robust Startup: Fail-fast bootstrap runs migrations, infrastructure seeders, and configuration validation before serving traffic.
- Institutional Hierarchy Sync: Campuses, semesters, departments, programs, courses, and enrollments are mirrored from Moodle.
- Per-User Hydration on Login: Moodle logins refresh the user's courses, enrollments, sections, and institutional roles.
- Section Sync from Moodle Groups: Course groups are materialized locally as
Sectionand attached to enrollments. - Institutional Authority Mapping: Dean and chairperson scope is derived from Moodle category structure, with support for manual dean assignment and a server-resolved dean-eligibility lookup for the admin UI.
- User Scope & Role Backfill During Sync: Enrollment sync now populates
user.campus/program/departmentand derivesuser.rolesfrom enrollments + institutional roles (protecting manually grantedSUPER_ADMIN/ADMIN) as explicit post-enrollment phases. - Dynamic Sync Scheduling & SyncLog Observability: Sync cadence is runtime-configurable and every run is recorded with per-phase metrics.
- Semester Label Enrichment: Moodle semester codes are parsed into display labels and academic year metadata.
- Moodle Connectivity Resilience (FAC-33): 10-second request timeouts and connectivity-specific failures prevent hanging auth and sync paths.
- Refresh Token Cleanup (FAC-35): Expired refresh tokens are purged on a 12-hour schedule with retention handling.
Phase 2: Questionnaire & Ingestion Engine
- Recursive Schema Validation: Questionnaire schemas enforce leaf-only questions and exact weight totals.
- Dimension Registry & Admin API: Canonical dimensions are seeded and can be managed through the dimensions module.
- Questionnaire Lifecycle Management: Questionnaires support creation, update, archive, publish, deprecate, version detail, and version-from-template flows (draft seeded from any prior published version).
- Institutional Snapshotting: Submissions persist faculty, department, program, campus, and semester snapshots for historical stability.
- Draft Save/Resume Flow: Respondents can save, retrieve, list, and delete drafts before final submission.
- Submission & Scoring: Finalized submissions validate answers, compute normalized scores, and enforce duplicate-submission rules.
- Bulk CSV Ingestion: Version-specific CSV templates and audited
/questionnaires/ingestuploads support bulk submission imports. - Ingestion Engine (Orchestrator): Stream-based processing supports dry runs, concurrency control, timeouts, and bounded error handling.
- Adapter-Based Ingestion Foundation: CSV is live in the API, and Excel adapter support exists in the ingestion layer for future exposure.
- Self-Serve File-to-Questionnaire Mapping: Imports still rely on fixed metadata headers plus question UUID columns; there is no user-defined mapping DSL or UI yet.
Phase 3: AI & Inference Pipeline
- BullMQ Job Queue (FAC-44): Queue-per-type analysis jobs run on Redis with retry and backoff policies.
- Pipeline Orchestrator (FAC-46): Confirm-before-execute orchestration tracks coverage, warnings, stage progression, and terminal states.
- Sentiment Analysis (FAC-46): Batch sentiment classification persists per-submission polarity scores.
- Sentiment Gate (FAC-46): Low-signal positive comments are filtered before topic modeling.
- Topic Modeling (FAC-46): Topic discovery persists assignments, keywords, and run provenance.
- Topic Labeling: Topic clusters are labeled before recommendation generation.
- Embedding Generation (FAC-46): pgvector-backed embeddings are stored and upserted per submission.
- Recommendations Engine v2 (FAC-55): Recommendations are generated directly via OpenAI with structured output, confidence, and pipeline-scoped supporting evidence (topic counts narrowed to the pipeline's
submissionIds, preventing cross-faculty leakage). - LLM Worker Hardening: Sentiment processor pins responses to the dispatched
submissionIdset, drops hallucinated IDs with observability logs, and terminally fails the stage when a batch is 100% hallucinated (retrying the LLM is counter-productive). - Worker Contracts & Inference Versioning: Zod-validated contracts and version fields exist across pipeline runs.
- Local Worker Simulation:
mock-worker/supports local development without deployed inference workers. - RunPod / Production Worker Rollout: Sentiment and topic-model stages still need production endpoint deployment and cutover.
- Pipeline Monitoring: There is no Bull Board or equivalent operator dashboard yet for failed jobs and queue health.
Phase 4: Analytics & Reporting Infrastructure
- Postgres-Native Analytics Strategy: Materialized views are the current analytics backbone instead of live multi-join dashboard queries.
- Snapshot-to-Analytics Refresh Pipeline: Completed analysis pipelines enqueue asynchronous analytics refresh jobs.
- Precomputed Aggregates:
mv_faculty_semester_statsandmv_faculty_trendsprovide dashboard-ready rollups. - Trend Analysis Engine: Trend APIs compute regression slopes and confidence (
R^2) over semester history. - Dashboard APIs: Department overview, attention list, and faculty trends endpoints are live and scope-aware.
- Faculty Evaluation Reports: Per-question reports and paginated qualitative comment endpoints are implemented.
- Analytics Freshness Tracking:
analytics_last_refreshed_atis recorded so consumers can show data staleness. - Faculty Evaluation PDF Export: Async PDF generation via BullMQ + Puppeteer, stored in Cloudflare R2 with presigned download URLs. Single and batch generation with scope-aware authorization.
- Excel Export: Excel report generation is not implemented yet.
- Long-Term OLAP Path: A broader warehouse or alternative analytical engine decision is still open if current Postgres views become a bottleneck.
Phase 5: Governance & Ecosystem
- Role-Protected APIs:
UseJwtGuard()andRolesGuardenforce route-level access across application modules. - Scoped Dean/Chairperson Access:
ScopeResolverServicerestricts analytics, curriculum, and faculty queries to authorized departments and programs. - Institutional Role Administration: Super admins can assign and remove manual dean/chairperson roles through admin endpoints.
- Admin Directory APIs: Super-admin endpoints support user listing, filtering, and institutional role management workflows.
- Append-Only Audit Trail: Auth, sync, questionnaire, analysis, and Moodle provisioning actions are captured through the global audit pipeline.
- Audit Review Surface:
GET /audit-logsandGET /audit-logs/:idexpose filterable, paginated audit queries (super-admin only) with stable ordering and LIKE-pattern sanitization. - Moodle Seeding Toolkit: API-native provisioning of categories, bulk/quick courses, and fake users replaces the external Rust CLI, with live Moodle tree inspection and cascading admin filters.
- Fine-Grained Permission Model: Access control is still role-centric rather than permission-centric.
- Notification Engine: Automated reminders and outbound notifications are still pending.
- External SIS Integration: Moodle remains the only production integration surface for institutional data.
Immediate Next Steps
- Productionize the remaining external inference stages by replacing mock or placeholder worker URLs with deployed sentiment and topic-model endpoints.
- Add operator visibility for BullMQ queues, sync runs, analytics refresh failures, and audit review workflows.
- Extend the reporting surface with Excel export, department summary rollup reports, and scheduled delivery paths.
- Mature governance from coarse role checks into a clearer permission model with explicit review tooling.
- Reassess the analytics storage strategy once dashboard scope expands beyond the current faculty- and department-focused materialized views.