# Concepts glossary

This glossary is the authoritative source for the terms used across the Bevaya documentation. Definitions are intentionally brief; where a term has a dedicated guide or reference page, the entry links to it. Terms are grouped by area — platform and hierarchy, the build model, the runtime and review model, statuses, integrations, insurance, and the API.

For a narrative introduction to how these concepts fit together, see [Platform concepts](../welcome/platform-concepts.md).

## Platform and hierarchy

**Bevaya** — Roots Automation's platform for controlled AI automation of document-heavy insurance operations. Always written in title case: *Bevaya*.

**Organization** — the top-level customer boundary. An organization contains all of your workspaces, users, and configuration, and is the boundary for access and tenancy. Every request is scoped to one organization, with strong isolation between organizations. See [Core entity definitions](./core-entities.md).

**Workspace** — a grouping of related AI Agents within an organization, used to separate work by team, line of business, or stage of work. See [Platform hierarchy](../onboarding/platform-hierarchy.md).

**Project** — the former name for the AI Agent level of the hierarchy. The UI now uses **AI Agent**; the term *project* persists only in the [Bevaya API](/api). See **AI Agent** and [Core entity definitions](./core-entities.md).

**Role** — the named permission set assigned to a user. The three standard roles are **Admin**, **Partner**, and **Reviewer**. See [Users and access](../onboarding/users-access.md).

**Admin** — the role with full configuration access, including building and publishing flows, AI intelligence (InsurGPT), and revealing or deleting variable values.

**Partner** — a building role that can create, publish, and activate flows and create or update variables, but cannot use AI intelligence, reveal decrypted variable values, or delete variables.

**Reviewer** — an operational role that works items and reviews but cannot build or run flows, view run history, or use AI intelligence.

**RBAC (role-based access control)** — the organization-scoped, configurable permission model that maps roles to what a user can see and do.

**SSO (single sign-on)** — how people sign in to Bevaya: federated identity through your organization's identity provider, resolved by email domain. See [Users and access](../onboarding/users-access.md).

## The build model

**AI Agent** — an automation worker that follows a defined insurance business process, such as submission intake or claim indexing. You start an AI Agent from a use-case template or build one from scratch, defining its work as a flow. The AI Agent is also the level of the hierarchy that contains flows and their related configuration — the level the API still calls a *project*. See [AI Agent reference](./ai-agents.md).

**Flow** — the node-based definition that determines how an AI Agent processes work. A flow begins with a trigger and continues through the connected nodes. See [Build AI Agents](../build-ai-agents/overview.md).

**Node** — a configurable step that performs work inside a flow. Outcomes like classification, extraction, matching, routing, human review, and write-back are built by composing nodes. See [Node catalog reference](./node-catalog.md).

**Node category** — the grouping a node belongs to in the builder's Nodes library: **Triggers, Apps, Utilities, Actions, Controls, InsurGPT**. See [Node catalog reference](./node-catalog.md).

**Trigger** — the node that starts a flow, ingesting the initial input and injecting it into the flow. See [Trigger reference](./triggers.md).

**Environment** — the organization-level runtime context selected when testing, publishing, or running a flow. See [Environments and variables reference](./environments-variables.md).

**Variable** — a named, reusable value set within an environment and optionally scoped more narrowly (workspace, AI Agent, or flow). All variable values are encrypted end to end and masked when displayed; there is no separate "secret" type. See [Environments and variables reference](./environments-variables.md).

**Draft** — the editable state of a flow. You run a draft to test it before publishing. See [Drafts and publishing](../build-ai-agents/drafts-publishing.md).

**Run Draft** — a build-time tool that runs the current draft in the selected environment so you can test and inspect it. It is not the production execution model. See [Test and debug a draft](../build-ai-agents/test-debug-draft.md).

**Publish** — the action that records a versioned flow from the current draft. Publishing does not start processing; it makes a version available to run. See [Drafts and publishing](../build-ai-agents/drafts-publishing.md).

**Version** — a recorded snapshot of a flow produced by publishing (for example, `v1.0.0`). The builder's version selector also includes the current **Draft**.

**Activate / Deactivate** — turning a flow's trigger live or stopping it. An active trigger starts runs; deactivating stops new runs. See [Configure triggers](../build-ai-agents/triggers.md).

