What the Evidence Packet Costs in Tokens per Case

Take a 50-page evidence packet. A rough rule of thumb quoted across model providers is about four characters or three-quarters of a word per token, and 1,000 words is about 1,333 tokens (iternal.ai); OpenAI's guidance on tokens uses the same four-characters-per-token approximation (Silicon Data). At roughly 500 words per page, the packet is about 25,000 words, or roughly 33,000 tokens by that ratio. To keep the example conservative we will use the 25,000-token figure.

Now split the two jobs.

Run the numbers for a simple two-step review: one pass for triage, one for the decision. Sending the full packet twice costs 50,000 input tokens. Storing once and rendering costs 5,000 for extraction, plus 500 for the triage summary, plus 3,000 for the decision slice: 8,500 tokens, about 17% of the full-send path. Three reviews with a single slice each land around 9,500 tokens against 75,000, roughly one eighth.

Output tokens bill higher than input in most published price sheets, and per-million rates differ by a factor of dozens between budget and frontier models (iternal.ai). That is why we count tokens and hold money aside: the token ratio is the durable part, and you re-price it against whatever model you route to. Token pricing tools will split input, output and cached input for you (tokencalculator.ai), and a sensible cost model keeps cost per request, cost per feature and cost per month as separate lines (Silicon Data).

The break-even is easier than it looks. Let E be extraction cost, R the render cost per review, F the full-packet cost, and n the number of reviews.

store-and-render:  E + n * R
send-full-packet:  n * F

store-and-render wins when E + n*R < n*F, i.e. E / (F - R) < n

With E = 5,000, F = 25,000 and R = 500, the break-even is 5,000 / 24,500, about 0.2 reviews. In other words, the structured store wins from the first additional view. The rule generalizes: compare the extraction cost with the saved tokens per review. Extraction is only not worth it when a case is genuinely reviewed once and never cited again. In a real queue, almost nothing is reviewed once, because appeal, spot-check and audit all render the same case again.

The same logic appears in content work. One interview or case study gets repurposed into a one-pager, a deck slide, a social post, an email and a website proof point, five formats with five distinct jobs from a single source (The Simons Group). Breaking a large piece into reusable components so it can be repurposed across channels without proportionally increasing resources is exactly the store-once, render-many pattern (Storyteq). The video walkthrough of content atomization makes the same point in funnel terms: identify the cornerstone piece, then create derivatives sized for each stage (Coursera). Case study teams that plan all the derivative uses before writing avoid redoing the interview for each format (Uplift Content).

For a review queue the translation is direct: the case is the cornerstone, the renders are the derivatives, and the extraction interview happens once.

The store is not a summary. It is a set of addressable parts, each with a citation, so a render can pull exactly what it needs. A workable schema has five layers:

1. Case header: ID, parties, dates, jurisdiction, status, decision owner.
2. Timeline: dated events, each linked to a source page and offset.
3. Claims: one row per assertion the decision turns on, with the supporting passage and confidence.
4. Rules: the policy or clause text that the claims are tested against, frozen at the time of decision.
5. Open questions: what is missing, contested, or needs a human call.

Every row carries a source pointer, usually file plus page plus a short quoted span. That is the unit a render can fetch on its own. Hierarchical indexing at paragraph, section and document level lets retrieval pull exactly the right amount of context for each query, rather than the whole document every time (reptile.haus).

Review workflows describe this as the evidence pack: the draft content, the customer context, the cited sources and the policy flags, packaged so the decision is obvious in seconds (StackAI). Their approval matrix is a useful checklist for what a render must contain for each action type, with the required approver role and the evidence list spelled out. Build the store to answer that list for every action type in your own matrix.

One practical limit: long retrieval pipelines fail by producing confident citations that do not support the claim, and detecting that is an active research problem rather than a solved one (arXiv FACTUM paper). So the store should keep the quoted span, not just the file name. A reviewer can settle a file name in one click; a wrong quoted span takes ten minutes to untangle.

A render is a function of the store and a view request. The view request says who is looking, what decision they face, and which slices they asked for. Three defaults cover most of a queue:

• Triage view: case header, top three claims, missing-information list, about 500 tokens.
• Decision view: the claims in dispute plus the rules they are tested against, about 3,000 tokens.
• Appeal view: the full timeline plus the original decision rationale, maybe 2,000 tokens because timeline rows are short.

With that layout, a case that gets triaged and decided costs 5,000 to extract, then 500 plus 3,000 to review: 8,500 tokens for the whole case, and every later appeal or spot-check costs a further 2,000 rather than a fresh 25,000. The queue's bill grows with the number of decisions, not with the size of the archive.

Two rules keep the render honest. First, the render never summarizes a claim it cannot cite; if the passage is missing, the claim appears on the open-questions list. Reviewers in RAG loops flag exactly this failure when asked whether an answer is factually correct based on the retrieved documents and whether retrieval found the necessary information (Label Studio). That review prompt is a good model for your own QA checklist. Second, the reviewer can always escalate to a larger slice on demand. Escalation is the escape hatch that lets the default view stay small.

The most common way a store-once design rots is a changed rule. A policy is updated, a decision is re-opened, and the frozen rule text in an old case no longer matches the live version. Handle this by versioning the rule layer separately from the case layer. A case cites a rule by version, and a re-render names both the version at decision time and the current version where they differ. That keeps the review of a past decision faithful to what the reviewer had, while surfacing the mismatch for anyone working from today's policy.

The second failure mode is drift in extraction quality. If extraction mislabels one claim, every render built from it repeats the error, cheaply and confidently. Automated metrics can tell you which cases to look at first: score faithfulness and context relevance, flag everything below a threshold, and sort by severity so human review goes where it is worth the most (Label Studio). The published sample code thresholds faithfulness at 0.7 and context relevance at 0.6, which is as good a starting place as any for a first pass.

The third is trust, which is measurable. Track accuracy, relevance, coherence, helpfulness and user trust against a pre-deployment baseline, and treat the numbers as a check on whether the renders are actually helping people decide (Glean). For a queue, helpfulness usually means decisions per reviewer-hour; if that does not move, the render is the wrong size.

Start with one case type, not the whole archive. The full-send path is already running, so it gives you the baseline for free.

1. Pick a case type with steady volume and at least two views per case.
2. Store 20 cases in the structured schema by hand, side by side with reasonable care. Compare extraction cost against the measured packet size, not against the 25,000 estimate.
3. Define the triage and decision renders, and measure the tokens they actually use, including the prompt scaffolding.
4. Run the queue in shadow for two weeks, rendering in parallel with the existing full send, and log which escalation path reviewers take and how often.
5. Cut over when the escalation rate is low enough that the renders are decided in one screen, and keep the full packet available as an explicit escalation for cases that need it.

Keeping a way to send everything matters for audit, and for cases where the render is plainly not enough. The goal is a cheap default and an expensive exception, not the removal of the exception.

Teams building this usually hit the same integration question: the extraction step, the render step and the evaluation step each want a different model. One API for text, image and embedding models with an OpenAI-compatible interface, prepaid and billed in dollars, removes that as a variable while you tune the cost model, and Quanta Inference is where that lives. If the harder part is the schema and the reviewer workflow rather than the plumbing, a specialist who builds it with you is the faster path, via Quanta.