> ## Documentation Index
> Fetch the complete documentation index at: https://docs.elementum.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Acceptance Testing

> Test deployed records, files, automations, agents, and complete business journeys.

<Warning>
  **Limited Release.** The EDK is currently in limited release and is not available to all customers. Commands, generated file layouts, and package APIs may change before general availability. Confirm you're on the latest EDK version before starting new projects.
</Warning>

User acceptance testing verifies that a deployed solution produces the required business outcome. A successful command or plausible agent response is not enough: persisted records, files, automation executions, tool calls, and user-visible results must agree.

The examples use the active profile. See [Authentication](/edk/authentication) if you need to select a different or ambiguous target.

Use the `/elementum-uat` coding-agent playbook when you want an assistant to execute and document this workflow. See [Playbooks](/edk/playbooks).

## Define the Test Contract

Before creating test data:

1. Confirm the profile, organization, App namespaces, test users, and permitted side effects.
2. Turn each requirement into a test with setup, action, expected observable result, and cleanup.
3. Identify every applicable layer: records, files, automations, agents, tools, conversations, integrations, and the final outcome.
4. Give test records and files a unique run prefix, such as `UAT-20260818-01`.
5. Decide whether cleanup is approved. Never delete data the test did not create.

Check the target before continuing:

```bash theme={null}
elementum auth status
elementum list apps
elementum automations list <app-namespace>
```

Stop if the profile or App differs from the agreed target. Do not run tests that mutate production data without explicit approval.

## Use a Practical Test Sequence

Test from the lowest layer upward. This makes failures easier to locate and prevents an end-to-end test from hiding a basic data or deployment problem.

### 1. Verify records and validation

Preview record creation, then create and read back a uniquely named fixture:

```bash theme={null}
elementum records create <app-namespace> \
  -f "Title=UAT-<run-id>" --dry-run

elementum records create <app-namespace> \
  -f "Title=UAT-<run-id>" --json

elementum records get <app-namespace> \
  <record-handle> --json
```

Exercise required updates, filters, status changes, relationships, and validation failures. Assert the stored field values after each operation. A zero exit code confirms that the request completed, not that the resulting record is correct.

### 2. Verify files

When the solution accepts files, use a representative fixture with the expected type and realistic content:

```bash theme={null}
elementum records create <app-namespace> \
  -f "Title=UAT-<run-id>-file" \
  -a "Attachments=./fixture.pdf" --json
```

Read the record back and confirm the attachment is present. Then verify any downstream extraction, classification, automation, or agent behavior that depends on the file.

Include unsupported type, empty file, large file, or malformed-content cases when the requirements define how they should behave.

### 3. Verify automations

Trigger each automation through its real entry point, such as record creation, record update, an approved on-demand action, or a supported webhook. Inspect the resulting execution:

```bash theme={null}
elementum automations status <app-namespace> \
  "<automation-name>" --latest --timeline

elementum automations status <app-namespace> \
  "<automation-name>" --latest --all-io --json
```

Verify:

* The intended trigger selected the execution.
* Tasks ran in the expected order.
* Each task received the correct inputs and returned the expected outputs.
* Record changes and external effects occurred exactly once.
* Failure and retry behavior matches the acceptance criteria.
* The final business result is correct.

### 4. Verify agents and tools

Test an agent with direct requests, missing-information prompts, confirmation or refusal gates, tool selection, multi-turn context, and error recovery:

```bash theme={null}
elementum chat "<agent-name>" \
  -m "<initial request>"

elementum chat "<agent-name>" \
  --continue <conversation-id> -m "<follow-up>"

elementum conversation "<agent-name>" \
  <conversation-id> --json
```

For file-aware behavior, attach the same type of fixture used by the real process:

```bash theme={null}
elementum chat "<agent-name>" \
  -m "<request about the file>" -a ./fixture.pdf
```

For every expected tool call, confirm the selected tool, inputs, result, and resulting record, automation, or external effect. If the agent can access packaged capabilities or delegate to another agent, verify routing and the delegated result independently. Do not infer tool correctness from the final message alone.

### 5. Run the end-to-end journey

Run at least one realistic journey across all participating components:

1. Create the initial record or submit the entry action.
2. Attach or generate required files.
3. Complete each user decision or stage transition.
4. Observe automation execution and external effects.
5. Exercise the agent and verify its tool calls where applicable.
6. Read back the final records.
7. Confirm the user-visible business outcome.

Use the unique prefix to find the final fixtures:

```bash theme={null}
elementum records list <app-namespace> \
  --where "Title=UAT-<run-id>" --json

elementum interventions list <app-namespace> \
  --status OPEN --json
```

Pass the journey only when the visible result, stored data, files, executions, conversations, tool calls, and required external effects all match the acceptance criteria.

## Record Evidence

For each test, record:

* Test ID and requirement.
* Fixture and setup.
* Commands or user actions.
* Expected and actual results.
* Record handles, execution identifiers, conversation identifiers, and relevant screenshots.
* `PASS`, `FAIL`, or `BLOCKED`.
* Cleanup status.

Use `FAIL` when the product behavior contradicts the acceptance criterion. Use `BLOCKED` when the environment, permissions, unavailable dependency, or invalid fixture prevented the test from reaching the behavior under review.

## Clean Up Safely

Delete only fixtures created by the current run, and only when cleanup was approved:

```bash theme={null}
elementum records delete <app-namespace> \
  <record-handle> --dry-run

elementum records delete <app-namespace> \
  <record-handle>
```

Record any fixture that could not be removed so the environment owner can review it.