Skip to main content
Ed-Fi.orgDocsCommunityAcademy

How the Ed-Fi Data Standard Fits Into Your Data Ecosystem

The Ed-Fi Data Standard is a specification for exchanging education data. Ed-Fi API applications, such as the Ed-Fi ODS/API and Ed-Fi API v8, operationalize the standard. Together they connect the systems that schools and agencies already run; they do not replace those systems. This page answers common questions about how they relate to other kinds of education data systems.

Does the Ed-Fi Data Standard replace a student information system?​

No. A student information system (SIS) is the application a school or district uses to manage enrollment, attendance, schedules, grades, and other student records. The Ed-Fi Data Standard defines how that data is described and exchanged, and an Ed-Fi API application implements it. Neither one is a substitute for a SIS.

The two work together:

  1. The SIS remains the source of truth where school staff enter and manage student data.
  2. The SIS vendor builds an API client that creates, updates, and deletes data on the agency's Ed-Fi API as it changes in the SIS. For example, when a student enrolls, the SIS sends a StudentSchoolAssociation record to the agency's API.
  3. Other products, such as assessment, HR, and learning systems, send their data to the same API. Because they all follow the Data Standard, the agency can connect the records without a custom mapping for each vendor.
  4. Downstream systems, such as data warehouses, reporting tools, and state reporting, read the data from the API.

For SIS vendors, this replaces custom extracts for each customer with one integration that many education agencies can receive. See Student Information System Providers and Ed-Fi API Integration Architecture for Data Providers.

Is the Ed-Fi Data Standard a data warehouse or data lake?​

No. The Ed-Fi Data Standard is not a database or a reporting tool: it defines what is exchanged, not how a system stores or reports on that data. An Ed-Fi API is a transactional system. It is optimized for exchanging operational data between source systems and a central data store. A data warehouse, data lake, or lakehouse provides analytical infrastructure, built for queries across large amounts of data.

Data sourced from an Ed-Fi API commonly feeds analytical systems in these ways:

  • Analytics run downstream of the API. Read-heavy analytical queries should be served from a dedicated data store, such as a data warehouse or reporting pipeline, that is populated by reading from the Ed-Fi API.
  • The API is an upstream source for a lake or lakehouse. In a data lake, the Ed-Fi API serves as a source for the ingest step, so the data that lands in the lake is already structured according to the Ed-Fi Data Standard.
  • Incremental loads use changed record queries. Downstream loads can read only the records that changed since the last load. See Using the Changed Record Queries.
  • Analytical models are built from the data. The Data Standard's Unifying Data Model is designed for writing interoperable data, not for dashboards and analytics, so analytical stores typically use their own models built from Ed-Fi API-sourced data.

For more detail, see The Ed-Fi Data Standard in the Age of AI and Ed-Fi in the Data Lake.

A data hub, in the Ed-Fi Community, is an organizational concept, not a technology layer: it provides a shared data infrastructure, usually run by an education service agency or a state, that collects data through an Ed-Fi API and then supports analytics and data warehousing for member districts.

Is the Ed-Fi Data Standard a state longitudinal data system?​

No. A state longitudinal data system (SLDS) is the system a state uses to keep education data over many years for reporting and research. The Ed-Fi Data Standard and Ed-Fi API can standardize and supply the data that goes into an SLDS, but they are not an SLDS.

In a typical state architecture:

  1. Districts' student information systems and other products send data to the state's Ed-Fi API, which validates the data as it arrives instead of relying on file-based submissions.
  2. The state periodically moves data from the Ed-Fi API's data store into a multiyear store.
  3. The state populates its SLDS for reporting needs. In some states the SLDS is based on the Ed-Fi Data Standard; in others it is a third-party or existing agency system.
  4. From the SLDS, the state generates data marts for state and federal reporting, such as EDFacts.

See Elements of an Ed-Fi Architecture and the SEA Playbook.