The A4L Community is pleased to highlight an important milestone for SIF Unity, built through years of standards work, implementation experience, and international collaboration.
Through continued work between A4L, the Postsecondary Electronic Standards Council (PESC), and colleagues in Australia, PESC Compliant JSON now has a stronger practical foundation for exchanging SIF Unity data alongside XML.
The PESC Compliant JSON standard itself is not new. Approved in 2019, it established a disciplined approach for representing XML Schema-based education standards in JSON. What is new is the level of clarity and verification now available for SIF Unity. In particular, two pieces have moved forward together: a predictable top-level JSON structure that follows the PESC JSON pattern, and a fully valid JSON Schema that can be used to test whether Unity JSON payloads conform to that expected structure.
That combination matters because it moves JSON support from written guidance toward implementation confidence.
Seeing the Structure
The clearest way to understand the step forward is to look at the top-level structure itself.
In XML, a document has a document element, often called the root element. For example, a collection of extended student records begins with the StudentPersonals element. That element carries the SIF namespace declaration and contains one or more StudentPersonal records.
<StudentPersonals xmlns="http://www.sifassociation.org/datamodel/na/4.x">
<StudentPersonal refId="9262831F-E0CF-4F6C-AC0E-0267B57E7438">
...
</StudentPersonal>
</StudentPersonals>Following the PESC JSON pattern, the XML document element becomes the top-level property in JSON. The namespace declaration is also preserved as a property on that JSON object, because PESC JSON treats namespace definitions like attributes.
{
"StudentPersonals": {
"xmlns": "http://www.sifassociation.org/datamodel/na/4.x",
"StudentPersonal": [
{
"refId": "9262831F-E0CF-4F6C-AC0E-0267B57E7438"
}
]
}
}This structure is important because the JSON is not an unwrapped array, an anonymous object, or a locally invented representation. It has a known top-level property derived from the XML document element, and it carries namespace information in the way PESC JSON prescribes.
That gives systems a stable entry point for routing, validation, documentation, examples, and troubleshooting. It also reduces the integration risk that comes from small, good-faith differences in how teams interpret a written specification.
From Guidance to Verification
PESC’s JSON standard gave the community the conceptual foundation: JSON should not be treated as a loose conversion from XML syntax. It should preserve the structure and intent of the underlying data model.
The remaining challenge for SIF Unity was practical verification. A prose standard can describe the expected pattern, but production software needs artifacts that can be tested, automated, and built into release processes. That is where the valid JSON Schema changes the conversation.
A valid JSON Schema gives implementers something concrete to build against. It allows SIF Unity JSON payloads to be tested with widely available JSON Schema validators. It supports automated regression testing, repeatable quality checks, implementation guidance, and stronger conformance workflows.
This is especially important for organizations planning production-ready support. JSON support can now be evaluated in terms of known document structure, schema validation, tooling compatibility, and test coverage rather than treated only as a serialization preference.
Building Toward Production Readiness
A4L is also in the process of creating a test suite for Premium Members developing production-ready software. The goal is to make this work actionable, not merely descriptive.
That test suite is intended to help confirm that real implementations are producing and consuming SIF Unity JSON in a predictable, standards-aligned way. It will give teams a clearer path to test payload structure, validate schema conformance, and identify issues earlier in development.
This matters because modern software teams need more than examples. They need repeatable checks that can be incorporated into development pipelines, quality assurance processes, certification preparation, and partner onboarding. A valid schema is a major part of that, but a test suite makes the expected behavior even more visible and operational.
The result should be less ambiguity, faster troubleshooting, and stronger confidence that different products are implementing the same exchange pattern in compatible ways.
Partnership Made This Possible
It is also important to recognize how this progress happened.
PESC deserves credit for stewarding the PESC Compliant JSON standard and giving the education standards community a common approach to JSON representation. That standard gave us the foundation.
The last mile required working technology. It required taking the written rules and turning them into schema support that could be used to validate real SIF Unity JSON payloads. That work was made possible by leveraging and extending open tooling originally developed in Australia, along with close collaboration with Australian colleagues who brought both technical experience and practical implementation insight to the effort.
That partnership moved the work from guidance toward verification, and now toward testable production readiness.
The Bottom Line
PESC Compliant JSON has taken a major step forward for SIF Unity.
With a predictable top-level structure, namespace handling that follows the PESC JSON standard, a fully valid JSON Schema, and test-suite work now underway for Premium Members, SIF Unity JSON is becoming a more practical and reliable implementation path.
That matters for software planning, integration risk, testing, conformance, and long-term interoperability. Most importantly, it keeps the focus where it belongs: trusted, standards-based education data exchange that can work effectively in the systems and architectures being used today.