A small context packet can make an AI response easier to control. It can also hide an important decision: which available information did the system exclude, and why?
In my public context-aware reception case, the central design is a resolver before generation. It reads operational context, selects an approved commercial directive and passes a smaller package to the response agent. The model does not receive every campaign clue, historical message and response rule as an undifferentiated bundle.
This technical note explores an extension to that pattern: an exclusion record for the reviewer. It is a design proposal, not a claim that a new exclusion ledger has been deployed or improved response quality.
When a reply is wrong, inspecting the final prompt may explain what the model saw. It cannot necessarily explain what a preceding resolver discarded.
That distinction matters when sources disagree. A campaign attribution can indicate one product family while the current conversation points elsewhere. A historical CRM field can still be populated even though its meaning is no longer current. An approved directive may exist without being applicable to this interaction.
The resolver needs a selection policy before generation. A reviewer also needs to distinguish “not available,” “available but stale,” and “available but deliberately excluded.” Those states imply different corrective work.
An absent source may require an integration check. An outdated source may need a freshness rule. A valid source excluded under the wrong policy may reveal a resolver defect. Adding more material to the prompt would not necessarily fix any of them.
Consider a fictional interaction about a replacement accessory. The system has a campaign signal for a complete product, an old CRM category and an approved accessory-support directive.
The proposed resolver output could identify the support directive as selected, record that the campaign signal was insufficient to establish the current request, and mark the old category as requiring freshness review. It would retain sanitized source references rather than copying the conversation into another log.
The response agent would receive the relevant directive and remaining uncertainty. A reviewer could separately inspect the exclusion reasons. This example describes a proposed contract; it is not a real customer exchange or an observed outcome.
I would avoid solving this by placing every excluded source back into the agent's context. That would recreate the ambiguity the resolver was introduced to reduce.
Instead, the response packet would contain the selected context, the applicable directive and any uncertainty needed to answer safely. A separate review record would capture source categories considered, the selection-policy version and concise exclusion reasons.
Access rules would apply to both records. A trace reference should not become a route around document permissions, and a reason code should not accidentally reveal sensitive source content.
The record would also need a bounded vocabulary. “Lower priority” is weak evidence if nobody can explain which rule established priority. Useful reasons describe a check: outside the current request, superseded version, unresolved conflict, insufficient attribution or unavailable source.
Before adopting an exclusion record, I would check:
These checks establish an inspectable design. They do not demonstrate that the resolver selects correctly. That would require reviewed cases, disagreement analysis and a measured baseline for wrong-context replies.
The public context-aware reception case provides the underlying resolver pattern and its current evidence limits.
When you review an AI response, can you explain both the context it received and the relevant context the system chose to leave out?