Shape of the system
Each client is an isolated tenant. A Chrome extension reports browser activity from the device, and the console turns that stream into reporting, policy enforcement, and alerts an operator can act on.
Thirty data models sit behind it. Most of the complexity is not the reporting, it is the device lifecycle.
Device lifecycle
This is where the first version was wrong. Devices moved between tenants by editing records, which produced orphaned data and devices reporting to the wrong client. The rebuild made revocation the only path.
- A device enrols against a per-tenant key and reports sessions and events.
- Revoking a device is detected by the extension within roughly five minutes, which then prompts for a new enrolment code.
- Enrolment is user-bound. A device only enrols if its signed-in user is registered or its email domain is allowed.
- Rejected enrolment attempts go to a review queue instead of failing silently.
Reporting and policy
- Domain categorisation with per-tenant overrides, driving both reporting and rule-based blocking.
- Alert rules over activity patterns, with notices that can be pushed to one device or the whole fleet.
- Location checks derived from IP, shown on a map, with configurable allowed areas.
- Executive PDF reports generated in-app, split into an organization view and a per-person view.
Operating it without a mail service
Admin invites and password resets are single-use links with expiry, generated once and shared through whatever channel the operator already uses. That removes an email service from the dependency list, which for a tool that manages other people's fleets is one less thing to run.
