The SIF data model explicitly binds most objects to an instance of SchoolInfo, either directly (through a SchoolInfoRefId element), or indirectly (e.g. StudentContactPersonal > StudentContactRelationship > StudentPersonal > StudentSchoolEnrollment > SchoolInfo). That means that, by default, your system needs to model SchoolInfo, and the direct and indirect links of any object to SchoolInfo, in order to work out what school the data relates to. In particular, for all StudentPersonal and StaffPersonal objects, the StudentSchoolEnrollment and StaffAssignment objects are critical, as join objects establishing the School that the student and staff belong to.
However, jurisdictional school hubs have adopted the design pattern of segregating all data about a school to a school-specific zone, which has its own endpoint. That means that if you are interacting with such a zone, you usually will not need to model joins of your other objects to SchoolInfo (including the join objects StudentSchoolEnrollment, StaffAssignment): all the objects you obtain from the endpoint are already filtered to be specific to that school. You may need to model equivalents to those objects anyway to segment data by school, if you are storing data for multiple schools in a relational database or graph database. But you won’t need to navigate the SIF data model to do so.
The join objects StudentSchoolEnrollment and StaffAssignment do contain additional attributes, that may need to be captured and modelled for particular use cases (notably Enrolment). Use cases indicate where that is the case.
Although you may not need to model joins to SchoolInfo, the SIF Specification typically requires that the objects you post to HITS include links to the SchoolInfo RefId, as the objects’ SchoolInfoRefId element. For that reason, you will need to consume the SchoolInfo object for your zone, so that you can link back to it in the objects you generate.