Invoices and receipts share a common entry point; how can we prevent the two structures from becoming mixed together

This paper uses synthetic samples to demonstrate the processing method. The code has been verified using examples in an isolated environment; this does not guarantee effectiveness for all real files or products. Before processing important files, please retain the original copies and verify them against the boundaries and acceptance criteria specified in the text. An interface that accepts both invoices and receipts at the same time can easily result in a large object with “all fields optional.” Such an object can accommodate anything, yet it becomes difficult to specify exactly what has been received. A clearer approach is to maintain two separate contracts, using explicitly typed fields to select one of them. oneOf does not require any one of them to be sufficient oneOf must match exactly one branch. If two branches are both traversed simultaneously, that also counts as a failure. When a branch has only a few optional fields, these fields may overlap extensively, causing valid inputs to fail instead. Use the required kind plus const , can eliminate such overlaps in advance. an executable diversion protocol from jsonschema import Draft202012Validator def branch(kind, identity): return { "type": "object", "additionalProperties": False, "required": ["kind", identity], "properties": {"kind": {"const": kind}, identity: {"type": "string", "minLength": 1}} } schema = {"oneOf": [branch("invoice", "invoice_number"), branch("receipt", "receipt_number")]} v = Draft202012Validator(schema) valid = lambda x: not list(v.iter_errors(x)) assert valid({"kind": "invoice", "invoice_number": "I-1"}) assert valid({"kind": "receipt", "receipt_number": "R-1"}) assert not valid({"kind": "invoice", "receipt_number": "R-1"}) assert not valid({"kind": "receipt", "receipt_number": ""}) assert not valid({"kind": "invoice", "invoice_number": "I-1", "receipt_number": "R-1"}) assert not valid({"kind": "unknown"}) This is the smallest record artificially constructed, not a complete field model of a real-world invoice. The code demonstrates branch selection and rejection of extraneous fields; tax rates, headings, and amounts must be defined separately. If the business permits additional fields, their namespaces should also be explicitly specified, rather than quietly removing all constraints. error messages should not simply display “mismatch” input feature actual suspicion suggested feedback kind missing cannot select protocol Please provide the document type type and number field conflict Two structures are mixed displays the conflicting fields and their sources numbered empty string key exists but has no value review ID range unknown type The current protocol does not cover enters the independent queue awaiting classification uncertain type also requires an exit If the classifier cannot distinguish between an invoice and a receipt, it should retain the unknown state rather than randomly selecting a branch to produce a “success” outcome. Classification confidence, structural validation, and business authenticity represent three distinct levels. Structural validation cannot retroactively prove the correctness of classification, nor can it verify the authenticity of the document. The document type must also be retained in the translation process. The same field may require different terminology across different documents. Use OmniDoc (product entry point) When working with terminology and a bilingual review workflow, providing the document type along with the delivery list helps the reviewer understand the context of the numbers and amounts. Do not let a generic JSON object obscure these distinctions. Reference: JSON Schema Combination Rules 。 - 1 -