Policy Engine & Tiers

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

Callers don’t 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 /completions vs deeper /validate flows)

• scoring rules and thresholds

• when to escalate or stay at the current tier

These semantics apply whether Bardiel is called from Virtual (GAME / ACP) or from ERC-8004 agents and registries.

---

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 / low-stakes tasks

• non-critical UX (suggestions, helper text, drafts)

• early prototyping and experiments in Virtual or ERC-8004 agents

---

safe

Goal: Balance trust vs cost. (Expected default for many agents.)

Typical behavior:

• 3 miners in parallel

• PoI-based similarity / consensus checks

• simple PoUW-style scoring for usefulness / coverage

Use cases:

• summaries and classifications that impact application flows

• pre-action or pre-settlement checks in Virtual (GAME / ACP)

• pre-action or pre-settlement checks for ERC-8004 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:

• ACP disputes and arbitration flows in Virtual

• ERC-8004 arbitration-like flows (when Bardiel is used as a dispute oracle)

• 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, etc.)

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 Virtual agents that see mixed difficulty tasks

• ERC-8004 agents that continuously process varied jobs

• generic “I don’t 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 (json_tool_call) vs open-ended text

  • known risky domains (“contract summary”, “financial analysis”, etc.)

• Caller context

  • surface (Virtual GAME vs Virtual ACP vs ERC-8004)

  • environment (testnet vs mainnet)

  • whether this is pre-action, pre-settlement, or post-dispute

• Historical data

  • prior disagreement rates for similar tasks

  • per-market 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 we gather real data):

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

  • oracle for critical decisions or governance-like actions

Virtual (ACP)

• Job execution (delegation): usually safe

• Pre-settlement validation: safe or oracle, depending on market rules and ticket size

• Disputes / arbitration: oracle by default, since these are binding decisions

ERC-8004 Agents and Registries (Planned)

• 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 ERC-8004 registries

These are configuration defaults; individual 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 to Virtual and ERC-8004 callers, see Versioning & Compatibility.