Soft-Index Anchors: Ephemeral Index Points Inferred From Agent Lineage

Mechanism

The soft-index-anchor mechanism partitions the index surface of the memory-native protocol into two coexistent regimes. A soft anchor is a tuple of an inferred locality signature, a confidence estimate, and a short time-to-live; it is generated by a participant when it observes that a cluster of recent access patterns concentrates around a particular memory region, agent lineage, or semantic neighborhood. The signature is computed by a sketching procedure over the relevant features and is sized to be cheap to transmit and cheap to compare. The confidence estimate captures the participant's belief that the anchor will continue to serve as a useful entry point for the immediate future; the time-to-live caps the duration over which the anchor may be relied upon before re-derivation.

A hard anchor, by contrast, is a tuple of a cryptographic commitment, a lineage proof, and an unbounded validity. Hard anchors are bound to specific agent-lineage records and are produced through the same commitment machinery that secures the rest of the protocol's audit surface. Hard anchors are expensive to produce relative to soft anchors and far more expensive to verify, but they offer guarantees that soft anchors do not: a hard anchor cannot be forged without breaking the underlying commitment, and a hard anchor's presence in a routing decision binds the decision to the lineage at a specific instant.

When a participant initiates a lookup, the protocol consults the soft-anchor cache first. If a soft anchor with sufficient confidence and unexpired time-to-live points toward a candidate locality, the lookup proceeds along that locality without further coordination. If the soft anchor is missing, low-confidence, or expired, the protocol falls back to a hard-anchor lookup, paying the verification cost in exchange for a guaranteed-correct entry point. The asymmetry is intentional: most lookups in a healthy memory-native deployment are routine, served quickly by soft anchors, while a minority require the structural guarantees of hard anchors and pay the corresponding cost.

Soft anchors are not authoritative. A consumer that acts on a soft anchor must be prepared to discover, after the fact, that the locality has shifted, that the inferred signature was based on a transient pattern, or that the participant that produced the anchor had only partial visibility. The protocol accommodates this by treating soft-anchor-driven lookups as advisory: a successful lookup that resolves the request validates the anchor; an unsuccessful or contradicted lookup invalidates the anchor and triggers a fall-back to the hard-anchor path. Validation and invalidation update the local soft-anchor cache, producing an adaptive system that improves with use without requiring central coordination.

Soft anchors expire. Time-to-live is the principal expiration mechanism but not the only one. An anchor is also retired when a contradicted lookup invalidates it, when a hard-anchor commitment supersedes the locality the soft anchor pointed to, or when the producing participant withdraws it. Expired soft anchors are not retained as historical artifacts; the disclosed construction is explicit that soft anchors leave no auditable trace beyond the lookups they served. Auditability of the protocol's behavior depends on hard anchors, not on soft anchors, and the boundary between the two regimes is precisely the boundary of the audit surface.

Operating Parameters

The soft-anchor regime exposes a small set of operating parameters tuned to the participant's workload and the deployment's tolerance for stale lookups. The sketch width and depth governing the inferred-signature computation are selected based on the cardinality of the locality space; wider sketches reduce false matches at the cost of memory and transmission overhead. Confidence-estimate calibration is performed empirically: a participant tracks the rate at which its soft anchors validate versus invalidate and adjusts the threshold above which an anchor is considered actionable.

Time-to-live is selected against the deployment's expected rate of locality drift. In a deployment where agent lineages are long-lived and access patterns concentrate stably, soft anchors may live for tens of seconds without significant invalidation. In a deployment where lineages are ephemeral and access patterns shift rapidly, soft anchors live for hundreds of milliseconds. The protocol does not impose a single time-to-live; each participant selects its own and advertises it alongside the anchor.

Cache size is the third parameter. A larger cache improves hit rate at the cost of memory and increases the surface area over which a stale anchor may persist undetected. A smaller cache forces more fall-backs to the hard-anchor path. The disclosed construction does not require any particular eviction policy; least-recently-used, least-frequently-used, and confidence-weighted policies have all been tested and yield qualitatively similar behavior.

Hard-anchor refresh cadence is the final parameter and determines how often a participant produces fresh hard anchors that supersede prior soft-anchor activity. Frequent refresh tightens the bound on how stale a soft-anchor-driven decision can become before a hard-anchor lookup corrects it; infrequent refresh reduces the cost of producing hard anchors but extends the period during which soft anchors operate without authoritative correction. Refresh cadence is typically aligned with the deployment's commit interval rather than tuned independently.

The protocol additionally exposes a fall-back budget: the maximum fraction of lookups in any window that may resolve through the hard-anchor path. The fall-back budget is not a strict cap but a signal; consistent breach of the budget indicates that soft-anchor calibration has degraded and triggers re-tuning of the upstream parameters. Healthy deployments operate well below their fall-back budget for the majority of their workload.

Alternative Embodiments

The construction admits several alternative embodiments that preserve the soft-versus-hard separation while varying the implementation. In a first embodiment, soft anchors are derived from a Bloom-filter-like sketch of recent access keys, with the sketch maintained per participant and gossipped opportunistically to neighbors. This embodiment minimizes coordination overhead and performs well when locality patterns are stable across small neighborhoods.

In a second embodiment, soft anchors are derived from a count-min sketch over agent-lineage features, with the sketch parameterized to favor recent observations. This embodiment is more expressive than the Bloom variant and is appropriate where the locality space is structured by lineage rather than by raw key frequency.

