Provenance-aware memory
Every record EDN stores carries a provenance class that records where the record came from. Provenance is not a label bolted on afterwards: it drives how, and whether, a record is allowed to reach your model.Confirmed fact versus excluded inference
EDN draws a hard line between what may be presented as fact and what may not.- Confirmed facts (
USER_STATED,USER_CONFIRMED,DOCUMENT_VERIFIED, and round records) can enter the fact-bearing sections of the context package. AI_INFERREDrecords may be included, but they are always flagged as inferences. They are never presented as established fact.AI_GENERATEDrecords are structurally excluded from the identity, context, and preference sections. They may appear only in the uncertain section, always marked as uncertain.
Deterministic, LLM-free retrieval
When your application asks for context, EDN ranks stored records by cosine similarity between the query and pre-computed record embeddings. A fixed similarity floor (0.45) separates genuine matches from loosely related noise, and a provenance gate excludes classes that are not eligible for retrieval. No generative model runs in the retrieval path. The same query over the same records returns the same records. Retrieval is a deterministic database query, not a model decision.Honest abstention
When a request is scoped to a project and retrieval returns no matching records, EDN does not quietly fall back to general knowledge. It emits an explicit grounded instruction telling the downstream model to answer only from the project’s sources, and to state plainly that the project has no sources on the topic if none apply. Abstentions are recorded in telemetry so you can see how often memory honestly declined.Citations
Because every retrieved record keeps its provenance and source, answers built on EDN context can be cited back to their origin. The Workspace renders these as inline citation markers with a provenance tag; your own application can use the same provenance data to attribute answers.The SIP
The Session Initialisation Package (SIP) is the compact, governed context package EDN assembles for a request. It has a fixed set of five sections and is held to a fixed token budget (a target of roughly 800 tokens and a hard cap of 1200), so what reaches your model stays small and predictable.If assembly would exceed the token budget the build fails rather than
silently truncating, so the package your model receives is never quietly cut
short.
