Provenance
Updated
A successful decision reply from the RightNow decision model can include provenance, metadata about the execution that produced the reply.
Read provenance
These Python and TypeScript programs send one decision over HTTP with no Idempotency-Key and print the X-Request-Id header as the current request. When the reply includes provenance, they print provenance.request_id as the first request, then the keyed replay state.
The field is optional. A stored reply written before provenance keeps its original body and has none. Read provenance only when it is present, and never fill a missing field.
Fields
A provenance object has exactly these fields.
decision_id- The decision ID, equal to the reply's
id. request_id- The ID of the request that produced the decision.
created- The decision's creation time in Unix seconds, equal to the reply's
created. model- The model string you requested, including an alias when you used one.
resolved_release- The concrete release, equal to the reply's
model. render_id- The serving render identifier.
numeric_fingerprint- The serving fingerprint, a string of 64 lowercase hexadecimal characters.
calibration_version- The exact calibration version of each answered question, by question name. A question refusal has no entry.
routedirectorlong, the context route of the reply.served_by- The reply's
served_byvalue. attachment_classes- The sorted, unique attachment kinds in the request:
audio,document,imageorvideo. Empty for a request without attachments. keyed_replayfalseon a fresh reply;truewhen the API returns a stored provenance reply for the sameIdempotency-Key.
An identifier with no public id reads unpublished.
A calibration version alone does not establish calibration. Read each answer's calibrated flag. Fingerprints and serving identifiers are strings, not quality scores or signatures.
Attachment classes contain no names, source URLs or content. A listed class still follows its existing input availability; this metadata grants no additional input support.
Request IDs and replays
The HTTP X-Request-Id header identifies the current request. It can differ from provenance.request_id, the first request that produced the decision.
A stream decision carries the same object at reply.provenance. The frame's request_id identifies the current request.
When the API returns a stored reply with keyed_replay set to true, it preserves the original decision ID, request ID, creation time and other provenance facts. Reusing the same key after a dropped connection does not guarantee the original reply.
A decision record lookup returns the stored reply with keyed_replay false: a lookup is not a replay.
Reply size
A reply too large to carry provenance omits it. Provenance never refuses a request.
Playground and data
In Playground, open Details after a run, then Provenance. Request shows the current request ID; First request shows the request that produced the decision. Older stored replies can omit provenance. Playground then shows provenance as not recorded. The stored body remains byte for byte unchanged; no missing field is inferred. Response JSON and its copied text keep the returned provenance values.
Provenance stays with the existing keyed reply and follows its retention and eviction rules. There is no separate provenance store. Decision IDs, request IDs and question names can link to your own records. Read Idempotency and the data handling terms.
Execution evidence is not returned.