tidaldb/docs/legal/tidaldb-patent-proposal.md

tidalDB Patent Proposal / Invention Disclosure

Prepared for patent counsel review. This is an engineering invention disclosure and claim-strategy proposal, not legal advice and not a formal patent application.

Date prepared: 2026-06-22

Project: tidalDB, an embeddable Rust database for personalized content retrieval and ranking.

Recommended first filing: a U.S. provisional utility application covering the combined system, with dependent embodiments for the lower-level data structures.

Working title:

Embedded ranking database with online multi-interest user profiles, decayed signal materialization, and scope-aware vector retrieval

Short version for counsel:

tidalDB is a single-process, embeddable database specialized for personalized content ranking. It replaces the usual distributed stack - event log, cache, feature store, vector database, text search, and ranking service - with one event-sourced database. The strongest patentable contribution is not any single formula. It is the concrete combination of:

1. A WAL-backed ranking database whose engagement events update multiple materialized ranking states immediately.
2. A lock-free per-entity signal ledger that maintains exponentially decayed signal scores in O(1) using atomic floating-point bit patterns.
3. A database-owned online multi-interest preference materializer that maintains multiple per-user interest vectors, each with adaptive learning state and forward-decayed importance.
4. A query executor that converts the top-M decayed interest clusters into multiple ANN searches, merges by best vector distance, then applies signal-based and personalization scoring in one ranking pipeline.
5. Scope-aware filtered vector retrieval that uses database-maintained bitmap predicates during ANN traversal so structured filters do not collapse recall.

The recommended claim strategy is to lead with the combined ranking-database system and use the formulas, atomics, query fanout, and persistence details as dependent claims. The isolated formulas have substantial prior art risk; the database-specific composition is the stronger invention.

1. Filing Recommendation

File one broad provisional first, then decide after prior-art search whether to split the later non-provisional strategy into separate application families or continuations.

Recommended provisional scope:

• Primary family: embedded ranking database with WAL-driven materializers for decayed signals, preference state, relationship state, text/vector retrieval, filtering, ranking, and feedback-loop updates.
• Secondary family: online multi-interest user preference materializer with cold-start single-vector fallback, threshold-split clustering, per-cluster adaptive learning rate, decayed cluster importance, top-M fanout, best-distance ANN merge, and max-over-clusters personalization scoring.
• Secondary family: lock-free O(1) forward-decayed signal ledger using atomic bitwise floating-point storage, timestamp-aware CAS retry semantics, and out-of-order event handling.
• Secondary family: scope-aware ANN retrieval integrated with database bitmaps and ranking profiles, including filtered graph traversal plus fallback strategies.

Counsel should decide whether to file as:

• One provisional with multiple invention groups, preserving filing date for all disclosed embodiments; or
• Multiple provisional applications if restriction risk or ownership strategy favors separation.

USPTO timing points for counsel:

• A provisional application does not require formal claims, an oath/declaration, or an information disclosure statement, and it is not examined.
• A provisional can establish an early effective filing date for a later non-provisional application.
• A corresponding non-provisional generally must be filed within 12 months to preserve the provisional benefit.
• USPTO cautions that pre-filing public disclosure, while sometimes protected in the United States within a grace period, may preclude patenting in foreign countries.
• The provisional disclosure should be as complete as possible because later claimed subject matter needs support in the provisional.

Do not publicly disclose this document, the implementation details, benchmark claims, or diagrams until counsel advises on filing. If any repository, demo, blog post, investor memo, or customer conversation has already publicly disclosed these details, list the exact dates for counsel. U.S. rules may allow a limited grace period, but many foreign jurisdictions are stricter.

2. Implementation Status

The following implementation status is based on the local tidalDB worktree as of 2026-06-22. Some files are modified or untracked in the current working tree, so the filing packet should preserve a snapshot, commit hash, or archive before any more refactoring.

Implemented and tested:

• Lock-free decayed signal hot tier.
• Canonical forward-decay kernel with in-order and out-of-order event handling.
• Single-vector adaptive learning-rate preference updates.
• Multi-vector preference store with cold-start tier, online clustering, decayed cluster importance, top-M query vectors, checkpoint/restore, and legacy row compatibility.
• Multi-vector ANN candidate fanout and best-distance merge.
• USearch filtered search wrapper and scope-bitmap use in SEARCH.

