Skip to content
cresvaDevelopers
All posts
Updated September 16, 2026ArchitectureTrust

The Architecture Behind Federated Trust Scores

Status, added 2026-08-21. This post describes a design, not a running

system. OSP specifies federated trust scoring; no platform other than

Cresva implements it today, and no transaction has yet been recorded through

the protocol, so there is no cross-platform signal to aggregate. Read every

present tense below as "the design says", not as "this is happening".

The API paths below are not real, added 16 September 2026. This post

prints GET /v2/storefronts/sf_abc123/trust and a /trust/history?days=90

endpoint. Neither exists. The live paths are

GET /api/storefront/{brandId}/trust and

GET /api/storefront/{brandId}/trust/signals, and there is no history

endpoint at all. The response shapes below are the design's, not the API's.

And the mechanism below is design too, added 16 September 2026. The

45-day decay half-life, the 1.5x multiplier on the ten most recent signals,

the Beta prior at alpha 40 beta 10, and the diversity requirements across

transaction value, category and geography are all specified here and none is

implemented. What the scorer does today is simpler and is documented on

the trust reference: fixed weights over absolute component

scores, with an unmeasured component excluded rather than imputed, and

measured_weight reporting how much of the score rests on evidence.

OSP specifies how trust scores are computed across independent storefronts without a central authority dictating what "trustworthy" means. This post is a deep dive into the intended technical architecture: Bayesian aggregation, temporal decay functions, cross-platform reputation portability, and the adversarial resilience mechanisms meant to 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. OSP is designed to connect independent storefronts with independent AI agent platforms, so that 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:

  • Accurate: reflects the storefront's actual reliability
  • Robust: resistant to manipulation by any single party
  • Portable: usable by any agent platform, not locked to one ecosystem
  • Fresh: updated in near real-time as new signals arrive
  • Interpretable: agents can understand why a score is what it is

This is a distributed systems problem as much as a data science problem.

Architecture overview

OSP'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 Intervals

Signal Collectors

Trust signals originate from three sources:

Transaction outcomes. Every OSP 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, OSP'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 OSP 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 the transaction_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.

OSP'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 OSP 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 OSP 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:

  • Successful transaction (no dispute): +1.0
  • Positive user review (4-5 stars): +0.6
  • Neutral user review (3 stars): +0.0
  • Negative user review (1-2 stars): -0.8
  • Dispute opened: -2.0
  • Dispute resolved in storefront's favor: +0.5 (partial recovery)
  • Dispute resolved against storefront: -3.0
  • Certification test passed: +0.3
  • Certification test failed: -1.5

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.

OSP specifies exponential decay on signal weights:

effective_weight = base_weight <em> exp(-lambda </em> age_days)

lambda is the decay constant. The design specifies a 45-day half-life: a signal 45 days old counts half as much as an identical signal from today, one at 90 days counts a quarter, and anything past 180 days retains under 6% of its original weight and is treated as negligible.

The design sets a different half-life per signal type:

  • Transaction outcomes: 45 days, the standard
  • User reviews: 60 days, on the reasoning that a review stays relevant longer
  • Certification results: 30 days, on the reasoning that technical quality changes quickly

Recency boost

Alongside decay, the design weights the 10 most recent signals at 1.5x. The purpose is responsiveness to a sudden change in quality: a storefront that starts failing deliveries today moves the number within days rather than weeks.

Cross-platform reputation portability

One of OSP'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 OSP'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. OSP'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. OSP detects this through:

  • Velocity analysis: A sudden spike in negative signals that deviates from the storefront's historical pattern triggers a review. Signals received during the spike are quarantined.
  • Source diversity: Signals from a small number of source accounts carry less weight than signals from diverse sources. If 50 negative reviews come from 3 accounts, the effective weight is much lower than if they come from 50 independent accounts.
  • Behavioral fingerprinting: Coordinated accounts often exhibit similar timing patterns, review text structures, and interaction patterns. The fraud detection system clusters signals by behavioral similarity and flags coordinated clusters.

Shill reviews

A storefront creates fake accounts to submit positive reviews for itself. OSP detects this through:

  • Transaction linkage: Reviews must be linked to a completed OSP transaction. Accounts that submit reviews without corresponding transactions are flagged.
  • Graph analysis: The fraud system builds a graph of account-storefront relationships and identifies suspicious patterns like single-use accounts that only interact with one storefront.

Score farming

A storefront creates small, low-risk transactions to accumulate positive signals and inflate their score. The design mitigates this through:

  • Transaction value weighting: the design weights a higher-value transaction more heavily, so a $5 transaction counts for less than a $500 one.
  • Diversity requirements: the design requires signal diversity across transaction value, product category and buyer geography before a score reaches high confidence, so 10,000 identical $1 transactions from one geography do not produce a high score.

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.

Correction, 2026-09-16. A "Performance characteristics" section here

published latency, throughput and storage figures as if they were production

readings. They were not measured, and the regional cache they described does

not exist. They have been removed rather than adjusted. The real measured

distribution across all storefront traffic to date is in the

retracted benchmarks post.

What's next

We are actively working on several trust system enhancements:

  • Categorical trust scores. Different product categories might warrant different trust evaluations. A storefront might be highly reliable for electronics but less so for clothing (due to sizing issues). Category-specific trust scores would let agents make more precise recommendations.
  • Predictive trust. Using the temporal trend data to predict where a storefront's trust score is heading, not just where it is now. An agent could proactively avoid storefronts whose scores are declining rapidly.
  • Trust score explanations. Natural language explanations of why a trust score is what it is, designed to be included in agent responses to users. "This store has a trust score of 84, driven by strong fulfillment reliability and above-average pricing transparency. Their dispute resolution is below average."

Questions about OSP's trust architecture? Reach out at developers@cresva.ai or join our GitHub discussions.