> ## Content Index
> Fetch the complete content index at: https://devinside.cloud/llms.txt
> Use this file to discover other available public pages before exploring further.

# More context still needs the same boundary
- URL: https://devinside.cloud/rag-or-broad-context-testing-two-paths-to-the-same-authorized-evidence/
- Published: 2026-11-12T15:49:29.000Z
- Updated: 2026-11-13T00:58:18.000Z
- Description: One team wants to retrieve a few relevant passages. Another wants to send the whole document collection to a model with a larger context window. The argument quickly becomes a contest between retrieval sophistication and model capacity.
- Author: Marcin Borecki
- Tags: Engineering, AI Engineering & Evaluation, #ai15, #devinside-review

Historical edition · Sources and examples scoped to 2025-12-18.

*Retrospective edition, scoped to 18 December 2025\. The document catalog and packet sizes in the browser are computed synthetic examples, not results from a live model or a later retrieval laboratory.*

One team wants to retrieve a few relevant passages. Another wants to send the whole document collection to a model with a larger context window. The argument quickly becomes a contest between retrieval sophistication and model capacity. Both sides can miss the question that comes first: which evidence is the application allowed to send?

The answer is not “whatever fits.” A broad packet can contain another tenant's document, an obsolete policy or an incomplete fragment whose missing condition changes its meaning. A narrow packet can make the same mistakes with fewer bytes and a more impressive relevance score.

Consider a small catalog containing public guidance, Blue-tenant policies and Red-tenant policies. Each record has an identity, version and content. A Blue user asks about uploads. We will build two packets from the same eligible catalog: a deterministic lexical top-k selection and a broad eligible set. Neither is a generative model; both must obey the same application boundary.

The reader should be able to distinguish the cost of selection, the size of a serialized packet, the presence of required evidence and the quality of an eventual answer. These are related observations, not interchangeable scores.

## Start with one evidence contract

The catalog should identify the source version and access scope before ranking begins. Public documents may be available to every tenant. Tenant-specific documents should be available only under the trusted scope. A requested catalog version should either match the selected snapshot or produce an explicit stale-version outcome.

A compact C# representation keeps the packet boundary independent of the selection strategy:

```csharp
public sealed record EvidenceDocument(
    string Id, string Tenant, bool IsPublic,
    string Version, string Text);

public sealed record ContextPacket(
    string CatalogVersion, string Tenant, string Strategy,
    string[] EvidenceIds, string Payload, int Utf8Bytes);

```

The tenant in this record describes the trusted application scope used to build the packet. It is not a grant that the model can create by asking for another tenant. The same distinction applies whether the downstream provider is local, hosted or replaced by a controlled test implementation.

Microsoft.Extensions.AI's [May 2025 general-availability announcement](https://devblogs.microsoft.com/dotnet/ai-vector-data-dotnet-extensions-ga/?ref=devinside.cloud) predates this edition and provides a contemporary integration context for provider abstractions. This article does not require a later package API to define eligibility, serialization or refusal. Those are application contracts that can be tested before any model receives the payload.

