> 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/readme.md).

# Concurrence Platform

Understand Concurrence's data foundation, agent workflows, deployment responsibilities, and the evidence used to improve healthcare operations.

Concurrence is a healthcare data and AI platform. Its Health World Model connects source records into shared patient and operational context. Applications, including agents and Scribe, can use that context and contribute observations through configured integrations. Teams define each application's permissions, supervise its actions, and evaluate the results.

## Choose Your Path

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><a href="/platform-overview/evaluation-packet.md"><strong>Evaluate the architecture</strong></a></td><td>Review ownership, data flows, capability scope, cost, and pilot acceptance evidence.</td></tr><tr><td><a href="https://docs.concurrence.com/developer-guide"><strong>Build an integration</strong></a></td><td>Choose access, run the starter, and verify an answer before connecting an external action.</td></tr><tr><td><a href="https://docs.concurrence.com/developer-guide/guides/operate-and-improve"><strong>Operate a deployment</strong></a></td><td>Inspect runs, reconcile outcomes, handle exceptions, and evaluate a proposed change.</td></tr><tr><td><a href="https://docs.concurrence.com/api-reference"><strong>Find an API contract</strong></a></td><td>Look up Platform, Scribe, or Classic operations, schemas, and upgrade guidance.</td></tr></tbody></table>

Plan a deployment with [Architecture and Deployment](/platform-overview/architecture-and-deployment.md), or go directly to [Regional Coverage and Data Residency](/platform-overview/data-residency.md).

