Core Primitives

Delegate & Validate

Status: Draft – API shapes and policies may evolve as Bardiel, Corgent, and the Cortensor Router advance.

Bardiel does not talk directly to miners. Almost everything it does rides on two core primitives exposed by the Cortensor Router:

• /delegate – Execution primitive “Send this job to the Cortensor network under a specific policy.”

• /validate – Safety / trust primitive “Check this result under a specific policy before I act or pay.”

These primitives are shared between:

• Corgent – Cortensor’s infra-native agent for ERC-8004 and agent ecosystems.

• Bardiel – Virtual-native service agent that runs on Cortensor and plugs into GAME, ACP, and (optionally) ERC-8004.

This page explains how Bardiel conceptually uses /delegate and /validate. For exact schema details, see Bardiel’s Agent Surfaces and the Router-level API references.

---

1. High-Level Concept

1.1 What /delegate Does (Execution Primitive)

/delegate is “send this job to the network”:

• You describe what you want done and how it should be run (policy).

• Cortensor routes the task across miners according to that policy.

• You get back results plus evidence, not just a string.

Two generations are supported underneath Bardiel:

• /delegate v1

  • Simple prompt → single completion.

  • Uses legacy fields like task_request_input for compatibility.

• /delegate v2

  • Lets agents offload small, bounded workflows with:

    • tools

    • max-step limits

    • timeouts and policies

  • Returns structured evidence (steps taken, tools used, configs) so upstream agents can reason about how work was performed, not just what the answer is.

Mental model for Bardiel: /delegate turns Cortensor into Bardiel’s execution fabric – Bardiel decides what to ask for and which policy tier to use; Router and miners handle how it gets computed.

---

1.2 What /validate Does (Safety / Trust Primitive)

/validate is the checkpoint Bardiel uses before an agent takes an irreversible step:

• Bardiel sends what was asked, what was produced, and how it should be judged.

• Cortensor re-runs or cross-checks work on the network where needed.

• Bardiel receives a stable verdict and supporting evidence that it can turn into its own status codes:

  • VALID, INVALID, RETRY, NEEDS_SPEC, etc.

Two generations are supported underneath Bardiel:

• /validate v1

  • LLM-style “check this” with free-form output.

  • Uses task_request_input / task_result_output plus basic criteria.

• /validate v2

  • Standard verdict-oriented contract with structured payloads for:

    • the claim being judged,

    • the context around it,

    • the policy (tier, redundancy, rules).

  • Can run redundant checks and aggregate them into a single verdict.

Mental model for Bardiel: /validate is Bardiel’s “are we sure?” API at the infrastructure level – Bardiel uses it to power Validation-as-a-Service and Arbitration-as-a-Service.

---

1.3 Why These Two Matter for Bardiel and the Agent Economy

Without these primitives underneath Bardiel:

• Without /delegate Bardiel would have to manage:

  • GPUs and infra directly,

  • routing and retries,

  • per-market tool orchestration.

• Without /validate There is no shared, neutral checkpoint at the network level to say: “This result is safe enough or correct enough to act or pay on.”

With /delegate and /validate available at the Router:

• Bardiel can offer Delegation-as-a-Service and Validation-as-a-Service to other agents.

• Bardiel can focus on policies, templates, and verdict semantics, while Cortensor focuses on compute and proofs.

This v2 surface is what both Corgent and Bardiel lean on for:

• REST

• MCP

• ERC-8004 / A2A integration

• x402 (pay-per-call) flows

v1 remains as a simpler, legacy-compatible path.

---

2. Endpoint Matrix (Router / Bardiel Perspective)

Bardiel itself exposes Virtual-native surfaces (GAME Functions, ACP hooks, etc.), but under the hood it calls the Cortensor Router.

At the Router level, endpoints are exposed with:

• v1 vs v2 payloads

• normal, trial, and x402 (payment-gated) variants

For Bardiel’s internal usage, the Router matrix looks like:

2.1 REST Endpoint Matrix (Router-Level)

