The Architecture Behind Federated Trust Scores
ACP computes trust scores across thousands of independent storefronts without a central authority dictating what "trustworthy" means. This post is a deep dive into the technical architecture: Bayesian aggregation, temporal decay functions, cross-platform reputation portability, and the adversarial resilience mechanisms that keep the system honest.
The federated trust problem
Centralized trust is easy. A single platform collects reviews, computes scores, and displays ratings. Amazon, Uber, and Airbnb all use this model. It works when one entity controls the entire marketplace.
Agent commerce is different. ACP connects thousands of independent storefronts with hundreds of independent AI agent platforms. No single entity controls the marketplace. Trust data originates from multiple sources - transaction outcomes, user feedback, certification results, and behavioral signals - collected by different platforms with different incentives.
The challenge is computing a trust score that is:
This is a distributed systems problem as much as a data science problem.
Architecture overview
ACP's trust system has four components:
[Signal Collectors] --> [Signal Aggregator] --> [Score Computer] --> [Score API]
| | |
Platforms Normalization Bayesian Model
Storefronts Deduplication Decay Functions
Certification Fraud Detection Confidence IntervalsSignal Collectors
Trust signals originate from three sources:
Transaction outcomes. Every ACP transaction generates structured outcome data: was the order fulfilled on time? Did the product match the description? Was there a dispute? These signals are the highest-fidelity input to the trust model because they reflect actual commerce behavior, not self-reported claims. User feedback. After a transaction completes, ACP's feedback protocol sends a structured questionnaire to the user (via their agent). The questionnaire covers product accuracy, fulfillment speed, packaging quality, and overall satisfaction. Responses are scored on a 1-5 scale with optional free-text comments. Certification results. The ACP certification engine periodically tests storefront compliance, data quality, and performance. Certification scores feed into the trust model as an independent, platform-neutral signal.Each signal type has a different trust weight and decay profile, which we cover in the scoring section.
Signal Aggregator
The aggregator receives raw signals from all collectors and performs three operations:
Normalization. Different platforms may use different rating scales or have different baseline expectations. A 4-star rating on one platform might be equivalent to a 3.5-star rating on another (due to cultural differences in rating behavior). The aggregator normalizes all signals to a common 0-100 scale using per-platform calibration curves computed from historical data. Deduplication. The same transaction might generate multiple signals (a transaction outcome plus a user review). The aggregator links related signals to the same underlying event to prevent double-counting. Deduplication uses thetransaction_id as the primary join key.
Fraud detection. The aggregator runs anomaly detection on incoming signals to identify manipulation attempts. Patterns like review bombing (sudden spike in negative reviews), shill reviews (coordinated positive reviews from related accounts), and score manipulation (artificial transactions designed to inflate metrics) are flagged and quarantined pending investigation.
Score Computer
The score computer takes normalized, deduplicated, validated signals and computes trust scores using a Bayesian model with temporal decay.
The Bayesian scoring model
The core insight of Bayesian scoring is that we should not treat a storefront with 5 reviews the same as one with 5,000 reviews, even if both have a 4.8 average. The storefront with 5 reviews has high uncertainty - its true quality could be anywhere from mediocre to excellent. The storefront with 5,000 reviews has narrow uncertainty - we are confident its quality is close to 4.8.
ACP's trust score uses a Bayesian model that explicitly represents this uncertainty:
Prior distribution
Every new storefront starts with a prior trust score based on the global population of ACP storefronts. Currently, the global prior is a Beta distribution with parameters alpha=40, beta=10, corresponding to an expected score of approximately 80 on a 0-100 scale. This prior reflects the fact that most storefronts that bother to register with ACP are reasonably well-maintained.
The prior is intentionally optimistic. A new storefront should not be penalized for having no history - it should start at a reasonable baseline and diverge from there as real data accumulates.
Posterior update
As signals arrive, the posterior distribution is updated using the standard Beta-Binomial conjugate update. Each positive signal (successful transaction, positive review, passing certification test) increments alpha. Each negative signal (dispute, negative review, failed test) increments beta.
The effective trust score is the posterior mean: alpha / (alpha + beta), scaled to 0-100.
Because the prior has alpha=40 and beta=10, a storefront needs roughly 50 total signals before the observed data begins to dominate the prior. This prevents new storefronts from having wildly volatile scores based on a handful of early interactions.
Per-signal weights
Not all signals are equal. A completed transaction with no disputes is a stronger positive signal than a 5-star review. A formal dispute is a stronger negative signal than a 3-star review. The score computer assigns weights to each signal type:
These weights are calibrated empirically against historical data to maximize the predictive power of the trust score (i.e., the score's ability to predict whether the next transaction will result in a dispute).
Temporal decay
Trust scores should reflect current behavior, not ancient history. A storefront that had quality issues six months ago but has since improved should not be permanently penalized. Conversely, a previously excellent storefront that has recently declined should see its score drop quickly.
ACP uses exponential decay on signal weights:
effective_weight = base_weight exp(-lambda age_days)
Where lambda is the decay constant, calibrated to produce a half-life of 45 days. This means a signal from 45 days ago has half the weight of an identical signal from today. A signal from 90 days ago has one-quarter the weight. Signals older than 180 days have less than 6% of their original weight and are effectively negligible.
The decay constant differs by signal type:
Recency boost
In addition to decay, ACP applies a recency boost to the most recent signals. The 10 most recent signals receive a 1.5x weight multiplier. This ensures that the trust score is responsive to sudden changes in storefront quality - if a storefront starts failing deliveries today, the score drops noticeably within days, not weeks.
Cross-platform reputation portability
One of ACP's design goals is that trust scores are portable across agent platforms. A storefront's trust score should be the same regardless of which AI agent queries it. This prevents platforms from creating proprietary trust silos that lock storefronts into single-platform relationships.
Portability is achieved through the signal aggregation architecture. All signals from all platforms flow into the same aggregator. The score computer produces a single canonical score per storefront that is served to all agents via the Score API.
However, agent platforms can apply their own weighting on top of ACP's trust score. For example, a premium agent platform might set a minimum trust threshold of 80, while a bargain-hunting agent might accept storefronts down to 60. Platforms can also weight individual trust signals differently for their use case - an agent focused on speed might weight response_time more heavily than pricing_transparency.
The key distinction is that the underlying data is shared and canonical, while the interpretation layer is platform-specific. This gives platforms flexibility without fragmenting the trust data itself.
Adversarial resilience
Any trust system that influences economic outcomes will attract manipulation. ACP's trust system is designed to be resilient to several known attack patterns:
Review bombing
An attacker coordinates multiple agents or accounts to submit negative reviews for a target storefront. ACP detects this through:
Shill reviews
A storefront creates fake accounts to submit positive reviews for itself. ACP detects this through:
Score farming
A storefront creates small, low-risk transactions to accumulate positive signals and inflate their score. ACP mitigates this through:
The Score API
Agents access trust scores through a simple API:
GET /v2/storefronts/sf_abc123/trust
{
"composite_score": 84,
"confidence": "high",
"signals": {
"product_accuracy": 91,
"fulfillment_reliability": 82,
"pricing_transparency": 88,
"customer_satisfaction": 85,
"response_time": 93,
"dispute_resolution": 72,
"data_freshness": 78
},
"metadata": {
"total_signals": 8432,
"signal_age_median_days": 18,
"last_updated": "2026-03-29T10:15:00Z",
"trend_30d": "+3.2"
}
}The confidence field indicates how much data backs the score: low (under 50 signals), medium (50-500), high (500+). The trend_30d field shows the score's trajectory, helping agents identify improving or declining storefronts.
Agents can also query historical trust data:
GET /v2/storefronts/sf_abc123/trust/history?days=90
{
"data_points": [
{ "date": "2026-03-29", "composite_score": 84 },
{ "date": "2026-03-22", "composite_score": 82 },
{ "date": "2026-03-15", "composite_score": 81 },
...
]
}Historical data lets agents detect patterns that a single snapshot cannot reveal. A storefront with a stable score of 80 over 90 days is a different risk profile than one oscillating between 60 and 90.
Performance characteristics
The trust system is designed for high throughput and low latency:
Trust scores are cached aggressively because they change slowly (the Bayesian model is intentionally smooth). Scores are recalculated every 5 minutes during business hours and every 30 minutes during off-peak. The cache TTL matches the recalculation frequency.
What's next
We are actively working on several trust system enhancements:
Questions about ACP's trust architecture? Reach out at developers@cresva.ai or join our GitHub discussions.