A Distributed Embedding Calculus of Trust

Trust between autonomous parties — human, software agent, or device — is subjective, asymmetric, and changes as new evidence arrives. Most engineered trust systems flatten this into a single scalar reputation score, which discards exactly the information that makes trust useful: whose trust, in what context, based on what history. This page sets out a framework for computing trust as a learned, distributed quantity rather than a static number: experiential embeddings to represent the subjective and contextual character of a trust relationship, a small calculus for combining and propagating those embeddings into usable trust scores, and a distributed architecture so no single node has to hold, or be trusted with, the whole picture.

The three pieces fit together as follows. Each pairwise relationship between entities is represented by a vector — an experiential embedding — that a learned model updates as interactions occur. The calculus defines how embeddings combine: how two hops of trust compose into a transitive estimate, how several trust signals aggregate into one, and how a single relationship's embedding drifts as new evidence arrives. The architecture distributes both the storage of embeddings and the computation of the calculus across nodes, so trust evaluation scales with the network rather than bottlenecking on a central authority.

Experiential Embeddings

An experiential embedding is a dense vector representation of the history of interactions, contextual factors, and outcomes between two specific entities — not a general-purpose profile of either party in isolation, but a representation of the relationship. This distinguishes it from a typical entity embedding (used, for example, to represent a user or product in a recommender system): the same entity can have very different experiential embeddings with different counterparties, because it captures the specific history and context of that pairing.

Four properties shape the design of such an embedding:

  • Subjectivity. The same objective interaction can be encoded differently depending on the trustor's own risk tolerance and prior experience, so the embedding is a function of both parties, not a property of the trustee alone.
  • Dynamicity. The embedding must update as new interactions occur rather than being fixed at creation — a requirement that graph neural network approaches to trust evaluation address directly by learning temporal attention over interaction sequences [1].
  • Context-dependence. Trust in one domain (code review) does not transfer automatically to another (financial cosigning) between the same two parties, so context needs to be encoded as part of the vector rather than assumed constant.
  • Asymmetry. A's trust in B need not equal B's trust in A; the framework stores directed embeddings per ordered pair, not one shared value per relationship.

Learning such embeddings is a graph representation-learning problem: entities are nodes, interactions are edges (or edge-updates), and the embedding of an edge should preserve both the local interaction history and its position in the wider trust graph. Random-walk based methods such as node2vec, which learn node representations by optimising the likelihood of preserving sampled network neighbourhoods, are a natural starting point for the structural component of the embedding, with the interaction history handled as a separate, learned time-series feature that is concatenated or fused before the final vector is produced [2].

A Calculus for Combining Trust

Given embeddings, the framework needs a small set of operations for turning them into usable trust scores and for combining scores from multiple sources. Three operations do most of the work.

Trust as a vector. Rather than reducing trust to one number, each evaluation is represented as a three-component vector separating positive evidence, negative evidence, and uncertainty:

\[ T = [T_{positive}, T_{negative}, T_{uncertainty}] \]

Keeping uncertainty as its own term matters in practice: a relationship with no interaction history and a relationship with a long history of exactly balanced positive and negative outcomes both have low net trust, but they call for very different handling — the first needs cautious probing, the second needs closer scrutiny.

Transitive propagation. When A must estimate trust in C via an intermediary B, the estimate composes the two hops rather than treating them independently:

\[ T(A, C) = T(A, B) \times T(B, C) \]

This is a simplification — real transitive trust is not simple multiplication, since it should also discount with path length and diversify across multiple independent paths — but it fixes the right intuition: trust degrades across hops rather than passing through unchanged, and an intermediary's own untrustworthiness should suppress, not just relay, what they vouch for.

Weighted aggregation and update. Where several trust signals about the same relationship are available (direct interaction, propagated estimates, external attestations), they combine as a weighted sum with weights reflecting the reliability of each source:

\[ T_{total} = \sum_{i=1}^{n} w_i \times T_i \]

and a relationship's trust vector updates continuously as new evidence arrives, with separate rate constants for how quickly positive evidence, negative evidence, and residual uncertainty move the estimate:

