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:

```text
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:

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

For out-of-order events:

```text
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:

```text
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:

```text
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:

```text
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:

```text
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:

```text
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.