> 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/operations/reference/terminology-mapping.md).

# Terminology Mapping

Map product terms to Classic API names and distinguish the separate Platform API contracts without renaming compatibility fields.

The [Glossary](https://docs.concurrence.com/reference/glossary) defines product terms consistently across the documentation. This page maps those terms to retained Classic API names. For example, a Context Graph describes workflow states, transitions, guidance, and tool bindings; the Classic API names that resource `service_hierarchical_state_machine`.

These are compatibility names, not a second set of product definitions. Do not apply a Classic endpoint or state schema to the Platform API because the product term matches. The cross-surface [API Terminology Mapping](https://docs.concurrence.com/reference/api-terminology-mapping) identifies the main differences.

{% hint style="info" %}
**Classic API.** These terminology mappings apply to Classic API endpoints and schemas.
{% endhint %}

## Core Concept Mapping

| Platform Docs Term    | API Name                           | Endpoint Prefix                                    | Description                                                                                |
| --------------------- | ---------------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| **Context Graph**     | Service Hierarchical State Machine | `/organization/service_hierarchical_state_machine` | The graph of states and transitions that defines an agent's conversational behavior        |
| **Actions**           | Tools                              | `/tool/`                                           | Versioned executable capabilities that agents invoke to perform work                       |
| **Dynamic Behaviors** | Dynamic Behavior Sets              | `/dynamic_behavior_set/`                           | Versioned sets of conversation triggers and actions that adjust agent behavior at runtime  |
| **Agent Core**        | Agent                              | `/organization/agent`                              | Versioned identity and authored guidance, distinct from service deployment configuration   |
| **Evaluations**       | Metrics + Simulations              | `/metric/` + `/simulation/`                        | Quality measurement (metrics) and automated testing (simulations) of agent behavior        |
| **Agent Forge**       | CLI tool (`forge`)                 | Uses existing API endpoints                        | Command-line tool for development workflows (scaffold, publish, test)                      |
| **Tool Call State**   | ToolCallState                      | Schema name in OpenAPI                             | A Context Graph state type where the agent generates parameters for a designated tool call |

## Evaluation Sub-Components

The platform concept of "Evaluations" spans two distinct API resource types:

| Platform Docs Term                    | API Resource                                                              | Key Endpoints                                                                                                                                                      |
| ------------------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Metrics** (quality criteria)        | Metric                                                                    | `POST /metric/`, `POST /metric/evaluate`, `GET /metric/metric_evaluation_result`                                                                                   |
| **Simulations** (automated test runs) | Simulation Persona, Scenario, Unit Test, Unit Test Set, Unit Test Set Run | `POST /simulation/persona/`, `POST /simulation/scenario/`, `POST /simulation/unit_test/`, `POST /simulation/unit_test_set/`, `POST /simulation/unit_test_set_run/` |

## Context Graph State Types

Within a Context Graph (API: `service_hierarchical_state_machine`), the following state types are defined:

| State Type       | API Schema Name   | Purpose                                                        |
| ---------------- | ----------------- | -------------------------------------------------------------- |
| Action State     | `ActionState`     | Executes tools and evaluates exit conditions                   |
| Annotation State | `AnnotationState` | Injects a predefined inner thought and moves to the next state |
| Decision State   | `DecisionState`   | Routes conversation flow based on conditions                   |
| Recall State     | `RecallState`     | Retrieves user memory via static and dynamic queries           |
| Reflection State | `ReflectionState` | Generates agent reasoning or summaries                         |
| Tool Call State  | `ToolCallState`   | Generates parameters for a specific tool invocation            |

{% hint style="warning" %}
**Platform API:** The Platform API context graph engine supports four state types: Action, Decision, Annotation, and Data Collection. The same context graph runs on both voice and text channels. Recall, Reflection, and ToolCall states are Classic API features only, and Data Collection states are Platform API only.
{% endhint %}

## Memory System Terms

| Platform Docs Term       | API Concept                | API Endpoint                       |
| ------------------------ | -------------------------- | ---------------------------------- |
| **Raw Transcripts**      | Conversation Messages      | `GET /conversation/{id}/messages/` |
| **Extracted Memories**   | User Memory                | `GET /user/{user_id}/memory`       |
| **Episodic User Models** | (Internal)                 | No direct API access               |
| **Global User Model**    | User Model                 | `GET /user/{user_id}/user_model`   |
| **Additional Context**   | `additional_context` field | `POST /user/{requested_user_id}`   |

See [Memory Architecture & API Mapping](/developer-guide/operations/reference/memory-architecture.md) for details on how to work with each layer.

## Deployment & Configuration Terms

| Platform Docs Term | API Name            | Notes                                                                                                 |
| ------------------ | ------------------- | ----------------------------------------------------------------------------------------------------- |
| **Version set**    | Version Set         | Named component selection on a service; names such as `staging` do not create an isolated environment |
| **Service**        | Service             | A configured AI experience; the term is the same in both contexts                                     |
| **Organization**   | Organization        | The top-level tenant boundary; the term is the same in both contexts                                  |
| **Role**           | Role                | RBAC role defining user permissions; the term is the same in both contexts                            |
| **Webhook**        | Webhook Destination | Configured endpoint that receives event notifications                                                 |

## Developer Console Labels

The Developer Console, which manages Platform API resources, uses its own labels for two of them:

| Console label | Platform API name | Notes                                                                        |
| ------------- | ----------------- | ---------------------------------------------------------------------------- |
| **Agents**    | Service           | A Console agent page shows the service's settings and its **API service ID** |
| **Personas**  | Agent             | A Console persona page shows the agent's versions and its **API agent ID**   |

API names, routes, and SDK types use `service` and `agent`.

## Where to Find Each in the API

For quick reference, these are common Classic resources and their base paths under `/v1/{organization}/`:

| Resource             | Base Path                                          |
| -------------------- | -------------------------------------------------- |
| Organization         | `/organization/`                                   |
| Agent                | `/organization/agent`                              |
| API Key              | `/organization/api_key/`                           |
| Context Graph        | `/organization/service_hierarchical_state_machine` |
| User Dimensions      | `/organization/user_dimensions/`                   |
| User                 | `/user/`                                           |
| Service              | `/service/`                                        |
| Conversation         | `/conversation/`                                   |
| Tool (Action)        | `/tool/`                                           |
| Dynamic Behavior Set | `/dynamic_behavior_set/`                           |
| Metric               | `/metric/`                                         |
| Role                 | `/role/`                                           |
| Simulation           | `/simulation/`                                     |
| Webhook Destination  | `/webhook_destination/`                            |
| Admin                | `/admin/`                                          |

## Tips for Reading the Documentation

* For a Classic Context Graph, look for `service_hierarchical_state_machine`; follow [Build and Prove a Workflow](/developer-guide/guides/build-and-prove.md) for Platform configuration and its owning references.
* Classic Actions use `/tool/`. A Platform Skill is a companion definition, not a renamed Classic code package; Platform Functions are read-only computations.
* Classic evaluation workflows can use both metrics and simulations. Evaluation is the activity, not one resource shared by both APIs.
* Use the [Classic OpenAPI spec](https://api.amigo.ai/v1/openapi.json) for exact Classic paths, parameters, and response schemas, and the owning Platform reference for Platform contracts.


---

# 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/operations/reference/terminology-mapping.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.
