The usage narrative is a short narrative text account of how the data exchange functionality is made available to product users. This information will be part of the certification registry entry. This SHOULD be fewer than 1000 words and can be provided in any common text format (MS Word, .txt file, etc.).

One or more score report templates that are currently used by the vendor to provide student results to end users of the certifying system.

The score report template(s):

• MUST cover all of the elements listed in step 2 above
• MUST be in wide use by the vendor currently – the vendor MAY choose which to use if there are different options or variations
• MUST be clearly marked to show elements that are not included in the Ed-Fi based API integration (e.g., elements not included in a visual picture could be surrounded by a red box and marked "not included")

• Per certification processes generally, these report templates MUST NOT contain any real student data

• MUST be provided as PDF files

The score report templates are used to validate that data semantics are preserved and report elements are mapped to the proper Ed-Fi assessment domain counterparts.

To help demonstrate what is wanted, view this score report from a fictitious vendor: Sample Score Template.pdf

Test data is a spreadsheet of the exact sample data that will be used in the certification process. The spreadsheet:

• MUST include all data fields from the score report template(s) submitted as part of item 5, above
• MUST include all data fields from the data mapping submitted as part of item 3, above
• MUST include records for a minimum of 100 students and a maximum of 500 students
• MUST be 100% fictitious and MUST NOT be obfuscated data or derived from actual school data in any way

If the certifying system data mapping includes elements that index assessment metadata to learning standards, the provider:

• MUST provide a spreadsheet of those learning standards that will be used. The spreadsheet MUST include the GUIDS and titles of those standards; no other fields are required
• SHOULD only include the learning standards referenced in the sample data; it SHOULD NOT be a full catalog of all learning standards from a provider

If present, vendor-specific enumerations MUST be provided in Ed-Fi JSON or XML format and will be published as part of the certification record. Note that only certain enumerations are permitted to be vendor-specific: Ed-Fi Assessment Outcomes API for Suite 3 Certification#Enumerations

The JSON MUST follow this format, which can be used to import the values into an Ed-Fi API:

Descriptors JSON

{
    "namespace": "[a namespace for your product, generally in URL or URI format]",
    "codeValue": "[your code value]",
    "description": "[description]",
    "shortDescription": "[short description; e.g for inclusion in a dropdown list]"
  }

Types JSON

{
    "codeValue": "[your code value]",
    "description": "[description]",
    "shortDescription": "[short description; e.g for inclusion in a dropdown list]"
  }

The certifying product will show via screen sharing the methods by which exchanges are triggered (and those MUST follow the requirements under Certification Requirements for Data Providers and be consistent with the Usage Narrative submitted in step 4, above).

If using a formal, shared rostering specification (e.g., Clever, OneRoster, Ed-Fi Enrollment API) that allows for multiple student identifiers, the provider MUST either:

a) Demonstrate that the product allows for configuration of which student ID (from the roster specification) is used when communicating with the Assessment API implementation. This is REQUIRED even if the student identifiers are optional in the roster specification, and MUST be done for all roster specifications. The student ID configuration is limited to the district/SIS student ID and the state student ID – other IDs are exempt (e.g., a student lunchroom code, a student Google ID).

b) Demonstrate the ability to roster students via the Ed-Fi Enrollment API or the Ed-Fi Core Student Data API.

The vendor will show via screen sharing or screen shots evidence of proof that this is configurable.

Note: this configuration is only REQUIRED for those systems that use a standardized roster specification where individual students may have multiple identifiers.

Using the sample data from step 6, the certifying system will transmit an entire set of assessment metadata and student assessment results, along with learning standards or learning objective metadata if those are included.

Detailed Steps

1. The vendor will transmit the entire set of assessment metadata and student assessment results to the sandbox.

2. The submitted score report(s) will be used to check for completeness and for valid semantics.
   1. All fields from 1.1. that are map-able to the Ed-Fi model must be included.
   2. Field meanings must be accurately represented according to the Ed-Fi definitions.
3. Ed-Fi will confirm the data landed and matched expectations from the Sample Data Spreadsheet provided by the vendor.
4. A full and more detailed analysis of the data will be conducted asynchronously after the certification session by the Alliance.

Any deviations from the expected data from the sample data spreadsheet or the vendor-provided score report(s) will be documented. Ed-Fi will notify the vendor of these deviations and request either updates to or additional clarification of the submitted documentation.

Note that in this step, Ed-Fi is also verifying that data definition semantics are reasonably preserved in the mapping from provider formats to Ed-Fi formats.

To simulate the need to re-sync data in the event of an indeterminate error, several student assessment results will be deleted from the previously transmitted results. The product will be asked to re-submit the same records to ensure that those records appear.

Detailed Steps

1. Ed-Fi Alliance will delete several student records randomly.
2. The certifying product will re-submit the same assessment metadata and student assessment results to the sandbox.

3. Ed-Fi Alliance will confirm the deleted records have reappeared in the sandbox.

A change will be made to a set of records on the certifying product side and the product must show the capability to re-send the data so as to update the values of the API resources.

Detailed Steps

1. Certifying product will be asked to update several a student assessment result records.
2. Ed-Fi Alliance will confirm the updated record in the sandbox.

Updates may be done at the StudentAssessmentItem, StudentObjectiveAssessment, or StudentAssessment level.

The provider / API client MUST be able to perform the following actions:

• Capture and log transport errors, including all HTTP errors.
• Re-attempt delivery of API resources updates following failed transmissions.
• In the event that repeated delivery fails for the same resource update, surface the error to a system user.

Field work within the Ed-Fi community has revealed that this application behavior is a necessary condition of system interoperability. Accordingly, the test scenarios may include situations in which an API resource (or resources) will be made unavailable to the client, or in which the API reports other errors due to resource availability (e.g., HTTP 500 error). The client is expected to be able to successfully handle such situations.

Detailed Steps

1. Create an error in the Assessment data.
2. Attempt to POST or PUT the updated value to the sandbox.
3. Provide a quick overview of how the error is surfaced to the user.
4. Correct the error and re-submit.
5. Data submission is confirmed by the Ed-Fi Alliance.