Technology providers MUST provide a verification that the certified product functionality is in use at a minimum of 3 local education agencies (LEAs) who are members of the Ed-Fi community. An "LEA" is considered as entity authorized to provide K–12 education services by a U.S. state or territory.

Format

To meet the requirement, the Ed-Fi Alliance MUST receive three verifications from LEAs (i.e., entities authorized to provide education services by a U.S. state), that use the attached form.

When are verifications required?

• At least one verification MUST be provided prior to the start of certification testing.
• Remaining verifications — which MUST bring the verification total to 3 — MUST be provided within 6 months of certification or the certification will be removed.

What LEA Projects Qualify?

LEA projects used to validate the integrations MUST meet these requirements:

• MUST be between two systems directly under agency control or contract. State compliance reporting (and similar use cases) are therefore excluded.
• Can be "pilot" or "production" in nature, but MUST be operational and be transferring real agency data. Projects MUST NOT be prototypes, proof-of-concept systems, similar development efforts that require manual intervention to make operational, or otherwise impermanent solutions.

What is Published?

Only the identity of the agency that provided the verification will be published in the Registry of Ed-Fi Certified Products. No other information from the verification is published.

Rationale

The main goal of implementation verification is to create a community-centric way to validate the quality and usability of Ed-Fi standards-based integrations.

In the initial years of Ed-Fi certification, a number of complaints emerged about certifying products under-investing in features or support critical to creating real-world integrations and value. While the scope and precision of certification testing grew over time to help compensate, it was still difficult to account for all the the possible issues that can cause a mismatch between customer expectations and actual certified product functionality. The most persistent problems included (but were not limited to):

• The provider did not adequately support the certified functionality, leaving customers "on their own" without access to normal support resources.
• The provider allowed or enabled local product customization that then "disqualified" the customer from accessing the certified functionality.
• The provider blocked access to certified functionality via high "add-on" pricing for the certified functionality, which undermines actual availability.

Situations like these proved difficult (if not impossible) to detect in formal certification testing, as doing so involved a level of subjective judgment around concepts of usability, efficiency, and if a feature should be supported given local practice or customization, among others. 

Implementation verifications provide a level of validation — via community member validations — that a technology provider is invested in and achieving standards-based data exchange in the "real world." This is what matters to the Ed-Fi community most.

A secondary goal of the requirement is to encourage technology providers to develop standards-based integrations in collaboration with actual end users. It is an accepted best practice in software development to work closely with actual users of the software to maximize the chances of creating customer value. 

Nearly all early issues experienced in the Ed-Fi community related to LEA access to certified functionality. Hence, the verifications MUST be from LEAs and MUST be use cases where data is moving between LEA controlled or contracted systems.