Six stages, each with a job of its own.

The pipeline does not generate into the void. Before the first file is processed you say in your own words what should come out of it: an instruction, the subject-matter context, and the people the course is meant for.

This guidance is free text, and it is never overwritten: each version is appended, with the full history kept. Individual source files can carry guidance of their own as well.

You upload your source material – PDF documents today. Files go straight into object storage over pre-signed links, and are only activated for the run once they have durably arrived there.

After that every file is converted from document to markdown as its own background job. The extracted text stays visible in the application – you can read what the next stage will be working from.

This stage runs in two passes. First, knowledge is extracted from each file on its own – you get a summary per source that you can actually read. Then those individual results are aggregated into a single, course-scoped knowledge base.

The difference matters: ten documents do not turn into ten parallel truths but into one shared foundation for the design stage to work on.

The design instruction is short and concrete: one lesson of each kind, one video, one quiz, one text – or whatever shape your course needs. A language model turns that into a complete course design: title, description, learning objectives, and modules holding the individual lessons with their types.

Then it is your turn. The design can be read, edited by hand or regenerated before anything is produced. Edits overwrite nothing: each one is stored as a new version.

The course design turns into a production that fans out: every lesson starts a job of its own, and production itself splits into four steps that run independently.

Each of those four steps can be bound to a different AI provider account – no single model has to be equally good at prose, video and questions. And every lesson carries its own status: whatever goes wrong is repeated on its own, not as a whole course.

Up to here you have been looking at individual lessons. Validation turns the perspective around: the course is there as a whole – learning objectives, modules, and beneath them every lesson, expandable.

Not as a list of statuses but as content: the text of a text lesson, the scenes of a video lesson with narration and visual cue, the questions of a quiz with the answer marked and explained. What you read here is what goes into the package.

The last stage renders, assembles and uploads. What comes out is a distributable course package: one folder per module, and inside it one file per lesson – HTML for text, quiz and transcript, MP4 for video.

The download runs over a link that is deliberately short-lived and states its own expiry. After that your learning platform takes over: eCourse authors courses, the LMS delivers them – for example ELP, the platform from the same house.

Team settings are where you register your own provider credentials. First as defaults: one provider for text, one for video. Below them, under “Stage Overrides”, it gets stage-specific – parsing, knowledge, design, production, validation and publishing each take credentials of their own.

Production is the one stage that carries two bindings: a text provider and a video provider. That is also the stage where the work fans out into four steps.

eCourse is multi-tenant, and the ordering is plain: a team holds projects, a project holds courses. Producing for several clients, you separate them by project; working by department, the same.

Members join by invitation and hold a role: owner, co-owner, admin or member. Permissions are not a matter of individual screens – every action goes through the same check, wherever in the pipeline it is triggered.