Build1 publisher3 min readPublished
Return the admission record, not the log line: one memory service's case for receipts
A dev.to design note argues memory services must ship the reason a fact passed reuse alongside the fact. The posted SDK snippet shows why that is harder than the argument.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- The author describes the failure mode as a stored fact being wrong in a quiet way: a preference from an old exchange gets reused, the answer reads clean, and later nobody can tell why that detail was allowed back into the result.
- The author argues that when a system returns remembered material the caller needs the text plus the reason it passed the reuse check, that a log line found after the action is weak evidence, and that the object leaving the memory service must carry the admission record with it.
- The pattern is implemented in Holographic, Law-Bound Memory (HLM), described as a stand-alone memory brain outside application code.
- The HLM README describes public API routes under /api/brain/*, with internal /api/v1/* services behind that layer.
- The outside shape of the API is intentionally thin: register an agent, write a fact, build a capsule.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
A dev.to design note argues that a memory service should hand back the reason a remembered fact passed its reuse check inside the same object as the fact, rather than leaving the explanation in a log line to be found afterwards [2]. The failure it names is the quiet kind: an old preference gets reused, the answer still reads clean, and nobody can later reconstruct why that detail was admitted [1].
The author's implementation is HLM, or Holographic, Law-Bound Memory, described as a stand-alone memory brain sitting outside application code [3]. Public routes live under /api/brain/*, with internal /api/v1/* services behind them [4], and the external surface is deliberately small: register an agent, write a fact, build a capsule [5]. The Python SDK posts to /api/brain/agents/register, /api/brain/memory/facts and /api/brain/context/capsule, with build_capsule defaulting to a 2048-token budget [6]; the Node client exposes the same three calls as registerAgent, writeFact and buildCapsule [7]. Two clients means a compatibility surface to maintain at the gateway, a cost the author accepts on the grounds that admission policy copied into every consumer drifts: one caller skips a selector, another copies an old threshold, a third treats a nearby match as good enough [8]. Centralising the decision gives one place to say yes or rebuild before the application acts [9].
The write path is what makes a receipt possible at all. Facts arrive as text plus tags, selectors and an optional tenant id [11], land in a brain_facts row, and trigger two further writes against the same fact id for facets and predicates, with the response returning the new id and both sets attached [12]. That is the argument in miniature: retrieval later has axes it can test instead of a blob of prose [10].
Those axes are thin in the current scaffold, and the author says so plainly. generate_facets emits a specific facet for a known selector value, and otherwise falls back to a general facet built from the first 256 characters of the text with token count capped at 64, constants the author flags as code constants rather than performance claims [13]. generate_predicates converts selector strings into a single AND-joined predicate by swapping the first colon for an equals sign, which the author calls rough [14]. The cost lands on the writer: a caller sending empty selectors can still store text, but leaves later selection fewer axes to test [15].
The reuse service, Conformal-Causal Reuse, accepts a cache key, an artifact type defaulting to resume_kit, selectors, and optional similarity and tau values [16]. Its rule requires similarity above tau plus the selector kinds stakeholder, time and channel to be present [17]. That is a checkable admission record, and it is exactly the sort of thing a post-hoc log cannot reconstruct. Whether the capsule response actually carries it back to the caller is where the published excerpt stops [17].
One detail undercuts the demonstration more than the rough predicates do. In the posted Python client, r.raise_for_status and r.json are referenced without call parentheses [19]. As written, no HTTP error is ever raised and each method hands back a bound method object rather than parsed JSON [20], so a caller of build_capsule receives nothing inspectable at all [21]. An argument about carrying receipts is weakened by a client that discards the response.
The service is versioned 0.1.0 [18], and the post reports no evaluation of reuse quality [13]. Worth watching: whether the capsule schema names the tau value and selector kinds that admitted each fact, or merely records that it passed; whether generate_predicates moves past equality on a single selector [14]; and whether the two SDKs stay in step once admission policy at the gateway starts changing [8].