memory-health

Call mubit_memory_health — POST /v2/control/memory_health — and report what it says about the store. limit (1 to 500) is how many entries it samples; the default is enough unless the user is specifically asking about an old part of a large run.

This inspects the store. mubit_status inspects the connection.

The two answer different questions and are easy to confuse, because both fail as "memory isn't working".

• mubit_status dials the instance. It tells you whether there is something at the other end, whether the key is accepted, and which typed ConnState applies. It knows nothing about what is stored.
• mubit_memory_health asks what is in there: how many entries, how stale they are, whether any of them contradict each other, and how each section is doing. It says nothing about the connection — if the instance is unreachable this call does not answer at all.

So a healthy connection over an empty store and a full store behind a dead endpoint look identical from the status line, and they have opposite fixes. Answer the question the user actually asked before offering a remedy for the other one.

Reading the answer

• Zero entries, connection fine. Nothing was ever written. Check that capture is on, and remember that an accepted ingest is queued, not stored — a run that just started can be legitimately empty for a minute.
• Entries present, but recall keeps returning nothing. The store is not the problem. That is a retrieval or scope question: go to /mubit-memory:doctor step 1 and read recall.empty_reason from the local status marker, which names the cause outright.
• Contradictions. Two stored lessons that disagree. Neither is automatically wrong and deleting both loses the argument: prefer a negative mubit_outcome on the one that turned out false, or /mubit-memory:forget if it should never have existed. Report the pair to the user rather than picking a winner yourself.
• Staleness. Old is not broken. Say so — a lesson that has not been touched in months is usually one that has not been contradicted either.