> 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.md).

# Validation-as-a-Service

Bardiel is a **trust and execution layer** for **Base, Virtual, ERC-8004, and other onchain agent ecosystems**.

**Validation-as-a-Service** is how agents, apps, and markets ask **Bardiel** to **check someone else’s work** — or to get a second opinion before taking an important step.

Where Delegation is:

> “Run this task for me.”

Validation is:

> **“Here is a task and a claimed result — is this actually good enough to trust?”**

Bardiel re-runs or cross-checks the task on **Cortensor**, interprets PoI / PoUW-style and other trust signals, and returns a structured verdict.

Validation is especially useful as a **checkpoint for agency and safety**:

* before acting,
* before paying,
* before settling,
* or before letting an AI output trigger a real consequence.

In practice:

* in **Base** and **Virtual** workflows, Validation is often used **pre-action**,
* in **ERC-8004-compatible** ecosystems, it can be used **pre- and post-action**,
* in **other agent ecosystems**, it acts as a reusable trust layer between “an agent produced something” and “the system accepts it.”

***

### When to Use Validation

Use Validation-as-a-Service when an agent, app, or market:

* receives a result from another agent or seller and wants assurance before acting or paying,
* chains multiple tools or agents and needs **guardrails** between steps,
* must enforce **schemas, constraints, or policies**,
* wants an **independent oracle** to confirm correctness or usefulness.

Typical use cases:

* pre-action checks in **Base-native** or **Virtual ACP** flows:
  * “Is this delivery acceptable before I confirm or settle?”
* verifying tool-call arguments or JSON outputs,
* sanity-checking summaries, classifications, or research reports,
* validating intermediate steps of multi-hop reasoning,
* post-action verification for **ERC-8004** jobs:
  * “Did the seller actually meet the spec?”

***

### High-Level Flow

1. **Agent, app, or market** calls Bardiel, for example:

   ```
   validate_with_bardiel(task, claimed_result, policy="safe")
   ```

   where:

   * `task` describes what was supposed to be done,
   * `claimed_result` is what another agent or seller produced,
   * `policy` controls how strict Bardiel should be.
2. **Bardiel** chooses a **validation pattern**, for example:
   * deterministic tasks → rerun + strict comparison
   * open-ended text → N-of-M consensus + usefulness scoring
   * structured outputs → schema/spec checks first, then PoI / PoUW-style checks
3. **Cortensor Router** (when reruns are needed):
   * replays or re-runs the task with 1 / 3 / 5+ miners depending on policy,
   * collects outputs plus relevant metadata and trust signals
4. **Bardiel**:
   * compares `claimed_result` against Cortensor consensus and/or the spec,
   * decides a **verdict** and **confidence**,
   * prepares a compact **evidence summary** and optional retry instructions
5. **Agent, app, or market** uses the verdict to:
   * accept the result and proceed,
   * request a retry or revision from the seller or upstream agent,
   * or, for high-stakes cases, escalate to **Arbitration-as-a-Service** or another dispute flow.

In **Virtual**, this typically happens *before* ACP’s own evaluator and dispute pipeline, reducing the number of obviously bad or low-quality actions that ever reach settlement.\
In **Base** and other onchain workflows, this can serve as the safety checkpoint before a transaction, market action, or state change.\
In **ERC-8004**, it can feed registries, validator logic, and marketplace settlement systems.

***

### Verdicts

Validation-as-a-Service returns one of:

* **`VALID`**\
  The claimed result aligns with Cortensor consensus and the task spec.
* **`INVALID`**\
  The result is clearly wrong, malformed, or violates constraints.
* **`RETRY`**\
  The structure is fine, but the content needs another attempt.\
  Often accompanied by specific retry instructions.
* **`NEEDS_SPEC`**\
  The **task description** is too vague or underspecified.\
  Bardiel cannot fairly judge quality without a tighter spec.

Each response includes:

* `status` – one of the verdicts above
* `confidence` – how strongly Bardiel believes the verdict
* `evidence` – summarized signals, not all raw data
* `retry_instructions` – what to fix, if the issue is recoverable

***

### Policy Hints

Validation supports the same **policy hints** as Delegation:

* **`fast`** – 1 rerun, light checks
* **`safe`** – 3 reruns, consistency + basic usefulness scoring
* **`oracle`** – 5+ reruns, strict thresholds and richer evidence
* **`adaptive`** – start cheap, escalate only if confidence is low

