PrismLMS: AI-Powered Learning, End-to-End

The content model is three levels deep. A course contains chapters, and a chapter contains items. An item is a PDF, a video, or a quiz. Every piece of course material resolves to one of those, which gives the admin UI a single mental model to teach and the generation pipeline a single shape to read.

Chapter items vary in structure. A quiz carries questions, options, and answers. A video carries a source and a duration. A PDF carries a file reference. Rather than model each as its own set of tables, item payloads are stored as JSONB in PostgreSQL, so supporting a new item type is a change in application code instead of a migration. The files themselves live in S3 and are served through CloudFront.

The same hierarchy carries multi-tenancy. Courses scope to a tenant, and everything beneath a course inherits that scope, so tenant isolation follows the tree rather than being re-established at each level.

The obvious way to build this is to hand a PDF to a model and ask for a quiz. We did not do that. Generation runs in two stages, and the split is the reason the output is usable.

The first stage reads the source material and extracts structured knowledge from it, building a unified knowledge base for the chapter. The second stage generates each artifact from that knowledge base rather than from the raw file. LangChain orchestrates both.

The payoff is consistency. When four artifacts are generated independently from the same source, each generation interprets that source afresh, and a quiz can end up testing material the summary never mentions. Generating from one extracted representation means all four artifacts describe the same chapter. It also makes the expensive comprehension work happen once instead of four times.

The knowledge base is what lets the platform synthesize across formats. Content that arrives as a PDF and content that arrives as a video are reduced to the same representation before anything is generated from either.

Once the knowledge base exists, the four artifacts have no dependency on one another. A quiz does not need the summary, and a mind map does not need the flashcards. Running them in sequence would make total time the sum of four model calls for no reason.

Five LLM executions are dispatched simultaneously and awaited together, using Promise-based concurrency in the NestJS services. Total generation time for a chapter lands at roughly 30 to 60 seconds, which is close to the slowest single call rather than the sum of all of them.

The range matters more than the midpoint. Because the wall-clock time is set by whichever call is slowest, a chapter dense enough to make one artifact expensive moves the whole number, which is why generation is quoted as a range rather than a fixed figure.

Half a minute to a minute of silence after clicking a button reads as a broken page. The generation time was already close to its floor, so the remaining work was on how that time is presented.

Artifacts stream to the client over Socket.IO as each one completes, with RxJS handling the event streams on the way through. The admin sees the summary appear, then the flashcards, then the quiz, in whatever order they finish. Nothing waits for the slowest call before anything is shown.

No measured time changed. The perceived wait did, because progress is visible for the whole duration instead of only at the end. Streaming over batch processing was the decision, and it did more for the authoring experience than shaving seconds off the pipeline would have.

Model choice is a deployment concern, not an application one. Some deployments want the strongest available hosted model. Others cannot send course material to a third-party API at all, or need per-token cost under a ceiling that a frontier model will not meet.

So the generation code targets an abstraction rather than a provider. The same pipeline runs against OpenAI GPT-4.1 or against Llama 3.1 hosted locally through Ollama, and switching between them is configuration. Neither the two-stage pipeline nor the parallel execution layer knows which one it is talking to.

That covers both cost optimization and data residency with one mechanism. A tenant that needs everything to stay on its own infrastructure runs the local model. A tenant that wants maximum output quality runs the hosted one. The services are packaged with Docker, so either shape deploys the same way.