> ## Documentation Index > Fetch the complete documentation index at: https://panaptico.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # How Panaptico Continuously Verifies Your Enterprise > Learn how Panaptico acquires signals, understands your estate, verifies intent, and routes action across IT systems in a closed loop. Panaptico runs a continuous verification loop across your enterprise IT estate. It acquires signals from identity, cloud, network, security, endpoint, and data systems; understands what those signals mean; verifies them against your declared intent; and routes action when reality diverges. This page walks through each phase of that loop. ## Acquire Panaptico brings data in through three modes. You choose the right mode for each system based on what you need to prove. * **Ask** — scripted API pulls on a schedule. Panaptico queries the system directly and records the full response as evidence. * **Listen** — log, metric, and event streams, commonly delivered via Cribl into your data lake. Panaptico reads these streams and treats each event as evidence. * **Test** — active probes that attempt operations and record the outcome. This includes negative verification: send the packet and prove it gets dropped, attempt the sign-in path and prove it fails without MFA, try the restore and prove it completes. All three modes write evidence into your lake. You own the data. ## Understand Raw telemetry is not enough. Panaptico resolves entities, turns events into meaning, and composes judgment. * **Transform** — resolves the same entity across multiple systems. An Okta device, a Cloudflare device, and an MDM device become one device with a unified history. * **Signals** — turn raw telemetry into business meaning (for example, "risky user" or "unmanaged device"). Each Signal is scored continuously against your threshold and carries decay and drift history. * **Enriched Signals** — compose multiple Signals into entity-level judgment. A user may be risky because of device posture, location anomaly, and failed probe results combined. ## Verify Verification is the core of Panaptico. The platform applies fourteen verification primitives to your live estate: 1. **State** — current value matches declared target. 2. **Absence** — something that must not exist does not exist. 3. **Sequence** — events happen in the required order. 4. **Relationship** — required links between entities exist and are valid. 5. **Coverage** — every expected resource is observed. 6. **Reconciliation** — two systems agree on the same fact. 7. **Budget** — a numeric limit is not exceeded. 8. **Expiry** — certificates, tokens, and policies are still valid. 9. **Conformity** — configuration matches a standard or baseline. 10. **Freeze Windows** — changes do not occur outside approved periods. 11. **Trajectory** — a metric is trending toward target, not away. 12. **Access-Path** — the required authentication and authorization path works. 13. **Separation of Duties** — no single actor can complete a sensitive workflow alone. 14. **Attestation** — a human or system has explicitly confirmed a state. Every evaluation produces one of four result states: * **At target** * **Off target** * **Unknown** (scope or data is incomplete) * **Unobserved** (no data arrived in the expected window) Missing evidence never becomes a manufactured pass. Panaptico does not silently inherit the last good value. ## Run Initiatives are the budget-level objects that executives fund, auditors audit, and boards review. An Initiative combines: * Declared intent (what "good" looks like) * Verified current state (what the live estate actually shows) * Gap analysis (what is off target, unknown, or unobserved) * A closed work loop (gap → ticket → fix → re-verification) * An exception lifecycle (approved deviations with expiry) * Trajectory (whether the initiative is improving or regressing) Examples include "USB Exfiltration Prevention", "Network Segmentation by Access Tier", and "Zero Trust by office". ## Act When reality slips, Panaptico routes action. Because the verification itself is evidenced, the routing decision is grounded in proof, not assumption. * **Work routing** — gaps become tickets with owners in ServiceNow or similar. * **Risk-adaptive access** — a risky login triggers a harder authentication path in Okta. * **Network placement** — a non-compliant device is moved to quarantine in Cloudflare. * **Verification-gated deploys** — a failing deployment verification triggers a rollback in LaunchDarkly. * **Risk-proportional approvals** — higher risk changes require broader approval. The integration is bidirectional. Existing tools enforce; the ledger decides when. ## Explore the platform Always-on sensors read your estate field by field. Turn raw telemetry into business meaning. Declare intent as a living program. Route action when reality diverges.