Flow	Normal	Trial	x402
Delegate v1	/api/v1/delegate	/api/v1/trial/delegate	/api/v1/x402/delegate
Validate v1	/api/v1/validate	/api/v1/trial/validate	/api/v1/x402/validate
Delegate v2	/api/v2/delegate	/api/v2/trial/delegate	/api/v2/x402/delegate
Validate v2	/api/v2/validate	/api/v2/trial/validate	/api/v2/x402/validate

2.2 Usage Modes (from Bardiel’s Point of View)

• Normal Standard authenticated calls Bardiel uses for steady-state workloads.

• Trial Rate-limited evaluation path, useful for Bardiel’s own test flows, demos, or alpha testers.

• x402 Payment-gated variant used when Bardiel is operating in a pay-per-call mode:

  • first call returns HTTP 402 with payment terms,

  • a payment is made (for example USDC on Base or COR on COR L3),

  • Bardiel retries with a payment proof header.

Bardiel’s Sessions, Billing & x402 page describes how these Router-level modes map into Bardiel’s own session and funding logic.

---

3. Payload Shapes – v1 vs v2 (Conceptual)

Bardiel’s Agent Surfaces wrap these payloads into a Virtual-native envelope (mode, task, policy, context). This section shows the Router-level shapes Bardiel builds internally.

3.1 /delegate v1 – Prompt-Oriented

Use when:

• Bardiel needs a simple completion from Cortensor.

• Backward compatibility or low-complexity tasks are sufficient.

Conceptual example (Router POST /api/v1/delegate):

{
  "session_id": 110,
  "task_request_input": "Create incident communication draft for MCP downtime.",
  "task_domain": "ops",
  "task_type": "communication",
  "evaluation_mode": "high_reliability",
  "web_url": "https://status.example.com"
}

Key fields:

• session_id – Cortensor session to use (funding + routing config).

• task_request_input – main prompt Bardiel sends.

• Optional domain/type hints (task_domain, task_type).

• Optional evaluation mode and URL context.

Bardiel uses this format mainly for simple delegation flows and for compatibility with older Router deployments.

---

3.2 /delegate v2 – Workflow-Oriented

Use when:

• Bardiel is offloading structured workflows, not just single prompts.

• Tools, multi-step control, and explicit policies are needed.

Conceptual example (Router POST /api/v2/delegate):

{
  "session_id": 205,
  "objective": "Use tools to evaluate candidate responses and choose the best one.",
  "input": {
    "kind": "array",
    "items": ["response A", "response B", "response C"]
  },
  "execution": {
    "mode": "tools",
    "model": "auto",
    "tools": ["rank_candidates", "summarize_text"],
    "max_steps": 8
  },
  "policy": {
    "tier": "balanced",
    "timeout_ms": 30000
  }
}

Key fields:

• objective – short, plain-language description of the task.

• input – structured input (string, array, object, etc.).

• execution – how the network should run it:

  • mode (for example tools, simple, chain)

  • model (or auto)

  • tools, max_steps, etc.

• policy – trust / SLA profile:

  • tier, timeout, and possible redundancy knobs (by Router version).

Bardiel wraps this inside its delegation mode when it needs workflows with tooling.

---

3.3 /validate v1 – Prompt-Oriented Check

Use when:

• Bardiel wants LLM-style “is this OK?” checks with minimal structure.

• Outputs are text-like and acceptance rules are simple.

Conceptual example (Router POST /api/v1/validate):

{
  "session_id": 302,
  "task_request_input": "Provide three bullet points about x402 payment flow.",
  "task_result_output": "x402 returns 402, client pays, then retries with receipt.",
  "task_domain": "api",
  "task_type": "explanation",
  "acceptance_criteria": ["accuracy", "conciseness", "non_hallucination"],
  "evaluation_mode": "llm_judge"
}

Key fields:

• task_request_input – original request.

• task_result_output – output Bardiel wants checked.

• acceptance_criteria – free-form acceptance rules.

• evaluation_mode – how Router/validators should judge it.

