Operating model
LocalGuard distributes one policy across components with distinct responsibilities. The dashboard manages it; the Core decides which configuration applies to each device; and the agent or browser extension carries out only the corresponding measure. This distinction keeps a dashboard screen separate from the technical action taking place on a computer or in a browser.
One decision, several stages
Section titled “One decision, several stages”Saving a rule does not mean it has already been applied. The change becomes available to the Core, which interprets it using the device, its relationship to the account, and the policy conditions. The paired component then receives the decision through its communication cycle and can report its result.
The role of each part
Section titled “The role of each part”The dashboard manages policy
Section titled “The dashboard manages policy”The dashboard is where filtering rules, time limits, schedules, and device decisions are defined. It also brings together the device, its known status, and pending actions. It does not directly block traffic or execute measures on a computer.
The Core interprets scope
Section titled “The Core interprets scope”The Core retains the configuration reference and evaluates the policy that applies to each device. It keeps the requested change, the calculated decision, and the status reported by the device distinct.
The component acts on its platform
Section titled “The component acts on its platform”The Windows Agent and browser extension do not share the same technical scope. Each receives the decisions it can execute and reports the status it can observe.
The dashboard does not send its screens to a device. The Core makes only the decisions applicable to that component available. This keeps the interpretation of rules, exceptions, schedules, and limits in one place instead of asking separate platforms to resolve the same family policy independently.
Configuration, application, and status
Section titled “Configuration, application, and status”A saved configuration records an administrative intention. An applied measure confirms that the relevant component has processed it. Operational status also indicates whether recent contact exists and which information the device could report. Keeping these readings separate prevents a pending change from being interpreted as confirmed protection.
The change must reach the component
Section titled “The change must reach the component”After a change is saved, the Core evaluates it for the assigned device and makes the resulting decision available to its paired component. That component updates on its own communication cycle. A computer can be switched off, disconnected, or simply waiting for that cycle, so devices should not be expected to reflect a change simultaneously.
Status is review evidence
Section titled “Status is review evidence”Reported status helps establish whether the component has been able to communicate and which operational information is available. It does not replace the saved configuration, and a lack of recent contact does not itself prove that the policy was removed or failed. Interpret it together with the device, its component, and the time of the last report.
Reading an incident
Section titled “Reading an incident”When a measure does not produce the expected result, follow the same order as the model: confirm the saved rule, check its device assignment, review reported component status, and then assess the measure itself.
Do not add or remove rules before this sequence is understood. Changing policy while a device is still pending an update introduces a second variable and makes the incident harder to diagnose. Activity and requests can provide context, but they are not proof that a configuration was received or applied.
From a change to device behaviour
Section titled “From a change to device behaviour”The path does not end when a change is saved. The Core evaluates the configuration, makes the relevant decision available to the paired component, and the component reports the operational information it can provide. Devices do not all update at the same moment: a computer may be offline, switched off, or awaiting its next communication cycle. A saved policy and recent contact must therefore be read as separate facts.
Saved configuration
Section titled “Saved configuration”Saved configuration is the account’s reference for the rules, categories, schedules, and limits expected on a device. It is the first point to check when confirming that a change belongs to the right device and family member.
Operational status
Section titled “Operational status”Operational status reports the contact and information a component was able to communicate. It is evidence for reviewing a result, not a replacement for the configuration itself. The Windows Agent and browser extension can report different information because they operate in different technical environments.
Reviewing an incident in order
Section titled “Reviewing an incident in order”First identify the affected device. Then confirm the assigned policy, the responsible component, and its latest reported status. Only then assess the rule, limit, schedule, or related activity. This order avoids changing a valid policy before establishing whether the device was merely waiting to update.
Boundaries of the model
Section titled “Boundaries of the model”Centralising decisions does not turn LocalGuard into a private-content inspection tool. The model covers policies, schedules, categories, devices, and the operational status needed to review them. Component-specific documentation explains the limits of each platform; this page explains how they fit together.