Agenda

• SEOA Split and new identity entities

  • Pending responses from TAG regarding Deprecation vs Deletion of the SEOA

  • Other changes and feedback currently received from the community

  • Poll to capture community understanding and acceptance of the changes for DS 6.0

• Assessment’s requested changes - open to community feedback.

Executive Summary:

• The poll results indicate that most of members are aware of the new identity entities in DS 6.0 (14 out 18 or 78% of respondents), and 50% (10 out of 20 people) consider the split of the SEOA useful.

• The Tech team is adding filtering to the API specifications to support grouping or filtering by domain - DMS-402, METAED-1608. This will facilitate entity search --particularly valuable after moving the EPDM entities into Core.

• The Data Standard 6.0 Release on the ODS API 7.3.1 is planned around Dec. 15th, 2025.

• Deletion or deprecation of the obsolete elements: The TAG team met on July 24 and recommended evaluating deleting the obsolete elements from the SEOA, renaming the SEOA and building a bridge in the API. The Ed-FI API team is evaluating this alternative and will present it to TAG on August. Meanwhile, we are deprecating elements in the SEOA. For more details, please review the TAG notes.

• New Entities are being renamed for simplification. Although the new entities have an EdOrg reference in their keys, they are built as domain entities. Staff and Demographics --originating from the SEOA – are at the same level as the SEOA.

• StudentCharacteristics (e.g., economic disadvantage) will be moved into the new StudentDemographics entity. StudentIndicator will remain within the existing SEOA.

• StudentAssessmentRegistration will update its dependency to refer to StudentDemographics instead of SEOA.

• BeginDate and EndDate in the new “directory” entities are available in the Address common, which contains the Period common with the beginDate and EndDate.

• StaffEducationOrganizationContactAssociation to be deprecated given the overlap with the StaffDirectory entity. We are considering not moving ContactTitle.

• We are also considering not moving LoginID into the new student identity and staff identity entities, but we are still analyzing it.

• CandidateDirectory, and CandidateDemographics not being created, as no requests nor use cases have been received

• Concerns regarding enrollment-based authorization were brought to the TAG group (on 7/24), and it was indicated that the StudentEducationOrganizationResponsibilityAssociation handles the enrollment relationship. For more details, check the TAG notes.

• The Assessment work group is scheduled for Aug 12, 2025 at noon CDT. Key discussions elements will include the request to add subject to the assessment key; “official” vs “unofficial” results among others.

• Next meeting will also include the discussion of the assessment key. There was no time to finish the discussion on the assessment domain. Additionally, big changes such as changing the key, require consensus from multiple states and vendors. A document (courtesy of EA) outlining assessment needs will be added here.

Participants

Meeting Materials

Open

Detailed Discussions

Poll Results:

Expand here to see detailed results

Open

Open

Enrollment-based Authorization - Responses from TAG:

Please review responses here: July 23, 2025 TAG Meeting - Ed-Fi Governance - Ed-Fi Confluence

“Analysis in the deck failed to take StudentEducationOrganizationResponsibilityAssociation into account: “This association indicates a relationship between a student and an education organization other than an enrollment relationship, and generally indicating some kind of responsibility of the education organization for the student. Enrollment relationship semantics are covered by StudentSchoolAssociation.” …”

Other changes related to splitting the SEOA and creating new identity tables

• Summary: We updated the names for the new entities and simplified the naming convention consistent with the conventions we have seen in other entities.

• Summary of changes --also discussed during the SEA and SIS-SIG meetings in July:

Other Responses and feedback:

• The duration of the address is key for state reporting purposes and will be available through the address common. While BeginDate and EndDate were not included in the new directory entities, they are included in the Address common as optional Period collection. The Address common is optional in the new StudentDirectory and StaffDirectory entities.

• CandidateDemographic and CandidateDirectory not created in DS 6.0. The Ed-FI Alliance hasn’t received any use cases requesting these entities.

• Release date of the Data Standard 6.0: in ODS/API 7.3.1 around December 15th, 2025, and then in DMS.

• Simpler, shorter domain entities names with EdOrg implicit: we have seen this trend in previous Data Standard versions. Additionally, the API team is evaluating the impact of making these new domain entities (as designed by Ed Comer) instead of associations. A request was made to show the endpoints, comparing the old SEOA collection with the new entities, along with an impact document. This will ensure TAG has an opportunity to discuss metadata and dependency implications. TAG has been informed of these changes, and we will prepare a visual diagram.

