The Retrieval Budget: A Worked DAL Challenge for RAG Pipelines
A retrieval system can fail quietly: the answer sounds plausible, but the context window was spent on documents that never helped. A small DAL challenge makes that tradeoff visible and gives the agent a repeatable way to keep evidence useful.
This article walks through a compact DAL pattern for bounding RAG retrieval, preserving the evidence that matters, and leaving a receipt for what the agent actually used.
The challenge: more context, less signal
Suppose an agent must answer a question about a repository. The corpus contains current contract docs, old implementation notes, session logs, and unrelated drafts. A naive RAG pass retrieves the top ten chunks and places them all in the prompt.
That approach feels safe because nothing was discarded. In practice, it creates three problems:
- stale notes can compete with current contracts;
- repeated chunks consume the context budget without adding evidence;
- nobody can later explain why a particular answer was produced.
The challenge is deliberately small: design one DAL task that retrieves a bounded set of context, prefers authoritative material, and writes an evidence receipt beside the result. The goal is not to invent a perfect ranking algorithm. It is to make the tradeoff explicit and inspectable.
Start with a hard budget
Represent the retrieval policy as data rather than burying it in prose. A minimal sketch might look like this:
``dal let retrieval_policy = { max_docs: 4, max_chars: 12000, models: ["canon"], prefer: ["runtime_contract", "execution_spec"], allow_advisory: false } ``
The exact object syntax can vary with the host integration, but the design principle is stable: retrieval has a ceiling. max_docs limits breadth; max_chars limits prompt pressure. The model selector and authority preference prevent a general search from treating every note as equally reliable.
A budget also gives the operator a meaningful failure mode. If the relevant evidence does not fit, the agent should report that constraint instead of silently expanding the context until the answer becomes expensive and hard to audit.
Retrieve, then classify
The next step is to separate finding candidates from deciding what may support the answer. A retrieval call can return paths, excerpts, and metadata:
```dal let candidates = rag::query( question, { model: "canon", limit: 12 } )
let usable = candidates |> filter(fn item -> item.authority in retrieval_policy.prefer) |> take(retrieval_policy.max_docs) ```
This two-stage shape matters. Asking the retriever for only four results assumes its ranking is already your policy. Asking for a somewhat larger candidate set gives the policy a chance to reject stale or merely adjacent material before the context is assembled.
If the corpus does not expose authority metadata, do not pretend it does. Use an explicit allowlist of known contract paths, or mark the evidence as advisory. A fallback can be simple:
``dal let usable = candidates |> filter(fn item -> item.path starts_with "docs/contracts/") ``
The important behavior is not the field name. It is the refusal to upgrade an unverified note into a source of truth merely because it ranked highly.
Assemble context without hiding truncation
After filtering, assemble excerpts until the character budget is reached. Keep the selected paths and the truncation decision in memory while constructing the prompt:
```dal let context = [] let used_chars = 0
for item in usable { let excerpt = item.excerpt if used_chars + len(excerpt) <= retrieval_policy.max_chars { context = append(context, item) used_chars = used_chars + len(excerpt) } }
let answer = agent::respond({ question: question, evidence: context, instruction: "Use only the supplied evidence for contractual claims." }) ```
A production host may provide a dedicated context builder, but the invariant should remain visible: selection happens before generation, and the final evidence set is bounded.
When an item is omitted because of the budget, record that fact. “Retrieved but not supplied” is different from “not found.” That distinction helps an operator decide whether to refine the query, raise the budget, or split the task into two questions.
Leave an evidence receipt
The final part of the challenge is the smallest and most valuable: write a receipt. It does not need to reproduce the entire prompt. It needs enough information to reconstruct the retrieval decision.
```dal let receipt = { question: question, selected: map(context, fn item -> { path: item.path, authority: item.authority, excerpt_chars: len(item.excerpt) }), candidates_seen: len(candidates), omitted_for_budget: len(candidates) - len(context), max_chars: retrieval_policy.max_chars }
fs::write( "COO-FILESYSTEM/work_logs/rag-receipts/2026-08-03-retrieval.json", json::encode(receipt) ) ```
A receipt is not proof that the answer is correct. It is proof of what the agent had available and which policy was applied. That makes review narrower: an operator can inspect the selected documents and ask whether the ranking or the answer needs correction.
For recurring jobs, use a unique filename or append structured records rather than overwriting a single receipt. Keep the receipt in a work-log or research lane, separate from the article or other user-facing artifact.
Test the tradeoff with two deliberate cases
A useful challenge is not complete until it tests both sides of the budget. Run the same question with a small limit and with a larger limit. Compare selected paths, omitted candidates, and the resulting answer.
The small-budget case should demonstrate restraint. The larger case should demonstrate whether additional evidence changes the conclusion or merely adds repetition. If the answer changes, the receipt tells you which document entered the context. If it does not, the larger budget may be unnecessary.
Also test a conflict: place a current contract and an older note among the candidates. The expected result is not “the newest-looking sentence wins.” The expected result is that the authority policy selects the contract, or flags the conflict for review when authority cannot be established.
Conclusion: make retrieval a controlled step
RAG quality is not only a model problem. It is a systems problem involving ranking, authority, budgets, and records. A small DAL workflow can make those decisions explicit without requiring a large orchestration layer.
Next steps are concrete:
- 1. define a maximum document and character budget for one real task;
- 2. retrieve a wider candidate set, then filter by documented authority;
- 3. record selected and omitted evidence in a receipt;
- 4. run a small-versus-large budget comparison;
- 5. send unresolved authority conflicts through the normal review gate.
The result is not more context. It is context an operator can explain.