> ## Documentation Index
> Fetch the complete documentation index at: https://developers.argosidentity.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Core concepts
> The data hierarchy, playbooks, the analysis lifecycle, verdict values, and credit categories, all on one page.
These concepts come up throughout the Omni documentation. Whether you work in the dashboard or through the API, the terms on this page are the ones used to explain it.
## Data hierarchy
```
Project Project — the unit for API keys, members, and credits
└── Workflow Workflow — policy + playbook + output schema
└── Profile Profile — one verification subject (one vendor, say)
└── Folder Folder — a group of documents in a profile (a default folder is created for you)
└── Item Item — one file, text, or JSON entry
└── Analysis Analysis — the result of verifying the whole profile with the playbook
```
| Level | ID prefix | Created in | Limit |
| -------- | ----------- | --------------- | ------------------------------------------------------------------ |
| Project | `proj_` | Dashboard | 5 per user |
| Workflow | `wf_` | Dashboard | 10 per project |
| Profile | `pf_` | Dashboard · API | Unlimited per workflow |
| Folder | `fd_` | Dashboard · API | Several per profile, with one default folder created automatically |
| Item | `item_` | Dashboard · API | No count limit. 10MB per file, 100MB total per profile |
| Analysis | `analysis_` | Dashboard · API | 10 per day on a trial project |
Projects and workflows are created only in the dashboard. An API key is issued per project, and that key can only work with the workflows, profiles, items, and analyses inside that project.
## Workflows and playbooks
A workflow is made of a **policy (plain language)**, an **AI model**, and an **output schema**. When you save a workflow, Omni reads the policy and builds a **playbook** — the execution plan an analysis actually follows.
| Component | Description | API field |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| Playbook ID | Formatted `PB-YYYYMMDD-XXXXXX`. Reissued only when the playbook is **regenerated** because the policy text or a policy document changed | `playbookId` |
| Playbook version | The patch version increments every time you edit actions, engines, or reference notes. The ID stays the same | `playbookVersion` |
| Action | One step of the playbook. It has a name (`snake_case`) and a description, and runs in order | `workflowActions[]` |
| Action ID | The stable identifier of an action. It does not change when you reorder | `workflowActions[].workId`, and `work_id` in the audit log |
| Step engine | The external verification engine attached to an action (AML screening, for example). Attached automatically from the policy, and changeable on the edit screen | `workflowActions[].engines[]` |
| Reference notes | Extra instructions given to the agent per action. Up to 20 per action, 500 characters each | `workflowActions[].referenceNotes[]` |
Editing the playbook does not change analyses that already finished. An analysis **freezes** and stores the playbook as it was at run time, and `playbookSnapshot`, `playbookVersion`, and `snapshotStatus` in the response tell you which version ran.
## Analysis lifecycle
```
POST /analyses/:id/analyze → pending → processing → completed
└→ failed
```
| Status | Meaning | What to do next |
| ------------ | ------------------------------------------------------ | ------------------------------------------ |
| `pending` | Queued | Keep polling |
| `processing` | The agent is running the playbook | Keep polling |
| `completed` | The result is final | Branch on `verificationStatus` |
| `failed` | The run failed. Check `error.code` and `error.message` | Check the item statuses, then run it again |
Analyses are asynchronous. The request returns `202 Accepted` and an `analysisId` immediately, and you poll [`GET /analyses/:analysisId`](/en/omni/api-reference/get-analysis) for the result. While an analysis is running on a profile, a new analysis request on that profile is refused with `409`.
To run an analysis, every item in the profile must be `ACTIVE`.
| Item status | Meaning |
| ----------- | ------------------------------------------------ |
| `PENDING` | Uploaded, text extraction (OCR) in progress |
| `ACTIVE` | Ready to be used in an analysis |
| `FAILED` | Processing failed. Delete it and upload it again |
## Three levels of verdict
An analysis result carries verdicts at three different levels. Branch your downstream processing on the top-level `verificationStatus`.
| Level | Field | Values |
| ------------------- | ------------------------------ | ------------------------------------------ |
| The whole analysis | `verificationStatus` | `verified` · `pending_review` · `rejected` |
| A playbook step | `agentAuditLog.steps[].status` | `passed` · `needs_review` · `failed` |
| An individual check | `findings[].result` | `passed` · `warning` · `failed` |
| `verificationStatus` | How it is decided | Recommended handling |
| -------------------- | ----------------------------------- | ------------------------ |
| `verified` | Every step `passed` | Approve automatically |
| `pending_review` | At least one step is `needs_review` | Send to a reviewer queue |
| `rejected` | At least one step `failed` | Reject or escalate |
## Analysis Score
A 0–100 measure of **how completely the analysis was carried out as defined**. It is not the AI's confidence. The API provides it as the `confidence` object.
| Part | Weight | How it is computed |
| ------------------- | ------ | ------------------------------------------------------------------------------------- |
| Step Execution | 40% | Share of the playbook steps that actually ran |
| Step Quality | 20% | Whether the steps that ran passed, and whether their assigned engines were called |
| Output Completeness | 40% | Share of output-schema leaf fields that received a value (arrays counted per element) |
The score gets a level of `HIGH` (80–100), `MEDIUM` (65–79), or `LOW` (0–64). `confidenceScore` (0–1) is separate — it is the confidence the agent recorded, and it can be empty.
## Output schema and extracted data
The output schema is a JSON Schema you define per workflow. `extractedData` in an analysis result follows that structure exactly, and each leaf field carries its value along with the grounds for it.
```json theme={null}
"company": {
"legal_name": {
"value": "ACME TRADING LLC",
"reasoning": "Extracted from the entity name field on the certificate of good standing",
"sourceStep": 1
}
}
```
A workflow with no schema, or an analysis where output assembly failed, returns the raw per-action structure without this envelope. How to tell the difference, and how to read a field that came back empty, is covered in [reading analysis results](/en/omni/guides/reading-analysis-results).
## Credits
A project's credit usage is aggregated into three categories.
| Category | Billed | Example |
| ----------- | -------------------------------------------------------- | ----------------------------------------------------------- |
| Environment | 00:00 UTC daily, regardless of project status | Keeping a workflow available |
| Operation | When an API request succeeds | Creating a profile, adding a file item, running an analysis |
| Tools | When an external engine call during an analysis succeeds | AML screening |
The breakdown is on the [credit usage](/en/omni/dashboard/project/credit-usage) tab in the dashboard.
## Next steps
From creating a project to reading your first analysis result.
The `extractedData` envelope, reasons for missing values, and the audit log.