← All publications

Project memory for Sanad 0.1

Approved project context can now be retrieved for a Sanad 0.1 request, with permission checked again before it reaches the model.

Carry useful context into the next request

Sanad 0.1 can now receive a bounded block of approved project memory alongside a request. The gateway retrieves context relevant to the current prompt and inserts it after the model’s system guidance.

The aim is to make established project context available without requiring a developer to repeat it in every conversation. A repository decision, for example, is useful only when it is both relevant to the question and still valid for the project. Retrieval therefore needs more than a similarity score.

Recheck permission after retrieval

The gateway searches with the request’s server-derived user or organization identity and project context. It then reloads matching records and verifies the exact principal, project, active state, expiry, and enabled memory policy before building the context block.

The second check keeps the vector index from becoming the authority for access. A matching vector may refer to context that has expired, been disabled, or belongs elsewhere. That context must be excluded even when it appears relevant.

Explicit enablement and bounded context

The integration applies to Sanad 0.1 when the request includes a project identifier and the relevant memory policy is enabled. Business requests use organization memory. Missing project context, disabled policy, unsuitable matches, or retrieval failures leave the request without an injected memory block.

This implementation uses approved curated summaries. Automatic learning from raw request traffic remains disabled. The next evaluation needs to establish whether the retrieved context improves repository decisions, and how often irrelevant or stale material survives the selection process.

Further reading