Ed-Fi
Ed-Fi is an open data standard and reference technology suite, stewarded by the Ed-Fi Alliance, for bringing a district's or a state's education data into one consistent model. It is considerably broader than rostering, and that breadth is the whole point of it.
| Ed-Fi | OneRoster | |
|---|---|---|
| Purpose | Unify education data for analytics, reporting and state accountability | Move roster and gradebook data from a SIS to applications |
| Scope of model | Students, staff, enrolment, attendance, assessment, discipline, finance, programmes, survey | Orgs, users, courses, classes, enrolments, terms, results |
| Steward | Ed-Fi Alliance | 1EdTech (formerly IMS Global) |
| Typical operator | State agency or a large district | The SIS vendor or a rostering intermediary |
| Infrastructure needed | A hosted ODS and API, plus people to run it | An endpoint or a scheduled file |
| Effort to stand up | A project, measured in months | A configuration, measured in days |
| Right tool for a comms platform | Overkill in almost every case | Yes |
The pieces, and what each one is for
People use "Ed-Fi" to mean four different things, which is most of the confusion:
- The Data Standard. The model itself, the entities, their attributes and their relationships, versioned and published. This is the part that is genuinely a standard.
- The ODS (Operational Data Store). A relational database implementing that model. Somebody has to host it: a state agency, a regional service centre, or the district.
- The API. A REST surface over the ODS that source systems write into and downstream systems read from. Vendors certify against specific API versions.
- Descriptors and extensions. Descriptors are the controlled vocabularies, absence reasons, programme types, race and ethnicity codings, which vary by state. Extensions add state-specific fields. Together these are why one state's Ed-Fi implementation is not portable to another's without work.
Newer deployments may also involve the Data Management Service, the Alliance's more recent platform work. The architectural point does not change: Ed-Fi is infrastructure a district or state operates, not a feed a vendor turns on.
When a district actually needs it
Ed-Fi earns its keep when the problem is analytical, joining attendance, assessment, behaviour, programme participation and demographics into one model so that early-warning indicators and state reporting come from a single place instead of eight exports.
Most districts encounter it because their state mandated it. Broadly there are four situations, and which one you are in determines everything about how a vendor integration should be scoped:
| Shape | Who runs the ODS | What a vendor integration looks like |
|---|---|---|
| Statewide, mandated | State agency or regional centre | Certification against the state's API version and descriptor set; state approval to connect |
| Statewide, optional | State, districts opt in | Same technically, but the district can also route around it |
| District-hosted | The district or its integrator | Direct API credentials; the district controls scope and can move fast |
| No Ed-Fi | Nobody | OneRoster or a direct SIS export; Ed-Fi is not the question |
The question to ask an Ed-Fi state. Not "do you support Ed-Fi" but "which API version, which descriptor set, and does connecting need state approval or district credentials?" The answer changes the timeline from weeks to a term.
Why a communications platform rarely wants Ed-Fi
A school-home messaging system needs a small, specific set of facts: who is enrolled where, which adults are attached to them, how to reach those adults, and what language they read. That is a rostering problem, and OneRoster or a plain scheduled export answers it directly.
Pulling the same facts out of an ODS means taking a dependency on state-specific descriptors and an approval process, to obtain a subset of data the SIS could have handed over on its own. It also frequently does not solve the hard part: guardian contact points and language preference are among the thinner areas of most real Ed-Fi deployments, because the analytics use cases that drove adoption did not need them.
Where Ed-Fi genuinely helps a comms programme is upstream of the messaging: it is where a district builds a defensible chronic-absenteeism or early-warning indicator, which then determines who gets contacted. The indicator lives in the data platform; the outreach lives in the comms platform. Keeping that boundary clean is the correct architecture.
Kastr does not implement an Ed-Fi ODS connector. It offers the separate custom JSON roster API, typed CSV import and native OneRoster REST/CSV ingestion. A OneRoster connection does not satisfy an Ed-Fi requirement.
Questions people actually ask
Is Ed-Fi a replacement for OneRoster?
No. They solve different problems and many districts run both. OneRoster moves rostering data from a SIS to applications. Ed-Fi unifies a much wider set of education data for analytics and state reporting. A communications platform needs the first; a data warehouse project is more likely to need the second.
Does a district have to host its own Ed-Fi ODS?
Not usually. In statewide deployments the state agency or a regional service centre hosts it. Large districts sometimes host their own for local analytics. Which applies to you determines whether connecting a vendor is a district decision or a state one.
Is Ed-Fi free?
The standard and the reference implementation are openly licensed, so there is no licence fee for the technology. The cost is operational, hosting, integration work and the people who maintain the descriptors and mappings. Districts routinely underestimate that second part.
Do communications vendors need to be Ed-Fi certified?
Only if the state or district requires it as a condition of connecting. Most school-home messaging platforms roster through OneRoster, a rostering intermediary or a direct export instead, because the data they need is a small subset of the Ed-Fi model.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers or add-on modules. Normal messaging is included under a published fair-use allowance, with transparent cost recovery only above it.