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

# Action checks and operational reports

> Check proposed actions, map monitor reference data, analyze transfers and estimate costs.

## Check a proposed booking before saving

Call `POST /api/v1/action-checks` with your organization's API key and await the
response **before** committing the booking. Compare canonical identifiers from
trusted booking/CRM data, not free-text names.

```json theme={null}
{
  "agentId": "11111111-1111-4111-8111-111111111111",
  "referenceData": {
    "requested": { "doctor_id": "doctor-42" },
    "proposed": { "doctor_id": "doctor-73" }
  },
  "comparisons": [
    { "key": "doctor", "expectedPath": "requested.doctor_id", "actualPath": "proposed.doctor_id" }
  ],
  "requiredTools": ["availability_lookup"],
  "tools": [{ "key": "availability_lookup", "status": "succeeded" }]
}
```

This example returns `decision: "flag_mismatch"`, `allowed: false`, with a
`mismatch` check. The three decisions are:

* `proceed`: all supplied comparisons match, all supplied tools succeeded, and every declared required tool is reported as succeeded.
* `request_clarification`: an input is missing, unusable, or a tool is pending/not called.
* `flag_mismatch`: a comparison differs or a tool failed.

The response contains check keys and statuses, never the reference values.
The API authenticates the agent inside the key's organization. It performs no
booking, ingestion, model call, or background job. It validates **the supplied
snapshot**; it does not fetch CRM state or prevent concurrent changes. Recheck if
the proposed booking changes, and keep your booking system's transaction and
idempotency protections. Do not commit on a timeout or non-200 response.

Limits: 64 KiB request, 1–20 comparisons, up to 20 tool statuses. Paths address
own object fields, at most six levels deep; arrays and objects are not scalar
comparison values. Types must match; whitespace around strings is ignored.
Missing/null/blank values and strings over 1,000 characters cannot pass.

Declare up to 20 `requiredTools` separately from the reported `tools`. If a
required key is omitted from `tools`, its check returns `missing`, with
`allowed: false` and `request_clarification` (or `flag_mismatch` if another
check fails). A matching doctor alone cannot approve that request. Required
tools default to an empty list for existing clients; always send the list when
you need execution prerequisites enforced. Tool keys must be unique and must
not collide with comparison keys. Keys are case-sensitive after trimming.

Build this list from trusted application policy, not from an LLM's reported
tool calls. The API cannot detect a prerequisite omitted from both lists.
Require checks such as availability lookup **before** booking; do not require
the booking operation itself to have succeeded before authorizing it. Report
statuses from actual execution results. Rebuild the snapshot and recheck after
any proposed doctor, appointment, or prerequisite state changes.

## Map reference data into a monitor

In an AI analysis stage, expand **Reference data**. Add a field label and a
dotted call-metadata path, such as `booking.doctor_id` or `crm.patient_type`.
Mark inputs required when the stage cannot judge without them. Save the monitor
normally; mappings travel with its pipeline version and historical analysis.

Only mapped scalar fields enter the stage's reference block. Each stage accepts
20 fields, up to 1,000 characters per scalar and 6,000 characters in total.
Oversized or absent required inputs leave the monitor **Not evaluated**, with
the missing field labels visible in its result trace. No model is called for
that monitor. Optional missing fields are disclosed to the judge. These mappings
are separate from the legacy **Use call context** option.

Use stable requested/proposed doctor IDs for deterministic checks. An AI monitor
can compare conversation evidence against CRM fields after the call, but is not
the synchronous action check.

## Explain transfers

Open **Reports → Transfer analysis → Create transfer monitor**. The editable
preset includes appropriate/avoidable transfers, abandonment, reasons, new/existing
patient type, task completion, and evidenced triggering questions.

1. Select the agents and review the instructions against their permitted tasks.
2. Add required reference mappings if policy or patient type needs CRM evidence.
3. Test and save the monitor. Review expected volume and sampling before opting
   into historical analysis; opening a report never queues evaluations.
4. Select the monitor and dates in Transfer analysis. The default is 14 days,
   bounded to 90 days, using UTC call dates.

Rates use known outcomes and show their numerators and denominators. Total calls
and evaluated calls remain separate; missing, filtered, sampled-out and older
monitor-version results do not become successful outcomes. Reason/patient/task
breakdowns and example calls support manual review. Small samples are visible,
not declared statistically significant. Questions require evidence of a link to
the outcome; proximity alone does not prove causation.

## Evaluate voice naturalness

**Voice naturalness (preview)** is disabled by default and is not live validated:
synthetic audio requests returned AWS HTTP 500. Keep `AUDIO_NATURALNESS_ENABLED=false`
on the app and worker until audio inference succeeds and multilingual examples
have been reviewed; enable it on both only after that validation.

The separate audio monitor is designed to assess the first 20 seconds of an
isolated agent track for naturalness, prosody, and
language suitability across audible languages. Correct words can still have poor
delivery; an accent alone is not a failure. Degradation scores run from 0 (natural)
to 100 (severe), with the monitor's affected threshold defaulting to 50.

This requires an isolated agent recording, worker audio decoding, and the
opt-in AWS audio inference configuration. Mixed/noisy/insufficient audio,
unsupported judgments and unavailable inference are **Not evaluated**, never a
clean bill of health. A short clip cannot detect late-call defects or prove
whether a caller is human. Validate scores with multilingual human reviewers
before customer rollout; this is not a calibrated speech-quality benchmark.

## Review costs without reducing compliance coverage

Open **Reports → Cost report**. Three ledgers remain separate: provider call
charges, trace component estimates, and monitoring estimates. Provider charges
may include the same costs as traces, so do not sum them. Unknown prices and
unavailable telemetry are explicit. Monitoring costs use recorded usage and
available prices, not invoice reconciliation.

Company selection uses each call's attribution. Historical usage without a
conversation link stays unattributed and is excluded from company views.
Ambiguous session references cannot attribute trace costs.

Select only optional, non-compliance monitors in the savings estimator. The
slider estimates an additional reduction of their currently recorded spend
through filtering or sampling. Every monitor starts excluded, no setting is
changed, and compliance checks must retain full coverage. Estimates exclude
infrastructure and unrecorded usage.

Programmatic reports use the same authenticated organization and company scope:

* `GET /api/v1/reports/costs?companyId=UUID&from=2026-08-24&to=2026-09-06`
* `GET /api/v1/reports/transfers?metricId=UUID&companyId=UUID&from=2026-08-24&to=2026-09-06`

Both require Reports entitlement. Company/date parameters are optional; transfer
reports require a monitor ID. Results identify the effective date window.
Saved written reports remain organization-wide snapshots and are hidden while
a company is selected; return to All agents to read them.