What a passing validation result establishes
JSON Schema Draft 2020-12 defines constraints including types, required properties, enumerated values and numeric limits [S1]. A passing result concerns the selected instance and schema. The position developed in this Opinion is that a decision record should also identify the assumptions supplied to that check. Some important business rules can be expressed directly in a schema. Other questions may depend on current external data, the provenance of supplied values or the authority of the party asking an application to act.
The useful engineering question is therefore whether the chosen constraints and inputs cover the decision under review. An approval workflow might need a current account status, a documented spending policy and evidence about the requester. The schema can participate in those checks, including through trusted values supplied when it is built. This article proposes recording what was provided and what was left outside the validation result. It does not assume that every application needs the same architecture or that a schema is merely a syntax filter.
Parsing RFC 8259 Syntax and Schema Validation
RFC 8259 describes JSON syntax and its data structures, including objects and arrays of values [S3]. A parser accepts or rejects text under those rules. Schema validation is a separate question about the resulting instance and the selected constraints [S1]. Keeping those results separate makes an error easier to interpret: malformed text differs from an otherwise readable instance whose amount violates a configured limit. Neither result should be described as a complete approval decision unless the application has explicitly defined that narrower meaning.
Schemas can express meaningful business constraints. For example, a numeric ceiling may be encoded when the policy value is available. Declaring an object property does not itself make that property required; required properties are separately specified [S2]. Draft 2020-12 also distinguishes format annotation from format assertion [S1]. In a proposed review, the team would record the chosen dialect and validator behavior rather than assume a date-like or email-like string received every intended check. A field label alone is not a description of the checks actually run.
Temporal Reference Data and State Drift
Consider an illustrative catalogue identifier that is permitted by yesterday's reference snapshot. A schema generated from that snapshot might correctly accept the identifier under its configured enum. If the catalogue changes before execution, the application faces a freshness question. That hypothetical change is not a defect in JSON syntax or proof of an intrinsic limitation in every schema. The proposed design review should ask which snapshot was authoritative for the decision, when it was obtained and whether the later action requires a newer check.
One editorial option is to check the reference value when the decision is made and preserve the version used. Another is to perform a further check immediately before a consequential action if the domain requires it. Either approach needs an owner for changes that occur between those points. A dynamically supplied constraint can help, but the validation result alone does not demonstrate that its input was fresh or authentic. The intended operating rule should say what happens when current reference data is unavailable.
Authority, Provenance, and the Source of Truth
An instance may contain a requester identifier or approval field that passes all declared type and value checks. That observation does not establish who submitted it or whether the claimed approval was issued through the accepted process. This is the article's reasoning about the scope of the evidence, not a claim that JSON Schema defines an authentication system. A proposed decision record should distinguish the data in the document from the independently accepted identity and authority associated with the request.
The same distinction applies to parsing. Accepting text under a syntax does not prove that a parser or its host application has no implementation vulnerabilities. The proposed pipeline should report parsing, instance validation and the remaining application decisions separately. A team might implement several checks within one service or distribute them across components; the important review question is which result each check establishes. Calling the entire sequence 'validation' can make an omitted authority check difficult to notice or discuss.
Hypothetical Approval Record Analysis
For a fully hypothetical illustration, assume a procurement record specifies an item identifier, a quantity of 500 and a unit price of 45.00. Assume its selected schema requires those fields, the chosen types and positive numeric values, while leaving the requester's current ceiling outside that schema. The instance is stipulated to satisfy those constraints; no validator was executed for this article. The total of 22,500 follows from the example inputs, rather than from a reported purchase or a measured product result.
Now assume that the workflow's accepted reference record shows the supplier is on hold and the authenticated requester's applicable ceiling is lower than 22,500. Under this hypothetical policy, the action should not proceed. The example does not show that numeric limits are impossible in JSON Schema: the ceiling could be supplied as a constraint. It shows why a reviewer needs to know which policy and current facts were used. A different schema or policy could produce a different conclusion, which should be recorded explicitly.
A proposed evidence and error contract
This article proposes an error contract that distinguishes unreadable text, a failed declared constraint and an unresolved external decision. A missing property can be returned with the relevant schema path. An unavailable reference source can instead identify the missing decision evidence and its owner. The second case should not be quietly converted into a passing result because the submitted identifier has the correct type. Equally, it should not be described as malformed JSON when the text and selected instance constraints are valid.
The proposed record would retain the schema identifier, the checked instance or an appropriate reference to it, the decision time and the relevant source versions. Reviewers would choose the retained detail according to the workflow and information handling requirements. An explanation should distinguish an accepted source value from a proposed interpretation of that value. Those distinctions make it possible to revisit a decision when a policy changes without pretending that the earlier check answered a question it was never configured to examine.
Architectural Remedies for Semantic Enforcement
A possible implementation begins with parsing and instance validation, then resolves any remaining application questions using accepted current context. This is an editorial design option, not a sequence mandated by JSON Schema or RFC 8259. Some constraints may be evaluated together; some reference values may already be incorporated into the schema. The review should test the actual arrangement with missing data, a changed source and an inconsistent approval record, recording the expected result for each case before any evaluation is run.
An implementation could express additional policy in application code, a configured rules engine or a schema suitable for that constraint. This article does not prescribe one technology. The practical requirement proposed here is a clear owner for each rule and an explanation of how it is tested and updated. A single passing badge is less informative than a record of the checks that ran, the facts they used and the decision that remains to be made by the accepted authority.
Conclusion on Structural and Business Validity
This Opinion rejects the assumption that every passing instance result is a complete business approval. The result needs the question it answered: the selected schema, supplied context and accepted authority. Some applications can encode much of that decision directly as constraints; others need additional current evidence. A useful review describes that boundary instead of assigning universal capabilities or universal limitations to the schema language. The example in this article is illustrative and does not establish the behavior of a particular validator or workflow.
The proposed decision record should make a later disagreement intelligible. If a reference value changes, the reviewer needs to know which version supported the original decision. If authority is disputed, a type-correct identifier does not settle the dispute. If a configured limit was absent, the record should identify that omission rather than call every structural result meaningless. These are editorial review questions grounded in the distinction between syntax, selected constraints and application decisions; they are not a claim of an implemented GPIRL control system.
Official background videos
External publisher context. These recordings do not demonstrate GPIRL products or validate the proposed designs.
- JSON Schema in 60 seconds
Official project introduction with validation and schema-reuse examples. Introductory background; it does not prove current external business facts or specify every Draft 2020-12 validation-vocabulary detail. Use the 2020-12 specification for normative claims.
Sources and further reading
- [S1] JSON Schema Draft 2020-12: Validation
- [S2] Understanding JSON Schema: Object
- [S3] RFC 8259: The JSON Data Interchange Format
References do not imply product certification or endorsement.
Have a related operational question? Bring one validation result and the decision it is expected to support to the discussion.