How the platform actually behaves.

They're nested levels of your institution's real structure. A Course belongs to a Group, a Group belongs to a Schoolhouse, and a Schoolhouse belongs to your Organization. Visibility follows this structure automatically — someone placed at the Schoolhouse level can see everything in their Schoolhouse and every Group beneath it, without anyone needing to grant that access course by course.

They're title labels for your own org chart — nothing more. All three carry identical system permissions at whatever level they're placed. What actually determines what someone can see and do is where they're placed — which Organization, Schoolhouse or Group — not which of the three titles they hold.

They can edit content that already exists within their scope, but they can't create a new course or restructure one — adding, removing or reordering its modules and pages. That's reserved for an ISD assigned to that specific course. This keeps course structure consistent even as broader oversight reaches further up the organization.

All four are assigned to specific courses, and an ISD, Course Director or Instructor can be assigned to several. Instructors teach, grade and edit existing course content. Course Support Staff help with day-to-day roster administration. A Course Director holds oversight for the courses they're assigned to. An ISD — Instructional Systems Designer — is the only role that can create a brand-new course or restructure an existing one.

COTR is a duty that can be added to a Schoolhouse or Organization-level staff placement, rather than a separate role. A COTR can upload and update fiscal-year training schedules, placing the resulting link on exactly the pages that need it — independent of the usual visibility rules.

Yes. A course doesn't have to belong to a Group. One that doesn't is reachable only by its own assigned staff, which is occasionally what you want for material that doesn't belong to any division in particular.

Go to the course catalog and click Sign up. Some courses require instructor approval, in which case you'll be marked Pending until approved. Some courses ask you to complete a short questionnaire first — you'll be taken straight to it, and your enrollment continues once you've finished. If a course is full, you'll join a waitlist instead; seats are filled by course staff, not automatically.

Some courses use a short pre-course questionnaire as an entry step — background, prerequisites, or needs the instructor wants to know about before the course starts. You complete it once, and your enrollment proceeds from there.

When you open an online course for the first time, you'll choose one. Credit mode follows the course as designed — you can't skip ahead of content you haven't completed, and finishing it, including all required quizzes, earns you credit and, where applicable, a certificate. Browse mode lets you explore the course freely in any order, but it does not earn credit — it's for review or preview only. Once chosen, the mode is locked for that enrollment.

Some pages include a popup you must open and acknowledge before you can continue — clearly marked, and confirmed with a small green checkmark once you've opened it. Not all prompts are required; optional ones are there for extra context and don't block your progress.

It shows every module in the course in order, with each one marked as not started, in progress, or complete — reflecting your real, verified progress, the same figure shown on the overall completion bar.

On the course itself. Each week's schedule appears when that week arrives — if you can't see a week yet, it hasn't been released. You can also use the calendar to see when your courses run and when classes meet.

It's where content published for people who have completed a course appears. The link shows up in your navigation once you hold your first certificate, and the page gathers alumni content from every course you've completed, grouped by course. If a course you finished doesn't publish anything for its alumni, the page will simply say so.

No. The link appears as soon as you've completed a course, whether or not that course publishes alumni content. When one of your completed courses adds something, it will appear there.

Only if the course has private messaging turned on — it's off by default. Where it's not available, use the course's discussion board instead.

Build a survey on the course as usual, then mark it as the course's pre-course questionnaire. A course can have one. Responses come back as charts, exportable to PDF, and you're notified as they arrive.

Importing a roster reads a spreadsheet in order to create enrollments — it looks up accounts and enrolls people. The roster document library simply stores spreadsheets against the course as reference material, kept as a history and readable in the browser. Uploading a document changes nobody's enrollment.

Upload a PDF per week. Release dates are computed from the course start date automatically, and you can override any individual week where the course doesn't follow the usual rhythm. Students see each week when it's released. The staff Excel schedule is separate and never visible to students.

Mark a module "Alumni only" on the course Build page — same authoring tools, same content block types, nothing new to learn. That module disappears from the course itself and appears instead on the site-wide Alumni page for anyone who holds that course's certificate. It never counts toward anyone's completion.

Materials, videos and images belong to the specific course they were uploaded for, rather than being shared across every course system-wide. The library defaults to showing items relevant to your own courses to keep things manageable — use the course filter to narrow further, or "Show all" to browse everything you have access to.

Yes — each of these keeps a version history. Open the item and look for its history to view or revert to a previous version.

That course has been marked restricted, meaning its materials are only visible to staff specifically assigned to it — even broader administrative access doesn't reach past the lock. Ask your Organization, Schoolhouse or Group administrator to formally assign you to that course.

It tracks which pages you have actually opened and checked while building a course, so you can see your own review coverage. It is kept provably separate from student completion — different storage, different computation, and distinguishing markup — so the two figures can never be confused for one another.

No. Course-level and organizational accounts are provisioned by an administrator. There is no public self-registration.

A unique numeric identifier, assigned per person. It's required for every account and shown alongside name and email wherever staff details are already displayed.

No. There is no dependency on the public internet at runtime — the platform is built for closed and air-gapped environments from the ground up. There is no external data repository and no vendor-hosted tenancy; the deployment lives inside your boundary.

Yes. The platform has a full-access administrative role that reaches every feature at every level — hierarchy, content libraries, site-wide settings and platform configuration — with one deliberate exception: private messaging between course staff and students, which stays with the people actually teaching the course. That single exclusion is recorded in the code and covered by tests, so it can't be reversed by accident.

Built-in, ready-to-activate connections to a company directory (Active Directory), external student records systems, and training-completion systems (SCORM). Each is scaffolded and inert until pointed at real infrastructure — none run or attempt a connection by default.

Django on Python, with MySQL in production and SQLite for local development. Pages are server-rendered with progressive JavaScript enhancement — there is no frontend framework and no build step, which means no compiled asset pipeline to reproduce inside a closed network.

A large automated test suite — over 4,800 tests in the application — runs on every code change before it ships. Beyond routine coverage, safety-critical logic is checked by mutation testing: deliberately reintroducing a bug to confirm the suite actually catches it, rather than trusting that a passing suite implies real protection.

A detailed feature walkthrough, technical documentation, and a full deployment and security handoff guide are available on request. If your evaluation needs something specific that isn't in those, ask us directly.