What the documents look like
On a Shopify standalone store, the merchant configures payment, shipping and fulfillment services directly. A TikTok Shop US store operates under a platform that centralizes returns, while this category does not. That difference shapes which records exist and where they live.
For order fulfillment, the working documents are order details, shipping rate templates, shipping labels and refund records. They sit across Shopify Admin, payment gateways and carrier systems. Order details record what was purchased and when. Shipping rate templates record the merchant's own rate rules. Shipping labels record carrier, service and dispatch data. Refund records record request date, amount and status. These documents update per order and daily, so an operating review that cites them must trace each statement back to a specific record rather than to a summary.
The consequence of getting this wrong is concrete: payment disputes, logistics complaints and inventory overselling. Citation tracing is the step that keeps a report sentence tied to the record that supports it.
Constraints at the citation tracing step
The knowledge base search node can associate one or more knowledge bases that share the same vector model. Its output is a citation array whose length can be zero, meaning the downstream path still runs even when nothing is retrieved. The citation cap is expressed in tokens, not in a top-k item count. The minimum relevance value is a 0-1 threshold that applies only in semantic retrieval or when result reranking is used; it is a filter threshold, not a final sort rule, and it does not perform permission or entity isolation. Hybrid retrieval merges multiple recall paths through RRF. Reranking requires a rerank model and must be enabled in settings. Image retrieval requires image input and model capability. None of these settings authorize a business action; retrieval output is evidence material, not approval.
Hypothetical drill sample. A standalone merchant reviews shipping labels and refund records for orders A-1001 through A-1050 for the period 1 March 2025 to 31 March 2025. The source sentences are: "Order A-1001 generated a shipping label on 5 March 2025; the carrier was Carrier Jia; the shipping rate template was East China Standard." "The refund record for order A-1001 shows a request date of 20 March 2025, a refund amount of 80 yuan, and a status of pending review." "The refund record for order A-1002 shows a status of completed, an amount of 120 yuan, and a date of 22 March 2025." The draft sentence under review is: "The refund for order A-1001 was completed, amount 80 yuan." The source states pending review. The draft sentence is therefore unsupported by the cited material on the status field.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this drill | Reason and comparison method |
|---|---|---|
| Associated knowledge bases | Two knowledge bases holding order details and refund records | Compare the vector model identifier of each; exclude any that do not match |
| Citation cap | A token value chosen to cover the sample source text | Compare against the sample source length to confirm the citation content covers it fully |
| Minimum relevance | Left at default, applied only in semantic retrieval or rerank | Compare with the current search mode to confirm whether the threshold applies |
| Search mode | Hybrid retrieval | Compare with the need for identifier-style queries and confirm RRF fusion is in use |
| Result rerank | Enabled as needed | Compare with the number of candidates and confirm a rerank model is available |
| Citation output | Check array length against the number of source sentences | Compare item by item with the source text to confirm nothing is missing or extra |
Three common errors
- Writing a pending status as completed. Input: the sample refund record for order A-1001 with status "pending review." Comparison: the draft sentence "the refund was completed." Observable result: the draft status field does not match the source status field.
- Treating retrieval output as authorization to execute. Input: the citation array returned by the knowledge base search node. Comparison: whether any approval or execution record exists. Observable result: citation content is present while authorization material is absent.
- Associating knowledge bases across different vector models. Input: two knowledge bases whose vector model identifiers differ. Comparison: the node's association condition. Observable result: the association is excluded or the identifiers are recorded as inconsistent.
How to verify the setup
- Input the three source sentences for order A-1001 and the draft sentence. Compare the draft status with the source status field. The check is satisfied if the draft is changed to "pending review" and the amount and date match the source.
- Input the refund record for order A-1002. Compare its status "completed" with whether the draft sentence cites that order. The check is satisfied if the draft does not mix the A-1001 and A-1002 statuses.
- Input a paper-level empty array [] as the retrieval output. Compare whether the downstream step continues on the empty result. The check is satisfied if the downstream design explicitly accepts an empty array without error. This does not claim that any real query returns an empty array.
These checks compare the draft against the cited source. They do not certify identity, approve a refund, or confirm that any business action occurred. Where the source does not state a field, the field remains unknown and the draft sentence remains unsupported rather than disproven.