Internally, Bardiel can vary:

* how much redundancy to use,
* which models or miner pools to sample,
* which rubrics to apply for usefulness, correctness, and safety.

Callers keep a simple `policy` parameter while Bardiel evolves its internal validation logic.

***

### Validation Across Ecosystems

#### Base and Other Onchain Agent Workflows

Validation is often used as a **pre-action checkpoint**.

Examples:

* check a summary before a trade or treasury action,
* verify a classification before triggering automation,
* confirm a tool output before a contract interaction.

The goal is simple:

> Do not let agent outputs directly move value or state without a neutral second check.

#### Virtual (GAME + ACP)

In **Virtual**, Validation is primarily **pre-action**:

* agents call Bardiel before ACP actions, tool calls, or user-impacting steps,
* ACP’s own evaluators and dispute logic remain the **post-action authority**,
* Bardiel’s role is to:
  * reduce bad or low-quality outputs before they hit ACP,
  * act as a high-signal **second opinion** for important steps.

#### ERC-8004-Compatible Ecosystems

In **ERC-8004-compatible** ecosystems, Validation can be both:

* **pre-action**:
  * “Should we trust this before we act?”
* **post-action**:
  * “Did the seller actually meet the spec?”

Bardiel can be exposed as a validator service whose verdicts and scorecards feed into:

* validator registries,
* agent/seller reputation systems,
* marketplace settlement logic.

**Arbitration-as-a-Service** then builds on this for explicit buyer-seller disputes.

***

### Example 1: JSON Tool Call Check

**Task:** Return JSON for `create_event(title, start, end)`.

**Claimed result:**

```
{ "title": "demo", "end": "tomorrow" }
```

Bardiel (no reruns needed):

1. Runs a schema/spec check:
   * required field `start` is missing
   * `end` is not ISO-8601 datetime
2. Returns:

   { "status": "INVALID", "confidence": 0.99, "evidence": { "schema\_errors": \[ "missing field: start", "field 'end' must be ISO-8601 datetime" ] }, "retry\_instructions": "Provide both start and end in ISO-8601 datetime format." }

No Cortensor rerun is needed here — Bardiel can reject purely on spec.

***

### Example 2: Consensus Check for Text

**Task:** Write 5 bullets summarizing the competitor landscape.\
**Claimed result:** Seller’s 5 bullets.

Bardiel:

1. Requests 3 Cortensor runs (`policy = "safe"`).
2. Uses consensus / similarity metrics to find the **stable cluster** across miner outputs.
3. Checks whether the seller’s bullets:
   * mention the same key competitors,
   * match the overall structure and major claims.

If the seller is an outlier and misses critical entities, Bardiel may respond:

```
{
  "status": "RETRY",
  "confidence": 0.84,
  "evidence": {
    "reason": "consensus_outlier",
    "missing_entities": ["Competitor A", "Competitor B"]
  },
  "retry_instructions": "Include competitors A and B, keep to 5 bullets, and note key differences such as pricing and positioning."
}
```

The buyer, agent, or orchestrator can now reasonably request a corrected version or decide whether to escalate.

***

### Example 3: Pre-Action Check for an Onchain Workflow

**Task:** An agent proposes a market action based on its own research summary and risk check.\
**Claimed result:** “This is safe to execute.”

Bardiel can validate:

* whether the summary actually supports the recommendation,
* whether required constraints were followed,
* whether the confidence should be high enough for the next step.

Possible result:

```
{
  "status": "RETRY",
  "confidence": 0.72,
  "evidence": {
    "reason": "insufficient_support",
    "notes": [
      "Claimed action is stronger than the evidence in the summary",
      "Risk bounds were not clearly stated"
    ]
  },
  "retry_instructions": "Provide explicit risk bounds and tie the recommendation to the cited evidence before proceeding."
}
```

This is the core “checkpoint for agency and safety” role Bardiel plays in Base, Virtual, and other onchain agent systems.

***

### In Short

**Validation-as-a-Service** is Bardiel’s everyday trust primitive.

It keeps agents and sellers honest, filters out low-quality outputs, and gives **Base, Virtual, ERC-8004, and other agent ecosystems** a reusable way to ask:

> **Is this result actually good enough to act on?**