> For the complete documentation index, see [llms.txt](https://docs.bardiel.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bardiel.tech/technical-architecture/policy-engine-and-tiers.md).

# Policy Engine & Tiers

Bardiel’s policy engine controls *how hard it tries* to trust a result.

Callers do not configure miner counts or PoI thresholds directly.\
Instead, they choose a **policy tier**, and Bardiel translates that into:

* redundancy (how many miners to use)
* validation depth (simple execution vs deeper verification flows)
* scoring rules and thresholds
* when to escalate or stay at the current tier

These semantics apply whether Bardiel is called from **Base, Virtual, ERC-8004, or other onchain agent ecosystems**.

***

### Available Tiers

Bardiel exposes four core tiers:

| Tier       | Typical redundancy | Primary goal                       |
| ---------- | ------------------ | ---------------------------------- |
| `fast`     | 1 miner            | Low latency, low cost              |
| `safe`     | 3 miners           | Default high-trust behavior        |
| `oracle`   | 5+ miners          | Maximum robustness for high stakes |
| `adaptive` | dynamic            | Cost-aware, confidence-driven      |

Exact counts may change over time; the **intent** of each tier stays stable.

***

### Tier Semantics

#### `fast`

**Goal:** Minimize latency and cost.

Typical behavior:

* 1 Cortensor miner
* basic schema checks and light sanity validation
* minimal reruns unless something is obviously broken

Use cases:

* exploratory or low-stakes tasks
* non-critical UX (suggestions, helper text, drafts)
* early prototyping and experiments across Base apps, Virtual agents, ERC-8004-compatible systems, or other agent workflows

***

#### `safe`

**Goal:** Balance trust vs cost.\
This is the expected default for many agents and markets.

Typical behavior:

* 3 miners in parallel
* PoI-based similarity / consensus checks
* simple PoUW-style scoring for usefulness / coverage

Use cases:

* summaries and classifications that affect application flows
* pre-action or pre-settlement checks in Virtual (GAME / ACP)
* pre-action checks for Base-native agent workflows
* pre- and post-action checks for ERC-8004-compatible jobs
* guardrails between multi-step tool calls or agent hops

***

#### `oracle`

**Goal:** Maximize robustness for high-stakes decisions.

Typical behavior:

* 5+ miners, often with **diversity sampling**
* stricter PoI thresholds (more sensitive to disagreement)
* stronger weighting by miner reputation / stake
* higher willingness to return `RETRY` or `INCONCLUSIVE` rather than guess

Use cases:

* arbitration-like flows in Base or other onchain agent markets
* ACP disputes in Virtual, where Bardiel is used as an extra oracle
* ERC-8004-compatible dispute or settlement flows
* large financial, reputational, or safety-critical tasks

This tier is intentionally **slower** and **more expensive**.

***

#### `adaptive`

**Goal:** Be cheap on easy tasks and strong on hard tasks.

Typical behavior:

1. Start as `fast` (1 miner, light checks).
2. Estimate preliminary confidence from:
   * agreement or disagreement between initial signals
   * task type and spec tightness
   * obvious issues (schema errors, missing constraints, clear spec problems)
3. If confidence is low or disagreement is high:
   * escalate to `safe` or `oracle`
   * re-run on multiple miners and re-evaluate

Use cases:

* long-running agents that see mixed-difficulty tasks
* Base-native or Virtual apps with variable workload quality
* ERC-8004-compatible agents that continuously process varied jobs
* generic “I do not know how hard this is” workloads
* large-scale systems that want to optimize spend over time

***

### Internal Decision Factors

Given a `task` and `policy`, Bardiel’s policy engine may also adjust behavior based on:

* **Task type**
  * structured tasks (for example `json_tool_call`) vs open-ended text
  * known risky domains (for example: contract summary, financial analysis, governance, trading)
* **Caller context**
  * surface (Base app vs Virtual GAME vs Virtual ACP vs ERC-8004-compatible flow)
  * environment (testnet vs mainnet)
  * whether this is pre-action, pre-settlement, or post-dispute
* **Historical data**
  * prior disagreement rates for similar tasks
  * per-market or per-app error patterns
  * miner pool performance (via Cortensor metrics)

These adjustments are internal, but the external tier still communicates the intent:

* `fast` → optimize for speed
* `safe` → optimize for correctness
* `oracle` → optimize for robustness
* `adaptive` → optimize for efficiency without losing trust

***

### Surface Defaults

Expected defaults, subject to tuning as Bardiel gathers more real-world data:

#### Base and Other Onchain Agent Apps

* **Routine delegation / validation:** usually `safe`
* **User-facing helpers or lightweight internal flows:** sometimes `fast`
* **High-value economic actions or state changes:** `safe` or `oracle`
* **Dispute-like or settlement-critical checks:** `oracle`

***

#### Virtual (GAME)

* **Default:** `safe`
* Callers can explicitly select `fast`, `oracle`, or `adaptive` per task

Example patterns:

* `fast` for quick UX-only helpers
* `safe` for core application flows and pre-action checks
* `oracle` for critical decisions or governance-like actions

***

#### Virtual (ACP)

* **Job execution (Delegation-as-a-Service):** usually `safe`
* **Pre-settlement validation:** `safe` or `oracle`, depending on market rules and ticket size
* **Disputes / arbitration:** `oracle` by default, when Bardiel is used as an extra oracle alongside ACP’s own evaluators

***

#### ERC-8004-Compatible Agents and Registries

* **Routine delegation / validation:** `safe` as a sensible default
* **Pre-/post-action checks for high-value tasks:** `safe` or `oracle` depending on risk profile
* **Arbitration-like flows:** `oracle` for settlement-grade decisions, when Bardiel is used as a validator / dispute oracle through registries or markets

These are configuration defaults; individual apps, markets, registries, or agents can override them where appropriate.

***

### Backward Compatibility

Within a given **major version** of Bardiel:

* Policy names (`fast`, `safe`, `oracle`, `adaptive`) are **stable**.
* Internal behavior can be tuned (miner counts, thresholds, scoring curves), but:
  * `fast` will not be made slower or more expensive than `safe` or `oracle`
  * `oracle` will not be degraded into a cheap tier

New tiers (for example, `audit` or `sandbox`) may be added **additively** in the future, without changing the meaning of existing ones.

For details on how policy changes are versioned and communicated across Base, Virtual, ERC-8004, and other integrations, see **Versioning & Compatibility**.