Cases (duvo cases)
Inspect a Case’s history
Create Cases
Create one Case with--title, or many at once with --from-file (a JSON file holding a single Case object or an array of up to 100). Pass - to --from-file to read the array from stdin.
data. Use --json-data for one Case, or a json_data object per Case in --from-file. The payload is validated against the Queue’s schema, and data and json_data are mutually exclusive — a request is either all free-text or all structured.
A schema-guarded Queue accepts only structured Cases: it needs a Case schema, and you send
json_data validated against it — free-text data is rejected. A Queue without the guard accepts free-text data (and also json_data when it has a schema). Either way, you no longer need to turn the schema guard off to add Cases by hand.Edit a Case
Update a Case’s title and/or its free-form data. Provide at least one field. Titles can be up to 500 characters.Editing a Case works whether it is pending, in progress, or already settled. Status, priority, and labels have their own commands.
Bulk-reprocess Cases
Re-process 1–100 Cases on a specific Agent in one call.Set Case priority
Raise or clear the priority of 1–100 Cases so higher-priority work is picked up first among eligible pending Cases. Priority levels arenone (the default), medium, and high. Due postponed Cases are still picked up before priority ordering applies.
Filter by status
--status takes display-status buckets — the same groupings the Queue view
offers — rather than the raw per-Case status:
Each Case in
--json output carries two fields. status is the raw
settlement column (pending, completed, failed). display_status is the
ten-state value the table’s STATUS column shows: a pending Case displays as
pending, in_progress, needs_input, or postponed depending on its live
state; a settled Case displays its stored outcome, or evaluating while the
evaluation still runs. --status filters on display_status, so a bucket count
does not equal a raw-status count. The CLI rejects the aliases claimed,
completed, and failed; use processing, resolved, and needs_review
instead.Filter by issue severity
When a Case evaluation flags failing rubrics, the Case records the highest severity it hit. Filter on it to triage the worst results first:Only
critical and medium are selectable. A Case whose failing rubrics are all
low severity is recorded as a success — low findings still appear in the Case’s
rubric breakdown, but they don’t hold the Case back, so no Case carries a low
severity to filter on.Filter by your own pending approvals
When a Case is waiting on approvers,--awaiting-my-approval narrows the list to
the Cases holding a decision that is yours to make:
--status needs_input and returns nothing alongside a settled status:
Only Cases in Queues that use approvals can match, so this returns nothing for a
team that does not have Case approvals in use.
--count-only when you need the matching total without Case rows. All Case filters still apply.
Setting priority never interrupts a Run or changes a Case’s status — it only affects the order pending Cases are picked up in.
Search Cases with label and structured filters
duvo cases list uses a query-string endpoint, so it can’t express label
filters. duvo cases search calls the JSON-body
POST /queues/{queue_id}/cases/search endpoint and carries the same status,
issue-severity, priority, date-range, sort, --field, --count-only,
--limit, --offset, and --json filters as list, plus one that list
can’t send:
--labelnarrows to Cases carrying specific labels. Acceptskey=valuefor keyed labels or a barevaluefor tag-style labels, matchingduvo cases labels assign/unlink. Repeat the flag to combine labels: repeated values for the same key are ORed, while different keys are ANDed.
--field works the same way in both commands: it filters on a field of a typed
Queue’s json_data, as <path>:<operator>[:<value>] (for example
$.invoice.amount:gte:5000). Supported operators are equals, notEquals,
in, notIn, gt, gte, lt, lte, contains, isSet, and isNotSet.
Repeatable, and all entries must match.
Reach for
search when you need to filter by labels; keep using list for the
plain status, severity, priority, date-range, structured-field, and free-text
filters.Export Cases as CSV
Download a Queue’s Cases as a CSV file for reporting or spreadsheet review. The export respects the same status, issue-severity, approval, priority, and search filters asduvo cases list, plus the --created-at-from and
--updated-at-from date bounds. Export applies lower date bounds only — the --created-at-to and
--updated-at-to upper bounds are available on duvo cases list, not on export.
Order the rows with --sort-by (created_at, updated_at, or postponed_to;
default created_at) and --sort-order (asc or desc; default asc). Each
row carries the Case’s id, title, status, priority, labels, lifecycle
timestamps, and data.
--output, the CSV is printed to stdout so you can pipe it into another
tool.
Manage Case labels
Attach or remove labels on a Case for filtering and organization.--label accepts either key=value (for keyed labels like priority=urgent) or just value on its own (for tag-style labels like urgent).Manage Case files
Work with the files attached to a Case — the invoice, EDI dump, or scan it was computed from.Upload declares the file’s type from its extension; pass
--mime-type for an extension the CLI doesn’t map. Files are capped at 50 MB, with 25 usable slots per Case. --output accepts a file path or an existing directory (the file keeps its own name inside it).Queues (duvo queues)
duvo queues stats returns counts keyed by Queue ID, including zeros for Queues with no matching Cases. Queue IDs that don’t belong to your team are silently dropped from the result.Case-level evaluation rubrics
A Queue’s case-level rubrics are the Pass/Fail questions a whole Case — across every Run that touched it — is judged against when an Agent settles it. Duvo generates them from the connected Agents’ AOPs, and you can manage the set the same way as an Agent’s custom rubrics: each rubric is a short title plus a Pass condition, with at most 12 per Queue version.--json to any command for machine-readable output.
Edits target the Queue’s current version’s rubric set — the one new Cases are judged against; already-judged Cases keep their original verdicts. A Queue gets its first rubric set after its first Agent-processed Case settles, so
add and replace fail with a conflict before then. Clearing the whole set isn’t supported — an empty set would be regenerated at the next settlement — so replace requires at least one rubric, and remove refuses to drop the last remaining one.Aggregations
An aggregation turns a typed Queue’s Case data into a small table of numbers instead of a list of Cases. It is a saved, Cube-style query over the fields the Queue declares — measures (count, sum, average, min, max, percentiles), optional groupings and a time bucket, plus filters — whose result is cached and recomputed on a staleness window, so a dashboard reading it stays cheap.Aggregations run over a Queue whose Cases carry structured data against a declared schema. A Queue of free-text Cases has nothing to aggregate.
--json to any command for machine-readable output.
A definition pins the Queue’s schema version when you create it, so its result always reflects the fields declared then; Cases created against an incompatible later schema are excluded and reported separately. Creating, refreshing, and deleting a definition need a Builder role or above — listing, reading a result, and evaluating are open to any team member.