Trust Domain (AVIP-TRU)
AVIP trust specification distinguishing the Platform event ledger from SDK-derived scoring and risk signals.
Trust Domain — AVIP-TRU
The Trust domain has two distinct outputs: the Platform produces Trust Events and maintains the Network Score from final business outcomes; the SDK can derive an Execution Score from proof records. The four-factor formula below specifies only the latter and must not overwrite or masquerade as the Platform Network Score.
Specification scope
AVIP-TRU-SCR is the SDK Derived Score profile. See Network Trust Score for authoritative Platform event rules. The two outputs require distinct scoreType values.
| Component | Code | Purpose |
|---|---|---|
| Derived Score Formula | AVIP-TRU-SCR | Four-dimensional SDK proof analysis |
| Verdict-Based Scoring | AVIP-TRU-VDT | How a Completion Proof verdict adjusts scores |
| Risk Flags | AVIP-TRU-FLG | Binary signals independent of the numeric score |
| Cold-Start & Verification | AVIP-TRU-CS | Caps and penalties that resist gaming |
AVIP-TRU-SCR — Score Formula
Purpose
Defines the deterministic computation of an agent's trust score from its proof records.
Normative Requirements
- The score MUST be computed only from on-chain proof records, not from agent self-reports, whenever such records exist.
- The computation MUST be deterministic: the same record set yields the same score for any participant.
- Proof records MUST be deduplicated by
txHashbefore scoring. - The final score MUST be clamped to the range 0–100.
Formula
raw_score = base + volume + risk_bonus + consistency
base = success_rate × 60 (max 60)
volume = min(total_tasks/100, 1) × 15 (max 15)
risk_bonus = (high_risk_successes/total)× 15 (max 15)
consistency = (1 − violation_rate) × 10 (max 10)
final_score = clamp(cold_start_and_verification(raw_score), 0, 100)Dimensions
| Dimension | Weight | Range | Measures |
|---|---|---|---|
| Base | 60% | 0–60 | Fraction of tasks that succeed |
| Volume | 15% | 0–15 | Experience depth (capped at 100 tasks) |
| Risk Bonus | 15% | 0–15 | Successful completion of high/critical-risk tasks |
| Consistency | 10% | 0–10 | Absence of policy violations |
Input Fields (per on-chain proof record)
| Field | Type | Used in |
|---|---|---|
success | boolean | success_rate |
riskLevel | low / medium / high / critical | risk_bonus |
policyViolations | integer | violation_rate |
verified | boolean | verification adjustment (AVIP-TRU-CS) |
txHash | string | deduplication key |
executor | string (DID) | agent identity |
traceRoot | string | links to execution proof |
Score Interpretation
| Range | Interpretation |
|---|---|
| 0–20 | Untrusted — no track record or a history of failures |
| 21–40 | Low trust — some activity, significant concerns |
| 41–60 | Moderate trust — reasonable record, may carry flags |
| 61–80 | High trust — consistent across multiple tasks |
| 81–100 | Very high trust — extensive, verified, includes difficult tasks |
A score of 0 means the agent has no completed tasks or its record could not be retrieved; it is the default state for new agents.
AVIP-TRU-VDT — Verdict-Based Scoring
Purpose
Defines how a Completion Proof verdict (A2A) adjusts the trust scores of both parties.
Normative Requirements
- A FULFILLED / PARTIAL / VIOLATED verdict MUST apply the adjustments below to executor and requester.
- Orders settled without an Intent MUST receive the flat legacy adjustment and MUST NOT produce a Completion Proof.
Adjustments
| Verdict | Executor | Requester |
|---|---|---|
FULFILLED | +3.0 | +1.5 |
PARTIAL | +0.5 | +0.5 |
VIOLATED | −5.0 | −1.0 |
| No Intent (legacy) | +2.0 | +1.0 |
Rationale
The asymmetry is intentional. Executors bear more risk and reward: they did the work, so fulfillment is rewarded more and violation penalized more. Requesters have a supporting role and receive smaller adjustments. A single VIOLATED (−5.0) requires roughly two FULFILLED (+3.0 each) to offset — trust is harder to build than to lose, and a violation leaves a lasting mark.
AVIP-TRU-FLG — Risk Flags
Purpose
Binary signals that surface specific concerns independent of the numeric score. An agent can have a moderate score and still carry flags.
Flags
| Flag | Condition | Meaning |
|---|---|---|
LOW_SUCCESS_RATE | success_rate < 50% | More tasks fail than succeed |
HAS_VIOLATIONS | any task has policyViolations > 0 | Has breached policy at least once |
LOW_RISK_ONLY | all tasks low-risk AND total > 50 | Avoids difficult tasks (possible gaming) |
RECENT_FAILURES | > 50% of last 10 tasks failed | Performance is deteriorating |
NO_VERIFIED_PROOFS | verified_count = 0 AND total > 0 | No on-chain verification of any proof |
LOW_RISK_ONLY triggers only after 50 tasks, to avoid flagging agents genuinely early in their career. RECENT_FAILURES provides a recency signal that a high lifetime average can otherwise mask.
AVIP-TRU-CS — Cold-Start & Verification Adjustments
Purpose
Caps and penalties that prevent a small or unverified history from producing a high score.
Normative Requirements
- An agent's score MUST be capped according to its task count until enough history exists.
- The verification penalty MUST be applied to the raw score before cold-start caps.
Cold-Start Caps
| Total tasks | Maximum score |
|---|---|
| < 5 | 55 |
| < 10 | 65 |
| < 20 | 75 |
| ≥ 20 | 100 (no cap) |
Verification Penalty
| Condition | Multiplier |
|---|---|
| total ≥ 3 AND verified_ratio < 50% | × 0.85 |
| total ≥ 10 AND verified_ratio < 50% | × 0.70 |
| total < 3 | none |
Interaction
The penalty multiplies the raw score first; the cap is applied afterward. In practice the verification penalty often pushes the score below the cold-start cap, making the cap moot. Legacy self-reported summaries always have verified_count = 0 and therefore receive the verification penalty once the agent has 3+ tasks — an incentive to migrate to on-chain anchored proofs.
On-Chain Mapping
The Derived Score is recomputed by the SDK from proof records and is not stored by a contract. The Platform Network Score is separately projected from Trust Events and stored in Registry. Both may use AnchorRegistry to verify input integrity, but they must not be collapsed into one source-ambiguous score.