- Add BUILD.bazel across tidal, tidal-net, tidal-server, tidalctl for bzlmod build - Add tidal/ crate docs (README, CHANGELOG, CONTRIBUTING, AGENTS, CLAUDE, API, ARCHITECTURE) and ai-lookup reference - Add docker standalone/cluster/deploy images, compose, and prometheus config - Harden WAL (batch format, writer, dedup, diagnostics), text syncer/collectors, and vector registry - Expand tidalctl CLI and tests; restructure WAL/visibility integration test suites - Refine tidal-net transport/client/server and tidal-server cluster/scatter-gather
1.5 KiB
1.5 KiB
Signals
Last Updated: 2026-02-19 Confidence: High
Summary
Signals are typed, timestamped event streams attached to entity signal ledgers. The database natively understands signal semantics: velocity (rate of change), decay (exponential or linear, configurable per type), and windowed aggregation (last hour, day, 7 days, all time).
Key Facts:
- Signals are NOT fields — they are streams with temporal semantics
- Decay half-lives are declared in schema, applied at query time
- Velocity is computed natively (rate of new events in a window)
- Windowed aggregation: 1h, 24h, 7d, all-time windows are first-class
- Negative signals (skip, hide, block) are equal citizens with positive signals
- Signal writes are atomic transactions updating item ledger, user preference vector, and relationship weights in one commit
File Pointer: VISION.md:39-41, USE_CASES.md:669-711 (Appendix C)
Signal Categories
| Category | Examples | Decay |
|---|---|---|
| Positive engagement | view, like, share, completion | slow-medium |
| Negative engagement | skip, hide, block, not_interested | fast-permanent |
| Relationship | follow, unfollow, interaction_weight | slow-permanent |
| Quality | completion ratio, dwell_time, replay | slow-medium |
| Recommendation | autoplay_accept/reject, search_click | medium |
| Notification | notification_open, notification_dismiss | slow-medium |