**InsurGPT** — Bevaya's insurance-tuned AI capability, used through InsurGPT nodes to classify documents and extract fields, and to generate insights. AI intelligence is an Admin capability. See [InsurGPT nodes](../build-ai-agents/insurgpt-nodes.md).

**Grounding** — an InsurGPT setting that ties extracted fields back to the source document location they came from, supporting field-to-page review.

**Classification** — determining what type each document is (for example, an ACORD form versus a loss run) so the flow can route and extract appropriately.

**Extraction** — reading the fields that matter from a document into structured data the flow can act on.

## The runtime and review model

**Workflow run (flow execution)** — a single execution of an AI Agent against one case: a document package, claim, submission, audit sample, or business event. A configured trigger starts a run in production. Browse and inspect runs in [Run history](../monitor-review/run-history.md).

**Run history** — the view that lists workflow runs and lets you open a run to inspect its steps, inputs, outputs, and errors. Viewing run history requires the Admin or Partner role. See [Run history](../monitor-review/run-history.md).

**Execution step** — one node's execution within a run, with its own status, timing, input, and output. Secrets are masked in step input and output. See [Run history](../monitor-review/run-history.md).

**Work item** — a prepared exception task created when Bevaya needs human judgment before completing a workflow action. It arrives with context already assembled — the source document, proposed classification, extracted fields, and a recommended match or action. See [Human review](../monitor-review/human-review.md).

**Human review** — the runtime step where a work item is routed to a reviewer for inspection or correction before the flow continues. A **Flag for Human Review** node sends an item to review. See [Human review](../monitor-review/human-review.md).

**Insights tab** — the work-item tab that presents the assembled context and AI-generated insights for the item.

**Review tab** — the work-item tab where a reviewer validates or corrects extracted fields and submits the item back to the flow.

**Confidence** — a per-field indicator shown on the Review tab as a dot: **High** (≥ 80%) or **Low** (< 80%), with the exact percentage in a tooltip.

**Item lock** — the mechanism that allows one reviewer to work an item at a time. An idle lock can be reclaimed after a short period. See [Human review](../monitor-review/human-review.md).

**Matching** — comparing a processed package to a record in your system of record — a policy or an existing claim — so the flow can route, attach, or write back correctly.

**Write-back** — writing the result of a run back into your system of record (for example, creating a claim record or attaching documents to an existing claim).

## Statuses

Bevaya uses two distinct status vocabularies. Do not conflate them.

**Workflow run status** — the lifecycle status of a flow execution: `PENDING`, `RUNNING`, `COMPLETED`, `FAILED`, `CANCELLED`. See [Workflow run statuses](./workflow-run-statuses.md).

**Work item status** — the lifecycle status of a work item: `QUEUED`, `IN_PROGRESS`, `DEFERRED`, `REVIEW`, `COMPLETE`, `CLOSED`, `FAILED`, `CANCELED`. In the UI these appear in title case. See [Work item statuses](./work-item-statuses.md).

**Item status reporting** — the count summaries (status cards) shown above the items list. Cards are data-driven — one per status currently present, with Canceled hidden — and display counts only; there are no trend or throughput analytics. See [Item status reporting reference](./item-statuses.md).

## Integrations

**App integration node** — a node that connects a flow to an external carrier or business system. See [App integration nodes](../build-ai-agents/app-integration-nodes.md).

**Guidewire** — the carrier system Bevaya integrates with through configured ClaimCenter requests, used to search, create, and update claims.

**Outlook** — the Microsoft email integration used both as a production trigger (the Outlook Trigger) and through Outlook action nodes for downloading, sending, and managing mail.

**System of record** — the carrier or business system that holds authoritative policy or claim data, which a flow looks up (matching) or writes to (write-back).

## Insurance terms

**Submission** — a new-business request to underwrite a risk, typically arriving as a packet of mixed documents. See [Submission Intake](../use-cases/submission-intake.md).

**Underwriting** — the process of evaluating and pricing a risk to decide whether and how to insure it.

**FNOL (First Notice of Loss)** — the first report of a new loss, usually arriving as a package of documents that opens a claim. See [Claim-to-Policy Comparison](../use-cases/claims-to-policy-comparison.md).

