> 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/platform-overview/core-concepts.md).
# Core Concepts
The relationships between workspace data, deployed configuration, live interactions, and outcome evidence in the Concurrence Platform.
Concurrence separates workspace data, workflow configuration, and execution records. Data supplies context, configuration defines the intended work, and execution records show what happened. Each has its own lifecycle.
This page introduces the Platform concepts. The [Glossary](/reference/glossary.md) provides shorter definitions, and the [Developer Guide](https://docs.concurrence.com/developer-guide) maps them to API resources.
## Workspace: The Shared Boundary
A [workspace](/data/workspaces.md) scopes data, configuration, and access. A service, a patient entity, and an operator's permissions are evaluated within that boundary. Organizations use separate workspaces when they need separate access, configuration, or operational control.
A workspace is not a workflow or a version of an agent. One workspace can contain several services. Creating a workspace also does not provision every channel or establish a particular hosting, retention, or compliance arrangement.
## Data: Records, Events, and Projections
| Concept | What it represents | Example |
| ----------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------- |
| **Data source** | A configured origin of supported records | A scheduling-system connection or a registered intake source |
| **Entity** | A modeled person or resource within the workspace | A patient, practitioner, or appointment |
| **World-model event** | A source-attributed observation or recorded change | A patient reports a new contact preference |
| **Projection** | A derived read view computed from relevant retained inputs | The current projected patient context |
| **Provenance and confidence** | Where an observation came from and how its source is ranked on supported paths | Distinguishing a patient report from a verified source record |
The [world model](/data/world-model.md) is the shared event and entity layer. A projection gives consumers a usable read without making them reconstruct the entire history. Projection is asynchronous, and some derived products use their own processing paths. An accepted event can exist before a later read reflects it.
Entity identity also needs an explicit basis. A recognized phone number can help resolve a caller binding; it is not, by itself, the workflow's identity verification. See [Connectors and EHR](/data/connectors-and-ehr.md#entity-resolution) for the current resolution and binding boundaries.
## Configuration: What a Service Deploys
| Concept | Responsibility |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Agent** | Identity, general behavioral guidance, and communication style |
| **Context Graph** | Workflow objectives, states, transitions, state guidance, and tool bindings |
| **Tool** | A specific operation the runtime can invoke under its access and execution rules |
| **Skill** | A prompt-driven companion definition that can use its declared tools; its state binding controls execution and result handling |
| **Service** | The deployment configuration connecting selected agent and Context Graph versions with runtime and channel settings |
| **Version set** | A named selection of component versions and supported runtime preferences for a service |
| **Channel use case and binding** | Provisioned channel identity and purpose, connected to the service that handles that route |
This is a configuration relationship, not a processing sequence. A deployed interaction combines these pieces. State bindings govern workflow tools, while supported runtime and platform tools can also be exposed through service and channel configuration.
Agent guidance and Context Graph instructions steer model behavior. Server-side authorization and tool validation determine which operations may execute. A tool's presence in a prompt does not grant new permissions.
These definitions separate the agent's perspective from the problem it is solving. The same agent can work through different Context Graphs, and a graph can be evaluated with different agent guidance. The [reasoning engine](/agent/reasoning-engine.md#what-the-designer-controls) combines them with current context and runtime controls during execution.
Version sets can pin agent and Context Graph versions. An unpinned component can resolve to a newer version when configuration is loaded. Source data, generated memory, integrations, and other settings have their own lifecycles; pinning a graph does not freeze the entire environment. See [Deployment Model](/platform-overview/deployment-model.md).
## Execution: Conversations, Sessions, and Runs
A **conversation** holds an interaction's history and lifecycle on a supported channel. A **session** is the runtime context processing the interaction. Continuity, termination, and retained configuration depend on the selected path; a new message does not universally create a new session or reload all configuration.
A **run** is the operational record used to inspect supported execution in the unified Runs surface. Run inventory and detail connect the operator or developer to the underlying interaction. They do not imply that every kind of listed historical run can still be started.
The [reasoning engine](/agent/reasoning-engine.md) consumes the available interaction signals and produces effects such as a reply, a tool invocation, or a transition. Channel-specific runtime behavior turns those effects into speech or messages. A generated reply and a delivered reply are separate outcomes.
Input, reasoning, actions, and delivery can have different lifetimes. A tool result can continue work without another user message, while a new request can arrive during a lookup. Tool bindings and channel controls determine how that overlap is handled; stopping a response does not undo an external action.
## Context: Current Facts and Memory
World-model context supplies selected entity information. [Memory](/agent/memory.md) derives useful observations and bounded models from earlier interactions, with scoped recall when more detail is needed. Conversation history supplies what has happened in the current thread, subject to that runtime's context handling. Together with state guidance and tool results, these inputs form the agent's working context.
These inputs serve different purposes. A remembered preference can help the agent communicate; a current scheduling lookup is needed when the next action depends on live availability. Generated memory and summaries can be incomplete and do not replace authoritative retrieval.
A Context Graph describes how work proceeds. The world model describes entities, evidence, and relationships. A workflow can consult related records without its states mirroring those relationships. Memory updates the context available for future reasoning; it does not train model weights or automatically rewrite the agent or graph definition.
Proposed extensions to [object memory](/agent/memory.md#design-direction-object-memory) and [execution coordination](/agent/reasoning-engine.md#design-direction-universal-reasoning-harness) are documented separately as design direction. Use the current person-memory and channel contracts when scoping a deployment.
## Evidence: What a Result Establishes
The meaning of success depends on the boundary being observed:
* A retained observation shows what was recorded and its source.
* A tool result shows the result exposed by that operation.
* A provider receipt supplies the delivery evidence available for that channel.
* A target acknowledgement or supported read-back can confirm an external change.
* An evaluation scores the evidence available under its definition.
Use those records together to investigate an outcome. A completed run or a favorable evaluation does not establish every downstream result. [How It Works](/platform-overview/how-it-works.md) follows these boundaries through one workflow.
---
# 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.concurrence.com/platform-overview/core-concepts.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.
