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.

Short content you can open without being enrolled in anything. A micro-lesson is a single screen — a summary, sometimes a video, some reading and a few knowledge checks — with a Mark as done control that becomes available once you've answered every check correctly. Retries are unlimited and nothing is scored. An informational video is just that: a title, a description and one video.

Both have their own link in your navigation, and anything published is open to you the day it goes up. More on both here.

Yes. There's a theme picker in the navigation bar with four settings: Standard, which is the appearance Guidepost has always had and what you start with; Light; Dark; and one that simply follows whatever your own device is set to.

The choice is yours and applies to your account only. Nobody else's view changes, and your organization doesn't pick one on your behalf.

On the course schedule, reachable beside the calendar. It lists every course run over a four-month window, grouped by month, with the dates, the title and the course code. It is deliberately the same for everyone signed in — you see the whole institution's schedule, not a filtered version of it.

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.

An ISD, and the full-access administrative role. That is the same line the platform already draws around creating a course: putting something in front of every person in the installation is a wider act than building a course inside one group, and an instructor cannot create a course today.

Uploading a video into a course library is unchanged — anyone who could do that before still can, on exactly the same terms. Editing, archiving, publishing and unpublishing an item stay with whoever created it.

No, and the platform will not claim otherwise. For a video uploaded to your deployment it records that a person opened it, on the strength of a real play event. That is the whole of the claim — it does not mean the video was watched to the end.

For a video hosted somewhere else, nothing is recorded at all, because we do not control that player and receive no reliable signal from it. Micro-lessons are different: those do record completion, because there is a real act to record.

If you need to be able to prove that a named person completed something, build a course — enrollment, required content, assessment and a certificate exist for exactly that.

Not for anything you have to evidence. A micro-lesson is one screen and has no roster, no enrollment and no certificate behind it, which is what makes it quick to publish and also what makes it the wrong instrument for a compliance record.

The useful test is not length. It is whether somebody will later have to prove a named person completed it.

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

Yes. Bulk user import takes a CSV or Excel file of up to five thousand rows, with username, email and role required and first name, last name and AIN optional. Column headings are matched against a table of aliases, so an export from an HR system usually works without being reshaped first. It is available both as a command your administrators run and as an in-app upload behind the full-access administrative role, and both go through the same code.

The whole file is validated before anything is created — an unrecognized role, a blank username or the same username twice stops the import with the row named, and nothing is written. Re-importing the same file later is safe: existing accounts are skipped, and a role that has changed is reported for a person to look at rather than applied silently. The detail is here.

Through a single-use, expiring link, one per new account. The platform does not email them — it hands the set of links to your administrators, who distribute them through whatever channel they already use for this. The in-app path mints the links at the moment you download them, writes none of them to disk, and skips anybody who has already signed in.

Every imported account is also created with a real, random password rather than an unusable one, so somebody whose link has expired can use the ordinary password reset rather than needing an administrator again. That is why a blank email address is a hard error in the import file.

No, and it never does. The AIN is yours: optional in the import file, accepted exactly as supplied, and never invented by the platform. The username is the only identity an import matches on. There is a duplicate check on AINs, but it exists to turn a database error into a readable message naming the two rows that collide — not to police an identifier we did not issue.

The platform is actively built and tested against WCAG 2.1 AA. A browser-driven scan covers twenty-two pages against exactly that rule set, at strictly zero violations, using a version-pinned scanner running against a populated deployment rather than an empty one. Contrast failures, an invalid table sort attribute, duplicate element identifiers, a missing skip link, a focus indicator that failed contrast on most of the backgrounds it was used against, and missing video captions have all been found and fixed.

We do not have a VPAT or an Accessibility Conformance Report, and we will not describe what we do have as one. Automated testing of this kind reaches roughly a third of the WCAG 2.1 AA success criteria — the mechanically decidable third. No screen-reader pass and no human keyboard-only pass has been run, and three hundred and seven elements over the page's layered background have no measured contrast ratio at all because the tool declined to judge rather than guess.

What we can send you is the assessment itself, gaps included. If a formal conformance report is a requirement of your process, tell us early and we will be straight with you about where that stands. The full position is set out here.

Yes — Standard, Light and Dark, plus a setting that follows the reader's own device. The preference belongs to each person rather than to the installation, because light-on-dark is harder for many readers with astigmatism and a bright ground is harder for many with photophobia. An installation-wide theme would take an accommodation away from whichever group it did not pick.

All three were verified independently against WCAG 2.1 AA rather than assumed to inherit the original results, since contrast is computed against rendered color and both grounds change. Why it is built that way.

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.

Not when you run it yourself. A self-managed deployment has no dependency on the public internet at runtime and no external data repository — the platform is built for closed and air-gapped environments from the ground up, and the deployment lives inside your boundary.

A hosted deployment is reached over the internet by definition, so it is not an option for a genuinely air-gapped network. That is the one real trade between the two, and it is why the self-managed option remains the answer for closed environments.

Yes. We call it Guidepost Cloud, and it is the same product — the same hierarchy, authoring, scheduling, assessment, certification and audit trail described everywhere else on this site. Nothing is held back, and there is no reduced edition.

The difference is operational: we run the servers, updates and backups, and you carry on administering your own organization. The hosted option is explained in full here.

Yes. Each hosted organization gets its own database and its own file storage. Your records are not rows in a shared table separated by a customer column, and your uploads are not files in a shared folder distinguished by a prefix.

That boundary is enforced by the infrastructure rather than by application code remembering to filter correctly, and it is verified from both sides when an organization is set up rather than assumed. If your review process needs the detail underneath that, ask us and we will provide it.

No. There is no self-service signup and no published price list. A hosted deployment starts with a conversation about your organization, the same way a self-managed one does — partly because which option suits you is worth establishing before anything else, and we would rather tell you honestly when the answer is the one you were not expecting.

There are three — Basic, Middle and Highest — and they are cumulative, so each one contains everything in the plan before it. Basic covers authoring a course, running it and certifying people. Middle adds the full organizational hierarchy, roster documents, staff scheduling and reporting that looks across courses. Highest adds integrations.

All three are available on both deployment models, and none of them has a published price. The plans page sets out exactly what each one switches on.

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.

One, today: a versioned, token-authenticated REST API that another system can read from and write to. It is real, working software, and every deployment carries it.

Connections to a company directory (Active Directory), to external student records systems and to training-completion systems (SCORM) exist in the codebase, but they have never been connected to or verified against a real external system. They are in active development rather than waiting to be switched on, and we would rather say that here than have you find out after a decision. Ask where a particular one stands and we will tell you plainly.

None of them runs or attempts a connection by default, which is a separate point and still true — nothing in Guidepost reaches outside your boundary on its own.

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 5,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.