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

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

• Virtual (GAME, ACP) – primarily pre-action / second-opinion validation

• ERC-8004 ecosystems – pre- and post-action validation and arbitration for agent marketplaces

Note: names like template_llm_validation_corgent_* reflect the initial internal naming. Bardiel is the Virtual-native agent and ERC-8004 validator that uses these templates under the hood.

---

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 to most users. Instead, they are chosen internally based on:

• mode: delegation, validation, arbitration

• policy: fast, safe, oracle, adaptive

• presence of consensus signals, claimed result, dispute context, etc.

---

1. General Oracle Check

template_llm_validation_corgent_v1

What it is

A generic “is this output acceptable for an agent 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 (or tool) produced the output

• Bardiel is being asked to judge it before the calling agent acts (pre-action), or immediately after a seller claims completion in ERC-8004 flows.

It’s also the natural template to support “think twice / second opinion” on an agent’s own draft result: “Here is what I’m about to do/say – is this good enough?”

When Bardiel uses it

• Virtual / GAME

  • pre-action check on a generated answer, plan, or payload

  • high-trust summaries, classifications, or plans

  • “second opinion” on the agent’s own output before tool calls or ACP actions

• 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- and post-action)

  • pre-flight checks before applying outputs on-chain or in other systems

Typical status outputs

• VALID – good enough to act on within the spec and policy

• INVALID – clearly wrong, hallucinated, or violating spec/safety

• RETRY – structure is okay but quality is too weak; try again

• NEEDS_SPEC – spec is too vague/contradictory to judge fairly

---

2. External Action / Safety Gate

template_llm_validation_corgent_safety_v1

What it is

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

• API calls

• payments and transfers

• on-chain transactions

• config changes or deployment actions

It emphasizes:

• correct target / environment (no mainnet vs testnet mix-ups)

• least privilege (no over-broad permissions)

• data protection and privacy

• compliance with security / policy constraints

When Bardiel uses it

• Virtual / GAME

  • an agent has a proposed tool call / transaction and wants to know:

    • “Is executing this external 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 that will be taken based on seller outputs

  • an additional guardrail before on-chain execution or settlement

Typical status outputs

• VALID – safe to execute as proposed

• INVALID – unsafe, misrouted, over-privileged, or obviously malicious

• RETRY – make specific changes (e.g. narrow the scope, fix target env)

• NEEDS_SPEC – action/spec is too underspecified to judge safety

---

3. Consensus / Comparison Check

template_llm_validation_corgent_consensus_v1

What it is

A validator used when we have:

• a claimed result (from a seller or agent), and

• a consensus or ground-truth signal, for example:

  • Cortensor N-of-M miner consensus

  • PoI cluster centroid / 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

• Virtual / GAME

  • cross-checking an agent’s output against redundant Cortensor runs

  • using a “safe/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 ERC-8004 marketplaces

Typical status outputs

• VALID – claimed result aligns with consensus and spec

• INVALID – claimed result is an outlier or contradicts spec/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

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 bad?

This template is used to decide whether the main problem is:

• “the output is bad” vs

• “the spec is too vague, so we can’t judge fairly”

When Bardiel uses it

• Virtual / GAME and ACP

  • when validation keeps hitting fuzzy boundaries

  • when outputs are “sort of okay” but the spec is obviously underspecified

  • when Bardiel is considering returning NEEDS_SPEC

• ERC-8004

  • when interpreting loosely-defined job specs that make fairness hard to decide

  • to protect both buyers and sellers when spec quality is the true 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/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

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 (safe/oracle)?”

It balances:

• task criticality

• required quality / risk tolerance

• current result quality

• extra cost and latency of escalation

In other words, it’s the reasoning layer behind:

• approve at current tier

• retry at current tier

• or 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 in GAME / ACP / ERC-8004:

  • when agents and markets want to be aggressive on speed for low-value tasks

  • but 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 (for example, minor quality issues)

• NEEDS_SPEC – spec is too fuzzy to justify more spend

• INCONCLUSIVE or manual_review – surface for human/configurable decision (implementation detail; mapping to final statuses may vary)

---

6. Buyer–Seller Dispute / Arbitration

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/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 (primary focus)

  • buyer claims seller’s output ignored constraints or was low-quality

  • seller claims they followed the spec and deserve payment

  • marketplace wants a neutral decision to drive settlement, refunds, and reputation

• Virtual / ACP

  • ACP already has its own evaluator and dispute mechanisms as the primary path

  • Bardiel arbitration is optional / future backup:

    • when both sides explicitly agree to use Bardiel as an oracle

    • or when ACP wants to incorporate Bardiel’s verdict as an additional signal

In other words:

• In ERC-8004, Bardiel arbitration is a first-class dispute oracle.

• In Virtual, ACP remains the main dispute engine; Bardiel arbitration is an optional extra layer when explicitly invoked.

Typical status outputs

• SELLER_VALID – seller’s output is acceptable and meets the spec (payout justified)

• SELLER_INVALID – seller’s output is not acceptable (refund / no payout)

• INCONCLUSIVE – spec and evidence do not allow a fair binding decision

Arbitration is conceptually integrated with economic logic:

• Bardiel provides the verdict (plus evidence and rationale).

• ACP or the ERC-8004 marketplace applies the consequences (payments, slashing, reputation updates, etc.).

---

How These Templates Work Together

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

• a general oracle check (corgent_v1)

• plus a consensus comparison (consensus_v1)

• plus a spec quality check (needs_spec_v1)

• and, in explicit disputes, an arbitration pass (arbitration_v1)

Which combination is used depends on:

• mode: delegation vs validation vs arbitration

• policy tier: fast, safe, oracle, adaptive

• presence (or absence) of consensus evidence 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 are surfaced in the API, see Agent Surfaces.

• For how policies influence which templates are used, see Policy Engine & Tiers.

• For arbitration-specific flows:

  • in Virtual, see ACP’s dispute/evaluator documentation (Bardiel is an optional secondary oracle).

  • in ERC-8004, see Core Concepts → Arbitration and future ERC-8004 integration guides.