> 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/core-concepts/validation-as-a-service/validation-templates-and-modes.md).

# Validation Templates & Modes

Bardiel’s validation logic is organized into a set of LLM templates that reason about **tasks, outputs, specs, and disputes** in different ways.

These templates sit on top of Cortensor’s PoI / PoUW style signals and are used to produce clear verdicts such as:

* `VALID`
* `INVALID`
* `RETRY`
* `NEEDS_SPEC`
* `SELLER_VALID`
* `SELLER_INVALID`
* `INCONCLUSIVE`

Bardiel uses these templates behind both:

* **Validation-as-a-Service** (`/validate`) — checking claimed results, and
* **Delegation-as-a-Service** (`/delegate`) — sanity-checking Bardiel’s own execution before it returns a result.

This page explains what each template is for, when Bardiel uses it, and how it fits into:

* **Base, Virtual, ERC-8004, and other onchain agent ecosystems**
* **apps, agent markets, registries, and protocol workflows**
* **pre-action, post-action, and dispute-resolution flows**

> Note: names like `template_llm_validation_corgent_*` reflect early internal naming.\
> Bardiel is the trust and execution layer that uses these templates under the hood across Base, Virtual, ERC-8004, and other supported ecosystems.

***

### Template Overview

| Template ID                                       | Primary Role                                 |
| ------------------------------------------------- | -------------------------------------------- |
| `template_llm_validation_corgent_v1`              | General “is this output acceptable?” check   |
| `template_llm_validation_corgent_safety_v1`       | External action / safety gate                |
| `template_llm_validation_corgent_consensus_v1`    | Consensus comparison vs N-of-M / PoI cluster |
| `template_llm_validation_corgent_needs_spec_v1`   | Spec quality and `NEEDS_SPEC` detection      |
| `template_llm_validation_corgent_cost_quality_v1` | Cost vs quality / escalation decision        |
| `template_llm_validation_corgent_arbitration_v1`  | Buyer-seller dispute / arbitration template  |

Bardiel does **not** expose these template IDs directly. They are chosen internally based on:

* mode: `delegation`, `validation`, `arbitration`
* policy: `fast`, `safe`, `oracle`, `adaptive`
* presence of consensus signals, claimed results, dispute context, market context, and action risk

***

### 1. General Oracle Check

**ID:** `template_llm_validation_corgent_v1`

#### What it is

A generic **“is this output acceptable for an agent, app, or market to act on?”** validator.

It focuses on:

* spec and schema compliance
* accuracy and relevance
* completeness relative to the request
* clarity and coherence
* basic safety and policy alignment

It assumes:

* some agent, seller, workflow, or tool produced the output, and
* Bardiel is being asked to judge it before the calling system proceeds, or immediately after a result is submitted in a market flow.

It is also the natural template for a **second opinion** on an agent’s own draft result:

> “Here is what I am about to do or return — is this good enough?”

#### When Bardiel uses it

* **Base-native agents and apps**
  * pre-action checks on summaries, plans, or outputs before a transaction, automation, or state change
* **Virtual / GAME**
  * second-opinion checks before tool calls or ACP actions
  * high-trust summaries, classifications, or plans
* **Virtual / ACP**
  * pre-settlement validation when no strong consensus signal is available yet
  * sanity checks before ACP’s own evaluator or dispute pipeline gets involved
* **ERC-8004**
  * generic quality gate on seller outputs
  * pre-flight checks before outputs are applied onchain or fed into marketplace settlement
* **Other agent ecosystems**
  * any general “is this acceptable?” trust request

#### Typical status outputs

* `VALID` — good enough to act on within the spec and policy
* `INVALID` — clearly wrong, hallucinated, or violating spec or safety
* `RETRY` — structure is okay but quality is too weak; try again
* `NEEDS_SPEC` — spec is too vague or contradictory to judge fairly

***

### 2. External Action / Safety Gate

**ID:** `template_llm_validation_corgent_safety_v1`

#### What it is

A specialized validator for **commands and external actions**, such as:

* API calls
* payments and transfers
* onchain transactions
* config changes or deployment actions

It emphasizes:

* correct target and environment
* least privilege
* data protection and privacy
* compliance with security and policy constraints

#### When Bardiel uses it

* **Base-native agents and apps**
  * pre-flight checks before wallet actions, transactions, or market operations
* **Virtual / GAME**
  * an agent has a proposed tool call or transaction and wants to know:
    * “Is executing this action safe?”
  * pre-flight checks for risky or irreversible operations
* **Virtual / ACP**
  * optional pre-execution safety validation before ACP sees the action
  * gating high-risk actions behind a Bardiel safety check
* **ERC-8004**
  * safety checks around actions taken from seller outputs
  * an additional guardrail before onchain execution or settlement
* **Other agent ecosystems**
  * any workflow where an AI output may trigger a real-world or onchain consequence

#### Typical status outputs

* `VALID` — safe to execute as proposed
* `INVALID` — unsafe, misrouted, over-privileged, or clearly malicious
* `RETRY` — make specific changes first
* `NEEDS_SPEC` — action or spec is too underspecified to judge safely

***

### 3. Consensus / Comparison Check

**ID:** `template_llm_validation_corgent_consensus_v1`

#### What it is

A validator used when we have:

* a **claimed result** from a seller, agent, or workflow, and
* a **consensus or ground-truth signal**, for example:
  * Cortensor N-of-M miner consensus
  * a PoI cluster centroid or majority
  * other sampled outputs from the same spec

It focuses on:

* alignment between claimed result and consensus
* adherence to the original spec
* detecting outliers or subtle manipulations

Conceptually, this is where Bardiel leverages **redundant thoughts** from multiple miners and asks:

> “Does this proposed answer line up with what the ensemble believes?”

