> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tryflare.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 30-Day Baseline

> How Flare builds a rolling baseline and flags deviations

# 30-Day Baseline

Flare builds a rolling frequency baseline from your analysis history. Each time you run an analysis, Flare records how often every field value appeared. On subsequent runs, it compares the current batch against the last 30 days of data to surface what has changed.

## Why it matters

Without historical context, an LLM analyzing a single batch of logs has to guess what's "normal." A `SetIamPolicy` call might be routine in your environment or a once-a-year event. The 30-day baseline removes the guesswork by giving Flare exact historical frequencies for every field value it has seen before.

The result: fewer false positives on routine activity, higher confidence on genuine deviations, and automatic detection of new values that have never appeared in your environment.

## How it works

<Steps>
  <Step title="Record">
    After each analysis (manual or scheduled), Flare records the frequency distribution of every field value in the log batch. For example: `principalEmail: user-a@corp.com` appeared in 62% of events, `service-bot@proj.iam` in 30%.
  </Step>

  <Step title="Compare">
    On the next analysis, Flare queries the last 30 days of recorded frequencies and computes the average percentage for each field value across all prior runs.
  </Step>

  <Step title="Annotate">
    The current batch frequencies are compared against the 30-day averages. Deviations are injected into the analysis context so Flare can calibrate anomaly scores based on what has actually changed.
  </Step>
</Steps>

## Reading deviation indicators

When 30-day baseline data is available, anomaly explanations reference historical context. In the underlying analysis, each field value is annotated with its deviation from the baseline:

| Indicator                 | Meaning                                                                    | Example                                                              |
| ------------------------- | -------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| **30d avg**               | The average percentage over the last 30 days                               | `62% (30d avg: 41%)`                                                 |
| **+/- delta**             | How much the current batch differs from the average                        | `+21%` means 21 percentage points above normal                       |
| **NEW**                   | A value that has never appeared in any prior analysis                      | First-time IP address, service account, or API method                |
| **Field deviation: HIGH** | At least one value in this field shifted by more than 20 percentage points | Indicates the field's overall distribution has changed significantly |

### What the deviation levels mean

* **HIGH** (above 20% shift) -- something has clearly changed. A principal that normally accounts for 40% of activity now accounts for 65%, or a new actor appeared at 15%. Worth investigating.
* **MEDIUM** (10-20% shift) -- moderate change. Could be seasonal variation or the start of something. Flare considers these in scoring but they rarely drive Critical findings on their own.
* **LOW** (5-10% shift) -- minor fluctuation. Normal operational variance in most environments.
* **Stable** (under 5% shift) -- business as usual. Flare deprioritizes stable fields to focus on what actually changed.

## Baseline coverage

The baseline gets more useful with every analysis you run:

| Analyses in 30-day window | Baseline quality                                                                              |
| ------------------------- | --------------------------------------------------------------------------------------------- |
| 0-1                       | No baseline available. Flare analyzes based on the current batch only.                        |
| 2-5                       | Basic baseline. Deviation scoring active but averages are rough.                              |
| 6-30                      | Strong baseline. Reliable deviation detection for common field values.                        |
| 30+                       | Dense baseline. Flare can detect subtle shifts that wouldn't register with fewer data points. |

<Tip>
  Set up [scheduled runs](/scheduled-runs) to build baseline coverage automatically. A daily scheduled run gives you 30 data points within a month -- enough for reliable deviation scoring.
</Tip>

## NEW values vs. First Seen

Both flag new activity, but at different levels:

* **First Seen badge** -- tracks whether a specific field value (e.g., a service account email) has *ever* appeared in a previous anomaly finding. Binary: seen or not seen.
* **NEW in baseline** -- tracks whether a value has appeared in *any* previous analysis (not just anomalies). The 30-day baseline covers all field values in the log batch, not just the ones flagged as anomalous.

A value can be "NEW in baseline" without being "First Seen" -- it may have appeared in logs before but was never flagged as an anomaly.

## Data retention

Frequency snapshots are tied to your analysis records and follow the same retention policy. Snapshots older than 37 days are eligible for cleanup. Only aggregate frequency data is stored (field name, value, count, percentage) -- never raw log content.