Security & deployment
Built for environments where the boundary is not negotiable.
Guidepost runs on your own network with no dependency on the public internet. This page covers how access control is layered, what the audit trail records, how content and uploads are validated, and the discipline behind the test suite.
Deployment posture
Closed networks are the design target, not a supported exception.
Most platforms treat an air-gapped deployment as a configuration to be discovered. In practice that surfaces as fonts that never load, embeds that hang, and features that quietly do nothing.
No public internet at runtime
The application does not reach outward to operate. Nothing in normal use depends on a CDN, a font host, an analytics endpoint or an external API.
No external data repository
There is no vendor-hosted store and no SaaS tenancy. Data stays inside the boundary you deploy into.
Integrations stay inert
Active Directory sync, external student records sync, SCORM completion export and the AI assistant are scaffolded and dormant. Each activates only once pointed at real infrastructure — none run or attempt a connection by default.
Access control
Layered, and re-derived at the point of action.
Two checks, not one gate
Access control is layered: a role and placement check, plus a scope check re-derived at the point of action. A single gate either holds or does not; two independent checks mean an error in one does not silently become an exposure.
One rule for management scope
A single primitive answers "what can this person manage" for every level in the hierarchy — strictly below their own placement, never at their own level. That last part is deliberate: it prevents the case where a staff member can delete the assignment granting their own access.
Read visibility follows the same structure through the same shared helpers, rather than each page assembling its own idea of what a viewer should see.
Deliberate exclusions are recorded, not just enforced
The platform's full-access administrative role is a single, greppable grant with one deliberate exception: private messaging between course staff and the students they teach, on the grounds that correspondence is not an administrative surface.
The grant is declared in one place precisely so it is reversible, and the surviving exclusion is covered by tests that fail if it is silently removed.
Restricted courses
A per-course materials lock excludes even Organization, Schoolhouse and Group-level staff from a course's content, limiting access to staff specifically assigned to it. Broader administrative access does not reach past the lock.
Audit trail
Attributable and timestamped
- Every enrollment, including who approved it and when
- Every grade, and every regrade
- Every certificate issued, independently verifiable by code
- Every administrative action across the hierarchy
- Version history on materials, videos, surveys and scheduled reports
Accounts
Provisioned, not self-served
Course-level and organizational accounts are created by an administrator. There is no public self-registration. Every account carries a unique numeric identifier (AIN) alongside name and email.
Content & upload safety
Everything authored, and everything uploaded, is checked.
Sanitization on every rich-text input
Authored content is sanitized as it is stored. No inline scripts are permitted anywhere in authored material.
Sandboxed embeds
Embedded content is constrained rather than trusted, and PDFs are rendered inline behind a clickjacking-safe viewer.
Uploads validated twice
Every PDF and Excel upload is validated by both file extension and content signature — never either alone. All three document types share one validation helper rather than three near-identical ones.
External links marked and hardened
Any link whose origin differs from the current page is automatically detected, marked, and hardened, with an escape hatch for internally proxied links.
Verification discipline
A passing test suite is not the same as protection.
Guidepost carries a large automated test suite — over 4,800 tests in the application, on a build lineage of more than 7,000 — run 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 test suite actually catches it, rather than trusting that a passing suite implies real protection. This has caught several guards that initially passed against the exact defect they were written to detect.
A related discipline applies to access rules. Any view that assembles its own data set rather than going through a shared, rule-carrying helper is where the next hole will be — so those are swept for deliberately rather than found by accident.
A worked example
"Hidden" and "hidden for the right reason"
A fix suppressing progress bars on the Alumni page was verified by a test asserting that the percentage bar's marker was absent. The test passed — while the module bar, a separate element behind a separate guard, was still rendering.
The lesson is recorded in the test itself: "the element is hidden" and "the element is hidden for the reason I think" are different claims, and a test matching the wrong marker confirms the first while the second is false.
Technology
A deliberately conventional stack.
Nothing here is novel, and that is the point — an institution taking custody of a deployment should recognize every part of it.
On Python 3.14.
In production; SQLite for local development.
Server-rendered templates with progressive enhancement.
Run on every change before it ships.
Server-rendered, no frontend framework
Pages are generated on the server with progressive JavaScript enhancement layered on top. There is no frontend framework and no build pipeline, which means no compiled asset bundle to reproduce and no toolchain to keep alive inside a closed network.
Ready to integrate
Built-in, ready-to-activate connections to a company directory (Active Directory), external student records systems, and training-completion systems (SCORM). Each is inert until configured against infrastructure inside your boundary.
Next step
Request the technical documentation.
Tell us about your environment and what your evaluation needs to cover. We will send the detail that matches it.