Concepts
Concepts
The ideas ysearch is built on, from the segment plane it inherited to the KV plane, pinned statistics epochs, and read-time matching it adds.
These pages explain how ysearch works and why. Each one opens with a status
line: what of it runs on main today, and which milestone brings the rest.
The normative text is the specification in the ysearch repository
(docs/ysearch/spec/); these pages summarise it for adopters.
| Page | What it covers | On main today |
|---|---|---|
| Why ysearch | The workload, the owner's requirements, and the choices they force | — |
| Architecture | The two planes, the roles, and how an article becomes matched | The inherited engine's roles |
| Segments and the catalog | Immutable segments on S3, catalog generations, what ysearch adds | Yes, inherited, plus formats 7 and 8 |
| Pinned statistics epochs | Read-time scoring, the epoch fold, G_chk, the drift bound, determinism |
The fold and bm25f-pinned-v1 (YS2) |
| Matching and dials | Campaigns, the match matrix, cells, tables, (α_c, τ_c) |
The YS3 matcher prototype: a library and an unmounted gRPC service |
| The KV plane | marekvs's CRDT design in Go on WavesDB, gossip, Raft leases | Pure building blocks (YS5) |
| Streams | Protobuf on Kafka-protocol topics, commit rules, exactly-once traffic | A throwaway prototype adapter (YS3) |
| Extensions | yexpr and WASM apps on the Component Model | No (YS8a, YS17) |
Figures marked (A) are assumptions from the specification, not measurements. They stay assumptions until the owner supplies real volumes or the YS4 qualification measures them.