LocalGuard overview

LocalGuard is a parental-control platform for administering protection across several devices from one account. The web panel centralizes configuration, while protection is applied by the component paired with each device. That distinction makes it possible to identify the policy assigned to a device, whether it can receive it, and which operational information it has reported.

The application does not treat every device as equivalent. A Windows computer running the Agent, a browser using the extension, and a device with no recent contact need different checks. This overview establishes those differences before the individual screen and component guides.

The problem it addresses

Family protection is not limited to blocking a web address. Usage decisions can combine schedules, time limits, categories, specific rules, devices running different systems, and exceptions that need an explicit decision without losing the context of the general policy. When those decisions are scattered across unrelated applications, it becomes difficult to determine which measure is active, where it is being applied, and why a device reports a particular state.

LocalGuard brings those elements together in one installation. Its purpose is not covertly to observe private content, but to give responsible adults a place to define limits, review device status, and resolve exceptions explicitly. Configuration, supervision, and technical enforcement remain distinct so that each decision can be reviewed with the appropriate context.

Clear supervision limits

Protection measures work with rules, domains, categories, schedules, and the mechanisms available to each component. They do not turn the panel into a tool for reading messages, passwords, or private content. This is intentional: LocalGuard is designed to establish and manage conditions of use, not to expand family data collection beyond what is necessary for that purpose.

A local-first model

LocalGuard is designed so that the installation retains control of family data. The Core, database, and rules are part of the infrastructure managed by the installation itself; SQLite is the primary source of truth for users, devices, configuration, and state. External services, when enabled, cover specific functions such as billing or notifications, but do not replace the family’s operational data.

This has a practical consequence: activity, rules, and devices are not treated as information that should be transferred to a separate supervision platform. Protection must remain understandable from the panel and attached to the system the family controls. Privacy is not an additional setting; it determines which data is retained, where it is processed, and which components can access it.

Installation data and responsibility

Each installation maintains its own users, families, devices, and rules. The local database keeps the information the Core needs to make decisions and display status in the panel. The person administering the installation is therefore also responsible for credentials, backups, and access to the infrastructure where LocalGuard runs.

Local administration does not remove the need to review configuration. A correct policy depends on assigning a measure to the appropriate device, confirming that its component is available, and keeping platform requirements current.

What LocalGuard administers

LocalGuard coordinates three areas: devices, protection measures, and operational supervision. Configuration describes what should happen; device status indicates whether its component can communicate; activity provides the available context to review the outcome. Each answers a different question and none should replace the others.

Devices and context

An account can contain several devices with different needs. Before changing a rule, identify the affected device and review which component is paired with it. That context determines which measures can be applied and how to interpret the information shown by the panel.

Protection, screen time, and requests

Categories, filtering rules, limits, and schedules describe the policy LocalGuard must apply. The configuration is stored centrally so that the account retains one reference even when each device has different rules. See Protection, Filtering rules, and Screen time for each measure.

The panel also brings together system status, available activity, and decisions that require an adult’s intervention. An additional-time or access request does not mean disabling a rule: it is reviewed in context and resolved explicitly, so exceptions do not silently become permanent policy changes.

How a configuration is applied

The panel does not itself enforce a restriction inside a computer or browser. When a change is saved, the Core evaluates the policy assigned to the device and maintains its operational state. The Windows Agent or browser extension then receive the decisions that apply to them and act only within their own technical scope.

Saved policy

The panel keeps rules, limits, and schedules.

LocalGuard Core

Evaluates the policy that applies to the device.

Paired component

Applies the measure within its technical scope.

Operational status returns to the panel for review.

The diagram separates the three responsibilities involved: the panel retains the policy, the Core decides which policy applies to the device, and the paired component enforces it. Its final line shows that operational status returns to the panel for review. It does not reproduce an application screen; it relates the preceding text to the flow between its components.

Saved configuration and applied measure

A saved rule expresses the expected policy, but does not by itself confirm that a device was able to apply it. To verify a measure, review the affected device, its latest contact, and the installed component. Only then does it make sense to interpret available activity or adjust the configuration.

Separate component responsibilities

The web panel presents configuration and allows decisions to be made. The Core holds business logic and operational state. Installed components execute the policies they receive and report their situation. This division prevents attributing a Core decision to a browser, or expecting the panel to perform an action reserved for an Agent.

See Components and scope, Windows Agent, and Browser extension for platform-specific responsibilities and requirements.

Status and follow-up

Status indicates whether a device has operational contact. Activity records the events its component can report. A device without contact does not prove a rule failed; likewise, a rule visible in the panel does not prove that it was applied if the device has not been able to update.

Review sequence

When a measure does not produce the expected result, first identify the device and confirm the policy assigned to it. Then check its operational status and paired component. Next review the relevant rules, limits, or schedules. Finally consult the related activity or request if that component can provide it. This separates a pending configuration from a connectivity issue or a component that needs attention.

Using this documentation

Start with this overview when you need to understand which part of the system participates in an action. Continue with the operating model when an issue concerns the relationship between configuration and device, and Components and scope when you need to know which part can enforce a measure. Then use the panel guides to manage protection, screen time, and devices from the appropriate interface.