Narrow verification commands run on 2026-06-22:

cargo test -p tidaldb multi_preference --lib
Result: 24 passed, 0 failed.

cargo test -p tidaldb usearch_filtered_search --lib --test vector_usearch
Result: 2 passed, 0 failed.

Important not-yet-complete or lower-confidence areas:

• Full end-to-end integration tests for multi-vector for_user retrieval should be added before making aggressive commercial performance claims.
• Periodic medoid reclustering is designed in research notes but not implemented.
• A full selectivity-based adaptive vector query planner is described in research but should not be represented as fully built unless counsel is filing on a planned embodiment.
• Benchmarks at 1M to 10M vectors and realistic filter selectivities should be produced before using exact performance numbers in prosecution or marketing.

3. Technical Problem

Personalized content platforms repeatedly build the same distributed ranking architecture:

• Search engine for text retrieval.
• Vector database for semantic retrieval.
• Event log for engagement ingestion.
• Cache or feature store for hot counters and user features.
• Stream processors for decayed/trending signals.
• Ranking service to join all signals and produce an ordered feed.

This stack causes stale features, lag between engagement and ranking changes, inconsistent filter semantics between text/vector retrieval, cache invalidation failures, high operational cost, and weak user-control semantics.

Conventional general-purpose databases do not model ranking as a primitive. They store rows and indexes, but they do not treat signals, decayed engagement, personalized interest state, cohort scoping, negative feedback, diversity, and ranking profiles as one coherent query/update system.

Existing recommender systems often solve parts of this problem, but outside the database:

• Multiple user embeddings or multi-interest representations are generated in ML systems or batch jobs.
• Decayed engagement scores are maintained in streaming systems, caches, or ranking services.
• Vector retrieval and structured filtering are handled by vector databases or search engines separate from the event log and feature store.
• Ranking pipelines join stale snapshots from many systems.

The tidalDB invention is a database system that owns the feedback loop: a signal write updates the ranking state, and the next query can immediately use that state without ETL, cache sync, or a separate feature store.

4. Proposed Invention

The invention is an embeddable ranking database that treats content ranking as a database primitive. The database stores entities, embeddings, signal streams, relationships, user preference state, ranking profiles, filters, and query-time retrieval indexes. A single durable write path records engagement events and updates multiple derived ranking states. A single read path retrieves candidates, filters them, scores them, applies personalization and diversity, and returns a ranked result set.

The most important embodiment is:

1. Receive an engagement signal identifying at least a user, an item, a signal type, a timestamp, and a weight.
2. Append the signal to a durable write-ahead log.
3. Update a per-item hot signal state using O(1) forward decay.
4. Update a per-user preference materializer by assigning the item embedding to one of the user's online-maintained interest clusters or opening a new cluster.
5. Update per-cluster importance using the same forward-decay kernel used for signal scores.
6. On a personalized query, select the user's top-M active clusters by current decayed importance.
7. Issue one ANN retrieval per selected cluster vector.
8. Merge results by entity id, retaining the best vector distance across clusters.
9. Apply user-state filters, hard negatives, signal boosts, relationship boosts, personalization scoring, and diversity constraints.
10. Return a ranked list from a single database query.

This makes ranking state a database-managed materialized view over durable events, not application code.

5. Core Embodiments

5.1 Event-Sourced Ranking Database

The database treats the WAL as the source of truth and all ranking structures as materialized views. The same event can update:

• Global signal counters and decay scores.
• User preference profiles.
• User-item state such as seen, liked, saved, hidden, and hard-negative state.
• Relationship weights between users, creators, and items.
• Cohort-scoped counters.
• Session or agent-scoped context.

This is a system-level invention candidate. The concrete technical effect is that ranking-affecting writes and personalized ranking reads share one storage model and one consistency boundary.

Source evidence:

• VISION.md: single-node embeddable ranking database replacing the distributed ranking stack.
• docs/specs/00-architecture-overview.md: WAL as event stream; materialized views for signal ledger, preference vectors, relationships, cohorts, and indexes.
• docs/specs/03-signal-system.md: signal streams with native decay, velocity, and windowed aggregation.

Patent framing:

