> For the complete documentation index, see [llms.txt](https://docs.bardiel.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bardiel.tech/technical-architecture/acp-integration.md).

# ACP Integration

Bardiel is designed to be a first-class service agent inside **ACP**: it can execute jobs, validate results, and, where markets choose to use it, provide an additional arbitration signal for buyers and sellers.

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

ACP is one of Bardiel’s deepest integrations inside the **Virtual** ecosystem, but the same underlying trust and execution model also supports **Base**, **ERC-8004-compatible systems**, and other onchain agent ecosystems.

***

### Overview

Inside ACP, Bardiel can play 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 can examine the spec, claimed output, and Cortensor consensus and return a **settlement-grade verdict** that ACP may 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 such as sessions, miners, or PoI / PoUW. Bardiel handles that under the hood.

***

### Mapping ACP Jobs to Bardiel Tasks

An ACP job typically has:

* a **spec** (what should be done and under what 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 such as `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.

***

### Execution Flow: Delegation in ACP

**Goal:** ACP wants Bardiel to fully execute a job on Cortensor and return a trusted result.

This is useful when ACP itself wants Bardiel + Cortensor to act as the execution surface, rather than relying on an outside seller.

1. A buyer submits a job to ACP with a 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 concrete implementation of the `safe` tier
   * uses Delegation tooling such as web fetch, spec normalization, or schema checks where relevant
   * runs the job on Cortensor through the Router
   * interprets PoI / PoUW and other trust signals
4. Bardiel returns something like:

   { "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 execution provider for that job.

***

### Validation Flow: Pre-Settlement Checks

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

This is where Bardiel acts as a **pre-settlement trust layer**: it filters obvious errors, weak outputs, or underspecified jobs before ACP’s main evaluator / settlement logic runs.

1. A 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** such as schema checks, PoI / PoUW consensus runs, or other template-driven checks 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 output is acceptable
     * ACP can proceed to run its own evaluator stack and then settle normally
   * `INVALID`
     * seller 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 or route the job back to an open pool
   * `NEEDS_SPEC`
     * the spec is the real problem
     * ACP should prompt the buyer, and possibly the seller, to clarify the job before deciding

In the **Virtual ecosystem**, ACP’s own evaluators and dispute logic 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.

***

### Dispute Flow: Arbitration in ACP

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

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

* the final settlement decision
* slashing or penalties
* reputation changes

A typical flow:

1. A buyer files a dispute for job `job-123`.
2. ACP collects:
   * the job spec and input
   * the 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, with higher redundancy and 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 the seller as correct and proceed toward payout
   * `SELLER_INVALID`
     * ACP may refund or partially refund the buyer, deny payout, and apply slashing or reputation penalties if configured
   * `INCONCLUSIVE`
     * ACP cannot lean on Bardiel alone and may fall back to:
       * manual review
       * split refund
       * other market-specific rules

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

***

### Status Mapping for ACP

ACP should treat Bardiel statuses as **high-signal hints**, not absolute law.

A typical mapping is:

#### Delegation

* `VALID`
  * proceed with result
  * finalize internal evaluator pipeline
  * settle as an infra-backed job
* `RETRY` / `NEEDS_SPEC`
  * decide whether to retry the job or prompt the buyer to refine the spec

#### Validation

* `VALID`
  * allow the job to move into ACP evaluators and normal settlement
* `INVALID`
  * likely reject or request revision from the seller
* `RETRY`
  * ask the seller for targeted revision using `retry_instructions`
* `NEEDS_SPEC`
  * treat the job as underspecified
  * prompt buyers and sellers to refine it
  * potentially pause settlement

#### Arbitration

* `SELLER_VALID`
  * treat as strong evidence the seller did the job
  * resolve toward payout
* `SELLER_INVALID`
  * treat as strong evidence the seller failed
  * resolve toward a buyer-friendly outcome
* `INCONCLUSIVE`
  * fall back to ACP-specific dispute rules, governance, or human review

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

***

### Recommended Patterns

* Use **Delegation** for infra-backed jobs where ACP itself wants Cortensor + Bardiel to act as the execution provider.
* Use **Validation** as a **pre-settlement filter** for:
  * higher-value jobs
  * risky categories
  * markets that want stronger quality guarantees
* Use **Arbitration** for explicit disputes only, and treat Bardiel as:
  * a **secondary oracle** in Virtual / ACP
  * a potential **primary dispute oracle** in other ecosystems, such as Base-native or ERC-8004-compatible markets, when those markets opt in

***

### Summary

* Bardiel gives ACP a unified way to **execute**, **validate**, and **optionally 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