What the documents look like
Import and export permit handling takes place before customs declaration and determines whether a shipment may lawfully cross a border. The materials this page covers are automatic import licences, dual-use item licences, contracts and product descriptions. These materials arrive per shipment and are not updated on a fixed schedule, so parsing and chunking follow the actual document set of each shipment.
The central difficulty in comparing contracts with transaction materials is that, within one shipment, the licence, the contract and the product description must all be resolvable to the same subject, the same period and the same field. The importer, commodity code and quantity stated on a licence are fields from one source; the buyer, product name and quantity in a contract are fields from another. After parsing, the document identity and version that let a chunk point back to its source text must be preserved, or the comparison has no basis.
Licences are largely tabular fields, while contracts are largely clause-based passages. A chunking step that separates a condition or a note from the content it constrains removes the basis for comparison. One group of source data can map to multiple indexes, and source data must be distinguished from retrieval indexes. Retrieval locates material content; it does not perform authorization judgment. A material being retrieved does not mean the shipment has been licensed.
Hypothetical paper exercise: the source text of one shipment's automatic import licence reads "Automatic Import Licence No. HYP-2024-0371, importer East China Machinery Co., Ltd., commodity CNC lathe, quantity 12 units, valid until 31 March 2025." The contract source text reads "Buyer East China Machinery Co., Ltd., seller an overseas supplier, subject matter CNC lathe 12 units, delivery period February 2025." The draft sentence to be assessed reads "The licence quantity for this shipment matches the contract quantity, and the licence is valid within the delivery period." This sample is a paper exercise and does not refer to a real entity.
Constraints at the document chunking step
Three industry facts shape this step. First, the materials are prepared per shipment and before declaration, so the chunk set belongs to one shipment and one document version. Second, the licence and the contract differ in structure, which means chunk boundaries must follow field boundaries and clause boundaries rather than a uniform length. Third, retrieval serves content location only, so a retrieved licence fragment cannot be read as an approval state for the shipment.
Because a condition, a note and the content they constrain can sit in separate passages, chunking must keep them together where the source structure ties them. The importer field on a licence and the buyer field in a contract are different fields from different sources; a comparison of subject identity requires checking both against the source text. The same applies to quantity and to dates: the licence validity end date and the contract delivery period are separate fields, and the comparison asks whether the delivery period falls inside the validity range.
Document identity and version must be retained so that each parsed field can be traced back to the passage it came from. Where a field is absent from the source, the comparison result stays unsupported or pending verification rather than being recorded as a conflict.
Configuration and implementation checks
The table below lists settings documented in the official technical text, or implementation checks, that relate to this page's documents and primary task. The numeric values are hypothetical starting points for this paper exercise, used for comparison against parsed results. They are not official defaults.
| Configuration item | Hypothetical starting point for this exercise | Reason and comparison object |
|---|---|---|
| Search mode | Hybrid search | The licence number is an exact query and the commodity description is a semantic query; both need coverage |
| Reference limit | Set to 3000 tokens for this exercise | The sample materials are short; compare against the actual tokens of one licence plus contract |
| Minimum relevance | Set to 0.3 for this exercise | Used to filter low-relevance fragments; compare against recall scores for the number and product name in the sample |
| Question optimization | Enabled for this exercise | The sample draft sentence contains a reference; compare against recall results with it disabled |
| Result reranking | Enabled for this exercise | Secondary ordering when candidate fragments are numerous; compare against ordering without reranking |
| Chunking basis | By field and clause boundaries | Preserve the complete correspondence between licence fields and contract clauses |
Hybrid search combines semantic recall and full-text recall through RRF, and reranking applies a second ordering to candidates. A relevance score is a filtering threshold, not a category, entity or permission filter, and it does not exclude unrelated businesses or unauthorized records. The reference limit is expressed in tokens, the documented unit, and not in a guessed item count. Image retrieval requires an image input and a model with the corresponding capability; reranking requires a rerank model and its configured enablement. Neither path runs on every request.
Three common errors
- Treating a successful upload as an updated retrieval index. After materials are uploaded, training and index status need separate verification. If the sample licence has been uploaded but training has not completed, retrieval may return an empty result, and an empty result does not establish that the licence does not exist.
- Treating a retrieval result as an authorization conclusion. Retrieving a licence fragment shows only that the fragment is in the library; it does not show that the shipment has been licensed. The "matches" judgment in the sample draft sentence requires manual field comparison, and retrieval does not complete that judgment.
- Treating fields from different sources as the same field. The licence field "importer" and the contract field "buyer" are similarly named, and whether they refer to the same subject still requires verification. In the sample the two names agree, which supports a same-subject judgment; differing names leave the judgment unsupported.
How to verify the setup
- Input the sample licence source text and contract source text, then compare whether the parsed fields retain subject, commodity, quantity and validity period. Observe whether licence number HYP-2024-0371 and the contract subject matter "CNC lathe 12 units" can each be traced back to their source text. If a field is missing or the quantity is separated from its clause, the chunking needs adjustment.
- Input the sample draft sentence, then compare whether the retrieved fragments contain both the licence quantity and the contract quantity. Observe whether the returned content supports the "quantities match" judgment. If only the licence fragment is returned and the contract quantity is not recalled, the judgment is unsupported.
- Input the sample licence validity end date "31 March 2025" and the contract delivery period "February 2025", then compare the two date fields. Observe whether the delivery period falls within the validity range. If the contract does not state a delivery period, the judgment remains pending verification and cannot be recorded as a conflict.
A comparison requires the same subject, the same period and the same field. Only explicitly mutually exclusive values in the same field constitute a contradiction. A field that is not stated, or evidence that covers only a related stage, leaves the result unsupported or pending verification. A pending review does not demonstrate the absence of an operating permission, and an unsigned termination is not a completed termination. Where required material is missing from the accessible retrieval scope or from a defined manual input, the gap is recorded as a gap.