Guidepost

About us

Built from running training, not from imagining it.

Guidepost exists because the hard part of institutional training was never the course. It was everything around the course — and most platforms leave that part to a spreadsheet.

Why Guidepost exists

The gap between a course player and an institution.

A learning management system usually models one thing well: a course. Modules, pages, a quiz, a completion percentage. That part is largely solved, and has been for years.

What is not solved is everything sitting above it. Which division owns this course. Who is allowed to see it, and who is allowed to change it. What happens when a deputy chief transfers and needs access to four schoolhouses' worth of material. Where next fiscal year's runs are recorded. Which week's schedule a student is entitled to see today. Who approved a given enrollment, and when — asked eighteen months later by someone conducting a review.

In most organizations those answers live outside the LMS entirely: in a permissions spreadsheet nobody trusts, a shared calendar that diverged from reality in March, and a mail folder. The platform holds the courses. The institution holds everything that makes the courses mean something.

Guidepost was built to close that gap by modelling the institution first. Organization, Schoolhouse, Group, Course — four real levels, with visibility and management authority following placement automatically. The course sits inside that structure rather than floating beside it.

In one sentence

What Guidepost is

A complete, purpose-built learning management platform designed around how a real institution is actually organized — not just how individual courses run — handling organizational structure and scheduling through interactive content creation, assessment, grading, certification and day-to-day administration.

And what it is not. Guidepost is not a hosted service you rent a tenancy in. It is not a course marketplace, and it has no public self-registration. It is a platform an institution deploys inside its own boundary and administers itself.

How it is built

Five convictions you can see in the product.

These are not aspirations. Each one is visible in a specific behaviour described elsewhere on this site.

One

Structure should grant access, not describe it

Placing someone in the org chart is the same act as granting them the scope their job requires. There is no second permissions model maintained alongside your structure — because a second model is one that will fall out of date, and the platform would then be enforcing a version of your organization that no longer exists.

This is also why staff titles are cosmetic. Chief, Deputy Chief and Staff mean whatever they mean in your institution. Guidepost does not reinterpret them.

Two

Closed networks are the design target

Air-gapped operation was a starting requirement rather than a late accommodation. That distinction shows up in unglamorous places: no external font or asset host, no build pipeline to reproduce inside the boundary, no analytics call, and integrations that stay genuinely inert until pointed at real infrastructure.

A platform that treats the closed network as an edge case fails in ways you only discover after deployment.

Three

A finite feature set beats an extensible one

There are eleven content block types, and every author gets all eleven on every page. There are four organizational levels and four course roles. The sets are deliberately closed.

An author learns the vocabulary once and it does not change between courses or between schoolhouses. The cost of that is that Guidepost will occasionally say no to a request. The benefit is that nobody has to be trained on a local dialect.

Four

One calculation, used everywhere

Where two parts of the product answer the same question, they call the same code rather than implementing the same idea twice. Module progress and overall completion compute from one shared function. Roster fields render on the roster and the course page through shared components. Alumni access uses one definition of completion, shared by both surfaces that need it.

Two implementations of one rule will eventually disagree, and the disagreement will be discovered by a student.

Five

A passing test is not the same as protection

Safety-critical logic is checked by mutation testing — deliberately reintroducing a bug to confirm the suite actually catches it. This has repeatedly found guards that passed cleanly against the exact defect they were written to detect.

One example is recorded permanently in the test that failed to catch it. A fix suppressing progress bars on the Alumni page was verified by asserting that the percentage bar's marker was absent. It passed — while a second bar, behind a second guard, was still rendering. "The element is hidden" and "the element is hidden for the reason I think" are different claims. Only one of them was true.

The honest part

Three decisions that were reversed partway through.

A product's design record is more informative than its feature list, because it shows what was tried and what was found not to work. These are drawn from Guidepost's own technical documentation.

Shared content libraries became course-owned

Materials and videos were originally attachable to many courses at once. In practice that produced a library every author had to search through to find their own work, with no reliable answer to "who owns this file."

They are now owned by exactly one course. Items already attached to several courses were duplicated per course during migration rather than arbitrarily assigned to one, with every duplication logged — because silently picking a winner would have deleted somebody's material.

Kept as-is: images remain a shared library, because they are referenced by things that cannot belong to one course — emblems, banners and page backgrounds.

Administrative access stopped being a list of exclusions

The platform's full-access role was originally defined as eight documented exclusions from course-level duties. A comprehensive review found that seven of the eight produced a role that could not actually administer the platform — there was no route to a course at all in several places, which read from the outside as broken access rather than as policy.

It is now a single blanket grant expressed in one predicate, with exactly one deliberate exception: private messaging between a student and the staff teaching them, on the grounds that correspondence is not an administrative surface.

Why it is one line: the grant is declared in a single place precisely so it is greppable and reversible, and the surviving exclusion is covered by tests that fail if it is quietly removed.

Four calendar views were built, then removed

The course calendar originally offered quarter, half-year and year views alongside day, week and month. They were built and then deleted.

Recurring weekly class slots were never expanded at those ranges, so each long view rendered as a list of course run bars above a message telling the reader to switch to Month. The views technically worked and were genuinely useless.

What replaced them: month view now pages through a two-year window — six months back, seventeen forward — which is what the long views were actually being reached for.

Working with us

What an evaluation actually looks like.

Guidepost is deployed into environments where a procurement decision is answerable to somebody, and where the platform will be administered by the institution rather than by us. That shapes how we prefer to work.

We would rather show the platform against your structure — your schoolhouses, your groups, the courses you are actually running — than against a demonstration dataset that has been arranged to look tidy. The organizational hierarchy is the part of Guidepost most worth testing against reality, and a generic demo tests it least.

A detailed feature walkthrough, technical documentation, and a full deployment and security handoff guide are available to an evaluating team on request. If your evaluation needs something specific — an accessibility question, a records-retention question, a question about how a particular integration would land in your environment — ask for it directly rather than waiting for it to appear in a brochure.

  1. Tell us how you are structured

    Divisions, departments, roughly how many courses, and how training is administered today.

  2. A walkthrough against that shape

    Pointed at the parts you will actually live in, for the people who will actually live in them.

  3. Documentation for your evaluation

    Technical overview, deployment guide, and answers to the specific questions your review process raises.

  4. A scoped pilot

    A defined pilot in your own environment, with a real course and real staff, rather than a sandbox nobody has a stake in.

Next step

Start with how your organization is shaped.

That is the part worth testing, and it is the first thing we will ask about.

Get in touch Browse the features