> ## Documentation Index > Fetch the complete documentation index at: https://docs.threataware.com/llms.txt > Use this file to discover all available pages before exploring further. # Vitals States Reference > The four-boolean model behind every Vital — required, deployed, functioning, configuredCorrectly ## The four-boolean model Every Vital — one integration's view of one device — is exposed in the query language as four boolean fields: ```text theme={null} system..required # is this control required for this device? system..deployed # is the control present? system..functioning # is it actively reporting? system..configuredCorrectly # does configuration match your policy? ``` These four booleans are the complete model. The UI surfaces composite badges that summarise the four-boolean combination, but under the hood the truth is always `true` or `false` across the four fields. ## Composite states explained The composite badges shown on a device's Vitals panel map to the four booleans like this. Badge labels are taken verbatim from the live UI (device detail → VITALS section): | Badge | required | deployed | functioning | configuredCorrectly | | ------------------------------------ | -------------------------------------------------------------------------------- | -------- | ----------- | ------------------- | | **Healthy** | `true` | `true` | `true` | `true` | | **Misconfigured** (config drift) | `true` | `true` | `true` | `false` | | **Not Functioning** (silent failure) | `true` | `true` | `false` | (any) | | **Not Deployed** | `true` | `false` | (any) | (any) | | **Functioning** | (used for non-required integrations that are reporting, e.g. directory services) | — | `true` | — | Scanner-type integrations (Qualys, Lansweeper, etc.) use a different two-state pair: **Detected** and **Not Detected Recently**. In conversation we use **Not Healthy** as an umbrella for any required-but-not-Healthy state (`required:true AND (deployed:false OR functioning:false OR configuredCorrectly:false)`). The Protect API surfaces some of these counts under slightly different names (e.g. `configurationCompliant` for the `configuredCorrectly` boolean). See [API → Vitals](/api-reference/vitals) for the API field names; the query language always uses the four field names listed above. ## Query expressions The corresponding query language clauses (using CrowdStrike as the example): | Want | Query | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Healthy devices | `system.crowdstrike.required:true AND system.crowdstrike.deployed:true AND system.crowdstrike.functioning:true AND system.crowdstrike.configuredCorrectly:true` | | Not Deployed (where required) | `system.crowdstrike.required:true AND system.crowdstrike.deployed:false` | | Broken agent (silent failure) | `system.crowdstrike.deployed:true AND system.crowdstrike.functioning:false` | | Config drift only | `system.crowdstrike.functioning:true AND system.crowdstrike.configuredCorrectly:false` | | Not Required | `system.crowdstrike.required:false` | | Any unhealthy state | `system.crowdstrike.required:true AND (system.crowdstrike.deployed:false OR system.crowdstrike.functioning:false OR system.crowdstrike.configuredCorrectly:false)` | ## How each boolean is computed Driven by **tag rules**. In each integration's configuration (Devices column gear → Configure Mode), you tick which tags require this control. A device whose tags match makes `required:true`. Devices with `required:false` are not in scope for this control — they don't fail Vitals on it. `true` when the integration sees this device in its inventory at all. Computed by comparing the device's presence across all your tools — if Microsoft Intune knows about the device but CrowdStrike doesn't, `system.crowdstrike.deployed:false`. This is "is the agent installed?". `true` when the integration's per-device data is reasonably fresh relative to the device's general activity. If the device is clearly online (recent activity in other tools) but this integration's last-seen is stale, `functioning:false`. This is **silent-failure detection** — broken agents that look healthy in their own console but stopped protecting weeks ago. `true` when the configuration checks you've defined match what the source tool reports. Each integration exposes different fields (prevention policy, tamper protection, signature freshness, encryption settings, etc.) and you tick which ones to enforce per tag. A device that passes `deployed` and `functioning` but fails any required configuration check is `configuredCorrectly:false`. ## The dashboard visualisation The **Integration Control** panel on the Dashboard shows the composite for each integration: * **N/M Healthy** count = devices where all four booleans are favourable, out of the devices where `required:true` * **Percentage** = N/M as a percentage * **Trend arrow** = change vs last period * **NOW / 7D / 1M / 3M / 1Y** buttons = time range for the displayed value ## Per-integration nuances The four-boolean model is consistent, but **what** each boolean considers varies by integration: | Integration | `deployed` signal | `functioning` signal | `configuredCorrectly` typical checks | | ------------------------------- | ---------------------------- | ---------------------------------- | ------------------------------------------------------------------------------------- | | `system.crowdstrike` | Device in CrowdStrike Falcon | Sensor reporting recently | Prevention policy applied; sensor Online; agent version | | `system.microsoft_defender_atp` | Device in Defender | Defender reporting recently | Real-time protection; tamper protection; cloud delivered protection; signatures fresh | | `system.microsoft_intune` | Device enrolled in Intune | Recent check-in | Compliance status; required apps deployed; profiles applied | | `system.jamf` | Device managed by Jamf | Recent check-in | FileVault on; profiles applied; firewall enforced | | `system.zscaler_client` | Client deployed | Recent cloud connection | Policy enforcement active | | `system.azure_ad` | User / device registered | Recent activity | MFA enrolled (where applicable) | | `system.onprem_ad` | Account exists in AD | Recent logon | Account enabled | | `system.sccm` | Device in SCCM | Recent sync (via PowerShell Relay) | Patches applied; compliance state | | `system.servicenow` | Device in CMDB | Recent CMDB update | (Mostly used for cross-reference, not enforcement) | If a configuration check you need isn't available, that's typically because the vendor's API doesn't expose the field. Open a request — Protect engineering adds checks as vendor APIs evolve. ## Common saved-view patterns | Saved view | Query | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | "End-User devices without CrowdStrike" | `tags:End-User AND system.crowdstrike.required:true AND system.crowdstrike.deployed:false` | | "Broken CrowdStrike agents" | `system.crowdstrike.deployed:true AND system.crowdstrike.functioning:false` | | "Misconfigured Intune devices" | `system.microsoft_intune.functioning:true AND system.microsoft_intune.configuredCorrectly:false` | | "Healthy devices (multi-control)" | `system.crowdstrike.required:true AND system.crowdstrike.deployed:true AND system.crowdstrike.functioning:true AND system.microsoft_intune.deployed:true AND system.microsoft_intune.functioning:true` | ## See also The conceptual model Setup walk-through Full grammar