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

> ## Agent Instructions
> Read /start/capabilities before choosing an integration. Use the deployed server’s tools/list for current tool inputs.

# Eligibility

> Control which variants can be considered.

Requirements filter variants before Dynamite chooses one. A variant must pass all its requirements. Keep the original ungated.

## Trigger a persona from page visits

Pass this `persona` to `save_persona`, along with the website UUID and current version:

```json theme={null}
{
  "name": "Operations evaluators",
  "need": "See implementation proof for an operations workflow",
  "trigger": {
    "pages": { "paths": ["/solutions/operations", "/customers/operations"], "min": 1 }
  }
}
```

Link the persona to a variant. The service compiles its trigger into runtime requirements. `min` counts distinct paths, not repeat visits.

For section attention, use this trigger instead:

```json theme={null}
{
  "section": {
    "path": "/solutions/operations",
    "selector": "#implementation-details",
    "seconds": 8
  }
}
```

Use one trigger type per persona.

> [!NOTE]
>
> Descriptions, `audiences`, and `when` help selection; they do not enforce eligibility. Keep access rules and discount eligibility in your application.

> [accordion] Requirement reference
>
> All configured requirements on a variant must pass:
>
> | Requirement | Actual check |
> | - | - |
> | `requiresInterest: { tag, distinctProducts }` | Summary contains the tag with enough distinct products/resources and strength at least 0.75 |
> | `requiresAttention: { tag, durationMs }` | A qualifying attention record for that tag reaches the duration |
> | `requiresFacts: string[]` | Every fact exists on the currently registered page's product |
> | `requiresPurchasedProduct` | Purchase summary includes that product |
> | `requiresDaysSincePurchase` | A relevant purchase is at least that old |
>
> Facts describe approved product/page facts, not arbitrary visitor attributes. Interest is decayed; repeatedly refreshing one product does not satisfy a requirement for multiple distinct products. Keep the original variant free of requirements.
>
> Live decisions strip browser-claimed purchase events and purchase records. Purchase gates are useful in simulations but need a trusted live integration before you can claim a replenishment or post-purchase campaign works in production.

> [accordion] Debugging and persona changes
>
> Inspect the registered page, visitor summary, and compiled requirements before checking the model’s choice. Eligibility does not force selection, and browser guards can still keep the original.
>
> Editing a persona updates linked variants. Deleting one removes its trigger and may broaden eligibility. Review affected variants before publishing.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.