search

ACP Integration

Bardiel is designed to be a first-class service agent inside ACP: it executes jobs, validates results, and (optionally) arbitrates disputes for buyers and sellers.

This page explains how ACP jobs map into Bardiel’s request envelope and how ACP should interpret Bardiel’s responses.

hashtag
Overview

In ACP, Bardiel plays three roles:

  • Execution Oracle (Delegation-as-a-Service) Run the job on Cortensor with a given policy (fast, safe, oracle, adaptive) and return a trusted result.

  • Validation Oracle (Validation-as-a-Service) Check a claimed result from a seller or another agent and return a verdict: VALID, INVALID, RETRY, or NEEDS_SPEC.

  • Dispute Oracle (Arbitration-as-a-Service) When a buyer files a dispute, Bardiel examines the spec, claimed output, and Cortensor consensus and returns a settlement-grade verdict that ACP can use as one of its decision signals.

All three modes share the same logical envelope described in Technical Architecture → Agent Surfaces:

  • mode: delegation | validation | arbitration

  • task: task description and input payload

  • policy: fast | safe | oracle | adaptive

  • context: optional domain / risk / latency hints

  • metadata: IDs and correlation fields for ACP / Virtual

ACP does not need to know about Cortensor internals (sessions, miners, PoI/PoUW); Bardiel handles that under the hood.

hashtag
Mapping ACP Jobs to Bardiel Tasks

An ACP job typically has:

  • a spec (what should be done and constraints)

  • an input (problem data)

  • a seller (who produced a result, if any)

  • an optional claimed result (for validation / arbitration)

  • a job type / category and price

Bardiel expects:

  • task.spec – the job spec / contract description

  • task.input – the main input or prompt

  • task.type – category like summarization, qa, classification, tool_call, etc.

  • task.claimed_result – seller output, when validating or arbitrating

  • task.dispute_context – extra metadata when a dispute exists

ACP gateways or Workers are responsible for mapping their internal job schema into this envelope.

hashtag
Execution Flow: Delegation in ACP

Goal: ACP wants Bardiel to fully execute a job on Cortensor and return a trusted result (no external seller involved, or seller = “Bardiel/infra”).

  1. Buyer submits a job to ACP with spec and input.

  2. ACP (or a Virtual Worker) builds a Bardiel request such as:

    { "mode": "delegation", "policy": "safe", "task": { "type": "summarization", "spec": "Summarize the document in <= 5 bullets, no hallucinations.", "input": "...raw document text..." }, "context": { "domain": "general_qa", "risk_level": "medium", "latency_sensitivity": "normal", "surface": "ACP" }, "metadata": { "acp_job_id": "job-123", "buyer_id": "buyer-abc" } }

  3. Bardiel:

    • chooses models, redundancy, and a policy tier implementation for safe

    • uses Delegation tooling (web fetch / spec normalizer / schema checks where relevant)

    • runs the job on Cortensor through the Router

    • interprets PoI/PoUW and other signals

  4. Bardiel returns:

    { "status": "VALID", "result": { "summary": [ "bullet 1", "bullet 2", "bullet 3" ] }, "confidence": 0.92, "evidence": { "tier": "safe", "redundancy": 3, "poi_cluster_agreement": 0.88 }, "retry_instructions": null, "trace_id": "bardiel-trace-job-123", "bardiel_version": "v0.1.0" }

  5. ACP interprets status = VALID as “delegation successful” and proceeds with its own payout / accounting logic (often treating Bardiel as the “seller of record” for infra-backed jobs).

hashtag
Validation Flow: Pre-Settlement Checks

Goal: ACP wants Bardiel to check a seller’s claimed result before settling the job.

  1. Seller submits a result for an existing ACP job.

  2. Before evaluating or paying out, ACP (or a Worker) builds a Bardiel request:

    { "mode": "validation", "policy": "safe", "task": { "type": "summarization", "spec": "Summarize the document in <= 5 bullets, no hallucinations.", "input": "...raw document text...", "claimed_result": { "summary": [ "seller bullet 1", "seller bullet 2", "seller bullet 3" ] } }, "context": { "domain": "general_qa", "risk_level": "medium", "latency_sensitivity": "normal", "surface": "ACP" }, "metadata": { "acp_job_id": "job-123", "buyer_id": "buyer-abc", "seller_id": "seller-xyz" } }

  3. Bardiel chooses a validation pattern (schema checks, PoI/PoUW consensus runs, etc.) and runs validation on Cortensor.

  4. Bardiel returns something like:

    { "status": "RETRY", "confidence": 0.84, "evidence": { "reason": "consensus_outlier", "missing_entities": ["Competitor A", "Competitor B"], "tier": "safe" }, "retry_instructions": "Include competitors A and B and keep the summary under 5 bullets.", "trace_id": "bardiel-trace-job-123-val1", "bardiel_version": "v0.1.0" }

  5. ACP uses status plus retry_instructions to drive its logic:

    • VALID

      • Seller’s output is acceptable. ACP can proceed to run its own evaluator stack and then settle/payout normally.

    • INVALID

      • Seller’s output is clearly wrong or malformed. ACP may:

        • reject immediately, or

        • offer a retry window, depending on market rules.

    • RETRY

      • Structure is okay but content is weak. ACP can:

        • request a revision from the seller with instructions, or

        • route the job back to an open pool.

    • NEEDS_SPEC

      • The spec is the real problem (too vague/contradictory). ACP should prompt the buyer (and possibly seller) to clarify the job before deciding.