Bardiel can map the Router’s response into its own VALID / INVALID / RETRY style statuses.

---

3.4 /validate v2 – Verdict-Oriented Check

Use when:

• Bardiel needs a clear verdict contract for high-impact decisions.

• Workloads may trigger payments, ACP settlements, or ERC-8004 outcomes.

Conceptual example (Router POST /api/v2/validate):

{
  "session_id": 409,
  "request_id": "v2-val-009",
  "claim": {
    "type": "summary",
    "description": "Summarize MCP endpoints exposed by router.",
    "output": "Stream endpoint is /mcp/messages and legacy is /messages.",
    "input_hash": "0xabc123"
  },
  "policy": {
    "tier": "balanced",
    "redundancy": 1,
    "rules": ["consistency", "non-hallucination"]
  },
  "context": {
    "dapp": "mcp-docs"
  }
}

Typical Router-level response (conceptual):

{
  "verdict": "VALID",
  "confidence": 0.92,
  "reasons": ["matches spec", "internally consistent"],
  "evidence": {
    "runs": [],
    "scores": []
  }
}

Bardiel then translates:

• verdict → Bardiel status

• confidence → Bardiel confidence

• evidence → Bardiel evidence field in its own response envelope

as described in Agent Surfaces and Validation Templates & Modes.

---

4. How Bardiel Uses /delegate and /validate

From a Virtual agent’s perspective, Bardiel exposes:

• mode: delegation, validation, arbitration

• policy: fast, safe, oracle, adaptive

• a task envelope (task type, input, spec, claimed result, dispute context)

Internally, Bardiel:

1. Reads intent Understands whether the call is delegation, validation, or arbitration.

2. Chooses policy tier Maps fast / safe / oracle / adaptive into Router-level tiers and redundancy.

3. Builds Router requests Chooses between:

   • /delegate v1 or v2

   • /validate v1 or v2

   • normal vs trial vs x402

4. Interprets Router results Uses PoI/PoUW-style signals and template logic to convert Router responses into:

   • VALID, INVALID, RETRY, NEEDS_SPEC, SELLER_VALID, SELLER_INVALID, INCONCLUSIVE

   • with confidence, evidence, and retry_instructions.

5. Returns a clean Bardiel response Back to GAME, ACP, or ERC-8004 agents, via the unified Agent Surfaces envelope.

---

5. Corgent, Bardiel, and the “AWS for Agents” Analogy

At the Router level, Cortensor is aiming to be “AWS for agents”:

• /delegate → execution fabric

• /validate → trust and safety fabric

Within that:

• Corgent is the infra-facing, ERC-8004-friendly agent:

  • leans directly on Router’s REST and MCP surfaces,

  • exposes /delegate and /validate to external agent ecosystems.

• Bardiel is the Virtual-native trust agent:

  • exposes GAME/ACP Workers and Functions,

  • wraps Router’s /delegate and /validate with Bardiel’s own:

    • policies,

    • validation templates,

    • arbitration logic,

    • tokenomics and incentives.

From a Virtual builder’s perspective:

• You integrate with Bardiel via Virtual-native surfaces.

• Bardiel integrates with Router /delegate and /validate for you.

---

6. Where This Page Fits in the Bardiel Docs

Suggested placement in the Bardiel documentation:

• Section: Technical Architecture → Core Primitives → Delegate & Validate (via Cortensor Router)

• Cross-links:

  • Link from:

    • Technical Architecture overview (where Router and Cortensor are introduced),

    • Agent Surfaces (to show how Bardiel’s envelope maps down to Router calls),

    • Validation Templates & Modes and Arbitration-as-a-Service (to show where verdicts come from).

  • Link to:

    • Cortensor Router API reference (for low-level schema details),

    • Corgent docs for ERC-8004-focused integrations.

This page should be treated as the conceptual bridge:

• explaining how Bardiel’s Delegation/Validation/Arbitration surfaces

• are powered underneath by Cortensor Router’s /delegate and /validate primitives.