Claim this as a computer system and method, not as an abstract idea. Recite specific database structures: WAL records, materializers, atomic hot state, embedding slots, bitmap filters, ANN indexes, ranking profiles, checkpointed derived state, and query stages.

5.2 Lock-Free O(1) Forward-Decayed Signal Ledger

Each item/signal pair stores running decay scores rather than scanning raw events at query time. The hot state is cache-line aligned and uses atomic integers to hold floating-point values by bit pattern. Signal updates run CAS loops on the score slots and handle out-of-order events without regressing timestamps.

Current implementation details:

• tidal/src/signals/hot.rs: HotSignalState is #[repr(C, align(64))], exactly one cache line, with decay_scores: [AtomicU64; 3].
• Scores are encoded by f64::to_bits() and decoded by f64::from_bits().
• on_signal() updates each decay lane with a CAS loop.
• The timestamp is re-read inside each score retry loop to keep the (old_score, last_update_ns) pair consistent under contention.
• tidal/src/signals/decay.rs: forward_decay_step() centralizes in-order and out-of-order decay arithmetic.

Mathematical behavior:

For in-order events:

S(t_event) = S(t_prev) * exp(-lambda * (t_event - t_prev)) + weight

For out-of-order events:

S = S + weight * exp(-lambda * (t_prev - t_event))

The timestamp advances only for in-order events.

Why this matters:

• Read-time ranking does not scan event logs.
• Signal writes do not block ranking reads.
• Multiple decay rates can be tracked for the same signal.
• Late events can be folded into the running score without replay.

Patent strength:

Moderate as a standalone claim. Forward decay and CAS loops are known. Stronger as a dependent claim in a ranking database that combines lock-free decayed signals with immediate user-preference materialization and personalized retrieval.

Possible dependent claim elements:

• Cache-line-aligned per-entity signal state.
• Multiple atomic floating-point decay lanes stored as integer bit patterns.
• Per-lane CAS retry using a reloaded timestamp to avoid stale decay intervals.
• Out-of-order event folding by pre-decaying event weight without timestamp regression.
• Read path applying one additional forward decay from stored anchor time to query time.

5.3 Online Multi-Interest Preference Materializer

This is the strongest individual invention hook.

The database maintains multiple interest vectors per user directly on engagement writes. The system starts with a single adaptive learning-rate vector for cold start. After a threshold number of positive interactions, the cold-start vector seeds the first cluster. Each later positive engagement is assigned to the nearest cluster by cosine similarity; if no cluster is sufficiently similar and the cluster cap has not been reached, a new cluster is opened. Each cluster has its own centroid, update count, adaptive learning rate, decayed importance, and anchor timestamp.

Current implementation details:

• tidal/src/entities/preference.rs: single-vector adaptive EMA with alpha = base / (1 + ln(count + 1)).
• tidal/src/entities/multi_preference.rs: multi-vector store.
• Cold start threshold: COLD_START_N = 5.
• Cluster cap: K_MAX = 10.
• Default split threshold: cosine 0.55.
• Default top-M serve-time clusters: 3.
• Default cluster-importance half-life: 30 days.
• Per-cluster adaptive learning rate uses the same logarithmic formula as the single-vector tier.
• Cluster importance is decayed by the same canonical forward_decay_step() kernel used by the signal ledger.
• Query vectors are the top-M clusters by current decayed importance.
• Candidate personalization scoring uses max cosine over clusters, not cosine against a single averaged vector.
• Checkpoint/restore stores version-tagged multi-cluster rows and reads legacy single-vector rows as cold-start K=1 rows.

Key novelty argument:

Prior art teaches multi-vector user representations, but generally as model outputs or offline/batch recommender-system features. tidalDB's implementation is a database materializer:

• It updates online in the database write path.
• It is derived from durable engagement events.
• It is persisted and restored by the database checkpoint system.
• It uses per-cluster forward-decayed importance so stale interests naturally fall out of top-M retrieval.
• It drives ANN candidate generation in the database query executor.
• It is coupled to signal scoring, user-state filtering, hard negatives, and ranking profiles.

Possible dependent claim elements:

