What the documents look like
Brand after-sales repair work is organized around warranty responsibility and physical repair outlets. The material set differs from platform-refund after-sales work: the core records are warranty cards, repair work orders, inspection reports and replacement approvals, drawn from the after-sales system, store orders, repair outlet feedback and the national three-guarantee catalogue. Each record carries a state that determines whether a handover can proceed. A warranty card states the covered scope and validity period. A work order records the repair process. An inspection report supports a determination. A replacement approval shows the boundary of authorization.
Operations handover must keep three states apart: material is present, an action has been executed, and a request is still awaiting approval. A retrieval hit or a completed form field does not by itself constitute authorization. This page addresses one task only: citation tracing for operations handover in brand after-sales repair services. It explains how source references are produced at the knowledge base search step, what the documented limits are, and how a handover draft can be checked against the underlying record text.
Constraints at the citation tracing step
The knowledge base search node outputs an array of references, and the array length may be zero. An empty array still lets the downstream chain run. The reference cap is measured in tokens, not in a count of items. The minimum relevance value takes effect only under semantic retrieval or result reranking, and it is a filter threshold rather than a final ordering rule. Neither the reference cap nor the minimum relevance value performs permission filtering, and neither excludes unauthorized records. Business verification, approval, database writes and external synchronization are separate downstream implementations and are not established by a retrieval result.
Hybrid retrieval combines multiple result paths through RRF, which is a fusion process in the retrieval pipeline. Reranking requires a rerank model and must be enabled according to the configuration. Image retrieval requires image input and a model with the corresponding capability. Knowledge bases associated with the search node must share the same vector model; bases built on different vector models cannot be associated together. Where this condition is not met, the correct action is to check the identifier and exclude the non-matching base, and to record the observation. Retrieval is not authorization.
Hypothetical paper exercise sample. A brand after-sales centre holds one work order whose source text reads: "Work order number WX-0001, send-in date 2 March 2026, fault description screen flicker, inspection conclusion ribbon cable poor contact, handling opinion replace ribbon cable, approval status pending review." The warranty card in the same batch reads: "Warranty card number BX-0001, valid until 31 December 2026, covers screen display faults." A drafted handover sentence reads: "This order has completed replacement approval and replacement can be arranged." The checking input is the work order text and the warranty card text above. The comparison is between the approval status field in the source text and the approval claim in the drafted sentence. The source states pending review; the drafted sentence states completed approval. The same field holds mutually exclusive values, so the drafted sentence is unsupported by the source.
Configuration and implementation checks
| Configuration or check item | Setting on this page | Basis and explanation |
|---|---|---|
| Associated knowledge bases | Select only after-sales material bases sharing the same vector model | Bases on different vector models cannot be associated together |
| Reference cap | Hypothetical trial starting value 4000 tokens, compared with 2000 and 8000 | Trial starting value for this exercise, not an official default |
| Minimum relevance | Hypothetical trial starting value 0.5, compared with 0.3 and 0.7 | Takes effect only under semantic retrieval or reranking |
| Search mode | Use full-text or hybrid retrieval for identifier-type questions | Numbers and model codes suit full-text matching |
| Reference handover | Pass retrieval output to the answering step, then check each item against the source text | An empty array still runs through the downstream chain |
| Material currency | Check sources against the current version and a historical version separately | Whether a citation is adopted still depends on review of the effective version |
The reference cap starting value of 4000 tokens is chosen for this exercise because the sample work order and warranty card together are short, and the value is compared against 2000 and 8000 to observe how much source text reaches the answering step. The minimum relevance starting value of 0.5 is compared against 0.3 and 0.7 to observe which candidate items survive filtering under semantic retrieval or reranking. Both values are trial starting points for this paper exercise.
Three common errors
- Treating pending review as completed approval. In the sample, the work order approval status field reads pending review while the drafted sentence states completed replacement approval. The two values are mutually exclusive within the same field, so the drafted sentence is unsupported.
- Treating a retrieval hit as authorization. A retrieved work order shows only that the material exists in the searched scope. It does not show that a replacement has been approved. Authorization requires a corresponding approval record, and that record is a separate business fact.
- Forcing an association across vector models. Knowledge bases built on different vector models cannot be associated together. The check is to inspect the identifier and exclude the non-matching base. No cross-model retrieval comparison is performed, and no runtime outcome is asserted for a combination the documentation does not permit.
How to verify the setup
- Input the sample work order text and warranty card text. Compare the approval status field in the source with the approval claim in the drafted sentence. When the source shows pending review and the drafted sentence states completed approval, the drafted sentence is identified as unsupported. The expected observation is this mismatch; the exercise does not claim the check has been run.
- Input the full sample text. Compare the retrieval output against the cited source text item by item. Where the answer contains content the source does not carry, record the gap. The expected observation is a recorded gap, not an assertion that every answer will match.
- Input a paper empty array [] as the reference output. Compare whether the downstream design continues to execute. The chain running through without producing a business action is the condition to observe. This uses an explicit paper input and does not claim that any rule-based retrieval returns an empty array.
Across all three checks, the evidence gap remains where the source does not state a value. An unsigned termination is not a completed termination, a pending request is not an approval, and an offered option is not an execution. Where a check cannot be completed within an accessible target retrieval scope or a defined manual input, the gap is recorded rather than filled with an assumed authorization or effective clause.