In a third embodiment, soft anchors are produced by a learned model that ingests recent access history and emits locality predictions with calibrated confidence. The learned-model embodiment achieves the highest hit rates in deployments with rich access histories but introduces a training surface that other embodiments avoid.

In a fourth embodiment, hard anchors are produced lazily, on demand, when a soft-anchor invalidation cascades into a sustained miss. This embodiment minimizes hard-anchor production cost at the expense of higher tail latency on invalidation.

In a fifth embodiment, the soft-anchor cache is shared across a cluster of cooperating participants through a gossiped overlay. Shared-cache deployments achieve higher aggregate hit rates than per-participant caches but require participants to trust one another's confidence estimates; the disclosed construction defends against estimate inflation through reputation feedback on the gossip channel.

Composition with Adjacent Primitives

Soft-index anchors compose with the other primitives of the memory-native protocol stack to produce a system whose behavior is more than the sum of its parts. Soft anchors compose downward with the agent-lineage primitive that supplies the features from which they are inferred; without lineage as a feature surface, soft anchors would degenerate to caches over raw keys, losing the semantic locality that gives the construction its hit-rate advantage.

Soft anchors compose laterally with the trust-weighted-routing primitive disclosed in the same family. A routing decision that consults a soft anchor for locality and a trust score for path selection completes in the time of the slower of the two computations, which in healthy deployments is the trust scoring rather than the soft-anchor lookup. The compositional payoff is asymmetric: soft anchors accelerate lookups that trust-weighted routing then directs across paths whose trustworthiness is independently established.

Soft anchors compose with the hard-anchor commitment primitive that defines the audit surface. The protocol's audit guarantees are computed from hard anchors only; soft anchors leave no audit trace and contribute no audit guarantee. This separation is structural and intentional. A licensee that confuses the two regimes by attempting to audit soft-anchor activity will discover that the construction does not support the inquiry; that limitation is a feature, not an oversight, because retaining soft-anchor history would undo the cost advantage that motivates the regime.

Soft anchors compose upward with the policy-evaluation primitive that consumes lookup results. Policies that gate disclosure, replication, or escalation may inspect whether a particular result was reached via a soft or a hard anchor and apply differential treatment. A high-stakes policy may require a hard-anchor confirmation before acting; a low-stakes policy may proceed on a soft-anchor result without confirmation. The protocol exposes the regime as metadata on the lookup result.

Prior-Art Distinctions

The soft-index-anchor construction is distinguishable from prior caching, indexing, and routing work along several axes. Distributed hash tables organize keys into a hierarchical container space and route by partial-key match; the soft-anchor construction does not impose a container hierarchy and routes by inferred locality, which captures correlations that container hierarchies cannot. The distinction is not merely architectural but functional: a DHT cannot represent the kind of probabilistic, lineage-derived locality that soft anchors express.

Cache hierarchies in conventional networking distinguish between fast and slow tiers but do not maintain a structural separation between probabilistic and cryptographically committed entries. The soft-anchor construction is not a cache tier; it is a regime, with its own confidence semantics, its own expiration semantics, and its own composition rules with the audit surface.

Bloom-filter and sketch-based routing accelerate lookups using probabilistic data structures but lack the explicit hard-anchor fall-back that the disclosed construction defines. A pure-sketch system either accepts false positives without a correction mechanism or augments the sketch with a separate verification path that is not coordinated with the sketch's lifecycle. The soft-anchor construction integrates the two paths into a single mechanism.

Content-addressable storage networks bind retrieval to cryptographic digests of content; they offer the verification guarantees that soft anchors deliberately do not provide. Soft anchors are not a substitute for content-addressable storage; they are a complementary regime that accelerates lookups whose results will, in audit-relevant cases, be confirmed against content-addressable references through the hard-anchor path.

Predictive prefetching in operating systems and storage stacks uses access-pattern inference to anticipate future requests but does not expose the predictions as first-class routing artifacts that participate in protocol-level decisions. Soft anchors are first-class artifacts produced by participants and consumed by the protocol's routing logic.

Disclosure Scope

The disclosure of Provisional 64/050,895 and continuation US 19/366,760 covers the soft-index-anchor construction as a structural primitive within the memory-native protocol, including the inference of soft anchors from agent lineage and access patterns, the explicit confidence and time-to-live semantics, the coexistence with cryptographically committed hard anchors, and the protocol-level routing logic that consults soft anchors first and falls back to hard anchors as confidence and validity require. The disclosure encompasses the alternative embodiments described above, including Bloom-sketched, count-min-sketched, learned-model, lazy-hard-anchor, and gossip-shared-cache variants.

The disclosure does not constrain the specific sketch family, the specific confidence-calibration procedure, or the specific time-to-live value beyond the structural requirements that soft anchors are ephemeral, probabilistic, and protocol-visible. Implementers are free to select sketch and calibration primitives appropriate to their workload. The disclosure also does not constrain the application domain; the soft-index-anchor construction has been instantiated for routing, retrieval, and discovery workloads without modification.

Outside the disclosure are pure-cryptographic-anchor systems that lack the probabilistic regime, pure-sketch systems that lack the cryptographic fall-back, and indexing constructions that conflate soft and hard regimes by attempting to audit soft-anchor activity. 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.