Trust-Weighted Route Scoring: Dynamic Path Selection Through Policy-Defined Trust Thresholds

Mechanism

The trust-weighted-routing mechanism associates with every peer of every participant a per-peer trust value that captures the participant's observed history with that peer. The trust value is not a global score; it is local to the participant who computed it, derived from interactions the participant directly observed or interactions that were attested to the participant by counterparties whose own trust the participant has independently established. Locality of the trust computation is structural, not incidental: a participant who routes through a peer is responsible for its own trust assessment of that peer and cannot delegate the responsibility to a global registry without giving up the audit guarantees that motivate the construction.

When a participant constructs a candidate route to a destination, the protocol enumerates the peers along the route and computes a path trust score as a function of the per-peer trust values, the freshness of those values, and the structural role of each peer in the path. The path trust function is monotonic in the trust of each constituent peer: a path containing a low-trust peer cannot score higher than the path-equivalent that excludes it. The path trust function also penalizes paths whose trust is concentrated in a small subset of peers, which would expose the path to disproportionate risk from a single compromise.

The path trust score is compared against a policy-defined threshold supplied by the participant or by the originating policy of the request. Paths above the threshold are eligible for selection; paths below the threshold are excluded. Among eligible paths, the protocol selects according to a configured network-health metric that may incorporate latency, congestion, time-to-live cost, and historical success rate. Trust gates eligibility; health-metric scoring selects within the eligible set.

Each routing decision is recorded in an append-only audit structure that is mandatory, not optional. The record captures the candidate set considered, the trust values consulted, the threshold applied, the eligibility outcome for each candidate, and the health-metric scoring within the eligible set. The audit record is the principal mechanism by which trust-weighted routing decisions become inspectable; without the record, the decisions would be locally optimal but globally opaque, undermining the use cases that motivate the construction.

Rotation is the final element of the mechanism. Peers that remain in the active routing set indefinitely accumulate disproportionate visibility into traffic patterns and become structural bottlenecks; the construction therefore mandates explicit rotation. Rotation is not an emergent property of the trust computation; it is a separate operation in which the active set is rebalanced according to a configured rotation cadence and a configured diversity criterion. Peers rotated out of the active set retain their trust values; rotation does not punish peers for being rotated, and a peer rotated out at one cadence will rotate back in at a subsequent cadence absent an intervening trust event.

Operating Parameters

The trust-weighted-routing construction exposes a set of operating parameters tuned to the deployment's risk surface and traffic patterns. The trust-threshold parameter sets the minimum acceptable path trust score; deployments tolerant of higher tail risk select lower thresholds, gaining access to more candidate paths at the cost of admitting paths through peers with thinner interaction histories. Deployments intolerant of tail risk select higher thresholds, accepting fewer candidates and accepting the higher latency that results from a smaller eligible set.

The trust-freshness parameter governs how heavily aged trust values are discounted relative to recent ones. A short freshness horizon produces a system that responds quickly to changes in peer behavior but is sensitive to short-term anomalies; a long freshness horizon produces a system whose trust assessments are stable but laggy. The freshness parameter interacts with the rotation cadence: a system that rotates aggressively benefits from a shorter freshness horizon because rotated peers re-enter with current rather than historical evidence.

The rotation-cadence parameter sets the interval at which the active routing set is rebalanced. Cadences shorter than the round-trip time of typical requests produce thrashing; cadences longer than the typical session duration concentrate visibility in too few peers. Empirically, rotation cadences in the range of tens of seconds to minutes work well for deployments at the scale of single data centers; cadences in the range of minutes to hours work well for wide-area deployments.

The diversity-criterion parameter governs the structural shape of the active set after rotation. Criteria range from random selection within the eligible set, which is simple and unbiased, to constrained selection that requires the active set to span multiple administrative domains, network paths, or operator identities, which is more complex but resilient against correlated compromise. The choice of diversity criterion is the principal lever by which a deployment trades simplicity for resilience.

The audit-completeness parameter is non-negotiable: the construction mandates that every routing decision be recorded, and the parameter governs only the durability and availability of the record, not its existence. Deployments may choose to anchor the audit record at varying frequencies, replicate it across varying numbers of substrates, or expose it through varying interfaces, but they cannot opt out of producing it. This rigidity is a structural feature: trust-weighted routing without a mandatory audit record degenerates into the kind of opaque policy overlay that the construction is designed to replace.

Alternative Embodiments

The trust accumulator that supplies per-peer trust values admits several alternative embodiments. In a first embodiment, the accumulator is a bounded-slope construction in which trust accrues at a saturating rate, decays without renewal, and is committed into a per-peer dynamic hash chain. This embodiment shares the saturation-and-decay properties of the trust-slope identity primitive and inherits its resistance to runaway accumulation and to long-dormant high-trust peers.

In a second embodiment, the accumulator is a Bayesian update over interaction outcomes, with prior and likelihood parameters derived from the deployment's historical base rates. This embodiment is more expressive than the bounded-slope variant but requires the deployment to maintain calibrated priors and to be vigilant for prior drift.