In the Virtual ecosystem, ACP’s own evaluators and pipelines remain the primary authority for settlement; Bardiel validation acts as a high-signal pre-settlement oracle that reduces junk and edge cases before ACP’s main logic runs.

hashtag
Dispute Flow: Arbitration in ACP

Goal: A buyer and seller disagree after submission; ACP wants an additional, neutral oracle decision.

In ACP, Bardiel Arbitration is optional and acts as a secondary oracle. ACP still owns:

  • the final settlement decision

  • slashing / penalties

  • reputation changes

A typical flow:

  1. Buyer files a dispute for job job-123.

  2. ACP collects:

    • job spec and input

    • seller’s final claimed result

    • any prior Bardiel validation outputs, evaluator scores, or logs

  3. ACP (or a Worker) builds an arbitration request:

    { "mode": "arbitration", "policy": "oracle", "task": { "type": "text_generation", "spec": { "must_include_keyword": "X", "max_length": 30 }, "input": { "prompt": "Generate 10 product names that obey the spec." }, "claimed_result": { "names": [ "... seller output ..." ] }, "dispute_context": { "buyer_id": "buyer-123", "seller_id": "seller-456", "market_id": "acp-market-1" } }, "context": { "domain": "naming", "risk_level": "high", "latency_sensitivity": "low", "surface": "ACP" }, "metadata": { "acp_job_id": "job-123", "dispute_id": "disp-987" } }

  4. Bardiel escalates to oracle-grade behavior (higher redundancy, stricter thresholds), runs arbitration on top of Cortensor’s consensus and spec checks, and returns something like:

    { "status": "SELLER_INVALID", "confidence": 0.94, "evidence": { "constraint_violations": [ "3/10 names missing keyword X", "2/10 names exceed 30 characters" ], "consensus_alignment": 0.21, "tier": "oracle" }, "retry_instructions": null, "trace_id": "bardiel-trace-disp-987", "bardiel_version": "v0.1.0" }

  5. ACP uses this as one of its primary signals when resolving the dispute:

    • SELLER_VALID

      • ACP can treat seller as correct and proceed to payout, potentially updating buyer/seller reputations accordingly.

    • SELLER_INVALID

      • ACP may refund or partially refund the buyer, deny payout, and (if configured) apply slashing or reputation penalties to the seller.

    • INCONCLUSIVE

      • ACP cannot lean on Bardiel alone and may apply fallback rules:

        • manual review,

        • split refund,

        • or other market-specific policies.

Bardiel never moves funds directly. ACP remains the settlement engine; Bardiel simply provides a settlement-grade judgment.

hashtag
Status Mapping for ACP

ACP should treat Bardiel statuses as high-signal hints, not absolute law. A typical mapping:

  • Delegation

    • VALID → proceed with result, finalize internal evaluator pipeline, settle as infra-backed job.

    • RETRY / NEEDS_SPEC → decide whether to retry job or prompt the buyer to refine spec.

  • Validation

    • VALID → allow job to move into ACP evaluators and normal settlement.

    • INVALID → likely reject or request revision from seller.

    • RETRY → ask seller for targeted revision using retry_instructions.

    • NEEDS_SPEC → treat job as underspecified, prompt buyers/sellers to refine, potentially pause settlement.

  • Arbitration

    • SELLER_VALID → treat as strong evidence seller did the job; resolve toward payout.

    • SELLER_INVALID → treat as strong evidence seller failed; resolve toward buyer-friendly outcome.

    • INCONCLUSIVE → fall back to ACP-specific dispute rules or human / governance input.

Exact policies are up to ACP markets and governance; Bardiel is designed to be configurable, not prescriptive.

hashtag
Recommended Patterns

  • Use Delegation for infra-backed jobs where ACP itself wants Cortensor + Bardiel to act as “the seller”.

  • Use Validation as a pre-settlement filter for:

    • higher-value jobs,

    • risky categories, or

    • markets that want strong quality guarantees.

  • Use Arbitration for explicit disputes only, and treat Bardiel as:

    • a secondary oracle in Virtual, and

    • a potential primary dispute oracle in ERC-8004-style markets (when those markets opt in).

hashtag
Summary

  • Bardiel gives ACP a unified way to execute, validate, and arbitrate jobs on top of Cortensor.

  • ACP mappings are straightforward:

    • jobs → Bardiel task envelopes,

    • Bardiel statuses → ACP settlement logic.

  • ACP remains the source of truth for payments and reputation; Bardiel is the trust and execution oracle that helps ACP make better decisions with verifiable evidence.

PreviousSessions, Billing & x402NextData & Telemetry

Last updated