[gedaiu]

Part of #1277. Related: #1273 (search returns scores, which the blend multiplies), #1276 (reading a record back by its name), #1278 (the other proposed record in this series).

The record before code, as CONTRIBUTING asks for a data-model change. No code here.

What it proposes

0071, "Use decays; the ledger does not":

1. Salience is a side table keyed by target (fact by its open statement, so it survives rematerialization; document; chunk), created on the first signal; per-base defaults otherwise.
2. Pure arithmetic computed at read time: strength 0.5^(age / half_life), retrieval +2 days (cap 365), boost +5, penalize −3 (floor 7), score = strength × (0.5 + 0.5 × importance), stale by days since last read. Nothing derived is stored, and confidence is untouched.
3. Reads record what they returned (REST search, search_chunks, entity_facts, timeline), batched and off the request path, with record: false for probes and evals; an explicit API for retrievals (Viewer, read token), feedback and settings (Editor, write token), each audited.
4. Ranking: rrf × (1 + salience_weight × score) before truncation; weight 0, the default, is today's order exactly.
5. An hourly sweep, queued per base like the governance loop: expiry deletes a document or chunk reversibly and closes a fact on the world axis; a source over max_documents evicts its weakest; every action is an audit row.

Dead ends recorded: columns on facts/documents, lowering confidence, storing strength, counting candidates. Risks: popularity feeding itself, write volume. Open: fact re-ranking, chunk rows across a re-parse, salience across a correction, closed statements and their typed rows, feedback over MCP.

The README index lists it under chat-and-mcp, and chat-and-mcp.md lists it under "Proposed and not built".

[WaylandYang]

Thank you for writing this up so carefully. As I said on #1277, this isn't something we'll take on now, and #1271 and #1276 come first, so I'm holding this PR. Could you turn it into a draft, or close it and reopen when those have landed? Please also drop the 0071 number for now: records are numbered in the order they land, without gaps, and #1213 is still waiting for one. Take the next free number when you pick it up again.

Two things to bring along when you do:

• "Weight 0 is today" has to cover writes too. As written, every read in every base records retrievals, including bases that never turn salience on, and read-only tokens end up writing. I'd record only when a base opts in, or explain why that can't work.
• Expiry as a world-axis close says something no document said. "Forget this after a week" is about use, not about when the fact stopped holding. A fact past its expiry could drop out of retrieval while staying true on both axes; if you keep the close, the record needs to explain why it is a statement about the world.

Smaller: a typed row with several source statements (typed_fact_sources) shouldn't take only the first one's salience.

[gedaiu]

Understood, thanks. It's a draft now and the number is gone: the file is unnumbered, and the index row and the chat-and-mcp.md line are out, to come back with the next free number once #1271 and #1276 have landed.

I've noted your three points for when I pick it up: record retrievals only in a base that opts in (or say why that can't work), either drop expiry as a world-axis close or justify it as a statement about the world, and don't let a typed row with several source statements take only the first one's salience.

[gedaiu]

Thank you for reading it so closely, and understood: #1271 and #1276 first. I've turned this into a draft and dropped 0071 from the title; when I pick it up I'll take the next free number then. I've noted both points to bring back: record use only when a base opts in (so read-only tokens and bases that never turn salience on write nothing), and expiry as a statement about use rather than a world-axis close.