\[ \frac{dT}{dt} = \alpha \cdot E_{\text{positive}} - \beta \cdot E_{\text{negative}} - \gamma \cdot T_{\text{uncertainty}} \]

Making \(\beta\) larger than \(\alpha\) encodes the common design choice that trust should be slow to build and quick to damage — a policy decision the calculus makes explicit and tunable rather than implicit in ad hoc scoring code.

The embedding and the calculus meet at trust prediction itself: a candidate trust score between two entities with no direct history is estimated from the similarity of their experiential embeddings,

\[ T(A, B) = f(\text{sim}(E_A, E_B)) \]

where \(f\) is a learned function mapping embedding similarity onto the trust vector. This is what lets the system produce a reasoned trust estimate for a pair of entities that have never interacted directly, using their positions in the wider embedding space.

Distributed Architecture

Centralising every entity's experiential embeddings in one store creates a single point of failure and a single party who must be trusted with everyone's trust history — an awkward position for a trust system to put itself in. The architecture instead distributes both storage and computation:

  • Local trust nodes. Each entity maintains its own local store of the embeddings for relationships it participates in, and performs its own local trust evaluations rather than querying a central authority for every decision.
  • Peer-to-peer propagation. Nodes exchange trust scores and (where privacy allows) embeddings with directly connected peers, so transitive trust estimates can be computed without any party holding the full graph.
  • Consensus for shared state. Where multiple nodes must agree on a fact that affects trust globally — a revocation, a confirmed violation — the system needs agreement despite the possibility that some participants are faulty or actively malicious. This is the Byzantine fault tolerance problem, and practical BFT consensus protocols exist precisely for this: agreement among \(n\) nodes tolerating up to \(\lfloor (n-1)/3 \rfloor\) arbitrary-behaviour faults, without requiring every node to trust every other [3].
  • An append-only ledger for high-stakes events. Not every trust update needs to be globally durable, but revocations and formal attestations benefit from an immutable, shared record that all nodes can verify independently — the same property that makes a distributed ledger useful for supply-chain provenance is useful here, applied narrowly to trust-affecting events rather than to every interaction.

This keeps the expensive part — embedding computation and local trust evaluation — local and cheap to scale by adding nodes, while reserving the expensive coordination machinery (consensus, shared ledger) for the comparatively rare events that genuinely need it.

Privacy in a Shared Trust Graph

An experiential embedding encodes real interaction history, which makes it sensitive by construction: propagating it naively leaks behavioural detail about both parties to every node it passes through. Three established techniques bound on that leakage without abandoning distributed computation:

  • Differential privacy. Calibrated noise, added according to the sensitivity of the function being computed, lets aggregate trust statistics be shared with a bounded, quantifiable privacy loss rather than an unbounded one [4]. Applied to embeddings, this means propagated trust scores can carry a formal privacy guarantee instead of an informal "we didn't share the raw vector" one.
  • Homomorphic encryption. Since Gentry's construction of a fully homomorphic scheme, it has been possible in principle to evaluate arbitrary functions — including the calculus's similarity and aggregation operations — directly on encrypted embeddings, so a node computing a trust estimate for a peer need not see that peer's embedding in the clear [5]. In practice this remains computationally expensive enough that it is worth reserving for high-value evaluations rather than every propagation step.
  • Secure multi-party computation. Where several nodes each hold partial evidence and want a joint trust estimate without revealing their individual inputs to one another, SMPC protocols let them compute that joint function cooperatively. This is the natural fit for the weighted-aggregation step of the calculus when the sources being combined do not trust each other with raw data.

None of these techniques is free: all three trade computation or communication overhead for a privacy guarantee, and the architecture should apply them selectively — proportionate to how sensitive a given trust decision actually is — rather than uniformly.

Where This Applies

The framework is domain-agnostic, but three settings illustrate where it earns its complexity over a simple scalar reputation score.

