Documentation

An assignment-grade database designed to track progress on Ximera assignments using time-series data and latest page-state snapshots. Helping instructors understand their assignments.

The load-bearing design decisions behind Modulus: a contract-based core resolved through a typed DI registry, a commands facade as the only public surface, single-instance in-process deployment, and three separate actor domains.

How packages/core is wired: the type-checked DI registry, the compose() lifecycle, three-level module assembly, the command pattern, and the logging and transaction machinery shared by every service.

The Modulus Postgres schema: identity and RBAC for two actor types, the activity / activity-code / enrollment graph, the two learner-signal tables, LTI integration tables, agent OAuth storage, and the conventions (UUIDv7, version counters, UTC timestamps) shared across them.

The content-authoring instrumentation layer that makes Ximera curriculum 'Modulus-aware': the published @modulus-learning/agent browser library (authoring API, events, local-first resilience, OAuth+PKCE with registry validation) and the server-side activity-state ingestion that records progress and page state under a strict per-activity scope.

How Modulus answers 'who are you?' and 'what may you do?' for its three actor types — learners, administrators, and instrumentation agents — covering the RS256 JWT layer, per-actor sessions and token refresh, ability-based authorization, and the agent's OAuth 2.0 + PKCE flow.

How Modulus is an LTI 1.3 tool for an institutional LMS: the three keypairs and trust model, platform registration, the OIDC login and launch flows, deep linking for content selection, and the queue-backed AGS score-passback worker built to survive thousands of concurrent submissions.

Modulus's security and privacy posture for IT and security staff: the FERPA-aligned data-isolation boundary, what learner data is and isn't stored, the authentication and trust mechanisms across LTI, sessions, and the agent, and the open questions (retention windows, throttling) that need institutional policy.

How a single gradebook build is deployed in one of three runtime modes — all-in-one, frontend-only, or admin-only — via DEPLOYMENT_MODE: what each mode serves, the route surfaces and where they are gated, the background-jobs switch, and the rule that a frontend instance may never run jobs.

A map of the Modulus documentation set — how it is organised into system, subsystem, and operational tiers, what each document covers, and which documents are available today versus planned.