867
memory records
3.1MB of durable state, separate from any session.
The memory layer
867 records that outlive every session, and one timeout that breaks retrieval.
Memory sits outside the model, as durable linked records rather than a longer context window. A rule discovered by one agent constrains a different agent weeks later.
Problem
An agent that forgets is an agent that repeats the mistake.
Context windows solve the wrong problem. They let a model hold more of the current conversation, which is useful, and they do nothing about the thing that actually matters in an operating business: what was decided three weeks ago, why a rule exists, and which approach was already tried and did not work.
Gevurah keeps memory outside the model. Each record is a single durable fact with its own provenance, and records link to each other, so retrieving one pulls the others that qualify it. The point is not recall for its own sake. The point is that a rule discovered by one agent on a Tuesday constrains a different agent on a Friday.
1,315
links between records
Memory is a graph. A fact that stands alone is usually a fact nobody will find again.
2,942
indexed chunks across 751 files
The retrieval index sits over the record store rather than replacing it.
Design
One fact per record, and the reason attached to it.
A record holds a single fact, a one line description used to decide whether it is relevant, and a category. Operational lessons carry the reason they exist and the condition under which they apply, because a rule without its cause gets applied in the wrong place by whoever reads it next.
Two habits keep the store usable at this size. Anything the source of truth already records, the code, the commit history, the ticket, is not copied into memory, so the store does not drift out of sync with the system it describes. And a fact that turns out to be wrong is deleted rather than annotated, because a contradicted record is worse than a missing one.
The merge gate
Before records are merged, a gate checks that each incoming file carries a unique token, so that two writers cannot silently overwrite one another. At the last audit it identified a unique token in 611 of 661 files. The 50 it could not resolve are handled rather than assumed.
Retrieval
The index is real. The live query path is currently degraded.
This is the part most systems would leave out of a page like this, so it goes near the top of ours. The semantic index exists and is populated. In live use, queries currently fall back to lexical ranking, because the timeout in front of the retrieval process is 30 seconds and the process takes 33.
Three seconds. That is the whole failure. It is worth stating plainly because it is exactly the class of defect that a capability slide never shows: the feature is built, it is tested, it is wired up, and in production it quietly serves the fallback while every dashboard stays green.
What we do not claim
The semantic index is not presented as a live retrieval capability. The index itself is genuine, and live queries currently pass to lexical ranking after the timeout described above. When that is fixed it will be reported as a fix, with the measurement that shows it.