How it works

Proctor is a native desktop agent, a REST API, and a review portal. The agent observes the candidate's machine during a session they agreed to; the API stores what it sends; the portal is where a person reads it. Deliberately, nothing in that chain decides anything.

The desktop agent

One native application per platform — Swift on macOS, WinUI 3 on Windows, GTK4 on Linux — rather than one cross-platform wrapper. Screen capture, permission prompts and the menu-bar indicator are OS surfaces, and using each platform's real API is what makes them behave the way a user on that platform expects.

• It runs only during a session, and only after consent is recorded server-side.
• It shows a visible indicator the whole time — a banner and a tray or menu-bar item.
• It holds its session token in the OS keychain or credential manager, never on disk in the clear.
• It buffers locally when the network drops and resumes the upload, so a bad hotel connection is not lost evidence.

The API

Every route is versioned under /v1 from the first release, so an integration built today keeps working. Sessions, evidence, events and webhooks are the public surface; the SDK and the API reference are generated from the running application's own OpenAPI document, which is why the reference cannot describe an endpoint that no longer exists.

The portal

Where a reviewer does the work: the session timeline, the evidence viewer, the transcript, and the notes they leave. Roles (owner, admin, interviewer, reviewer) are enforced in the API guard rather than by hiding buttons, and every sensitive read is written to the audit log.

What crosses the wire