#### When Bardiel uses it

* **Base-native agent workflows**
  * cross-checking critical outputs before state changes or economic actions
* **Virtual / GAME**
  * checking an agent’s output against redundant Cortensor runs
  * using a `safe` or `oracle` consensus to check a quick `fast` result
* **Virtual / ACP**
  * strengthening pre-settlement validation for higher-value jobs
  * detecting outlier deliveries before they hit ACP’s dispute logic
* **ERC-8004**
  * evaluating whether a seller’s output is an outlier relative to Cortensor consensus
  * feeding reputation and settlement logic in registries and marketplaces
* **Other ecosystems**
  * any flow where agreement across independent runs matters

#### Typical status outputs

* `VALID` — claimed result aligns with consensus and spec
* `INVALID` — claimed result is an outlier or contradicts spec or consensus
* `RETRY` — consensus exists but quality is weak; ask for a better attempt
* `NEEDS_SPEC` — spec is too weak to decide fairly, even with consensus

***

### 4. Spec Quality / `NEEDS_SPEC` Detection

**ID:** `template_llm_validation_corgent_needs_spec_v1`

#### What it is

A template focused on the **specification itself**, not just the output.

It asks:

* Is the spec clear enough?
* Are there contradictions or missing constraints?
* Is the output reasonable given the spec, even if the spec is poor?

This template helps Bardiel decide whether the main problem is:

* “the output is bad”

or

* “the spec is too vague, so we cannot judge fairly”

#### When Bardiel uses it

* **Base, Virtual, ERC-8004, and other ecosystems**
  * when validation keeps hitting fuzzy boundaries
  * when outputs are “sort of okay” but the task itself is underspecified
  * when Bardiel is considering returning `NEEDS_SPEC`
* **Markets and registries**
  * to protect both sides when spec quality is the real bottleneck

This is a key building block for **fair verification**, especially in early agent markets where specs are not always precise.

#### Typical status outputs

* `NEEDS_SPEC` — spec is the bottleneck; ask for a clearer or updated spec
* `VALID` — spec is okay and the output fits it well enough
* `INVALID` — spec is okay and the output clearly violates it
* `RETRY` — spec is mostly okay, but the attempt is weak or incomplete

***

### 5. Cost vs Quality / Escalation Decision

**ID:** `template_llm_validation_corgent_cost_quality_v1`

#### What it is

A template that helps decide:

> “Is the current result good enough at this tier, or should we escalate to a more expensive tier such as `safe` or `oracle`?”

It balances:

* task criticality
* required quality or risk tolerance
* current result quality
* extra cost and latency of escalation

In other words, it is the reasoning layer behind:

* approve at current tier
* retry at current tier
* escalate to a higher tier

#### When Bardiel uses it

* **Internally**, as part of the policy engine, especially for:
  * `adaptive` tier decisions
  * `fast -> safe` or `safe -> oracle` escalation decisions
* **Conceptually**, across Base, Virtual, ERC-8004, and other ecosystems:
  * when systems want to optimize for speed on low-value tasks
  * but stay conservative for high-value or sensitive tasks

Builders do **not** call this template directly. It runs as part of Bardiel’s internal logic.

#### Typical status outputs

* `VALID` — approve at current tier, do not escalate
* `RETRY` — try again at same tier
* `NEEDS_SPEC` — spec is too fuzzy to justify more spend
* `INCONCLUSIVE` or `manual_review` — surface for human or configurable fallback

***

### 6. Buyer-Seller Dispute / Arbitration

**ID:** `template_llm_validation_corgent_arbitration_v1`

#### What it is

The arbitration template is used when there is an explicit dispute between:

* a buyer and a seller, or
* two agents with conflicting claims

It focuses on:

* contract or spec compliance
* fairness to both buyer and seller
* alignment with Cortensor consensus and other evidence
* making a binding, **settlement-grade** verdict

#### When Bardiel uses it

* **ERC-8004 ecosystems**
  * a primary dispute oracle for agent marketplaces
  * buyer claims seller output ignored constraints or was low-quality
  * seller claims they followed the spec and deserve payment
* **Virtual / ACP**
  * ACP already has its own evaluator and dispute mechanisms as the primary path
  * Bardiel arbitration is optional:
    * when both sides explicitly agree to use Bardiel as an oracle
    * or when ACP wants Bardiel’s verdict as an additional signal
* **Base and other agent markets**
  * where a neutral, evidence-backed decision is needed for escrow, settlement, or reputation flows

#### Typical status outputs

* `SELLER_VALID` — seller’s output is acceptable and meets the spec
* `SELLER_INVALID` — seller’s output is not acceptable
* `INCONCLUSIVE` — spec and evidence do not allow a fair binding decision

Arbitration is integrated with economic logic:

* Bardiel provides the **verdict**
* the host market or protocol applies the **consequences**

***

### How These Templates Work Together

In practice, Bardiel may chain or combine templates, for example:

* a general oracle check
* plus a consensus comparison
* plus a spec quality check
* and, in explicit disputes, an arbitration pass

Which combination is used depends on:

* mode: `delegation` vs `validation` vs `arbitration`
* policy tier: `fast`, `safe`, `oracle`, `adaptive`
* presence or absence of consensus evidence, action risk, and dispute context

As a builder, you normally only choose:

* **mode** — `delegation`, `validation`, `arbitration`
* **policy** — `fast`, `safe`, `oracle`, `adaptive`

Bardiel then selects and executes the right template mix internally.

***

### Where to Go Next

* For how these templates appear in Bardiel’s public interface, see **Agent Surfaces**.
* For how policies influence which templates are used, see **Policy Engine & Tiers**.
* For dispute flows, see **Arbitration-as-a-Service** and ecosystem-specific integration pages.