search

/delegate & /validate Versions

Status: v2 is Bardiel’s default surface on top of the Cortensor Router. v3 and v4 are roadmap stages that add explicit consensus and programmable trust, adopted by Bardiel as they roll out at the router layer.

hashtag
1. What /delegate and /validate Are For (Bardiel)

From Bardiel’s perspective, there are two core Cortensor Router primitives it builds on:

  • /delegate – Execution primitive

    • “Send this job to the Cortensor network under a specific policy.”

    • Offloads a bounded workflow (models, tools, routing, retries, redundancy) from Bardiel to Cortensor.

    • Returns not just final text, but (in v2+) structured evidence about how work was done — steps, tools, configs — that Bardiel can interpret and compress into a verdict.

  • /validate – Safety / trust primitive

    • “Before I act, pay, or settle, 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 Bardiel:

  • A cloud-like execution fabric to offload heavy work (/delegate) at agent-economy scale (the “AWS for agents” part).

  • A neutral trust checkpoint (/validate) to turn messy AI behavior into clear, programmable decisions for Virtual, ACP, and ERC-8004 markets.

Bardiel’s Delegation-as-a-Service, Validation-as-a-Service, and Arbitration-as-a-Service are all built on these router primitives.

hashtag
2. Current Surfaces Bardiel Uses (v1 + v2)

Bardiel sits on top of the Cortensor Router and inherits its versioned surfaces:

  • v1 (prompt-oriented, legacy)

    • 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 flows

      • prompt → judgment flows

      • early Bardiel experiments and smoke tests

  • v2 (contract-first, policy-aware) – Bardiel’s current default

    • POST /api/v2/delegate – payloads shaped around:

      • objective, input, execution, policy, plus optional tools / workflow / metadata

    • POST /api/v2/validate – payloads shaped around:

      • claim, policy, context, plus optional actor / metadata

    • Enforces clear separation between:

      • What is being asked (objective / claim)

      • How it should run (execution)

      • Under which guarantees (policy / tier / timeouts / basic redundancy)

All four combinations (/delegate v1/v2, /validate v1/v2) exist at the router, but:

  • Bardiel targets v2 as the main surface for:

    • GAME Workers / Functions

    • ACP integration hooks

    • future ERC-8004 validator / oracle endpoints (often via MCP/x402)

  • v1 remains supported as a simpler, prompt-oriented fallback for specific use cases and testing.

hashtag
3. Router Evolution – v0 → v4 (How Bardiel Maps Onto It)

This section mirrors Cortensor’s router roadmap but framed as: “What does this mean for Bardiel?”

v0 – Bare LLM API (Pre-Router Era)

  • Single-shot /completion style calls to one model or one session.

  • No explicit distinction between:

    • execution vs validation

    • policy vs payload

  • Redundancy and checking are hand-rolled in the app:

    • custom retries

    • ad-hoc “LLM judge” prompts

    • no shared verdict contract

Bardiel impact: This is essentially “pre-Bardiel” — useful for prototypes, but not enough for Bardiel’s role as a shared trust and execution layer.

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

  • Router introduces the two primitives as separate endpoints:

    • /delegate → “do this for me”

    • /validate → “check this for me”

  • Still prompt-centric:

    • task_request_input, task_result_output

    • light hints (task_domain, task_type, evaluation_mode)

  • Runs against a single session_id:

    • any miner redundancy is configured inside that session

  • Good for:

    • early Corgent / Bardiel prototypes

    • simple “send → answer” and “send → judgment” flows

Bardiel impact:

  • v1 is what Bardiel can use for simple text jobs and early ACP/GAME smoke tests.

  • Bardiel still has to infer a lot from raw prompts; there’s no strong contract yet for tasks, policies, or verdicts.

  • Bardiel v0.x may still support v1 for backwards compatibility, but v2 is where it becomes a serious trust agent.

v1 remains supported as the simpler legacy path Bardiel can fall back to when needed.

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

This is the current default for new Bardiel 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, tools, timeouts.

      • policy – tier (fast, safe, oracle, sometimes balanced), latency/timeout bounds, basic redundancy, safety rules.

    • /validate v2:

      • claim – what is being asserted (summary, classification, tool output, trade, plan step, etc.).

      • policy – tier, redundancy level, rules (non-hallucination, consistency, schema compliance, etc.).

      • context – task/app metadata that matters for the verdict.

  • Verdict contract for /validate:

    • VALID, INVALID, RETRY, NEEDS_SPEC plus reasons and evidence.

    • Bardiel can map these directly onto ACP / GAME / ERC-8004 flows.

  • Policy & tiers become first-class:

    • tier encodes trust vs cost tradeoffs:

      • fast (low latency, minimal redundancy)

      • safe (default high-trust)

      • oracle (higher redundancy / stricter checks)

      • adaptive (start cheap, escalate when needed)

    • Timeouts and basic redundancy move from ad-hoc logic into structured policy.

  • Router view is still mostly single-session:

    • Bardiel hits one session_id.

    • That session may fan out to miners internally, but explicit consensus is still a session-level concern, not a router-level knob.

  • Unified surfaces:

    • v2 is available across:

      • REST, MCP, A2A/agent-cards, x402 (pay-before-run).

