The Assessment Outcomes API describes a REST API surface to enable exchange of assessment metadata and student assessment results between disparate and geographically separated systems operated by different organizations. The API resource models are derived from and consistent with the underlying Ed-Fi Unifying Data Model v2.2.
The Ed-Fi Assessment API provides a blueprint for a source system (the provider) to manage a core set of assessment data on a target system (the consumer) using RESTful APIs. In this data exchange architecture, the provider implements an API client, which uses HTTP/S requests and RESTful patterns to manage API resources on the consumer system, which implements the API definition itself (see Figure 1).
Figure 1. Overview of API and API client architecture
This is often thought of as a "push" model, as the provider pushes data to the consumer, who has implemented the API surface.
While this architecture can be understood as the provider transferring data from itself to a consumer system, the API interactions are often more sophisticated. In real-world use cases within the Ed-Fi community, field evidence suggests that using such an API includes a broader set of responsibilities on behalf of the provider and consumer systems, such as the responsibility for regular auditing the state of data synchronization and addressing gaps in synchronization when they occur. 
The Ed-Fi UDM provides a logical model and data dictionary that define the semantics (entities, properties, and definitions) and the structure (relationships between entities including cardinality) of all data within all Ed-Fi published standards. They are "unifying" in the sense that they ensure the compatibility of the structure and meaning of data across all Ed-Fi standards.
The UDM is concerned principally with data directly related to student outcomes and results that can be used by teachers and others to make instructional decisions to improve student performance.
Consistent with that goal, the assessment data exchange models described in these standards are therefore focused on capture and delivery of results (see the outlined section of Figure 2).
Figure 2. Focus of the Ed-Fi Assessment API Standards
Note that this does not mean the Ed-Fi UDM and the Ed-Fi data exchange standards do not capture information related to the assessment instruments themselves, the learning management system (LMS), or other context in which a student interacts with an assessment instrument. Elements related to those processes and artifacts do appear in the Ed-Fi UDM, but they are generally present because those elements are valuable in the interpretation of the student outcomes. 
Given that focus of the Ed-Fi UDM and data exchange standards, the exchanges enabled in the model described here are not designed to deliver on the following functions and use cases:
This standard uses the Ed-Fi Unifying Data Model v2.2. All entities, properties and relationships are derived from that logical model and must observe those semantics and structure to be considered a faithful implementation of this standard.
Many assessments are multi-tier in the sense that they provide multiple scores or result sets for each assessment. An example would be a single "reading" assessment that tested multiple skill areas, such as "Reading Comprehension," "Accuracy and Fluency," "Phonemic Awareness," and so on. In the Ed-Fi model, the top-level assessment is an Assessment and the skill areas are ObjectiveAssessments. This structure is recursive, so that there can be any number of levels of ObjectiveAssessments.
Once the student takes the assessment, the results are captured in the StudentAssessment and StudentObjectiveAssessment, each of which has references back to its parent entity. Finally, for assessments that report item level results, there are AssessmentItems and StudentAssessmentItems. (See Figure 3 for a partial UML representation of the Ed-Fi Assessment domain model.)
Figure 3. Principal entities in Ed-Fi Assessment domain
Critical for use of student assessment results is defining for stakeholders what student knowledge, skills, and other competencies are being assessed. In the Ed-Fi assessment model, LearningStandards and LearningObjective play this role.
Both LearningStandards and LearningObjectives are hierarchal as well; this matches the tiered pattern seen frequently in academic standards.
ObjectiveAssessments can map to LearningStandards or LearningObjectives. As noted above, a mapping to a LearningObjective may also signify a mapping to a LearningStandard, if the LearningObjective is so mapped. AssessmentItems can be mapped to LearningStandards.
Figure 4. Ed-Fi Assessment domain representation of learning standards
The architecture covered by this model of data exchange is intended to serve the following example use cases. Note that these use cases are illustrative, not exhaustive: they outline a few high-value uses cases and do not cover all possible use cases.
This API standard is designed to allow applications to read and write assessment data through a secure REST interface.
API implementers and clients are expected to follow all guidelines in the Ed-Fi API Design and Implementation Guidelines. These include requirements relating to errors, authentication, security, and other aspects of API usage and implementation. Any MUSTs from that document are considered required to conform to this standard. If there are differences between the requirements included in this document and the Guidelines, the information provided in this document is assumed to have precedence.
An Open API definition of the REST interface is provided below. Consumer implementations wishing to conform to this standard are expected to implement paths and resources as described in that Open API specification. In addition, providers must accurately follow the semantics in the Ed-Fi UDM.
 Additional examples would be that the provider is also required to be able to reconcile records following errors or other transport problems, implement data quality checks, and log and surface errors to users.
 For example, it can be helpful for teachers looking at the results of a test to be able to see the test questions, or to understand if a student was provided one or more accommodations for the test itself.