List example documents

What they are for

Each entry is a fictitious document published against one profile, together with the audit that was produced from it. They exist so you can demonstrate or test a profile without sending a real investigation — which, given what these documents normally contain, is worth doing.

You see the examples belonging to your own organisation and the shared ones. Examples another organisation uploaded for its own profiles are never visible to you, even if the profileId happens to coincide.

The response is large

Three of the fields are whole documents rather than references to them:

• pdfBase64 — the example document itself, inline.
• jsonOutput — the entire stored run: identifier, meta, workers and reducer, where reducer.output is the same shape as an audit's result.clinicalData. One field is withheld: see below.
• actions — the pre-generated åtgärder described below, each a whole document of its own.

There is no metadata-only mode and no pagination. A profile with several examples answers with several megabytes, so do not call this on a page load or in a polling loop; fetch it when someone asks for an example.

The reviewers' instructions are not part of it

Each entry under jsonOutput.workers describes one reviewer's part of the audit — what it found (output), which rules it was given (loaded_rules), and the case material it worked from (user_prompt). What it does not carry is system_prompt: the instructions that make a reviewer behave the way it does. Those are ours, and they are no longer served.

Until August 2026 they were, by oversight rather than by design — they had never been described here and nothing we ship reads them. Everything else in the response is unchanged, so an integration that replays an example, renders its findings or reads its rules is unaffected. If you built something that reads system_prompt, tell us what it does and we will find you another way to it.

Some examples come with their åtgärder already written

An example is a finished audit, and step 3 — drafting an appeal, a decision, a letter — used to start from nothing every time you opened one. Where somebody has published an answer in advance, it travels with the example in actions, and reading it costs you nothing.

Each entry carries:

• actionType — the same id you would send to POST /v1/action. This is what tells you which åtgärder are already answered and which ones still need a run.
• actionName — what the åtgärd is called, as it read when the answer was written.
• generatedDocument — the answer, in the same shape POST /v1/action returns.

actions is an empty array for most examples: an answer exists only where somebody chose to publish one, and there is no way to request that we generate the rest. Treat a missing åtgärd as normal rather than as an error, and fall back to running it.

A published answer is a recording, not a live result. If the åtgärd behind it has been reworded since, the answer still reads as it did when it was written — which is exactly what makes it free. Run the åtgärd yourself when you need the current wording.

The stored audits are from before the citation rework

reducer.output in every shared example still carries the old citation fields. Sending one to POST /v1/action as clinicalData therefore answers 400 BAD_REQUEST, for exactly the reason described there.

This is not fixed by rewriting the stored fields — primary_label cannot be derived after the fact. The examples will be regenerated against the current format in a later release.

The documents themselves are unaffected and fully usable. If you want a fresh audit in the current format, run the example's pdfBase64 through POST /v1/analyze — which is also a more honest demonstration, since it exercises the engine rather than replaying a recording of it.

Request

Errors

A profile with no examples answers 200 with an empty list rather than 404, so an empty array is not an error condition to handle.