• Cold-start single-vector tier that becomes the K=1 seed for multi-cluster preference state.
• Per-user adaptive cluster count using a threshold split rule.
• Per-cluster adaptive learning rate based on the cluster's own update count.
• Per-cluster forward-decayed importance using the same decay kernel as item signal scores.
• Query-time deterministic top-M cluster selection by decayed importance.
• Max-over-clusters personalization scoring.
• Version-tagged checkpoint format with legacy single-vector compatibility.
• Dropping torn cluster tails during restore while preserving valid prefix clusters.

5.4 Multi-Vector ANN Fanout and Merge

For personalized retrieval, the database resolves one or more query vectors from the user's interest clusters and issues one ANN search per selected cluster. The results are merged by entity id, retaining the best vector distance. Final ranking remains the job of the ranking pipeline; vector distance is a retrieval signal, not the final score.

Current implementation details:

• tidal/src/db/query_ops.rs: resolves similar_to, warm for_user, cold for_user, and anonymous query cases.
• Warm for_user resolves top-M cluster centroids from the multi-vector preference store.
• tidal/src/query/executor/candidate_gen.rs: ann_candidates_multi() issues one search per query vector, deduplicates by best distance, sorts closest first, and truncates to the candidate limit.
• tidal/src/query/executor/pipeline.rs: prefers the multi-vector fanout set when present and falls back to single-vector search or scan.
• tidal/src/ranking/profile.rs: CandidateStrategy::Ann includes top_clusters, with a serde default for backward compatibility.
• tidal/src/ranking/builtins.rs: for_you uses top-M fanout; related uses a single seed-item vector.

Patent strength:

Moderate alone because PinnerSage and other recommender systems issue multiple retrieval queries for multiple user interests. Stronger in combination with the database-owned online materializer, decayed cluster importance, and integrated ranking query executor.

Possible dependent claim elements:

• Profile-configured fanout width.
• Automatic selection of fanout for for_user and suppression of fanout for similar_to.
• Per-cluster ANN over a shared item embedding index.
• Merge by minimum distance before ranking-stage signal scoring.
• Single-vector path remaining byte-equivalent when only one cluster is active.
• Fallback to scan when no preference vector or vector index is available.

5.5 Scope-Aware Filtered ANN Retrieval

The database uses scope bitmaps and Rust predicates to constrain ANN retrieval during vector search, rather than retrieving unfiltered neighbors and filtering afterward. This is important because post-filtering can collapse recall when the predicate selects only a small fraction of the vector corpus.

Current implementation details:

• tidal/src/storage/vector/usearch_index.rs: wraps USearch filtered_search with a Rust predicate closure.
• tidal/src/query/search/executor/pipeline.rs: if a scope bitmap exists, calls filtered_search(query_vector, k, ef_search, |id| bitmap.contains(id)).

Patent strength:

Weak if claimed as "USearch callback from Rust" because USearch's public Rust API already exposes filtered_search with a custom closure. Stronger if claimed as a database query-planning composition:

• Database-maintained metadata/user/cohort scope bitmaps.
• Predicate-filtered ANN traversal.
• Separate BM25 and ANN branches fused in one search pipeline.
• Ranking-profile scoring after retrieval.
• Optional fallback to scan or brute force based on selectivity.

Possible dependent claim elements:

• Scope bitmap constructed from user state, cohort state, metadata filters, or policy filters.
• Predicate excludes ids not representable in the bitmap domain.
• ANN candidate generation respects scope during traversal.
• Fallback strategy when filtered ANN returns insufficient results.

6. Representative Claim Strategy

Counsel should draft formal claims. The following is only engineering scaffolding.

Independent Claim Candidate A - System

A computer-implemented database system comprising:

• A durable log configured to store engagement events for content entities.
• A signal materializer configured to maintain, for each content entity and signal type, a running decayed score and timestamp.
• A preference materializer configured to maintain, for each user, a plurality of interest clusters, each cluster including a vector representative, an update count, a decayed importance value, and an importance timestamp.
• A vector retrieval index storing embeddings for content entities.
• A query executor configured to select a subset of the user's interest clusters according to current decayed importance, issue vector nearest-neighbor searches using the selected cluster vectors, merge results by best vector distance, and rank the merged results using signal scores and personalization scores.

Technical hooks to include:

