> ## 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. # Declare Intent: Define What Matters in Panaptico > Define tracked fields, Signals, populations, and Initiatives so Panaptico verifies exactly what you care about, not what a vendor prescribes. Panaptico verifies what you declare, not what a vendor thinks you need. You define which resources matter, what "good" looks like for each field, how populations are scoped, and how initiatives are scored. This guide explains the four layers of intent declaration and how they compose into continuous verification. ## Tracked fields on resources The most basic unit of intent is a tracked field. You choose a resource type from a connected provider, select a field, and declare the target condition. Panaptico compares the live value against that target on every poll. For example, on a GCP compute firewall rule you might track: * Field: `sourceRanges` * Target: all values must be within `10.0.0.0/8`, `172.16.0.0/12`, or `192.168.0.0/16` * Result: At target, Off target, Unknown, or Unobserved You can track many fields on the same resource type. Each field is evaluated independently, with its own evidence and history. ## Signals with thresholds Signals turn raw telemetry into business meaning. A Signal is a named, scored evaluation that combines one or more data points against a threshold you define. Examples: * **Unmanaged device** — device seen in Okta but not in MDM within 24 hours. * **Risky user** — failed MFA rate exceeds 5 percent over a 1-hour window. * **Stale secret** — a key in AWS IAM has not rotated in 90 days. Each Signal carries: * A threshold and scoring rule * Decay and drift history (how the score changes over time) * Full evidence for every evaluation * A result state: At target, Off target, Unknown, or Unobserved ## Populations via Identity Links and Groups Populations let you declare intent for a scoped subset of your estate rather than everything at once. Panaptico resolves entities across systems so that populations are verifiable and consistent. * **Identity Links** — cross-system entity resolution. An Okta user, an Azure AD user, and a SailPoint identity become one person. * **Groups** — named populations like "Japan Office", "Main Admin Users", or "Production VPCs". Groups are built from filters across any connected provider and are re-evaluated on every poll. You can apply tracked fields and Signals to a Group, and the evaluation runs only against members of that population. ## Initiatives that compose it all An Initiative is a budget-level object that combines everything above into a living program. It is what executives fund, auditors audit, and boards review. An Initiative contains: * **Declared intent** — the full set of tracked fields, Signals, and populations that define "good" for this program * **Verified current state** — the live result of every evaluation * **Gap analysis** — what is Off target, Unknown, or Unobserved * **Closed work loop** — every gap becomes a Work Item (gap → ticket → fix → re-verification) * **Exception lifecycle** — approved deviations with owners and expiry dates * **Trajectory** — whether the initiative is improving or regressing over time Examples of Initiatives: * "USB Exfiltration Prevention" * "Network Segmentation by Access Tier" * "Zero Trust by office" ## How to declare an Initiative 1. Go to **Initiatives** in the dashboard and click **New Initiative**. 2. Name the Initiative and describe the business outcome. 3. Add populations (Groups) that define the scope. 4. Add tracked fields and Signals that define "good". 5. Set the polling interval and evidence retention. 6. Save. Panaptico begins continuous verification immediately. ## Next steps Understand how every result carries scope, coverage, freshness, and full history. See how gaps become tickets with owners and automatic re-verification.