![Two selection strategies, one authorized snapshot](https://devinside.cloud/content/images/2026/11/devinside/v4/AI15/shared-boundary.svg)

[Inspect the full diagram ↗](https://devinside.cloud/content/images/2026/11/devinside/v4/AI15/shared-boundary.svg)Swipe the drawing to inspect it.

## Broad context still has a selection rule

“Send everything” is rarely literal. It usually means everything in a selected tenant, version, collection or document type, perhaps after excluding large or unsupported records. That is a selection policy even if it does not use a relevance ranking.

The broad path in the model includes every eligible document in stable identity order. The narrow path counts exact query-term matches in eligible documents, sorts by that simple score with an identity tie-break and takes k records. This is intentionally lexical and educational; it is not semantic retrieval or an evaluation of embedding quality.

Change the tenant and watch both packets change eligibility together. Change the query and the narrow packet can change while the broad packet remains stable. Change k and the narrow packet grows. None of these controls allows either path to include a foreign-tenant document.

This makes a useful comparison possible: how much material does each policy select under the same evidence boundary, and does the selected packet contain the source the task requires? It does not yet answer which strategy produces a better generated answer.

## The packet is a representation, not a bag of text

Concatenating passage text alone loses information needed to interpret and audit the result. Include stable evidence identity and version in the serialized representation. Otherwise a model or a reviewer may see a plausible sentence without knowing which policy revision supports it.

Order is part of the representation too. A stable order makes hashes and exact-size comparisons reproducible. An unstable dictionary iteration order can change bytes without changing the evidence set, creating noise in a cache or an investigation.

The serializer should have a defined schema and escaping behavior. Text can contain quotes, line breaks and characters outside ASCII. Counting characters is not necessarily counting bytes, and counting bytes is not counting model tokens.

```csharp
string payload = JsonSerializer.Serialize(selectedDocuments);
int bytes = Encoding.UTF8.GetByteCount(payload);

if (bytes > maximumUtf8Bytes)
    throw new InvalidOperationException("Context packet exceeds its byte budget.");

```

This .NET 9 baseline code illustrates a UTF-8 byte boundary. It does not estimate a provider's token count or charge. A production model adapter may need another limit based on the provider's tokenizer and message framing. The two limits can coexist if the application names them accurately.

![The representation determines the byte count](https://devinside.cloud/content/images/2026/11/devinside/v4/AI15/bytes-not-tokens.svg)

[Inspect the full diagram ↗](https://devinside.cloud/content/images/2026/11/devinside/v4/AI15/bytes-not-tokens.svg)Swipe the drawing to inspect it.

The browser uses actual UTF-8 encoding of its synthetic JSON packet. Add or select a document with non-ASCII content and the byte count reflects the encoded representation. The display labels the number as bytes, so a smaller packet cannot silently become a claim about model cost.

## Refuse oversize input before you alter its meaning

A convenient implementation can truncate a packet when it exceeds a limit. That may remove the condition that makes a policy true, split a record or drop the evidence identity while retaining its text. The resulting packet fits, but it is no longer necessarily the packet the application intended to send.

The model chooses a simpler policy: build the complete selected representation, measure it, then either accept it or refuse the packet. It does not silently cut bytes or reduce k after the fact. A real product may choose another policy, but it should be explicit about which evidence is removed and what the caller should do next.

Try setting the byte budget exactly to the displayed packet size. The packet is accepted under the inclusive limit. Reduce the budget by one byte and it is refused. That boundary is independently calculable and does not depend on a model deciding whether the context “looks short enough.”

A broad packet can fail the limit while the narrow packet fits. That is a concrete tradeoff. It still does not prove that the narrow packet contains sufficient evidence or that the broad packet would have produced a better answer if allowed through.

## Required evidence and irrelevant evidence are different questions

Suppose the task requires the upload-size policy and the executable-file restriction. A top-one lexical match may contain only one of them. A broad packet may contain both plus unrelated material. The application should report required-evidence presence separately from size.

The model marks two synthetic policy identities as required for its upload task. You can change k and see whether both are included. This is a deterministic fixture expectation, not a general evaluator of arbitrary questions. If the task changes, the required-evidence oracle must change too.

![More selected material is not the same as a better answer](https://devinside.cloud/content/images/2026/11/devinside/v4/AI15/coverage-versus-volume.svg)

[Inspect the full diagram ↗](https://devinside.cloud/content/images/2026/11/devinside/v4/AI15/coverage-versus-volume.svg)Swipe the drawing to inspect it.

The strongest case for broad context is that selection can omit a crucial condition the user did not know to name. The strongest case for retrieval is that a bounded, relevant packet can reduce unrelated material and make provenance easier to inspect. Both arguments are plausible. Neither can be settled by counting documents alone.

A useful experiment fixes the authorized evidence snapshot and evaluates the task outcome across representative question families. It retains failures, unsupported claims and refusals. It should not compare a carefully curated narrow corpus with an unrestricted broad corpus and attribute every difference to context strategy.

## Version changes invalidate old packets

If a policy changes, a previously constructed packet may no longer represent the current task. Keeping the same question and tenant does not make the old payload current. The packet should identify the catalog version used to construct it, and a consumer should know whether it accepts that snapshot or requires a fresh one.

In the visual, a requested version that differs from the active catalog stops packet construction. Changing the catalog content also changes the serialized bytes and can alter the required budget. The model does not reuse a stale success merely because the new attempt failed.

This is especially important when caching is introduced. A cache key based only on question text can cross tenant or version boundaries. A key based on a raw packet hash can preserve byte identity while still omitting the policy that made the packet eligible. Decide which identities belong in the cache contract before treating a hit as a valid answer.

The same principle applies to a large-context session that retains previous documents. A later request may need a different evidence scope. The existence of retained text in a conversation does not establish permission to use it for the new task.

## A scripted receiver can test the packet without grading an answer

Before calling a generative model, an application can send the packet through a controlled receiver that records its version, evidence IDs and byte count. That tests the adapter boundary: what did the application actually provide, and did it preserve the declared scope?

![The same question can require a different evidence revision](https://devinside.cloud/content/images/2026/11/devinside/v4/AI15/stale-packet.svg)

[Inspect the full diagram ↗](https://devinside.cloud/content/images/2026/11/devinside/v4/AI15/stale-packet.svg)Swipe the drawing to inspect it.

Such a receiver cannot establish answer quality. It can expose a missing field, an oversize refusal that occurs too late, or a version mismatch hidden by a convenience method. It should be described as a contract test, not as a model benchmark.

Likewise, the interactive browser model does not infer meaning from the selected documents. It performs lexical selection, eligibility checks and serialization. Its causal animation carries the selected evidence identities and computed packet sizes toward the byte boundary, where the packet is accepted or refused. The visible outcome is computed from the current inputs.

## Make the next comparison narrower and more useful

One particularly revealing case is a query whose words match a general public document more strongly than the tenant's specific restriction. A narrow lexical selector can return the public explanation and miss the exception. A broad eligible packet contains both, but the eventual answer still has to apply the specific rule correctly. Presence and interpretation remain separate obligations.

Do not fix that case by adding the expected answer to the query or by removing the difficult public document from only one strategy's corpus. That would change the task to make the result easier. Preserve the same eligible snapshot, record the missing required evidence and decide whether the selector needs a different policy, a larger k or an explicit refusal when the packet cannot support the requested claim.

The same discipline applies when broad context fails the budget. Increasing the limit may be appropriate, but it is a new configuration. Silently trimming one packet while calling both strategies unchanged would make the comparison harder to reproduce and its conclusion less useful.

Before arguing for retrieval or broad context, write down the common boundary: trusted scope, source identities, version, serialization and overflow policy. Then vary the selection strategy while keeping that boundary fixed.

Inspect a case where narrow selection misses required evidence, a case where broad context exceeds the budget and a case where a foreign document would otherwise score highly. Those cases teach more than a single average packet size because they reveal what each strategy can fail to preserve.

The model's context window is a capacity. The application's evidence contract is an obligation. A larger capacity can make different designs possible, but it cannot decide which documents the application may disclose, which version the answer should represent or which missing condition the user needs to know about.

GO FURTHER

## Inspect the contemporary laboratory.

This is a newly reconstructed historical edition, not a claim of earlier authorship. Later executed experiments, their exact environments and original results are preserved in a separate notebook.

[Open the current laboratory notebook ↗](https://devinside.cloud/lab-notebooks/v4/AI15.html)

[Download the current reconstruction sources ↗](https://devinside.cloud/content/files/v4/AI15-reconstruction.zip)