> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/developer-guide/platform-api/data-world-model/service-memory.md). # Service-Scoped Memory Configure service-scoped memory dimensions, opt eligible conversations into processing, and verify versioned observations and views before using them. Service-scoped memory turns eligible completed sessions into source-linked observations, dimension views, and a combined model. It is an optional processing path identified by workspace, service, and an application-supplied `memoryid`. Each conversation contributes to one memory subject; the pipeline does not aggregate memory for multiple people in the same conversation. Before creating a dimension, confirm that memory processing and an authorized reader are provisioned for your application. Dimensions define what to extract; using the results in later conversations requires a reader tool, as described below. This path is separate from existing person-enrichment memory and does not migrate it. See [Memory](https://docs.concurrence.com/agent/memory#service-scoped-dimension-memory). ## Prerequisites * A configured service and a credential with `Service.update` permission in its workspace. * Provisioned memory processing and an agreed reader for its outputs. Coordinate any transition from existing memory processing rather than running overlapping paths unintentionally. * A stable application mapping between the human speaking and the memory identifier. This memory describes the speaker; an operator discussing a patient does not make it the patient's memory. * A declared string context key named exactly `memoryid`, supplied when the conversation starts. `memoryid` is application input, not identity verification or authorization. Scope access in the application and reader; do not let an untrusted caller select another person's memory. ## Create or Revise a Dimension Define a dimension around information that changes how a later interaction should be handled. For example, describe communication preferences and changes to them instead of asking for a generic transcript summary. {% openapi src="" path="/v1/{workspace\_id}/memory/dimensions" method="post" %} {% endopenapi %} Example request body, using a synthetic service identifier: ```json { "service_id": "00000000-0000-4000-8000-000000000001", "key": "communication_preferences", "description": "Capture the speaker's preferred contact times and communication style, including stated changes and their reasons. Exclude preferences attributed only to someone else." } ``` The operation checks that the service belongs to the workspace and returns `201` with no response body. Each successful request appends the next definition version for that workspace, service, and key, including when the key already exists. It is not an idempotent replacement: reconcile an ambiguous result with the implementation owner before repeating the request. The public API has no companion list, update, or delete operation for dimensions. ## Opt a Conversation Into Processing Follow [Pass Context to Tool Parameters](/developer-guide/guides/conversation-context.md) to add `memoryid` to the service's `accepted_context` and send a value in the conversation-create request's `context` map. Preserve the service's other accepted keys when updating the list. Reuse the identifier only for the same intended person within that service and workspace. Processing uses completed production sessions linked to a conversation and configured service dimensions. Sessions without the identifier, conversation linkage, or dimensions remain pending. Voice extraction uses the full call transcript; a text conversation that spans sessions uses the interval after the preceding session end through the current end. Verify this path with an eligible production session using synthetic data; simulation results alone do not exercise it. ## Processing and Definition Versions | Stage | Inputs and result | | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Extract | Uses the session transcript, current dimension definitions, and existing views to produce source-linked observations classified as new information, confirmation, or contradiction. | | Consolidate | Combines a dimension's current view and new observations under its latest definition, then appends a new view version. | | Synthesize | Combines every current dimension view with the definition version that produced it. The previous combined model is not an input. | Changing a definition does not retroactively regenerate existing views, combined models, or historical observations. New observations make consolidation eligible; synthesis follows changed view versions. Different dimensions can therefore contribute views produced under different definition versions. A broader definition may need new sessions to obtain the missing evidence. Processing is asynchronous and model-generated. Failed or invalid generations remain pending, valid empty extraction marks a session processed, and successful no-op reruns do not create additional output versions. Extraction can miss information, and there is no guaranteed time by which a session's results will be available. ## Verify Before Using the Outputs For agent recall, configure an authorized reader tool and bind its `memoryid` parameter from conversation context. The graph must expose that tool and instruct the agent when to call it; empty results are a normal first-session outcome. Reader names and access are deployment-specific. The dimension-creation operation alone does not install readers or add them to a graph. Use synthetic sessions with a new preference, a later correction, and no relevant information. Through the provisioned reader, verify the workspace/service/memory scope, source conversation, definition versions, changed views, and combined model. Check that the correction reaches the intended application before assuming a later session can use it. Keep structured clinical facts in their authoritative retrieval path. Generated memory remains interpretive evidence; it does not replace clinical records, prove identity, or guarantee recall. If processing or reads are unavailable, use the workflow's established fallback and retain the session identifiers for reconciliation. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.concurrence.com/developer-guide/platform-api/data-world-model/service-memory.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.