What the documents look like
A hypermarket fresh-food concession counter is frequently run by a supplier who stations staff on site and shares revenue with the store. Because of that arrangement, the concession contract and the daily trading materials have to be checked against each other item by item. The materials involved are the concession contract, daily sales reports, shrinkage records, and food purchase inspection records. Daily sales reports and shrinkage records are produced daily; food purchase inspection records are produced per batch; the concession contract sets the revenue-share ratio, the shrinkage allocation, and the settlement basis. The core action of contract-to-trading-material comparison is to place the contract's counterparty, period, and field values alongside the corresponding values in the trading materials inside one context and judge whether they agree.
Context and tokens determine how much source material can be loaded at the same time, and whether the model can see every basis needed for the judgment. If the context window is too small, material is truncated and a judgment may rest on half a sentence. The reference limit is controlled by tokens, so one very long passage can crowd out the space available to other materials. The reply limit constrains output length and is a different value from the model's available context. Prior history changes the input that reaches the model for the same question, so history conditions must be held fixed during checking.
Constraints at the context limits step
Comparison requires the same counterparty, the same period, and the same field. Only when the contract states a supplier's revenue-share ratio for a given month, and the report gives that supplier's sales for that month, can the two be set against each other. When the context window is insufficient, material is trimmed and the judgment may see only part of the clause. The reference limit is expressed in tokens, and an over-long single passage consumes space that other materials need. The reply limit only restricts output length; it is not the same number as the model's usable context. Historical input changes the content sent to the model for the same question under empty history versus history-bearing conditions, so the history condition must be fixed when checking.
Hypothetical paper exercise sample: the contract text supplied for checking reads, "Party A, a fresh-food department, and Party B, an aquatic products supplier, enter a concession contract with a term from 1 March 2025 to 28 February 2026; the supplier's counter sales for the month are shared at twelve percent; shrinkage is borne thirty percent by Party B." The draft sentence to be judged reads, "All shrinkage for this supplier in March 2025 is borne by the store." The comparison input is the contract text above together with a shrinkage record marked with the same supplier and the same month. The judgment concerns whether counterparty, period, and field agree; the shrinkage-bearing ratio is a field stated in the contract, and the draft sentence and the contract value are mutually exclusive on that field.
Configuration and implementation checks
| Configuration or check item | Value or action relevant to this page | Explanation and comparison method |
|---|---|---|
| AI model maximum context | Use the value actually displayed for the selected model | Compare against the combined length of contract text plus trading material to decide whether segmentation is needed |
| Reply limit | For this hypothetical trial, start at a length that can hold the judgment reason and its cited basis | Compare against the output needed for the draft-sentence judgment; too short truncates the basis |
| Reference limit | Token-controlled; for this hypothetical trial, start at a value covering the key contract clauses and the shrinkage record fields | Compare against the length of a single passage and observe whether key clauses are trimmed |
| Minimum relevance | Takes effect only in semantic retrieval or with result reranking | Compare against recalled results to filter low-relevance fragments; it does not perform permission filtering |
| Question optimization | Enable when a follow-up question contains a reference | Compare the retrieval terms before and after enabling to judge whether the reference is resolved |
| Structured handoff | When json_schema is used, check that fields are complete | Check that counterparty, period, and field are returned and parseable |
Three common errors
- Treating the reply limit as the full context window. Observable error: estimating how much material fits from the reply limit, so contract clauses are trimmed. Check: read the model's displayed maximum context, compare it against the combined length of contract text plus shrinkage record, and observe whether the key clause enters the input intact.
- Using semantic relevance in place of permission or entity isolation. Observable error: assuming a similarity setting excludes other suppliers' records. Check: inspect the retrieval scope and record identifiers, and confirm whether returned content belongs to the same supplier and the same period.
- Treating a pending-review state as an existing operating authority. Observable error: judging that the shrinkage allocation has changed on the basis of a handover request still under review. Check: compare the request's status field against the clause stated in the contract, and observe whether any effective change basis exists.
How to verify the setup
- Verification one: input the contract text above together with the shrinkage record marked with the same supplier and the same month, compare the shrinkage-bearing ratio stated in the contract against the shrinkage record's field value, and if the two are mutually exclusive on the same field, judge that the draft sentence is not supported by the contract.
- Verification two: input the same comparison question under two conditions, empty history and history-bearing, compare the actual content sent to the model in each run, and if the history condition causes material to be trimmed, record the context difference and do not use it to judge a contract clause.
- Verification three: use an explicit paper input of an empty result to check the downstream handoff design, compare the downstream node's output when it receives empty references, and observe whether an unsupported shrinkage-bearing conclusion appears; whether the retrieval result is empty must be recorded from actual observation, and no invented rule is presumed to return empty.
Retrieval checks record actual observations and failure branches, and do not guarantee a first-hit match or full recall. Libraries built on different vector models cannot be jointly associated; identifiers must be checked first and non-matching ones excluded, with actual observations recorded and no runtime result inferred.
This page addresses only the hypermarket fresh-food concession counter, contract-to-trading-material comparison, and context and tokens. Which materials, operations, or requests are in which authorization state during an operational handover is a separate matter; retrieval or a form must not be treated as authorized execution.