In a third embodiment, trust is computed as a weighted aggregate over directly observed interactions and attested third-party interactions, with the attestation weight determined by the trust of the attesting party. The graph-aggregated embodiment captures community-level reputation effects and is appropriate for deployments where direct observation is sparse, but it is more sensitive to collusive subgraphs and typically incorporates a damping term and a collusion-detection observer.

In a fourth embodiment, the path trust function is multiplicative rather than monotonic-aggregate; path trust is the product of per-peer trust values normalized to the unit interval. The multiplicative embodiment penalizes long paths sharply and is appropriate for deployments where path length itself is a risk factor.

In a fifth embodiment, rotation is driven by an explicit randomized schedule with cryptographic commitment, so that the rotation pattern itself is auditable and cannot be biased toward favored peers. The committed-rotation embodiment is appropriate for deployments that must defend against suspicion of insider bias.

Composition with Adjacent Primitives

Trust-weighted route scoring composes with the adjacent primitives of the memory-native protocol stack to produce a transport whose behavior is jointly governed by performance and trust. The primitive composes downward with the per-peer trust accumulator, whatever its specific embodiment; without an accumulator, the routing logic has no trust signal to consume and degenerates to pure health-metric routing.

The primitive composes laterally with the soft-index-anchor primitive disclosed in the same family. Soft anchors accelerate locality lookup; trust-weighted routing then directs traffic across paths whose trustworthiness is independently established. The compositional payoff is that lookup acceleration and trust gating operate on independent surfaces, and a participant that pays the cost of one is not forced to pay the cost of the other on the same workload.

The primitive composes with the cryptographic-commitment primitive that anchors the audit record. Without the commitment, the audit record is locally produced but not externally verifiable; with it, the audit record is a structural artifact that an external observer can inspect and independently validate. The combination is what makes trust-weighted routing audit-complete rather than merely audit-friendly.

The primitive composes upward with the policy-evaluation primitive that consumes routing outcomes. Policies that gate disclosure, escalation, or retry behavior may inspect the trust score of the path that delivered a request and apply differential treatment. A policy that demands high-trust delivery for a sensitive request can specify a minimum path trust score; the routing primitive will either select a qualifying path or decline the request, and the audit record will capture the decision.

The primitive composes laterally with the rotation observer that monitors the active set for diversity and freshness. The rotation observer is itself a participant in the protocol and consumes the audit record produced by trust-weighted routing as one of its inputs. The two primitives operate on a shared surface but with separable responsibilities.

Prior-Art Distinctions

Trust-weighted route scoring is distinguishable from prior routing, reputation, and policy-overlay work along several axes. Conventional dynamic routing protocols such as link-state and distance-vector routing select paths on health metrics alone and treat trust as an external concern handled by upstream policy; the disclosed construction integrates trust as a first-class transport-level property and does not depend on any external policy to enforce it. The distinction is functional: a deployment that uses a conventional routing protocol cannot express the kind of joint health-and-trust decision the construction defines without bolting on a separate enforcement layer that operates outside the routing decision and is therefore not audit-coordinated with it.

Reputation-based routing in peer-to-peer networks computes peer scores from interaction histories but typically does not mandate audit completeness, does not mandate explicit rotation, and does not separate trust gating from health-metric scoring. The disclosed construction differs by mandating all three properties at the level of the primitive itself.

Policy-based routing systems such as BGP allow operators to express path preferences but do not derive those preferences from observed interaction history and do not produce a per-decision audit record that captures the trust evidence consulted. The disclosed construction is not a policy-routing system; it is a routing system whose policy surface is structurally defined and structurally audited.

Onion-routing and mix-network designs randomize peer selection to defeat traffic analysis but do not condition selection on trust and do not maintain trust accumulators. The disclosed construction is compatible with diversity-driven selection but adds the trust gating that anonymity-focused systems do not provide.

Trust-management frameworks such as KeyNote and SDSI define vocabularies for expressing trust assertions but do not specify a routing-time consumption of those assertions or an audit record of the consumption. The disclosed construction is not a trust-vocabulary system; it is a routing system whose trust input could be expressed in such a vocabulary but whose contribution lies in the routing-time mechanism that consumes the trust input and produces an audit record of the consumption.

Disclosure Scope

The disclosure of Provisional 64/050,895 and continuation US 19/366,760 covers the trust-weighted-routing construction as a structural primitive within the memory-native protocol, including the per-peer trust accumulator, the path trust function, the policy-defined threshold, the mandatory audit record, and the explicit rotation operation with diversity criterion. The disclosure encompasses the alternative embodiments described above, including bounded-slope, Bayesian, graph-aggregated, multiplicative-path, and committed-rotation variants.

The disclosure does not constrain the specific accumulator family, the specific health-metric function, or the specific rotation cadence beyond the structural requirements that trust be locally computed, audit-recorded, and rotation-rebalanced. Implementers are free to select accumulator and health-metric primitives appropriate to their deployment. The disclosure also does not constrain the application domain; the construction has been instantiated for memory-region routing, agent-message routing, and capability-invocation routing without modification.

Outside the disclosure are conventional routing systems that lack trust integration, reputation systems that lack mandatory audit, and trust-overlay systems that operate outside the routing decision rather than within it. Licensees seeking guidance on whether a contemplated implementation falls within the disclosed scope should consult the claims of US 19/366,760 directly and engage Adaptive Query for written confirmation.