Peer-to-peer lending. Regional social capital measurably affects both funding success and default rates in P2P lending markets, independent of a borrower's individual credit signals [6]. A context-aware, embedding-based trust score can capture that regional and relational signal directly, rather than requiring it to be hand-engineered as a separate feature bolted onto a conventional credit score.

Social Internet of Things. Where devices form relationships on behalf of their owners, trust evaluation needs to account for the owners' social relationships as well as the devices' own interaction history — reputation, direct experience, and social-graph proximity all carry independent signal [7]. This is a close structural match for the framework's per-relationship, context-tagged embeddings.

Content and reputation systems. Any system currently relying on a single aggregate reputation number — a marketplace seller rating, a community moderation score — is a candidate for replacement by a directed, context-aware trust estimate, provided the interaction volume is large enough to train useful embeddings in the first place; this last condition is the framework's main practical limiting factor, discussed below.

Open Problems

Three limitations are inherent to the approach rather than implementation details to be optimised away:

  • Cold start. A new entity with no interaction history has no meaningful embedding yet, and the framework has nothing better to fall back on than a wide uncertainty band until enough interactions accumulate. This is a structural weakness relative to systems that can bootstrap trust from external credentials.
  • Interpretability. A learned similarity function over high-dimensional embeddings is harder to explain to an affected party than a rule-based reputation score, which matters wherever a trust decision needs to be justified — to a regulator, to a user disputing a decision, or to an auditor. Attention-based architectures that expose which prior interactions most influenced a given trust estimate are a partial answer, not a complete one.
  • Adversarial manipulation. Because the embedding is learned from interaction history, an adversary who can generate cheap, favourable interactions can attempt to manipulate their own embedding directly — a stronger attack surface than gaming a simple counted-reviews reputation score, and one the aggregation and consensus layers need to be designed against explicitly rather than assumed away.

None of these rules out the approach; they set the conditions under which it is worth the added complexity over a scalar reputation score — enough interaction volume to learn from, a use case where context-sensitivity is worth more than simplicity, and a tolerance for probabilistic rather than fully explainable trust decisions.

  • Legal Framework in Computing — the compliance obligations that attach to any system processing behavioural interaction data.
  • Trustworthy Software — auditability and provenance as engineering pillars, the systems-level counterpart to this page's relationship-level framework.
  • Chatbots in Healthcare — a domain where a context-aware, per-relationship trust score would need to interact directly with sectoral privacy regulation.

References

  1. Wang, J., Yan, Z., Lan, J., Bertino, E., & Pedrycz, W. "TrustGuard: GNN-based Robust and Explainable Trust Evaluation with Dynamicity Support." IEEE Transactions on Dependable and Secure Computing, 2024. https://arxiv.org/abs/2306.13339
  2. Grover, A., & Leskovec, J. "node2vec: Scalable Feature Learning for Networks." Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, 2016. https://arxiv.org/abs/1607.00653
  3. Castro, M., & Liskov, B. "Practical Byzantine Fault Tolerance." Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI), 1999. https://pmg.csail.mit.edu/papers/osdi99.pdf
  4. Dwork, C., McSherry, F., Nissim, K., & Smith, A. "Calibrating Noise to Sensitivity in Private Data Analysis." Theory of Cryptography Conference (TCC), 2006. https://link.springer.com/chapter/10.1007/11681878_14
  5. Gentry, C. "Fully Homomorphic Encryption Using Ideal Lattices." Proceedings of the 41st Annual ACM Symposium on Theory of Computing (STOC), 2009, pp. 169–178. https://dl.acm.org/doi/10.1145/1536414.1536440
  6. Hasan, I., He, Q., & Lu, H. "Social Capital, Trusting, and Trustworthiness: Evidence from Peer-to-Peer Lending." Journal of Financial and Quantitative Analysis, 57(4), 2022, pp. 1409–1453. https://www.cambridge.org/core/journals
  7. Truong, N.B., Lee, H., Askwith, B., & Lee, G.M. "Toward a Trust Evaluation Mechanism in the Social Internet of Things." Sensors, 17(6), 1346, 2017. https://www.mdpi.com/1424-8220/17/6/1346