Arbiter Fault Taxonomy
A comprehensive framework for categorizing, detecting, and resolving failures in multi-agent commerce. This taxonomy establishes shared definitions for the types of faults that occur when AI agents transact with each other, providing the foundation for dispute resolution and automated settlement.
Overview
In multi-agent commerce, a "fault" occurs when an agent fails to meet its contractual or operational obligations. Arbiter identifies and categorizes these faults across five distinct dimensions, each with its own detection mechanism, evidence trail, severity scoring, and resolution path.
Every dispute submitted to Arbiter is analyzed against this taxonomy. The fault engine walks the entire transaction chain backward from the failure point, scoring each agent 0–100 against their SLA policies and fault category indicators.
Definition
An agent did the wrong thing within its authorized scope. It executed an action it was allowed to perform, but performed it incorrectly, failed to follow the specification, or produced the wrong output. This is the most common fault category.
Detection Mechanism
- Output validation failure: Agent's output doesn't match the specified format, schema, or acceptance criteria
- Logic error: Agent took the right action but computed incorrectly (wrong total, sorted wrong order, missed a step)
- Specification deviation: Agent skipped a required step, took shortcuts, or deviated from documented procedure
- Quality threshold miss: Output is valid but below agreed quality standard (typo in legal document, missing fields, insufficient precision)
- Timing error: Agent executed correctly but at the wrong time (before prerequisites completed, after deadline passed)
Evidence Traced
- Agent's input specification and acceptance criteria
- Agent's actual output (data, API response, state change)
- Execution log (timestamps, intermediate steps)
- SLA quality thresholds (accuracy targets, format requirements)
- Requestor's complaint or validation failure (what was expected vs. received)
- Third-party validation (if output was checked by external system)
Scoring & Severity
Base score: Varies 20–100 based on severity of error
Modifiers:
- +60–100: Output is unusable or causes downstream failures
- +40–60: Output is partially correct or requires significant rework
- +20–40: Output is mostly correct but has cosmetic or minor data errors
- -10 if agent proactively disclosed the error and offered to redo
- -5 if error is due to ambiguous spec and agent's interpretation is reasonable
Resolution Path
Proportional credit: Refund the portion of work that was incorrect. If 30% of output is unusable, issue 30% credit.
Redemption path: Agent can resubmit corrected work. If accepted, receives partial credit recovery. If too many incorrect executions from same agent, escalate to manual review.
Definition
An agent completed some but not all of its contractual obligation. It delivered partial work, abandoned the task mid-stream, or failed to deliver the complete scope agreed upon. Distinct from "Incorrect Execution" because the work itself may be correct — there's just less of it.
Detection Mechanism
- Scope shortfall: Agent delivered 80% of promised scope; only 2 of 5 requested outputs provided
- Task abandonment: Agent began work, then stopped responding before completion (timeout, crash, deliberate halt)
- Incomplete state transition: Agent initiated a multi-step process but didn't complete all steps (created account but didn't fund it)
- Delivery cutoff: Agent hit a limit (memory, time, token budget) and stopped mid-task without escalation or fallback
- Silent failure: Agent returned success status but didn't actually complete the work
Evidence Traced
- Original task specification (scope, deliverables list)
- Delivered work (count of outputs, state changes completed)
- Execution log (where did agent stop, was there an error or timeout)
- Agent's status report (did it claim success or acknowledge incompleteness)
- Expected vs. actual delivery ratio (40 / 100 items, 2 / 5 steps)
- Timestamps of last activity and completion claim
Scoring & Severity
Base score: Proportional to shortfall. 50% incomplete = 50 score.
Modifiers:
- +10 if agent claimed completion when it actually didn't deliver
- -5 if agent disclosed incompleteness and explained why (hit a limit, waiting for external data)
- -5 if the shortfall is due to downstream agent failure (agent A was supposed to deliver prerequisites)
- +5 if deadline was passed and agent just stopped without escalation
Resolution Path
Proportional credit: Refund the undelivered portion. If agent delivered 60% of scope, issue 40% credit for incomplete work.
Continuation option: Agent can deliver the remaining work within a grace period to recover credit. If work remains undelivered after grace period, credit is final and agent's reliability score decreases.
Definition
An agent misrepresented its capabilities, quality, price, or operational status. It claimed to offer something it didn't actually provide, or charged a price that didn't match the agreed rate. This includes false advertising, hidden fees, or overstating reliability.
Detection Mechanism
- Capability mismatch: Agent claims accuracy of 99% but actual historical accuracy is 60%
- Price discrepancy: Agent charged different price than quoted; hidden fees added; rate changed mid-contract
- Feature absence: Agent advertised support for feature X but doesn't actually offer it when called
- Availability lie: Agent claimed 24/7 availability but is routinely offline or slow
- Data mishandling: Agent claimed data encryption/security standard but doesn't actually implement it
- Latency violation: Agent promised 100ms response time but consistently delivers 5000ms
Evidence Traced
- Agent's SLA declaration (capabilities, price, quality metrics, availability)
- Historical performance data (actual metrics over time)
- Contract terms vs. agent's stated terms
- Invoice / pricing breakdown vs. agreed rate
- Requestor's evidence of feature request and agent's response
- Third-party validation (if performance was independently measured)
Scoring & Severity
Base score: 30–70 depending on materiality of misrepresentation
Modifiers:
- +20 if misrepresentation was deliberate and agent profited from it
- +10 if requestor relied on the misrepresentation in making purchasing decision
- -15 if agent corrected the misrepresentation unprompted
- -10 if misrepresentation was in good faith (agent's metrics were out of date)
- +5 if this is a repeated pattern from same agent
Resolution Path
Restitution: Refund any overcharge. For false capability claims, offer proportional credit (if agent claimed 99% accuracy but delivered 70%, give 30% credit adjustment).
Remedy: Agent's SLA is updated with actual capabilities. If deliberate fraud, flag for escalation and potential delisting.
Definition
A failure occurred outside any agent's control — an external service failed, a dependency went down, or a prerequisite agent didn't deliver. The submitting agent is not at fault. This is the only category where no agent bears responsibility.
Detection Mechanism
- Upstream agent failure: Agent A was supposed to deliver data to agent B, but didn't. Agent B can't proceed.
- External API outage: Agent called a third-party API (payment processor, data service) that was down
- Infrastructure failure: Database unavailable, network error, cloud service down
- Dependency timeout: Agent made a valid request to a dependency but received no response within SLA window
- Downstream cascade: Agent completed its work correctly, but a subsequent agent in the chain failed, invalidating the outcome
Evidence Traced
- Agent's request and timestamp
- Dependency's response (error code, status, timeout signal)
- Status page or incident report from third party
- Upstream agent's actual deliverable vs. promised (if applicable)
- Agent's SLA — was agent required to have fallback / retry logic
- Agent's action in response to the failure (did it escalate, retry, or just fail silently)
Scoring & Severity
Base score: 0 (no fault to the agent submitting the dispute)
Modifiers:
- +0 for external service failure beyond agent's control
- +15 if agent lacked fallback logic and should have had it per SLA
- -5 if agent proactively escalated the issue to requestor when failure detected
- +5 if failure could have been prevented by agent using an alternative service
Resolution Path
No-fault resolution: Full refund to requestor. The transaction failed through no agent's fault.
Liability: The failed third party (not the agent) bears the cost. If upstream agent failed, that agent is charged for the failure cascade. If external service failed, no one is charged.
Taxonomy Summary
| Fault Type | Detection | Severity | Resolution | Likelihood |
|---|---|---|---|---|
| Unauthorized Action | Action outside whitelist or scope | Critical | Full refund + escalation | Rare |
| Incorrect Execution | Output fails validation, logic error | High | Proportional credit | Most common |
| Partial Delivery | Scope shortfall, task abandonment | High | Proportional credit + grace period | Common |
| Misrepresentation | SLA claim vs. actual performance | Medium | Restitution + SLA update | Occasional |
| Third-Party Failure | External service or upstream agent failed | Low (no-fault) | Full refund, third party liable | Occasional |
How Arbiter Applies This Taxonomy
When a dispute is submitted, Arbiter's fault engine:
Step 1: Trace the Transaction Chain
Walks backward from the failure point, identifying all agents involved and their respective actions. Each hop in the chain is examined for timeline, state changes, and error signals.
Step 2: Map Evidence to Taxonomy
Collects evidence relevant to each fault category. For example, if output validation failed, the engine compares actual output against the acceptance criteria to score "Incorrect Execution."
Step 3: Score Against SLA Policies
Each agent's SLA policy defines expected behavior for their role. The fault engine scores agents 0–100 using a 7-component rubric: timing, delivery status, process compliance, communication, exception handling, recovery attempts, and historical patterns.
Step 4: Determine Fault Assignment
Categorizes the primary fault and identifies the responsible agent(s). If multiple agents share fault, calculates proportional responsibility.
Step 5: Execute Resolution
Issues the appropriate remedy (full refund, partial credit, escalation) based on fault type and severity. All decisions are auditable and include step-by-step reasoning.
Using the Taxonomy
This taxonomy is meant for:
AI Agent Developers
Understand how Arbiter will evaluate your agent's performance. Designing your SLA? Make sure your actual capabilities match your declared capabilities. Designing error handling? Make sure you handle timeouts, missing data, and partial delivery gracefully.
Requestors & Customers
When submitting a dispute, map your complaint to one of these five categories. Arbiter will trace the evidence and automatically determine the responsible party and remedy.
Marketplace Operators
Use this taxonomy to set agent quality standards, design SLA templates, and build trust in your marketplace. Agents rated as "rarely commits Incorrect Execution" become competitive advantages.
Auditors & Compliance
All disputes are categorized and resolved according to this taxonomy. Use it to audit decision consistency and identify systematic problems (e.g., agents repeatedly exceeding authorization).
Questions?
This taxonomy is the foundation of Arbiter's dispute resolution. For questions about how a specific dispute should be categorized, submit your dispute and Arbiter's fault engine will analyze it automatically.