Bardiel impact:

  • v2 is the baseline Bardiel depends on for its Delegation, Validation, and Arbitration surfaces.

  • Bardiel’s own Policy Engine & Tiers page maps directly to router-level policy.tier.

  • Bardiel’s agent-facing envelopes (mode/task/policy/context/metadata) are thin wrappers over /delegate and /validate v2.

Mental model: v2 gives Bardiel solid execution and verification primitives with contracts and tiers, but consensus is mostly inside one session.

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

Goal: turn redundancy + consensus into explicit, configurable knobs at the router layer for /delegate, /validate, and factcheck. Bardiel then becomes a first-class “consensus consumer”.

Consensus in the request (router-level, conceptual):

  • replicas: 1 / 3 / 5

  • session_pool: list of candidate session_ids (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.

  • replicas = 3 or 5:

    • router fans the same logical request to 3 or 5 independent sessions,

    • each with its own miner slice and infra,

    • then aggregates results and returns:

      • a final answer/verdict, plus

      • per-replica evidence + agreement metrics.

Applies to:

  • /delegate – redundant execution runs.

  • /validate – redundant verification runs.

  • factcheck – generalized redundant reality checks.

Consensus in the response (conceptual):

  • replicas – how many runs executed.

  • agreement – fractional agreement (e.g. 0.67 for 2/3).

  • verdicts – per-replica verdicts or statuses.

  • strategy – aggregation strategy used.

  • confidence – derived consensus confidence.

Bardiel impact:

  • Bardiel’s “fast/safe/oracle/adaptive” tiers can map onto:

    • replicas (1/3/5),

    • aggregation strategy,

    • and how to react to disagreement.

  • Bardiel can surface:

    • consensus metadata in its own evidence block,

    • and use it internally for Arbitration-as-a-Service and higher-stakes ACP / ERC-8004 flows.

  • This is where Bardiel becomes more than a single-run judge: it becomes a consensus-aware trust agent.

v3 tagline (Bardiel view): “Agent-ready consensus, exposed as a policy.”

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.

Key ideas at the router layer:

  • Pluggable aggregation strategies

    • aggregation: "majority", "weighted", "median_of_means", "model_ensemble", etc.

    • weight_by: "reputation", "stake", "latency", "cost".

  • Reusable validation / fact artifacts

    • High-value /validate or factcheck calls emit artifacts:

      • id, kind, scope, ttl

    • Other flows can reference these instead of re-running full consensus.

  • Cost-aware, dynamic redundancy

    • Low-risk paths auto-downshift redundancy over time.

    • High-risk paths auto-upgrade to more replicas / stricter rules.

  • Deep integration with PoI/PoUW

    • Tied into miner reputation, slashing, and optional on-chain anchoring.

Bardiel impact:

  • Bardiel can:

    • choose aggregation strategies based on agent and market policies,

    • treat router-level validation artifacts as long-lived trust objects,

    • expose references (IDs/hashes) in its evidence field so ACP and ERC-8004 flows can reuse them.

  • Over time, Bardiel becomes:

    • both a user of router-level trust fabric,

    • and a curator of long-horizon trust artifacts for Virtual and agent ecosystems.

v4 tagline (Bardiel view): “Programmable, reusable trust for multi-agent systems.”

hashtag
4. Snapshot Summary (Bardiel-Focused)

Use this block in Bardiel roadmaps to summarize how it maps to router versions:

  • v0 – Bare LLM API Single-shot completions; no shared contracts; redundancy and validation are app-specific. Pre-Bardiel.

  • v1 – First /delegate & /validate Prompt-oriented, single-session endpoints; early Bardiel prototypes; 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/x402. Bardiel v0.x and v0.2+ are built primarily on this.

  • v3 – Next: Explicit consensus-aware router 1/3/5 replicas as policy; standardized consensus blocks in requests/responses; explicit redundancy + consensus metadata across /delegate, /validate, and factcheck. Bardiel v0.5+ adopts this for higher-stakes validation and arbitration.

  • 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 Bardiel and other agents.

hashtag
Appendix: Further Reading

For deeper context on how this aligns with Cortensor’s broader vision:

  • “AWS for the Agent Economy” – turning Cortensor into cloud-style infra for agents.

  • “AWS for Agents: The Cloud Behind the Agent Economy” – how /delegate generalizes “send this to the network.”

  • “Intelligent AI Delegation Meets /delegate” – how Cortensor’s surfaces line up with Google DeepMind’s Intelligent AI Delegation framework.

(These are described in Cortensor’s docs and X posts; Bardiel builds directly on the same primitives, but focuses on Virtual, ACP, and ERC-8004 use cases.)

PreviousCore PrimitivesNext/delegate & /validate v3 Spec - Consesus

Last updated