The M1-M6 Pipeline
The mineable ABI contains six optional hooks. A miner may improve one hook or a combination. Any absent hook uses the deterministic reference implementation.
| Hook | Stage | Mineable responsibility |
|---|---|---|
| M1: ingest transform | Write | Normalize input and derive labels, salience, retention hints, and chunk metadata |
| M2: organize | Write | Resolve entities and aliases; derive relations, conflicts, corrections, and multi-hop structure |
| M3: consolidate | Write | Deduplicate, summarize, cluster, merge, and maintain compact derived memory |
| M4: candidates | Read | Produce a bounded candidate frontier for a query |
| M5: rank | Read | Order candidates using relevance, validity, time, conflicts, scope, and confidence |
| M6: pack | Read | Select and render the best evidence under the final context budget |
M3 operates as a scheduled phase. The portable agent integration invokes it at deterministic boundaries, including session end and configured event-count or storage-pressure triggers. Its output is available to the read path after validation and survives restart.
The six hooks form one composable pipeline. A useful improvement may, for example, add alias structure in M2, consume it during M4 candidate generation, apply temporal ordering in M5, and remove redundant evidence in M6. Combined candidates are supported and evaluated as one release.
Storage use, deterministic work, rendered context cost, and corpus-scale behavior are part of the evaluation surface where the active law defines them. Wall-clock latency is reported separately because it varies with hardware.
Fixed retrieval and initial modules in 1.1.0
The conversation profile uses hybrid-rrf60.bge-small-en-v1.5: BM25 plus the
release-pinned local bge-small ONNX encoder, fused with full-ranking RRF60 at the
existing M4 provider seam. Evaluation and the adapter use the same provider.
Weights, tokenizer, runtime payloads, ordering and fusion are fixed by the host;
miners continue improving M1–M6 modules, without supplying an encoder capability.
An M4 hook may call ctx.provider.candidates with permitted query reformulations.
The trusted host meters actual provider calls, encoding, vector scoring and fusion.
All three initial profile modules use ctx.ref_m5_rank to rank the authoritative
servable M4 candidates, removing the reference policy's 512-cell availability
limit and bounded prior-version retrieval restriction. The document module also
retains its accepted M6 packing override. Document and event retrieval remain
lexical/BM25. A direct reference-store API does not automatically adopt these
modules; use the public current-state consumer setup below.
Provider identity is machine-readable in the release-bound
objects/retrieval-config.json, obtained through the verified kit/release graph.
For each profile it names the descriptor and descriptor_root. Parent-vector
and schema responses currently omit that provider field; tooling should resolve
this object and verify its release hash rather than infer the provider from prose.