# /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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.cortensor.network/community-and-ecosystem/products-and-agents/corgent/delegate-and-validate-versions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.