The model outputted one extra field; should it be accepted or rejected?

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 outlined in this document. The extraction result contains one extra item. confidence , which appears quite useful on the front end, was thus directly displayed as “trustworthiness.” The problem is that this field may neither be defined nor calibrated. An extra field is not necessarily harmless: it could lead downstream systems to treat unagreed-upon values as valid inputs. first determines whether the interface is open or closed Internal exploration tools can allow for extended fields, while stable delivery interfaces often require stricter boundaries. JSON Schema’s additionalProperties: false can reject undefined properties of the current object, but it does not automatically recursively overwrite each nested object. What is allowed at each level must be clearly specified. This does not mean that all interfaces should reject all extensions. The key is to make clear-cut choices and leave a versioning mechanism for upgrades. Silently ignoring something today and suddenly using a field with the same name tomorrow can easily lead to divergent interpretations of historical data. turns unknown fields into observable errors from jsonschema import Draft202012Validator schema = {"type": "object", "required": ["name", "evidence"], "properties": {"name": {"type": "string"}, "evidence": {"type": "object", "required": ["page"], "properties": {"page": {"type": "integer", "minimum": 1}}, "additionalProperties": False}}, "additionalProperties": False} validator = Draft202012Validator(schema) valid = lambda x: not list(validator.iter_errors(x)) assert valid({"name": "Demo", "evidence": {"page": 1}}) assert not valid({"name": "Demo", "confidence": 0.99, "evidence": {"page": 1}}) assert not valid({"name": "Demo", "evidence": {"page": 1, "guess": True}}) The value in this example 0.99 is merely a synthetic input that should be rejected, not the actual quality result of any model. The example checks both the top level and nested layers to prevent oversights where only the outer layer is closed while the inner parts remain arbitrarily expandable. After rejection, provide repairable information. case ’s returned information shall include should not do top-level multi-field unknown key name, protocol version automatically displays it as the trusted indicator inner multi-field object path, unknown key name returns only a single JSON error new version legal extension explicitly defined new schema secretly relaxes the constraints of the old version model repeatedly outputs the redundant key extraction task failure reason After each deletion, pretend that the original output was acceptable. discard field is also a data processing decision If the approach of “read known fields and ignore others” is indeed adopted, the original results and filtering behavior should be documented. Otherwise, it will be difficult to determine whether a particular field was absent in the source data to begin with or was removed at the interface layer. Discarding fields should not be used as a means to conceal the model’s failure to comply with the protocol. leaves one boundary for translation and one for extraction document translation output and structured field output are two distinct contracts. Using OmniDoc (product entry point) When processing documents, the field list can be used for post-translation verification, but one should not automatically accept additional business judgments or confidence-level fields simply because the translation is fluent. Reference: JSON Schema additionalProperties 。 - 1 -