Rederive

A screening verdict has to stay explainable months after it was issued: an auditor, a regulator or your own compliance team may ask why a customer was accepted or refused. Rules and labels change over time, so re-running today's check would answer a different question. Rederive answers the right one: it replays the verdict under the ruleset version and label snapshot it was issued with, and returns the score it had, not the score today's ruleset would give.

This works because every verdict is pinned to a ruleset version, a label snapshot and a chain height (see The pin), and keeps the findings it was derived from.

Request

POST /v1/verdicts/{verdict_id}/rederive with the checks:read scope. verdict_id is the verdict_id of a completed check.

Field	Required	Description
as_of	no	An ISO 8601 date-time with an offset. Audit metadata only: it is echoed back and never changes the result. It cannot be earlier than the moment the verdict was issued or more than five minutes in the future. When omitted, the time of the call is used.

The body is optional. Unknown fields are rejected.

Rederive is free: it records no usage, moves no quota or balance, calls no third-party data source and has no side effect, so it needs no Idempotency-Key. It is limited to 20 requests per minute per account, across all of the account's keys; see Rate limits and quotas.

curl

curl -s -X POST https://api.leeri.ai/v1/verdicts/$VERDICT_ID/rederive \
  -H "Authorization: Bearer $LEERI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"as_of":"2026-10-27T12:00:00Z"}'

Node.js

const response = await fetch(`https://api.leeri.ai/v1/verdicts/${verdictId}/rederive`, {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.LEERI_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ as_of: '2026-10-27T12:00:00Z' }),
});
const { data } = await response.json();

console.log(data.score, data.band, data.findings_digest, data.label_watermark.verified);

Python

import os
import requests

response = requests.post(
    f"https://api.leeri.ai/v1/verdicts/{verdict_id}/rederive",
    headers={"Authorization": f"Bearer {os.environ['LEERI_API_KEY']}"},
    json={"as_of": "2026-10-27T12:00:00Z"},
    timeout=30,
)
data = response.json()["data"]

print(data["score"], data["band"], data["findings_digest"], data["label_watermark"]["verified"])

Response

The answer uses the usual success envelope; the replay is in data.

Field	Description
verdict_id	The verdict that was replayed.
as_of	The as_of you sent, echoed, or the time of the call.
rederived_at	When this replay ran.
pinned	ruleset_version, label_snapshot_id and chain_height: the coordinates the verdict was issued at, and the ones this replay used.
score, band	The score derived from the stored findings under the pinned ruleset, and its band. The same meaning as on the check; see Score and band.
recommended_action	The action the band maps to: accept for low, manual_review for medium, reject for high and severe.
analysis_depth, partial, partial_reasons, degraded_sources, coverage_limitations, exposureIndexLag, provider_fallback	The completeness of the verdict as it was pinned, echoed exactly as stored; see How complete the verdict is. A replay makes no third-party call, so it can neither clear nor add a reason.
findings	Every stored finding, including warnings that carry no weight.
exposure	The exposure of the verdict.
findings_digest	The SHA-256, in hex, of the canonical form (RFC 8785) of the finding set. Two replays of the same verdict return the same digest.
label_watermark	Whether the label evidence still stands; see below.
evidence_report	Whether the evidence report still matches its registered hash; see below. null when the verdict never had a report.

Label watermark

Every finding that rests on a label records the source and the source link it was read with. The replay looks each of those labels up again at the verdict's label snapshot and confirms it still resolves to a row with the same source, source URL and provider.

Field	Description
verified	true when every checked label finding resolves unchanged.
checked	How many label findings were replayed against the label history. Findings that rest on a curated registry entry are not labels and are not counted.
discrepancies	One entry per finding that did not resolve: its rule_id and a reason, one of label_missing, not_live_at_watermark, provenance_mismatch or watermark_not_pinned.

Report check

When the verdict has an evidence report, evidence_report carries report_id, payload_hash_registered (the hash registered when the report link was first handed out), payload_hash_rederived (the hash of the report rebuilt now, at the payload version it was registered at) and matches. A report issued before a later change to the report format still matches. matches: false means the stored verdict and the registered report have diverged, and should be raised with support.

Using it

• Store verdict_id with your decision record, next to the pin, so you can replay it whenever you are asked.
• Keep findings_digest if you need to prove later that the set of findings has not changed.
• A replay returns the score the verdict had at the time. To screen the address under today's rules, run a new check instead; see Address checks.

Expected errors

Status	Code	When
400	VALIDATION_ERROR	A malformed verdict_id, or an as_of that is not an ISO 8601 date-time with an offset, is earlier than the verdict or is in the future.
403	SCOPE_ERROR	The key does not have the checks:read scope.
404	NOT_FOUND	No verdict with this id exists for your account and environment. A check that has not completed yet answers exactly like an unknown id.
429	RATE_LIMIT_EXCEEDED	More than 20 replays in a minute. Retry after Retry-After.