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

# Journal-entry testing

> An audit procedure that publishes its own SQL

`POST /v1/workspaces/{workspace_id}/je-testing` returns a job whose result is a
`je_testing`.

Python: `client.search.je_testing`. TypeScript: `client.search.jeTesting`.
MCP: `je_testing`. CLI: `ndi je-testing`.

A sibling of [deep search](/api-reference/intelligent-search), not a preset of
it. Deep search retrieves and cites; this route *performs a test*. The run
orients itself in the workspace's ledger package, writes SQL over the ingested
tables itself, and answers with `sql_receipts`: every statement it ran, the
tables each one registered, and a bounded result. A figure in the answer is
meant to be readable out of one of those receipts, and a receipt carries
everything needed to re-run it.

`figures` is the checkable half of the answer — one entry per criterion, with
the `definition` it was tested under, the `population` it ran over, the `count`
that met it, and the `result_ids` of the statements behind it.
`exception_listing_result_id` names the receipt worth opening: an unfiltered
count points at every row, an exception listing points at the rows that failed.
A criterion the workspace holds no material for comes back
`cannot_be_performed`, with `result_ids` naming the probes that establish the
absence.

`binding` is the definitional layer the whole run rests on: which column is the
period, which values mean posted, which clock a timing test used. Two runs that
disagree usually disagree here first.

## Scope

`paths` names the files of the package under test — each entry is an uploaded
file, never a folder. `path_prefix` scopes to a folder, and the two compose as
an intersection. Omit both to test the whole workspace: the run orients over
every queryable file the caller can see and finds the ledger package itself,
the same way deep search behaves when unscoped.

## Reasoning budget

`reasoning_effort` controls the thinking budget without changing the JET engine.
Its accepted values are `none`, `minimal`, `low`, `medium`, and `high`. Omit it
for the route default; an explicit `null` uses the model catalogue's prescription.
The internal exact-model header can still pin an engine for evaluation.

The reverted `effort` selector and `tier` are rejected by the strict body.
New jobs have `effort: null`; previously stored jobs retain their recorded level.
There is no `top_k` (the run authors its own citation list) or
`allow_clarification` (a run that cannot proceed says so in its answer).

## Partial and degraded runs

`exhausted: true` means the step budget ran out before the procedure finished —
a successful, partial response, not a failure. `execution_status` says whether
the run tested what it was asked to test; `quality` grades how well a performed
test went. `degraded` is set when the run broke before finalizing an answer but
had already computed real working: `sql_receipts` and `binding` are published,
`figures` is empty, and `answer` says so.

A run keeps its conversation: pass the result's `session_id` on a later request
to ask a follow-up in the same thread. Only the API key that started a thread
may continue it, and a thread whose turn is still running returns `409
session_busy`.

See [Search methods](/concepts/search-methods),
[ledger understanding](/api-reference/ledger-understanding), and
[Jobs](/api-reference/jobs).