For an existing service, try [First Console Conversation](https://docs.concurrence.com/developer-guide/guides/first-console-conversation). To extend a deployment, use [Connect Another Workflow](/data/connect-another-workflow.md).

## Understand the System

A useful deployment brings these pieces together. An agent rescheduling an appointment needs the right patient context, current availability, permission to make the change, confirmation from the scheduling system, and a person to handle exceptions. The conversation is one part of the work.

A second workflow can reuse authorized connections, identity mappings, and source-linked context from the first while keeping its own permissions and transactions. The [Shared Context and Applications](/platform-overview/shared-context-and-applications.md) map shows how the pieces fit together.

Prefer a concrete example? [One Patient, Two Workflows](/data/patient-context-walkthrough.md) follows shared patient context from a clinician-reviewed note to a confirmed booking, with source evidence and ownership at each step.

Read these pages in order for a technical introduction:

1. [What Concurrence Does](/platform-overview/what-amigo-does.md) - the product, the problem it addresses, and where it fits in an existing organization.
2. [Core Concepts](/platform-overview/core-concepts.md) - how workspaces, world-model data, services, agents, Context Graphs, and runs relate.
3. [Shared Context and Applications](/platform-overview/shared-context-and-applications.md) - a visual map of the data foundation, events, and application ownership.
4. [How It Works](/platform-overview/how-it-works.md) - follow an appointment change from source data to a confirmed outcome and later evaluation.
5. [Design Principles](/platform-overview/design-principles.md) - the engineering choices and trade-offs behind that architecture.
6. [Operating Model](/platform-overview/operating-model.md) - who defines the workflow, operates it, and decides what changes.

## Follow Your Question

### Review an Enterprise Architecture

Follow [Architecture and Deployment](/platform-overview/architecture-and-deployment.md) for a connected path from ownership and regional scope to implementation and release. Use the decision index below to jump to a specific question.

<details>

<summary>Architecture decision index</summary>

Use these pages together to decide where Concurrence fits in your application and data architecture. Record the selected arrangement in the [Technical Evaluation Packet](/platform-overview/evaluation-packet.md).

| Decision                                             | Read                                                                                                                                                              | Leave with                                                                                    |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| What does our application own?                       | [Shared Context and Applications](/platform-overview/shared-context-and-applications.md), then [Reference Deployment](/platform-overview/reference-deployment.md) | Boundaries between shared context, application transactions, and authoritative source records |
| Where does each component run, and what can we move? | [Cloud Ownership and Integration Boundaries](/platform-overview/cloud-ownership.md)                                                                               | Execution, data, operating-access, billing, and portability decisions                         |
| Which data crosses each boundary?                    | [Data Residency](/platform-overview/data-residency.md) and [Compliance and Audit](/operations-and-safety/compliance.md)                                           | Processing paths, access scope, retention questions, and review evidence                      |
| What is available for this deployment?               | [Capability and Availability](/platform-overview/capability-availability.md) and [Healthcare Interoperability](/data/healthcare-interoperability.md)              | Supported interfaces, prerequisites, and dependencies to confirm                              |
| What drives total cost and response time?            | [Cost and Latency Optimization](/platform-overview/cost-and-latency.md)                                                                                           | Cost categories, measurement boundaries, and workload assumptions                             |
| Who approves, releases, and operates it?             | [Operating Model](/platform-overview/operating-model.md) and [Deployment Model](/platform-overview/deployment-model.md)                                           | Named responsibilities, release evidence, and recovery ownership                              |

</details>

### Explore a Capability

| Your question                                                     | Continue here                                                                                                                                                                                       |
| ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| How does Concurrence represent conflicting or incomplete records? | [World Model](/data/world-model.md), then [Connectors and EHR](/data/connectors-and-ehr.md)                                                                                                         |
| How is an agent configured and constrained?                       | [Agent Core](/agent/agents.md), [Context Graphs](/agent/context-graphs.md), and [Runtime Safety](/operations-and-safety/runtime-safety.md)                                                          |
| How does a workflow reach a patient or operator?                  | [Channels](/channels/conversations.md) and [Operators and Escalation](/operations-and-safety/operators.md)                                                                                          |
| How do we establish that it works and release a change?           | [Testing and Evaluation](/testing/testing.md), [Deployment Model](/platform-overview/deployment-model.md), and [Continuous Improvement](/agent/pattern-discovery-and-reuse.md)                      |
| Where does data go, and what can we inspect?                      | [Data Residency](/platform-overview/data-residency.md), [Compliance and Audit](/operations-and-safety/compliance.md), and [Intelligence and Analytics](/intelligence-and-analytics/intelligence.md) |
| What evidence supports a deployment decision?                     | [Evaluating Concurrence](/platform-overview/evaluating-amigo.md)                                                                                                                                    |

The [healthcare use cases](/use-cases/use-cases.md) apply these concepts to specific workflows. They are design patterns; provisioning, integrations, and operating decisions determine the deployed behavior.

For the architecture thesis, read [Universal Reasoning and the Liquid World Model](/agent/universal-reasoning.md): how software defines the problem, data supplies evidence, and exact programs, fast decisions, and deliberative models divide the work.

## Concepts, Implementation, and Reference

This space explains behavior, architecture, and operating boundaries. The [Developer Guide](https://docs.concurrence.com/developer-guide) provides authentication, endpoint contracts, SDK guidance, and integration examples. Start its [Getting Started path](https://docs.concurrence.com/developer-guide/getting-started) when you are ready to implement. The [API Reference and Change Logs](https://docs.concurrence.com/api-reference) provide generated operation schemas and historical changes. The [Glossary](/reference/glossary.md) is a lookup reference; [Core Concepts](/platform-overview/core-concepts.md) explains the relationships behind the names.

Unless a page says otherwise, these concepts describe the Platform API. The Classic API remains supported for existing integrations and has its own resources and contracts. Use the API named in the implementation guide for your deployment.

## Read Capability Claims in Context

A documented interface can require provisioning, configuration, or a particular runtime. The [capability matrix](/platform-overview/capability-availability.md) distinguishes those requirements from private previews. Confirm the capabilities needed for your deployment before committing to scope or timing.

When evaluating a deployment, trace the claim to its prerequisites and observable result. A recorded request, a completed agent turn, a delivered message, and a confirmed external change are different pieces of evidence.

{% hint style="info" %}
**Integration identifiers.** Classic API hosts, SDK packages and imports, and other integration identifiers use the names shown in their contracts, including `amigo`. See [Rebrand and Compatibility](/reference/concurrence-rebrand.md).
{% endhint %}


---

# 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/readme.md?ask=<question>&goal=<user_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.