**Claim** — a request for payment under a policy following a loss. A claim is identified by a claim number and associated with a claimant and a date of loss.

**Policy** — the insurance contract in force for a risk; its declarations define coverage, limits, and terms.

**Declarations** — the summary page of a policy stating coverages, limits, deductibles, and key terms; used in coverage comparison.

**Coverage comparison** — an AI-assembled comparison of a reported loss against the policy in force. It is decision support, not a coverage determination — an adjuster approves before anything is finalized. See [Claim-to-Policy Comparison](../use-cases/claims-to-policy-comparison.md).

**Reserve** — the amount an insurer sets aside to cover the expected cost of a claim.

**Adjuster** — the person who investigates, evaluates, and settles a claim.

**Document package** — the set of documents that arrives for one case (a submission packet, an FNOL package, inbound claim mail, or a full claim file) and is processed as a unit.

**ACORD form** — a standardized industry insurance form commonly included in submission and claim packets.

**SOV (Statement of Values)** — a schedule listing insured properties and their values, common in commercial submissions.

**Loss run** — a report of a policyholder's prior claims history, used in underwriting.

**Claim indexing** — classifying inbound claim documents and filing them against the correct existing claim. See [Claim Indexing](../use-cases/claims-indexing.md).

**Claim file summarization** — reading a full claim file to produce a concise briefing for handoff, supervision, or audit. See [Claim File Summarization](../use-cases/claims-file-summarization.md).

## API terms

For the full developer reference, start at the [Bevaya API overview](/api).

**Bevaya API** — the RESTful JSON API for operating your AI Agents programmatically: uploading documents, starting and rerunning flow executions, inspecting steps, and reading items. In prose the API is "the Bevaya API," but its base URL, paths, schema names, and status values retain the platform's original `roots.ai` naming and are used exactly as shown.

**API key** — the long-lived credential for programmatic access. It is separate from how people sign in to the UI and must be kept secret. See [Authentication](/api/authentication).

**Access token (JWT)** — the short-lived token you obtain by exchanging an API key at `POST /token/authenticate` and then send as `Authorization: Bearer <token>` on every other request. See [Authentication](/api/authentication#exchange-api-key-for-access-token).

**File** — an uploaded document referenced by a `fileId`. Upload via `POST /files`, then `PUT` the content to the returned signed URL. See [Files](/api/files).

**File pages** — the rendered page images of a file, retrieved with `GET /files/{fileId}/pages`. See [File pages](/api/files#get-file-pages).

**Flow execution** — the API resource for a workflow run, started with `POST /flows/{flowId}/run` and listed with `GET /flow-executions`. Runs are asynchronous; the run response returns an `executionId`. See [Flow executions](/api/flow-executions).

**Rerun** — re-running a flow execution with the same inputs via `POST /flow-executions/{executionId}/rerun`, which returns a new `executionId`. A rerun repeats side effects; it is an API operation, not a UI replay feature. See [Rerun a flow execution](/api/flow-executions#rerun-a-flow-execution).

**Item (API)** — the API resource for a work item, listed with `GET /items` and retrieved with `GET /items/{id}`. See [Items](/api/items).

**Required identifier** — an ID an endpoint needs to locate a resource: a workspace, project, flow, execution, file, or item ID. See [Required identifiers](/api).

**Rate limit** — the API allows 60 requests per minute; responses include `X-RateLimit-Limit`, `X-RateLimit-Remaining`, and `X-RateLimit-Reset`. See [Errors, rate limits, and trace IDs](/api).

**Trace ID** — the `X-Encore-Trace-Id` header on every API response; record it and include it when contacting support.

**APIError** — the standard error response body, with a machine-readable `code` and a human-readable `message`.

## Where to go next

- [Core entity definitions](./core-entities.md) — the organization, workspace, AI Agent, environment, and variable entities in detail.
- [AI Agent reference](./ai-agents.md) — what an AI Agent is, its lifecycle, and what it does and does not decide.
- [Platform concepts](../welcome/platform-concepts.md) — the narrative model behind these terms.
- [Build AI Agents](../build-ai-agents/overview.md) — create, configure, test, and publish an AI Agent.
- [Bevaya API](/api) — operate AI Agents programmatically.