A document-review example, followed by recordings of three actual Studio tests. The documents are fictional; the responses and citation error are real.
Imagine reviewing a draft procedure. You need to find what it says, check whether the evidence supports it, and record what still needs an answer.
Read text directly where possible. Flag scans or diagrams that need different handling, and keep unreadable pages visible.
Use the review criteria you supplied. Each finding should point to the passage that supports it.
A second pass reads the evidence before the draft. Code checks page references and quoted passages; disagreements remain visible.
A person accepts, rejects or investigates each finding. A citation check cannot establish whether the conclusion is sound.
This explains a design approach. The checks and acceptance criteria for a build depend on your documents and the decisions you need to make.
Agree the expected answers with a qualified reviewer before running the test. Include missing evidence, incorrect findings and cases where the model should leave the question unresolved.
Measure missed problems, false alarms, human review time and API cost. A cheaper model is useful only if the complete review still meets the agreed standard.
Exact identifiers and conceptual questions need different tests. I would compare lexical, semantic and combined search against queries representative of your work, then inspect the retrieved passages.
These clips show actual responses from the Document Desk — Luna agent using ten fictional documents. Questions and retrieved excerpts were processed by OpenAI. This is a recorded demonstration, not a live chat or evidence from a customer.
Question: According to the Support guide, what are the normal support hours? Show the source.
The answer gives Monday–Thursday, 09:00–16:00 UTC and preserves the closure-date exception. The cited Support guide supports that answer.
Silent screen recording. Fictional documents. Actual response shown; clip trimmed after the result.
Question: Will support be open on Monday 14 September 2026 at 10:00 UTC? Check both the Support guide and Team calendar.
The conclusion is correct: support is closed on 14 September 2026. The two citation links are attached to the opposite source statements. The error is retained in this clip; a correct conclusion does not make this a clean pass.
Silent screen recording. Fictional documents. Typing and setup omitted; the answer and citation check are retained.
Question: What telephone number should I call for support?
The answer says no telephone number is provided in the supplied documents. It does not invent one. This is one observed result, not a guarantee that missing information will always be recognised.
Silent screen recording. Fictional documents. Actual response shown; clip trimmed after the result.
I would assess a larger, representative set of questions before recommending a build. These clips show what happened in three tests, including a source-link mistake; they do not establish a reliability rate, time saving or production-readiness claim.
Most tools hand people a dropdown of model names and let them guess. The names change every few months, and the guess is wrong in one of two directions — a one-line question sent to the most expensive model on the list, or a genuinely hard one answered in a hurry by the cheapest. Here the platform sizes the question first and picks for them.
A quick assessment of what the ask actually needs. Its cost and response time depend on the routing implementation and should be measured.
Reformat this, summarise that, what does this term mean. Most of the day's traffic never needs more.
Longer reasoning, comparisons across documents, anything where a fast answer would be a shallow one.
The first escalation is letting a model think for longer, not reaching for a costlier one. Price is the last lever, not the first.
The choice is made once, at the top of a thread, so an answer's character doesn't shift halfway through a discussion.
None of this is a black box we invented and licensed to you. The routing policy is a piece of configuration on your own system: you can read it, change the boundary, or pin a team to local models entirely. The routing behaviour and data boundaries are agreed and tested for each build.
This is a demonstration of the platform. CPLT — the association behind it, and the builds it takes on when a team asks — lives on cplt.tech, along with what a build costs. It starts with a free forty-five-minute scoping call that ends in a one-page written note on what your team can run.