• The signal materializer updates scores in O(1) without scanning event history.
• The preference materializer updates online in response to the same engagement events recorded in the durable log.
• Cluster importance uses a forward-decay computation.
• The query executor returns results from one database query without an external feature store or ranking service.

Independent Claim Candidate B - Method

A method for personalized content retrieval comprising:

1. Recording an engagement event in a database log.
2. Updating an atomic decayed signal score for an item referenced by the event.
3. Updating a user preference materializer by assigning an item embedding to one of multiple user-interest clusters or creating a new cluster.
4. Updating an importance value for the assigned cluster using an exponential forward-decay rule.
5. Receiving a ranking query for the user.
6. Selecting top-M clusters based on current decayed importance.
7. Searching a vector index with each selected cluster vector.
8. Merging vector-search results by retaining, for each item, a best vector distance across searches.
9. Computing final ranking scores from decayed signals and user preference similarity.
10. Returning an ordered result set.

Independent Claim Candidate C - Non-Transitory Medium

A non-transitory computer-readable medium storing instructions that cause one or more processors to perform the method of Claim Candidate B.

Dependent Claim Candidates

Preference materializer:

• The user remains in a single-vector cold-start tier until a threshold number of positive interactions is reached.
• The first cluster is seeded from the cold-start vector.
• A new cluster is created when a candidate embedding's best cosine similarity to existing clusters is below a threshold and the cluster cap has not been reached.
• If the cap is reached, the embedding is assigned to the nearest existing cluster.
• Each cluster has its own logarithmically decaying adaptive learning rate.
• The current cluster importance is computed by decaying an anchored importance value from an anchor timestamp to query time.
• The query uses deterministic top-M clusters rather than a stochastic sample.
• The personalization score for an item is a maximum similarity over the user's clusters.

Signal materializer:

• Decayed signal scores are stored as bit representations of floating-point values in atomic integer fields.
• A compare-and-swap loop updates each score.
• A timestamp is re-read inside each retry loop.
• Out-of-order events are folded by pre-decaying the event weight without regressing the last-update timestamp.
• The hot signal state is aligned to one cache line.
• Multiple decay rates are stored per entity/signal cell.

ANN retrieval:

• A profile parameter controls the number of interest clusters used for ANN fanout.
• Fanout is enabled for user-personalized retrieval and disabled for seed-item-related retrieval.
• Results from multiple ANN searches are deduplicated by entity id and keep the minimum vector distance.
• A scope bitmap predicate is applied during ANN traversal.
• The system falls back to scan retrieval when no query vector, no index, or no ANN results are available.

Persistence and recovery:

• Multi-cluster preference rows include a format-version sentinel.
• Legacy single-vector rows restore as cold-start user state.
• A malformed or torn cluster tail is dropped while preserving earlier clusters.
• Restored vectors are normalized and NaN-neutralized before use in scoring.

7. Prior Art and Distinguishing Arguments

Counsel should perform a professional patentability search. The following is an engineering prior-art map to guide that search.

7.1 PinnerSage

Reference:

• Pal et al., "PinnerSage: Multi-Modal User Embedding Framework for Recommendations at Pinterest", KDD 2020 / arXiv 2020.
• URL: https://arxiv.org/abs/2007.03634

Relevant teachings:

• A single user embedding is insufficient for multi-modal user interests.
• User actions are clustered into coherent clusters.
• Clusters are represented by medoids.
• Multiple user-interest vectors are used for recommendation retrieval.
• System deployed in production at Pinterest.

Risk:

This is the biggest prior-art risk for broad "multi-vector user embedding" claims.

Distinctions:

• PinnerSage is an external recommender-system embedding framework, not an embeddable database materializer.
• PinnerSage uses offline Ward hierarchical clustering and medoids; tidalDB's implemented embodiment uses online threshold-split centroids updated on engagement writes.
• tidalDB composes interest clusters with database-managed forward-decayed importance, WAL/checkpoint persistence, ranking profiles, filters, and immediate query execution.
• tidalDB supports cold-start single-vector migration to multi-cluster state in the database.

Claim guidance:

Do not claim "representing a user with multiple vectors" broadly. Claim the database-managed online materializer and query executor combination.

7.2 MIND / Multi-Interest User Networks

Reference:

