Data & Telemetry

Bardiel is intentionally data-informed.

To improve its delegation, validation, and arbitration decisions over time, Bardiel collects and aggregates carefully chosen signals about tasks, outcomes, and performance.

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 and regulatory constraints.

---

What Bardiel Logs

At a high level, Bardiel records:

1. Task Metadata

• calling surface (for example GAME, ACP, ERC8004)

• task type (summarize, classify, json_tool_call, text_generation, etc.)

• selected policy (fast, safe, oracle, adaptive)

• optional anonymized identifiers for:

  • calling agent

  • ACP market or ERC-8004 registry / integration

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 → oracle)

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 (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 where applicable)

5. Arbitration-Specific Data

For arbitration flows (ACP or ERC-8004–style disputes), 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: ACP market ID, ERC-8004 registry / validator ID

  • so Virtual and ERC-8004 operators can understand dispute patterns

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, 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, GAME vs ACP vs ERC-8004)

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 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 segment, market, or registry)

---

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 ACP:

  • dispute frequency and resolution patterns per market

  • proportion of SELLER_INVALID decisions

  • validation coverage before settlement

• for ERC-8004:

  • how often Bardiel is called as a validator/oracle per registry

  • disagreement rates vs other validators

  • typical tiers used for different classes of tasks

These views are intended for:

• Virtual core developers

• large ACP markets and Virtual 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 mainnet 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 Virtual / ACP / ERC-8004 ↔ Bardiel ↔ Cortensor

• targeted inspection without scanning unrelated traffic

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.