docs(rfc): x402-trust-score v0.2 — normalize subscores + decouple agent/provider weight

[jlromeiro]

Summary

Spec-only PR. Bumps docs/rfc/x402-trust-score.md from v0.1 → v0.2 (still DRAFT, public comment open until 2026-06-30 per the spec header).

No code changes in this PR. Implementation will land in a separate PR after the spec stabilizes.

Why v0.2

v0.1 had three correctness/auditability issues identified in review:

1. Mixed subscore scales — the published weights (0.30·P1, 0.20·H1, etc.) did not match the actual contribution to the final score because some subscores were 0-1, some 0-25, some 0-100. A "perfect" agent could only reach ~50 before the multiplier.
2. weight(p) undefined — §12 listed it as an open issue, but the spec implicitly mixed agent score with operator weight via weighted_avg(provider_score * weight), allowing attestation volume to dominate the agent score.
3. No guidance for inactive subscores — H1 depends on /report, which isn't built yet (see docs/superpowers/specs/2026-05-12-trust-score-cross-op-roadmap.md gap analysis). The spec did not say what to do when a subscore's required infrastructure is missing.

Key changes (v0.2)

• All subscores normalized to 0-100 before weighting (P1, P2, D2, H1, R1). Published weights now match effective contribution.
• H1 uses Laplace (add-one) smoothing — new pubkeys with 0 disputes score ~85.7, not 100. Convergence to 100 requires sustained volume.
• global_trust_score(pubkey) and weight(p) explicitly decoupled. Agent behavior and operator credibility are computed independently and never multiplied together.
• Explicit weight(p) formula (§5.2): tier_base · log10(1 + attested_count_30d) · sqrt(months_in_network), with a cap at cap_multiple_of_active_median × median_over_active_cohort and a conditional floor for production operators with real reach and clean recent history.
• active_cohort defined precisely — median is computed only over providers with positive raw weight, production tier, recent activity, and reach above pubkey_reach_threshold. Prevents dormant operators from collapsing the median to zero.
• Conditional renormalization (§5.1.3) — when a subscore is inactive (e.g., H1 before /report is built), the broker MUST renormalize remaining weights to sum to 1.0 and expose per-subscore status in /info via inactive_until_<feature> markers.
• cross_provider_bonus preserved binarily — a small operator's attestation increments active_in_n_providers by 1 regardless of volume. This is the structural mechanism that keeps small operators relevant.
• pubkey_reach_threshold (default 25), cap_multiple_of_active_median (3), floor_weight (0.3), active_window_days (7) — all published as governance parameters in GET /info.provider_weight_policy, tunable via the public change-window without an RFC bump.
• Idle decay window 30d → 60d in R1, reflecting that many agent workloads (cron, batch, rebalancers, sazonal) are intermittent.
• Resolved §12 "Provider weighting policy" open issue — removed from open issues.
• Added §5.1.5 reference values table — sanity check across top / mid / new agents in Phase 1 and Phase 1.5+ deployments.

Impact on operators (large vs small)

• Large operators: raw weight still grows with volume, but log-scaled and tenure-dampened. Cap at 3× active-cohort median prevents capture. Lose absolute "domination" ranking but keep cross-op signals they cannot compute alone.
• Small operators: floor 0.3 in good standing (with real reach + no disputes) keeps weight meaningful — not 1/1000× of a giant. cross_provider_bonus is binary, so being the Nth operator a pubkey transacts with carries the same +0.1 increment as any other. This is the BR-first / tier-2-friendly mechanism the protocol needs to attract small operators.

Test plan

This PR is spec-only, so "tests" are correctness checks against the spec text:

• Section numbering is internally consistent (§4.4, §5.1.3, §5.2.3 references resolve).
• Formulas in §5.1.1, §5.1.2, §5.1.4, §5.2.1, §5.2.3 parse correctly and have no scale mismatches.
• GET /info JSON examples in §5.1.3 and §5.2.3 are well-formed.
• Sanity values in §5.1.5 reproduce by hand for the three reference agents.
• §14 changelog entry mentions all major behavior changes vs v0.1.
• No dangling reference to the removed §12 "Provider weighting policy" item.
• Public comment window (2026-06-30 per spec header) still valid.

Code

A follow-up PR will update index.js, lib/detection.js, lib/agent-status.js, lib/ratelimit.js, and the broker scaffolding (when extracted per docs/superpowers/specs/2026-05-12-trust-score-cross-op-roadmap.md Phase 1) to match this spec. Not in scope here.

🤖 Generated with Claude Code

[kilo-code-bot]

Kilo Code Review could not run — your account is out of credits.

Add credits or switch to a free model to enable reviews on this change.