Core concepts - ARGOS Identity

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 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.

"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.

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 tab in the dashboard.

Next steps

Quickstart

From creating a project to reading your first analysis result.

Reading analysis results

The extractedData envelope, reasons for missing values, and the audit log.

​Data hierarchy

​Workflows and playbooks

​Analysis lifecycle

​Three levels of verdict

​Analysis Score

​Output schema and extracted data

​Credits

​Next steps

Quickstart

Reading analysis results

Data hierarchy

Workflows and playbooks

Analysis lifecycle

Three levels of verdict

Analysis Score

Output schema and extracted data

Credits

Next steps