Scores and findings

The number, and which rule broke on which turn. Two endpoints, one reader's job.

A score without its findings is a number nobody can act on. These two are meant to be read together.

The endpoints

GET /v1/scoresThe numbers, cursor paged
GET /v1/findingsWhat each rule found, cursor paged

bash

curl "https://app.evidova.com/v1/scores?session_id=...&limit=50" \
  -H "authorization: Bearer ak_live_..."

Filters both share

session_idOne call or chat
dimensionOne score area
client_id, channelWhose customer, and voice or chat
from, toThe window to read
limit, cursor1 to 200, defaulting to 50, and the next_cursor from the last page
verdictFindings only. What the rule concluded
overallScores only. The overall number rather than one area

What a score carries

valueThe number itself
dimension, outcomeWhich score area, and what it came to
completenessHow much of the area was actually read
hard_cap_appliedTrue when one automatic fail held the number down on its own
rubric_version_id, instrument_versionWhat produced it
evaluated_atWhen

What a finding carries

questionThe rule, as the plain question it asks
verdict, severityWhat it concluded, and how much it matters
evidence_turnsThe turns it is citing. This is the half that tells somebody what to fix
panelWhat the second-reading judges said
critique, confidenceThe reasoning, and how sure it was
check_id, rubric_version_idWhich rule, under which frozen set
Note: Always read rubric_version_id before you compare two scores. A score only compares with another frozen under the same rules, and mixing versions in one trend is the commonest way to draw a chart that means nothing.

Read next

  • Metrics · Bucketed readings, so you can chart quality beside your own numbers.
  • Errors and status codes · Every status both surfaces return, and what to do about each one.
  • API · Send conversations in, and read the scores back out. Two surfaces, one key format.
This page as markdown