The M1-M6 Pipeline
The mineable surface is six optional hooks:
| Hook | Plain role |
|---|---|
| M1 | Clean up and label incoming information |
| M2 | Link entities, spot relations and conflicts |
| M3 | Periodically tidy: deduplicate, summarize, consolidate |
| M4 | Gather candidate memories for a query |
| M5 | Rank those candidates |
| M6 | Pick and pack the best evidence into the context budget |
Conversation memory now combines keyword retrieval (BM25) with a fixed local
bge-small encoder using RRF60. This provider is host-owned: miners improve hooks,
not model weights. An M4 hook can reformulate a query through
ctx.provider.candidates; the host measures that work. Document and event
profiles still use keyword retrieval.
All three profiles start from M5 modules that rank the store's available candidates, fixing the old 512-cell retrieval limit. Documents also retain their M6 packing improvement. Your opponent is the current module, while the reference runtime still supplies the protected genesis floor.
A miner can improve one hook or several together. Any hook a release does not include falls back to a reference implementation. Storage, deterministic work, and packed-context cost are protected admission measurements alongside quality, so improvements have to be efficient, useful memory rather than clever bloat.