What the documents look like
Near-expiry markdown handling tracks the shelf-life lifecycle of batch stock rather than weighing individual order items. The working materials are batch age pulled from the point-of-sale system, store inspection rounds, ERP inventory, and quality-check records, refreshed daily or per shift. Copy drafting draws on four document types: the near-expiry list, the markdown approval form, the write-off record, and the promotional price tag. These documents bound what a draft may say. A batch's sellable status, whether a markdown approval carries a signature, whether a write-off record has already quarantined unsellable goods, and whether the promotional price on the tag matches the approved price all sit inside these records. A drafted sentence that reaches past what these materials state has no support.
Because the fields are dense and the sentences short, a near-expiry list often packs batch numbers, dates, quantities, and approval states into a small block of text. That density matters at the context and token stage, where the amount of content a single model request may reference, the token budget for retrieved knowledge-base citations, and the number of prior chat turns carried forward all get decided.
Constraints at the context limits step
Context and token settings govern three separate things here: how much content one model request may reference, how many tokens of knowledge-base retrieval are cited, and how much conversation history is carried into a multi-turn exchange. Near-expiry documents carry batch numbers, dates, quantities, and approval states in compact form. The citation limit is measured in tokens, so an overlong passage can be truncated and push an approval state or validity date outside the cited range. The minimum relevance value only takes effect under semantic retrieval or result reranking; it is a filtering threshold and does not perform permission or entity isolation, and retrieval on its own does not constitute authorization. The reply cap and the model's maximum context are two distinct quantities and cannot substitute for each other.
Hypothetical paper exercise. A store's shift inspection record dated 10 March 2025 reads: "Batch A-0310, yogurt 6 units, best before 12 March 2025, appearance normal, added to near-expiry list." The markdown approval form of the same day reads: "Batch A-0310 markdown application, approval status is pending review, applicant: store inspector, approver field blank." The draft sentence under review is: "This batch of near-expiry yogurt has passed markdown approval and is on special sale today." The comparison checks whether the draft's subject (batch A-0310), object (yogurt), and state (markdown approval) match the same field with the same value in the source materials. The approval form records the status as pending review; the draft says "has passed." These are mutually exclusive values in the same field, so the sentence is unsupported by the materials.
Configuration and implementation checks
The table lists only settings documented in the official material that bear on this page's task, or implementation checks to carry out. The values are starting points for this hypothetical exercise, chosen for comparison, not official defaults.
| Configuration item | Hypothetical starting point and reason | How to check |
|---|---|---|
| AI model | Choose a model whose popup shows the needed context length; verify against actual capability | Compare the model's stated maximum context with the combined length of the near-expiry documents plus the draft sentence |
| Reply cap | Set high enough to hold the supporting fields and the action, to avoid truncation | Check whether the output contains the batch, status, and validity fields |
| Knowledge-base citation limit | Controlled in tokens; check against single-passage length and the sample question | Observe whether the near-expiry list and approval form are cited whole or clipped |
| Minimum relevance | Takes effect only under semantic retrieval or result reranking | Compare candidates before and after filtering; confirm the status field is not filtered out |
| Memory turns | Keep a small number of prior turns for multi-turn follow-ups | Compare the same question with empty history and with history present |
| Reply format | Select json_schema only when a downstream step reads fixed fields | Verify all fields are present and parsing succeeds, not merely that the text is short |
Three common errors
- Treating the reply cap as the full context window. The reply cap limits only the length of a single answer; the model's maximum context is the length of content a request may reference. Comparing the wrong pair lets a long near-expiry document be misjudged as fitting.
- Using retrieval relevance in place of an authorization decision. The minimum relevance value is a filtering threshold. A high-similarity record need not belong to the current store or the current shift, and a retrieval result does not constitute approval or operating permission.
- Reading "pending review" as "passed." In the hypothetical sample the approval form shows status pending review and a blank approver field, while the draft says "has passed markdown approval." These are mutually exclusive values in the same field, and the approver's signature evidence is absent.
How to verify the setup
- Input the hypothetical inspection record and approval form verbatim, together with the draft sentence "This batch of near-expiry yogurt has passed markdown approval and is on special sale today." Compare the draft's status field with the approval form's status field. When "has passed" and "pending review" disagree, judge the sentence unsupported; it must be rewritten to the pending-review wording or supported by added signature material.
- Input the same question with empty history and with history present, and compare the history content actually carried into each request. If the history version introduces an approval conclusion not confirmed in an earlier turn, record the difference and trace its source; a state not stated in the materials stays unverified.
- Input the knowledge-base citation result explicitly given as empty, [], in the hypothetical sample, and check how the downstream node handles an empty citation. Observe whether the downstream step emits unsupported copy. Do not conclude that a real retrieval must return empty, and do not assert that any invented rule returns [].
Libraries built on different vector models cannot be jointly associated; confirm the identifier first and exclude those that do not match, record the actual observation, and do not run a cross-model retrieval to compare missed recalls. Image retrieval requires an image input and matching model capability, and reranking requires a model enabled under its settings; the optional paths shown in the document flow diagram do not mean every request executes all of them.