• Li et al., "Multi-Interest Network with Dynamic Routing for Recommendation at Tmall", arXiv 2019.
• URL: https://arxiv.org/abs/1904.08030

Relevant teachings:

• A user can be represented by multiple vectors.
• Multiple interests can be extracted from behavior sequences.
• Multi-interest vectors can be used in a matching stage before ranking.

Risk:

Broad multi-interest representation for recommender systems is not novel.

Distinctions:

• MIND is a neural network architecture using capsule routing, not a database materialized state system.
• tidalDB does not train or infer multiple interests from a model; it maintains clusters online from engagement writes inside a database.
• tidalDB's clusters carry decay anchors, checkpoint state, and query-planning semantics.

Claim guidance:

Emphasize online database update, durable event derivation, decayed importance, and ranking-query integration.

7.3 Filtered ANN / ACORN / Vector Databases

References:

• Patel et al., "ACORN: Performant and Predicate-Agnostic Search Over Vector Embeddings and Structured Data", arXiv 2024.
• URL: https://arxiv.org/abs/2403.04871
• USearch Rust API documentation for filtered_search.
• URL: https://docs.rs/usearch/latest/usearch/struct.Index.html

Relevant teachings:

• Filtered vector search is a known problem.
• Predicate-aware HNSW traversal is a known approach.
• USearch already exposes a filtered_search closure in Rust.

Risk:

The FFI predicate trampoline alone is not a strong novelty hook.

Distinctions:

• tidalDB uses filtered ANN inside an embedded ranking database that also owns signal ledgers, user state, preference clusters, ranking profiles, and scoped filters.
• The searchable scope can be database-derived from user history, hard negatives, cohort predicates, metadata indexes, or policy state.
• Search results feed a ranking pipeline that combines text, vector, signal, and personalization evidence.

Claim guidance:

Do not claim USearch's callback. Claim the database-level query-planning composition and scope-bitmap integration.

7.4 Forward Decay / Time-Decayed Streams

Relevant teachings:

• Exponential time decay for streaming aggregates is known.
• Maintaining running decayed scores is a known mathematical transformation.

Risk:

The formula alone is not enough.

Distinctions:

• tidalDB embeds decayed scores in a per-entity ranking hot tier.
• It uses atomic bitwise floating-point storage and CAS update loops.
• It handles out-of-order events in the same kernel used by multiple database materializers.
• It combines decayed item signals and decayed preference-cluster importance in one query/ranking architecture.

Claim guidance:

Claim the concrete memory layout, concurrency semantics, and ranking-database use, not the exponential formula by itself.

8. Subject-Matter Eligibility Notes

Patent counsel should frame the claims as a concrete database technology improvement. Avoid claims that read as "recommend content using preferences" or "rank items with decay". The claims should recite data structures, event processing, concurrency, vector retrieval, and query execution.

Useful concrete technical effects:

• Reduced need to recompute decayed scores by scanning event logs.
• Reduced staleness between engagement write and personalized read.
• Reduced latency/operational complexity by performing ranking materialization in one embedded database process.
• Improved retrieval coverage for multi-modal users by avoiding a single averaged preference vector.
• Improved filtered vector-retrieval recall by applying scope predicates during traversal rather than after retrieval.
• Improved crash recovery and backward compatibility for derived preference state.

USPTO baseline:

• USPTO says utility patents require usefulness, enablement, novelty, and non-obviousness, and that abstract ideas cannot be patented.
• URL: https://www.uspto.gov/patents/basics/essentials
• USPTO subject-matter eligibility guidance points practitioners to MPEP 2103-2106.07 and recent AI eligibility guidance.
• URL: https://www.uspto.gov/patents/laws/examination-policy/subject-matter-eligibility

9. Enablement Map for Counsel

The following files show the invention is not merely aspirational.

Multi-interest preference:

• tidal/src/entities/multi_preference.rs
  • Lines 1-46: module-level design summary.
  • Lines 54-88: cold-start threshold, cluster cap, split threshold, top-M, and importance half-life.
  • Lines 99-118: cluster fields.
  • Lines 285-340: engagement update, cold-start migration, and cluster routing.
  • Lines 370-386: max-over-clusters cosine scoring.
  • Lines 411-434: top-M query vector selection by decayed importance.
  • Lines 490-520: threshold assign-or-split.
  • Lines 553-656: checkpoint and restore.
  • Lines 661-759: versioned encoding, legacy decode, normalization, adaptive learning-rate helper.

