> 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/data-and-telemetry.md).

# Data & Telemetry

Bardiel is intentionally **data-informed**.

To improve its delegation, validation, factcheck, and arbitration decisions over time, Bardiel collects and aggregates carefully chosen signals about tasks, outcomes, and performance across **Base, Virtual, ERC-8004, and other onchain agent ecosystems**.

This page describes what Bardiel logs conceptually and how that data is used.

> Note: exact logging policies may differ between testnet and mainnet and will respect privacy, security, and regulatory constraints.

***

### What Bardiel Logs

At a high level, Bardiel records:

#### 1. Task Metadata

* calling surface (for example `BASE`, `GAME`, `ACP`, `ERC8004`, or another agent integration)
* task type (`summarize`, `classify`, `json_tool_call`, `text_generation`, `factcheck`, etc.)
* selected policy (`fast`, `safe`, `oracle`, `adaptive`)
* optional anonymized identifiers for:
  * calling agent or app
  * market, registry, protocol, or integration surface

#### 2. Decision Metadata

* mode (`delegation`, `validation`, `arbitration`)
* final status, such as:
  * `VALID`, `INVALID`, `RETRY`, `NEEDS_SPEC`
  * `SELLER_VALID`, `SELLER_INVALID`, `INCONCLUSIVE`
* confidence score (normalized 0–1)
* whether escalation occurred (for example `adaptive` escalating to a higher tier)

#### 3. Cortensor Interaction Signals

Summarized trust signals returned from Cortensor, such as:

* redundancy (how many miners were used)
* PoI agreement levels (for example cluster agreement, outlier flags)
* PoUW ranges (for example minimum / median / maximum usefulness scores)
* validator outcomes (for example integrity violations, commit/reveal mismatches)

#### 4. Performance Metrics

* latency (per tier, per task type, per surface)
* error rates (timeouts, router errors, invalid requests)
* cost estimates (tokens, gas, COR usage, or payment-path usage where applicable)

#### 5. Arbitration-Specific Data

For arbitration flows, Bardiel additionally logs:

* dispute outcome (`SELLER_VALID`, `SELLER_INVALID`, `INCONCLUSIVE`)
* high-level reasons (constraint violation, consensus outlier, under-specified spec, etc.)
* surface and market-level tags, for example:
  * Base-native app or market identifier
  * ACP market ID
  * ERC-8004 registry / validator ID

This helps operators understand dispute patterns across different ecosystems and workflows.

Where possible, Bardiel favors compact, derived features over full raw payloads.

***

### What Bardiel Does *Not* Log by Default

By default, Bardiel does **not** intend to store:

* long-form raw content beyond what is needed for:
  * immediate processing, and
  * short-lived debugging windows (configurable)
* secrets or credentials accidentally embedded in payloads (keys, tokens, private data, etc.)
* full per-miner traces, unless explicitly enabled for debugging

The goal is to collect enough data for learning and observability **without** turning Bardiel into a general-purpose data warehouse.

***

### How the Data Is Used

Bardiel uses its telemetry for three main purposes:

#### 1. Tuning Policies and Thresholds

* adjust PoI / PoUW thresholds per task type
* refine when `adaptive` escalates to `safe` or `oracle`
* set better defaults per surface (for example Base-native app flows vs GAME vs ACP vs ERC-8004-compatible flows)

#### 2. Improving Scoring Models

* design and refine rubric-style scoring for usefulness and coverage
* distinguish “easy” vs “hard” workloads
* identify new categories that need custom logic (for example highly regulated content, governance actions, or high-risk financial tasks)

#### 3. Understanding System Behavior

Across Bardiel + Cortensor:

* identify disagreement hotspots
* track miner pool performance (via Cortensor metrics)
* detect regressions in latency or cost
* spot suspicious patterns (for example repeated near-threshold failures from a specific app, market, registry, or integration)

***

### Telemetry Views (Conceptual)

Over time, Bardiel should surface aggregated views such as:

#### Per-Tier Metrics

* average latency and cost for `fast`, `safe`, `oracle`, `adaptive`
* escalation rates (how often `adaptive` escalates)
* disagreement rates per tier

#### Per-Task-Type Metrics

* which task types most often return `RETRY` or `NEEDS_SPEC`
* which categories most frequently require arbitration
* per-task-type distributions of confidence scores

#### Per-Market / Integration Metrics

For **Base-native apps and agent workflows**:

* validation frequency before state-changing actions
* disagreement rates on delegated or verified tasks
* typical policy tiers used for different classes of workflows

For **ACP**:

* dispute frequency and resolution patterns per market
* proportion of `SELLER_INVALID` decisions
* validation coverage before settlement

For **ERC-8004-compatible systems**:

* how often Bardiel is called as a validator / oracle per registry
* disagreement rates versus other validators where applicable
* typical tiers used for different classes of tasks

These views are intended for:

* Base-native app and protocol builders
* Virtual core developers
* ACP markets and integrators
* ERC-8004 registry / protocol operators
* eventually, community / governance where appropriate

***

### Privacy & Retention Principles (Draft)

High-level principles for Bardiel’s data handling:

* **Minimize**\
  Log metrics and derived features, not unnecessary raw data.
* **Anonymize where possible**\
  Prefer hashes or pseudonymous identifiers over direct end-user IDs.
* **Bounded retention**
  * keep detailed logs only for a limited window (for debugging and analysis)
  * keep long-lived aggregates and statistics for trend tracking
* **Environment-aware**\
  Treat testnet and mainnet differently:
  * testnets allow more experimentation and logging
  * mainnet logging is more conservative and policy-driven

Exact policies (durations, fields, anonymization rules) will be documented as Bardiel approaches broader production usage and may be subject to legal and compliance review.

***

### Relationship to `trace_id`

Every Bardiel response includes a `trace_id`.

This enables:

* correlating a specific decision with internal logs
* joint debugging across ecosystem ↔ Bardiel ↔ Cortensor
* targeted inspection without scanning unrelated traffic

Examples include:

* Base app ↔ Bardiel ↔ Cortensor
* Virtual / ACP ↔ Bardiel ↔ Cortensor
* ERC-8004-compatible registry or market ↔ Bardiel ↔ Cortensor

In most applications, `trace_id` should be logged alongside application-level IDs to make support and debugging easier.

***

In summary, Bardiel uses data to get **smarter and safer** over time, while aiming to minimize unnecessary retention of raw content and preserve privacy wherever possible.