• Performance concerns that these changes may cause: the redesign, particularly the separation of identification codes and demographics, was motivated by the difficulty in searching identities and the need to provide the "whole package of JSON objects" when updating just one part of the identity

  • Ed-Fi believes these changes should lead to performance improvement rather than degradation, especially from the "identification code side," as updating an "aggregate entity" like the SEOA was less efficient.

  • It was also discussed that performance is unlikely to be a major issue for the new demographics and contact entities, since these are typically one-to-one entities for students. This means they won't significantly increase the number of records, unlike larger entities such as student sections, attendance, or grades, which contain multiple records per student.

  • The split may lead to a “net increase in API calls” , but the processing time per API call might reduce because the previously "big " SEOA, which had to collect many different things before processing, is now split into smaller parts. This could result in a net reduction in overall processing time.

  • Performance will also depend on where SEAs place their extensions, so that small pieces of information (for example, free lunch eligibility) would not carry large updates as it was placed in the SEOA in previous versions.

  • We also expect improved "user experience on the error resolution side," as errors would be more specific to student contact or student demographics rather than a large, undifferentiated SEOA record.

  • Huge thanks to Skyward, EA, Ed-Fi solutions team for contributing to this discussion.

• RFC 37 (b) identity names to be updated from DSWG discussion and after receiving final TAG recommendation.

Assessment Model Asks and Feedback:

• Proposal for an "Official vs. Unofficial" Flag for student assessments: discussed with Nebraska. A suggestion was made to add a flag to student assessments to designate results as either "official" or "unofficial." “Official” results would indicate that the results are finalized, accepted, and unlikely to change, while “unofficial” results would imply they are not yet reviewed or fully processed.

  • As more state assessments become Ed-Fi certified, there is an increased likelihood of receiving data directly from assessment vendors before the state has officially approved it. In such cases, the state has not yet certified the data.

  • If both “official” and “unofficial” results need to be preserved, such flag could be part of the key, as official record sent later could overwrite the previous unofficial records.

  • An alternative approach is managing the official/unofficial distinction at the namespace level: if vendor releases early results, they would be under the vendor's namespace, but if the state later releases official results, it would be a new authorship and ownership under the state's namespace. This suggestion was liked by NE.

  • There could be three layers of updates: from the assessment vendor, the state, and even districts, further complicating how results are handled and tracked.

  • Next steps: issue will also be discussed in the Assessment WorkGroup. The metadata around the assessment namespace should reflect on who owns or authorizes the results.

• Request to add the academic subject to the assessment key, came from Educational Analytics (EA) based on their implementations in South Carolina.

  • The primary goal is to facilitate dashboard reporting and address ambiguities that arise when the subject is not explicitly part of the assessment key.

  • Current challenges and ambiguity: the data model has subject, but not as primary key. EA indicated that there is no direct way to link a student assessment result to a particular subject due to inconsistencies in values. Some assessment vendors, like iReady, send separate assessments for different subjects (e.g., iReady Math, iReady ELA), which inherently links scores to a subject. However, other cases involve a single assessment identifier linking multiple subjects via an academicSubjects object, where scores for different subjects (e.g., ELA scale score, Math scale score) are included within the same student assessment record. This necessitates custom coding downstream to correctly associate scores with their respective academic subjects

  • The proposed solution is that a single subject should be linked to an assessment, and therefore, it would have to be part of the primary key of the student assessment record. This would make the academic subject a strict data element tied directly to the assessment, rather than a collection. For Composite tests, if would use “composite” subject for the top-level assessment.

  • This is a “big change” and there is concern about how it would affect other assessment providers, such as ACT.

  • Next Steps: The assessment work group (AWG) us scheduled for August 12t, 2025 to have a detailed discussion.

  • There was no time for EA to show their document, so it will be shared at the next meeting and during the AWG session.

• Additional requests were received but not discussed due to time constraints. These will be reviewed in detail during the AWG: Breaking Out Student Objective Assessment (because this is a large object); Changing "When Assessed Grade Level" to "Assessed Grade Level"; Making School Required; Linking Objective Assessment to Multiple Parents:

NEXT STEPS:

• The assessment work group is scheduled for August 12, 2025 to discuss key issues for assessments. Please email Maria.Ragone@ed-fi.org if you would like to participate and did not receive an invitation.