Single-vector fallback:

• tidal/src/entities/preference.rs
  • Lines 92-125: adaptive learning-rate EMA.
  • Lines 228-260: restored update counts and legacy row append support.

Decayed signal ledger:

• tidal/src/signals/hot.rs
  • Lines 1-13: lock-free O(1) running decay rationale.
  • Lines 48-70: cache-line-aligned struct and atomic decay slots.
  • Lines 147-204: CAS update loop and timestamp advance semantics.
• tidal/src/signals/decay.rs
  • Lines 66-123: canonical in-order/out-of-order forward-decay kernel.

ANN fanout:

• tidal/src/db/query_ops.rs
  • Lines 163-210: resolving seed, warm-user, cold-user, and anonymous ANN query vectors.
• tidal/src/query/executor/candidate_gen.rs
  • Lines 132-209: multi-vector ANN search and best-distance merge.
• tidal/src/query/executor/pipeline.rs
  • Lines 151-224: use of fanout candidates and scan fallback.
• tidal/src/ranking/profile.rs
  • Lines 104-118: CandidateStrategy::Ann with top_clusters.
• tidal/src/ranking/builtins.rs
  • Lines 293-306: for_you top-M fanout.
  • Lines 364-375: related single-vector path.

Filtered ANN:

• tidal/src/storage/vector/usearch_index.rs
  • Lines 322-355: Rust predicate wrapper around USearch filtered search.
• tidal/src/query/search/executor/pipeline.rs
  • Lines 425-434: scope-bitmap predicate during ANN search.

Research/design support:

• docs/research/multi-vector-preference.md: compares offline medoid, online centroids, and hybrid periodic recluster; recommends online now with future medoid snap.
• docs/research/ann_for_tidaldb.md: vector index selection, filtered ANN context, multi-vector retrieval discussion.
• docs/research/tidaldb_signal_ledger.md: signal-ledger architecture, running decay scores, and storage tiers.

10. Suggested Figures

Counsel may want drawings for a provisional or non-provisional application.

Figure 1 - Overall system:

Application
  -> tidalDB write API
  -> WAL
  -> materializer fanout
       -> signal ledger
       -> user preference clusters
       -> relationship state
       -> user state / hard negatives
       -> cohort counters
  -> query executor
       -> text / ANN / signal candidate generation
       -> filters
       -> personalization and signal scoring
       -> diversity
       -> ranked results

Figure 2 - Multi-interest user update:

positive engagement
  -> load item embedding
  -> if user interaction count < N:
         update cold-start EMA vector
     else:
         seed first cluster from cold-start vector if crossing threshold
         find nearest cluster by cosine
         if best cosine < threshold and K < Kmax:
             create new cluster
         else:
             blend into nearest cluster with per-cluster adaptive LR
         update cluster importance by forward decay

Figure 3 - Personalized query fanout:

FOR USER query
  -> compute current decayed importance of each cluster
  -> select top-M cluster vectors
  -> ANN search per cluster vector
  -> merge by entity id, keep best distance
  -> filter seen/blocked/hard-negative items
  -> score by decayed signals + max cluster cosine + relationships
  -> diversity selection
  -> result list

Figure 4 - Atomic decayed signal cell:

64-byte hot state:
  entity id
  last update timestamp (AtomicU64)
  signal type id / flags
  decay score 0 as AtomicU64(f64 bits)
  decay score 1 as AtomicU64(f64 bits)
  decay score 2 as AtomicU64(f64 bits)

on signal:
  load timestamp
  for each decay lane:
      load score bits
      compute forward_decay_step
      CAS score bits
      retry with fresh timestamp on CAS failure
  CAS timestamp if event was in-order

11. Commercial Value / Product Claim

The practical benefit is not just recommendation quality. It is operational simplification for any application that currently assembles personalized content ranking from multiple systems.

Potential markets:

• Social feeds.
• Media libraries.
• Marketplaces.
• Creator platforms.
• Search/discovery surfaces.
• AI-agent memory and retrieval systems.
• Enterprise knowledge retrieval with user/session preference state.

