> For the complete documentation index, see [llms.txt](https://docs.cortensor.network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cortensor.network/community-and-ecosystem/products-and-agents/corgent/delegate-and-validate-versions.md).

# /delegate & /validate Versions

> Status: **v2 is live today** across Router REST/MCP/x402 surfaces.\
> **v3** and **v4** are roadmap stages that progressively add explicit consensus and programmable trust.

***

### 1. What `/delegate` and `/validate` Are For

**Two core primitives:**

* **`/delegate` – Execution primitive**
  * “Send this job to the network.”
  * Offloads a bounded workflow to Cortensor (models, tools, routing, retries, redundancy).
  * Returns not just final text, but structured evidence of *how* work was done (steps, tools, configs in v2+).
* **`/validate` – Safety / trust primitive**
  * “Before I act or pay, check this for me.”
  * Re-runs or cross-checks a claimed result under a policy.
  * v2+ returns a **standard verdict contract**:
    * `VALID` / `INVALID` / `RETRY` / `NEEDS_SPEC`\
      plus reasons, evidence, and (later) consensus metadata.

Together they give agents:

* A **cloud-like execution fabric** to offload heavy work (`/delegate`).
* A **neutral trust oracle** to confirm results before irreversible actions (`/validate`).

***

### 2. Current Surfaces (v1 + v2)

Today, the Router exposes:

* **v1 (prompt-oriented)**
  * `POST /api/v1/delegate`
  * `POST /api/v1/validate`
  * Fields like `task_request_input`, `task_result_output`, `task_domain`, `task_type`, `evaluation_mode`.
  * Good for simple prompt → answer / prompt → judgment flows.
* **v2 (contract-first, policy-aware) – current default**
  * `POST /api/v2/delegate` – payloads shaped around:
    * `objective`, `input`, `execution`, `policy`, optional `tools` / `workflow` / `metadata`.
  * `POST /api/v2/validate` – payloads shaped around:
    * `claim`, `policy`, `context`, optional `actor` / `metadata`.
  * Enforces clear separation between:
    * *What* is being asked (`objective` / `claim`),
    * *How* it should run (`execution`),
    * *Under what guarantees* (`policy` / tier / timeouts / basic redundancy).

All four combinations (`/delegate` v1/v2, `/validate` v1/v2) are available across:

* **REST**, **MCP**, **A2A / agent cards**, and **x402** (pay-per-call).

***

### 3. Router Evolution – v0 → v4

This section describes how `/delegate` and `/validate` evolve across **router versions**.\
The same primitives are reused by **Corgent** (infra-facing, ERC-8004-friendly) and **Bardiel** (Virtual-first service agent) surfaces.

#### v0 – Bare LLM API (Pre-Router Era)

* Single-shot `/completion`-style calls to a single model or session.
* No explicit distinction between:
  * execution vs validation,
  * policy vs payload.
* Any redundancy or checking is **hand-rolled per app**:
  * custom retries,
  * ad-hoc “LLM judge” prompts,
  * no shared contract or common verdict format.
* Works for demos and one-off tools, but **not enough for an agent economy**.

***

#### v1 – First `/delegate` & `/validate` (Prompt-Oriented)

* Introduces the two primitives as **separate endpoints**:
  * `/delegate` → “do this for me”
  * `/validate` → “check this for me”
* Still **prompt-centric**:
  * fields like `task_request_input`, `task_result_output`, with light hints (`task_domain`, `task_type`, `evaluation_mode`).
* Runs against a **single `session_id`**:
  * any miner redundancy is handled inside that session’s configuration.
* Useful for:
  * early Corgent / Bardiel prototypes,
  * simple “send → get answer” and “send → get judgment” flows.

> v1 remains supported as the **simpler legacy path**.

***

#### v2 – Contract-First, Policy-Aware Router (**Today**)

This is the **current default** for new integrations.

**Key changes vs v1:**

* **Structured payloads** instead of free-form prompts:
  * `/delegate` v2:
    * `objective` – what the agent wants done.
    * `input` – data to work on (string, array, structured).
    * `execution` – mode, model, max steps, tool usage, timeouts.
    * `policy` – tier (`fast`, `balanced`, `safe`, `oracle`), latency/timeout bounds, basic redundancy, safety rules.
  * `/validate` v2:
    * `claim` – what is being asserted (summary, transaction, tool output, plan step…).
    * `policy` – tier, redundancy level, rules (e.g. non-hallucination, consistency).
    * `context` – task/app metadata that matters for the verdict.
* **Verdict contract** for `/validate`:
  * `VALID`, `INVALID`, `RETRY`, `NEEDS_SPEC`\
    plus reasons and evidence, so agents know *how* to react.
* **Policy & tiers become first-class:**
  * `tier` ⇒ high-level tradeoffs:
    * `fast` (low latency, minimal redundancy),
    * `balanced`,
    * `safe`,
    * `oracle` (higher redundancy / stricter checks).
  * Timeouts and basic redundancy (especially in factcheck-style flows) move from ad-hoc to **structured policy**.
* **Router view is still mostly single-session:**
  * Clients hit a **single `session_id`**.
  * That session may internally fan out to multiple miners / models, but consensus aggregation is **implicit**, not an explicit router-level knob.
* **Unified surfaces:**
  * v2 is available consistently across:
    * REST, MCP, agent cards (A2A), and x402 (pay-before-run).

> **Mental model:**\
> v2 gives you **execution and verification primitives with structured contracts and policy tiers**, but consensus still mostly happens *inside* a session.

***

#### v3 – Explicit Redundancy & Consensus (1 / 3 / 5 Sessions)

**Goal:** turn **redundancy + consensus** into **explicit, configurable knobs** at the router layer across `/delegate`, `/validate`, and `factcheck`.

**3.1 Redundant Sessions as Policy**

Requests gain a `consensus` block, for example (shape, not final schema):

* `replicas`: `1` / `3` / `5`
* `session_pool`: list of candidate `session_id`s (e.g. `[201, 202, 203]`)
* `aggregation`: `"majority"` (later `"weighted"`, `"median"`, etc.)
* `disagreement_policy`: `"return_all"` / `"fail_hard"` / `"best_effort"`

Router behavior:

* `replicas = 1` → behaves like v2 today.
* `replicas = 3` or `5`:
  * router fans the **same logical request** to **3 or 5 independent sessions**, each with its own miner sample and infra slice.
  * each session runs independently (Cortensor principle: redundant, independent runs).
  * router aggregates the results and returns:
    * a **final answer / verdict**, and
    * **per-replica evidence + agreement metrics**.

Applies to:

* `/delegate` – redundant execution runs.
* `/validate` – redundant verification runs.
* `factcheck` – redundant world/fact checks (generalizing today’s 1/3 pattern into a standard “1/3/5 replicas” contract).

**3.2 Consensus Metadata in Responses**

Every v3 router response includes a consensus block, e.g.:

* `replicas`: how many runs were executed.
* `agreement`: fractional agreement (e.g. `0.67` for 2/3).
* `verdicts`: list of per-replica verdicts or high-level statuses.
* `strategy`: aggregation strategy used (`"majority"` initially).
* `confidence`: derived confidence score.

Examples:

* `/delegate`: “2 of 3 runs agree on this structured result.”
* `/validate` or `factcheck`: “3 of 5 runs agreed the claim is TRUE under this policy.”

Agents don’t just get “an answer” – they see **how many independent runs agreed**, and with what confidence.

**3.3 Uniform Semantics Across Surfaces**

The same `consensus` semantics apply across:

* REST, MCP, A2A, and x402.

Agents can tune reliability vs cost using:

* `tier` (fast vs balanced vs safe vs oracle),
* `replicas` (1 / 3 / 5),
* `aggregation` and `disagreement_policy`.

> **v3 tagline:**\
> \&#xNAN;**“Agent-ready consensus”** – explicit redundancy knobs + structured consensus metadata for `/delegate`, `/validate`, and `factcheck`.

***

#### v4 – Programmable Trust & Reusable Artifacts

If v3 turns consensus into a **knob**, v4 turns it into a **programmable trust fabric** and a pool of **reusable artifacts**, not just one-off responses.

**4.1 Pluggable Aggregation Strategies**

Beyond simple majority:

* `aggregation` choices like:
  * `"majority"`, `"weighted"`, `"median_of_means"`, `"model_ensemble"`.
* Optional hints such as:
  * `weight_by`: `"reputation"`, `"stake"`, `"latency"`, `"cost"`.

Router still hides miner-level complexity, but **agents decide how consensus is formed**, not just how many replicas run.

**4.2 Reusable Validation / Fact Artifacts**

High-value `/validate` or `factcheck` calls can emit **stable validation artifacts**, e.g.:

* `id`: unique artifact identifier (e.g. `val_0xabc123...`).
* `kind`: `"validation"` / `"factcheck"`.
* `scope`: logical scope (e.g. `trade:1234`).
* `ttl`: suggested time-to-live.

Other agents or flows (ERC-8004, A2A, x402, on-chain actions) can then:

* **reference** this artifact instead of re-running full consensus,
* express policies like:
  * “Only execute this action if `val_0xabc123...` is `VALID` with confidence ≥ 0.9.”

The **agentic web** becomes:

* A **graph of delegated calls + shared validations**, not just isolated API calls.

**4.3 Cost-Aware, Dynamic Redundancy**

Redundancy becomes **dynamic**, driven by policy + observed risk:

* **Low-risk paths**:
  * auto-downgrade to `replicas = 1` once enough similar calls have consistent validations.
* **High-risk paths** (payments, on-chain writes, critical financial or safety actions):
  * auto-upgrade to `replicas = 5` with stricter aggregation.
  * optionally require **multi-model** redundancy (different backbone families must agree).

All controlled by high-level policy, not per-call plumbing.

**4.4 Deep Integration with Cortensor’s Core**

v4 explicitly ties consensus and artifacts into:

* **Proof of Inference (PoI)** and **Proof of Useful Work (PoUW)**.
* Miner reputation / slashing signals.
* Optional on-chain anchoring of critical validations via **Corgent** in **ERC-8004** markets.

> **v4 tagline:**\
> \&#xNAN;**“Programmable, reusable trust”** – pluggable consensus strategies, reusable validation artifacts, and dynamic redundancy driven by cost, risk, and PoI/PoUW-powered reputation.

***

### 4. Snapshot Summary

Use this block for high-level roadmaps:

* **v0 – Bare LLM API**\
  Single-shot completions; no shared contracts; redundancy and validation hand-rolled per app.
* **v1 – First `/delegate` & `/validate`**\
  Prompt-oriented, single-session endpoints; early agent flows; simple “do this / check this” semantics.
* **v2 – Today: Contract-first, policy-aware router**\
  Structured payloads for `/delegate` and `/validate`, explicit verdict contract, tiers, and basic redundancy inside a session; unified across REST, MCP, A2A, x402.
* **v3 – Next: Explicit consensus-aware router**\
  1/3/5 replicas as policy; standardized `consensus` blocks in requests/responses; explicit redundancy knobs and consensus metadata across `/delegate`, `/validate`, and `factcheck`.
* **v4 – Later: Programmable trust fabric**\
  Pluggable aggregation strategies, reusable validation artifacts, and dynamic redundancy tied to PoI/PoUW, reputation, and risk – making `/delegate` + `/validate` the core “intelligent delegation” layer for agents.