A Context Object Should Carry Its Receipt

A stored fact can be incorrect in a subtle manner. The response still appears flawless. An outdated preference from a previous exchange gets reused; the message proceeds with assurance, yet later it becomes unclear why that particular detail was reintroduced into the outcome. This represents the error I constructed around. When a system returns previously remembered material, the caller must receive both the text and the rationale behind passing the reuse verification.

A log entry discovered subsequent to the action offers insufficient evidence. The object departing the memory service must include the admission record along with it. To maintain a streamlined interface, I employed this approach in Holographic, Law-Bound Memory (HLM), an independent memory brain located outside of application code.

The interface is deliberately minimal, featuring public Application Programming Interface (API) endpoints under /api/brain/* and internal /api/v1/* services behind that layer. The exposed boundary is intentionally thin, comprising three main actions: registering an agent, writing a fact, and constructing a capsule. The Python Software Development Kit (SDK) in sdks/python/hlm_sdk/client.py illustrates this boundary without disclosing table names or policy code.

Importing the necessary modules, the HLMClient class initializes with a base URL and optional authentication token. It then provides methods to register an agent, write a fact, and build a capsule. The TypeScript client in sdks/node/src/index.ts offers identical functionality, including methods named registerAgent, writeFact, and buildCapsule.

While this adds a compatibility layer at the gateway, it is deemed necessary as each consumer may have different admission policies. Centralizing the decision-making process allows the service to either approve or reject requests before the application takes action. When writing facts, HLM includes additional metadata such as tags, selectors, and an optional tenant field.

This information enables the service to make informed decisions before the query is executed. The write model in services/memory/app/main.py is straightforward, with a FactIn Pydantic model defining the structure of the incoming fact data. Once the fact is created, two further writes occur against the same fact ID: one for facets and another for predicates.

The response returns the new fact ID along with both sets of data attached. The generation of facets and predicates follows different paths in the current scaffold. If a known selector value is present, a specific facet row is generated. Otherwise, a general facet is created using the first 256 characters of the text, with a token count capped at 64.

While these processes may seem rough, they effectively convey the shape of retrieval, providing more information than just a text snippet. The decision to perform predicate creation simplifies the retrieval process, as the fact now leaves the write path carrying verification handles that machines can utilize. The tradeoff is placed on the writer, as callers who send empty selectors can still store text but have fewer axes to test during selection.