Customer-visible advantages:

• One embedded database rather than separate event log, cache, feature store, vector database, search engine, and ranking service.
• Fresher personalization because engagement writes immediately update ranking state.
• Better handling of multi-modal user interests.
• Native decay, velocity, windowed aggregation, user state, hard negatives, and diversity constraints.
• Lower operational burden for small teams building sophisticated ranking surfaces.

12. Attorney Questions

Ask counsel to evaluate:

1. Should the first filing be one broad provisional or several provisionals?
2. Which claims should be drafted as system claims vs method claims vs computer readable medium claims?
3. How should the claims avoid Alice/abstract-idea risk?
4. How much of the unimplemented roadmap should be disclosed as alternative embodiments?
5. Does the current implementation or repository history create any public disclosure dates?
6. Who are the correct inventors for each invention group?
7. Does any employment, contractor, open-source, or company agreement affect ownership?
8. Should the filing include source-code appendices, pseudocode, or only algorithmic descriptions?
9. Should foreign/PCT rights be preserved, and on what timeline?
10. Should benchmarking data be generated before non-provisional filing?

13. Information Counsel Will Need

Prepare these before the attorney meeting:

• Names and citizenship/residence of inventors.
• Assignment entity, if any.
• Dates of conception for:
  • decayed signal ledger;
  • adaptive preference vector;
  • multi-vector preference materializer;
  • ANN fanout merge;
  • filtered ANN scope bitmap integration.
• Dates of first reduction to practice.
• Git commit hashes or tarball snapshots for implementation evidence.
• Whether the repo has ever been public.
• Any demos, blog posts, pitch decks, customer conversations, Discord/Slack messages, or tweets that disclosed technical details.
• Whether contributors used any third-party code or generated code that affects ownership.
• Benchmark plans or existing benchmark outputs.

14. Recommended Attorney Summary Email

Subject: Patent review request - tidalDB embedded ranking database

Body:

I would like your help evaluating a provisional patent filing for tidalDB, an
embeddable Rust database designed for personalized content ranking.

The strongest invention appears to be a database-managed feedback loop where
engagement events update decayed signal state and online multi-interest user
preference state, and personalized queries use the user's top decayed interest
clusters for ANN candidate fanout before ranking with signal and personalization
scores.

The attached disclosure includes implementation evidence, prior-art risks, and
possible claim elements. I am especially interested in whether we should file one
broad provisional covering the combined ranking database or split the decayed
signal ledger, multi-interest materializer, and filtered ANN query execution into
separate filings.

Please also advise on public-disclosure timing, foreign/PCT strategy, inventorship,
and how to draft the claims to avoid abstract-idea issues for software/database
technology.

15. Source List for Counsel

Official patent references:

• USPTO Patent Essentials: https://www.uspto.gov/patents/basics/essentials
• USPTO Provisional Application for Patent: https://www.uspto.gov/patents/basics/apply/provisional-application
• USPTO Subject Matter Eligibility: https://www.uspto.gov/patents/laws/examination-policy/subject-matter-eligibility

Technical prior art and context:

• PinnerSage: https://arxiv.org/abs/2007.03634
• MIND: https://arxiv.org/abs/1904.08030
• ACORN: https://arxiv.org/abs/2403.04871
• USearch Rust API: https://docs.rs/usearch/latest/usearch/struct.Index.html

Project documents:

• VISION.md
• docs/specs/00-architecture-overview.md
• docs/specs/03-signal-system.md
• docs/research/multi-vector-preference.md
• docs/research/ann_for_tidaldb.md
• docs/research/tidaldb_signal_ledger.md

16. Bottom-Line Assessment

Recommended attorney positioning:

Lead with:

A concrete database architecture for immediate personalized ranking updates, where durable engagement events maintain both decayed item signals and decayed multi-interest user preference clusters, and where ranking queries use those clusters to perform multi-vector candidate retrieval and final scoring inside one embeddable database.

Do not lead with:

• "We invented multi-vector recommendations."
• "We invented exponential decay."
• "We invented filtered HNSW."
• "We invented adaptive learning rates."

Those are prior-art-heavy. The invention is the combination, the database materialization boundary, the online update semantics, and the specific serving-path mechanics.