When extracting the order status, why should there be an "unknown" option?

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-world files or products. Before processing important files, please retain the original copies and verify them against the boundaries and acceptance criteria outlined in this document. When the order status is not in the system’s predefined list, the easiest approach is often to select the value that “most closely resembles” it. The time saved on making this judgment may turn into errors in subsequent processes: for example, the original text simply said “waiting for more information,” yet the system proceeded as if it were “approved.” is allowed to be unknown in order to preserve the fact unknown should not serve as a catch-all for all exceptions, but it is more honest than an unfounded definitive answer. This paper confines the business state to pending 、 approved 、 rejected and unknown , and retain the original text fragment. The enumeration constraint governs the output vocabulary and does not verify whether the word selected by the model conforms to the original text. If the business does not accept unknown values, the task can be escalated to a human operator instead of silently selecting a default status in the field. Default values are only appropriate when explicitly specified in the business agreement; they should not be generated automatically by the extraction script. synthesis state mapping and enumeration check from jsonschema import Draft202012Validator schema = {"type": "object", "required": ["state", "source_text"], "properties": {"state": {"enum": ["pending", "approved", "rejected", "unknown"]}, "source_text": {"type": "string"}}, "additionalProperties": False} validator = Draft202012Validator(schema) mapping = {"待审核": "pending", "已批准": "approved", "已拒绝": "rejected"} def map_state(text): return {"state": mapping.get(text, "unknown"), "source_text": text} assert map_state("已批准")["state"] == "approved" assert map_state("等待更多资料")["state"] == "unknown" assert not list(validator.iter_errors(map_state("等待更多资料"))) assert list(validator.iter_errors({"state": "probably-approved", "source_text": "?"})) Here, only explicit phrase mappings are performed; synonymic sentences, negative sentences, and contextual variations are not processed. The term “unapproved” cannot be mapped to approved . If fuzzy matching is added, such counterexamples must be included, and the original textual evidence must be preserved. How do unknown values enter the work queue? result processing strategy needs to retain explicitly matches enters the next-level business validation source fragment and rule version is not in the mapping marks unknown original text, do not automatically rewrite multiple-state conflict to human disambiguation all candidates and position format does not conform to enum rejection result error path and output version Do not enable silent compatibility when the status word table changes. ’s new status may imply that downstream systems need to add a new branch. Simply replace the old unknown is automatically interpreted as a new state, which will overwrite the historical meaning. The old records should be retained, the migration scope should be clearly defined, and it should be verified which tasks require re-extraction. translation must also retain uncertainty In multilingual documents, first confirm the source document’s status, then verify how the target language expresses it. Do not allow the affirmative tone of the translation to override the original text’s uncertainty. OmniDoc (product entry point) can serve as the entry point for document translation, but the release rules for business status should still be explicitly maintained by your system. Reference: JSON Schema enum 。 - 1 -