DocsCore conceptsHow Memnox remembers

How Memnox remembers

One word, four different things underneath. What an organization needs to remember is not one kind of record, and pretending it is produces a search box where an answer should be.

Each kind answers a different question, so each is stored in the shape that question needs.

Kind

What happened

Source events: messages, pull requests, transcripts, documents, each with a link back to itself. Append only, never edited. The timeline everything else is built from.

What is true

Verified facts: who holds what authority, who is responsible for what, what the organization has stated about itself. Every one carries provenance and a verification status.

How things relate

The graph: ownership, cause, evidence, supersession. Six node kinds, six relations, and every node pointing back at a source.

What was settled

Decision memory: the rules a named person approved, the only kind that reaches the runtime and tightens a verdict.

Why the shapes matter

A question like what is our refund policy wants a verified fact. Why is it our policy wants the events behind it. Who is affected if we change it wants the graph. What happens if an agent ignores it wants decision memory, because that is the copy the gate consults.

A single store, whatever its shape, answers one of those well and the rest badly. The failure of the flat approach is familiar to anyone who has asked a search index a why question and been handed nine documents.

Nothing is overwritten

Organizations change their minds, and the old answer stays load bearing long after it stops being current. So a fact or a decision that changes is superseded, never edited. The chain keeps both questions answerable: what is our policy walks to the end of the chain, and why did we do it the other way in March stops at the link that was current in March.

This is also what makes the audit trail mean something. A verdict from last quarter is explained by last quarter's rules, which still exist, unmodified, exactly as the gate read them.

Memory ages, and says so

A decision whose evidence is old, whose owner has left, or which nothing has touched in a long time is surfaced for confirmation. A practice that has drifted from the written rule is reported. Neither is resolved automatically, because in both cases only a person knows whether the memory or the behaviour is the one that is wrong.

Ageing is a reason to ask, not a reason to act. Nothing decays into deletion.

What a reader is entitled to

Memory is filtered before retrieval, not after. Need to know decides which evidence a person or an agent is entitled to reach, then the search runs over what is left. An agent never out-reads the person it works for, and every answer carries a count of what was withheld, because an agent that does not know it was filtered reports a partial answer as a complete one.

Console → Graph, with one decision selected and its evidence, supersession chain and affected systems visible

Console → Graph, with one decision selected and its evidence, supersession chain and affected systems visible

screenshot slot, save as public/screens/…png and set  src

Four kinds of memory on one screen: the event it came from, the fact it states, the things it touches, and the rule it became.