CetusEd
A student changes systems. Their record shouldn’t change with them.
A child moves buildings, a district changes vendors, the state stands up a platform, and each time, someone re-keys the same facts and something is lost in the copy. This page is the technical and legal map of what it takes for a record to survive those crossings: how CetusEd exchanges it, what stays in the district’s own hands, and what has to be true — in code, in contract, and in law — before a student record moves both ways.
Current state · what each system requires · the sequence · what the district decides
The district is the steward. Integration doesn’t change that.
Most integration stories end with a copy of the district’s student data sitting on a vendor’s servers, because that is the easy way to build it. CetusEd’s constraint is the opposite, and it is architectural rather than contractual: records live on district-managed devices, and any connector runs on infrastructure the district owns and can switch off. A district that connects CetusEd to its SIS is extending its own perimeter, not handing data across one.
What moves today — and what doesn’t.
The build program that carried the platform out of its own pilot is complete, so the question is no longer whether the code exists: inbound rostering is written and tested against the OneRoster and Clever specifications, outbound write-back is built and scoped narrowly, and the state-reporting extract is generated. What still stands between a district and a live connection is a district decision — the connector below, the SIS vendor’s partner credentials, and the district’s privacy agreement — not another build.
| Path | State | What that means |
|---|---|---|
| Roster file import | Available now | CSV with field mapping, a district bundle format that registers schools and staff, and per-school files. This is how every district starts, and it needs no agreement with anyone. |
| Mid-year migration | Available now | Active plans arrive with their effective dates, and the statutory clocks re-arm from the real dates rather than resetting to zero. A continuing-student guard stops a migration from looking like a new evaluation. |
| Live roster sync (inbound) | Built | OneRoster 1.1/1.2 REST and the Clever Data API: students, demographics, teachers, classes, and enrollments to homeroom; changed-since delta pulls; withdrawn students are un-rostered rather than deleted; the state student identifier is reconciled. It switches on with the district connector below and credentials from the SIS vendor. |
| District connector | Built | A small service the district deploys on its own cloud account, with an allow-list of the SIS hosts it may reach. It authorizes reads and the narrow write-back routes below — every outbound write is logged, idempotent, and revocable at the district’s end. |
| Signature collection at a distance | Available | In-person signing works now. Remote consent by secure link is available against the governing law: an opaque token, never the record; the signer authenticates and views a redacted document served from district-controlled storage, and the signed bytes are chained into the audit log. It runs on the district’s own connector. |
| Write-back to an SIS or IEP system | Built (narrow) | Write-back is scoped to the handful of fields a receiving system genuinely needs — placement category, federal setting code, the state student identifier, and the disability categories as Washington lists them. Each field is reconciled and reversible; the district’s connector is the only writer, every write is authorized there and logged on both sides, and a retry cannot duplicate a record. |
| State reporting extract | Built | A submission file is generated in the shapes state reporting consumes — the Ed-Fi-shaped projection, placement category and federal setting code, the state student identifier, and the disability categories as Washington lists them — and a district reviews it before anything moves. Reporting no longer has to run from the SIS. |
“Built” means it ships in the platform now; what turns it on is the district’s decision — its connector, its credentials, its agreement. This page reflects the platform at the completion of its 2026 build program; the parts that live in other organizations’ hands — SIS partner registrations, certifications, an independent audit — are named where they apply rather than assumed away.
Four hurdles, and only one is engineering.
Districts are usually told integration is an engineering question. It is mostly not. Three of the four things standing between a working connector and a live one are permissions and paperwork, and they run on other organizations’ calendars.
The sequencing consequence: the engineering for a given connector is usually the short pole. Partner admission and the district’s privacy process are the long ones, and they can start before a line of connector code is written.
What each one actually requires.
Gathered from each vendor’s own published developer and partner documentation. Where a requirement is not public, this says so rather than guessing — a district’s own account team is the authority on its own contract.
- Partner registration is mandatory. Qmlativ’s API is reached through an Integration Access record that synchronizes to Skyward’s Partner Portal, and the portal is what issues a vendor its credentials. A district cannot simply hand out a key.
- The district controls what is exposed. The Integration Access record declares which tables and fields are exposed and which operations are permitted, so read-only is a real, enforceable configuration, not a promise.
- Each vendor gets unique credentials per district, which is the model CetusEd wants anyway: no shared secret, revocable by the district alone.
- Status: not registered. This is the single highest-value partner conversation for a Washington district, and it is a prerequisite, not a formality.
- Two doors. A district administrator can mint an OAuth client ID and secret from the Developer Console for a specific installation; broader distribution runs through PowerSchool’s partner program and its developer portal.
- Permissions inherit from the creating account, so the scope a connector gets is decided in the district’s own admin portal — again, a real control rather than a policy statement.
- Special-education relevance: PowerSchool is both an SIS and one of the vendors the state’s market research identified as capable of delivering a statewide IEP platform, so this integration could matter twice.
- Status: not registered.
- Rostering is the supported path. Edupoint documents third-party integration via the OneRoster API, which is the same interface CetusEd already implements — the shortest technical distance of the three.
- A test environment first. Edupoint’s own guidance is to configure a Test/Train site for a third-party app before production, which matches how a pilot should run regardless.
- Beyond rostering — anything richer than roster and enrollment — runs through Edupoint’s partner relationships, and the terms are not public.
- Status: not registered; OneRoster support means the read direction is largely a credentials-and-agreement problem rather than a build.
- File-based by design. Published guidance routes student data through a secure file transfer or an uploader, with nightly synchronization from the SIS — not an open partner API.
- Partner data flows require a signed data-sharing agreement between the customer and each party before assessment or goal data moves.
- Practical read: a district running both would most likely exchange scheduled files rather than call an API, which is lower-risk and slower, and is a district-to-district decision, since the customer holds both agreements.
- Status: no contact. Listed because MTSS-platform overlap is the question a district running one will ask first.
- Sign-in already works against Microsoft Entra ID, Google Workspace, and Clever using OpenID Connect with PKCE, with the signature check on by default. A district can require it and disable email login entirely.
- Publisher verification is Microsoft’s trust step for a multi-tenant app — a registered app, a verified publisher domain, and membership of Microsoft’s partner program. There is no charge to verify.
- Google is the steeper one. Anything beyond basic sign-in — reaching a district’s Drive, Calendar, or mail data — means restricted scopes, and restricted scopes mean a third-party security assessment by a Google-approved assessor, renewed annually, before the app can be distributed.
- Consequence, and it shapes the roadmap: CetusEd uses identity for sign-in only. Reaching into Workspace content would convert a small integration into a recurring annual audit obligation, so it is deliberately out of scope.
- Implementing a standard and being certified against it are different things. CetusEd implements the OneRoster rostering interface; it holds no conformance certification, and does not claim one.
- Ed-Fi’s partner badge has a market-availability bar a pre-pilot company cannot meet: the functionality must be available across an entire US state or purchasable by at least 100 districts, and must show real usage in a district.
- Which is the honest sequence: pilots first, then the district count, then certification — not the other way round. Anyone claiming otherwise has skipped a step the standards body will not skip.
- Status: OneRoster implemented, uncertified. Ed-Fi implemented end to end; certification waits on the district-count bar above.
Every one of these is the district’s to sign.
None of this is exotic; districts execute these agreements routinely. It is listed because integration proposals usually omit it, and then the timeline slips by a term.
A statewide IEP platform is coming. Its own requirements set the bar.
Under E2SSB 5263 (2025), Washington is standing up one statewide IEP system on a published eight-year roadmap: planning and procurement in 2025–26, platform setup in 2026–27, a pilot in 2027–28, phased implementation in 2028–29, and full statewide launch in 2029–30. The state’s own solicitation for that platform states its technical requirements, and they are a useful specification for anything expecting to live beside it.
Sources: OSPI, Statewide Individualized Education Program System feasibility study, April 24 2025, and OSPI’s published statewide-IEP project roadmap and platform solicitation. Submissions for the platform closed on 30 June 2026; no vendor had been announced as of this page’s date.
In the order it can actually happen.
Each stage is gated by the one before it. Nothing here has a promised date — a one-person company with no completed pilot yet does not get to schedule other organizations’ approvals, and the pilot districts’ own priorities will reorder some of it.
- In-person and multi-party signing on a shared device, and the completion rules that follow a fully signed document through to the case manager.
- A district-facing report of exactly what a connector would send and receive, generated from the same column list the disclosure check uses, so an IT reviewer can read the data map before agreeing to anything.
- Export coverage for the fields a receiving system needs, including the state student identifier and the state reporting categories.
- The district deploys the connector on its own cloud account, with an allow-list naming only its SIS host.
- Turn on inbound rostering against a test environment first, then production; verify the delta sync, the un-roster path, and that local corrections survive an overnight run.
- Requires the SIS vendor’s partner credentials and the district’s data-privacy agreement. Both start before the code does.
- A notification carries an opaque token, never the record. The signer authenticates and views a redacted document served from district-controlled storage.
- On the district-configured signature path the link between token and student stays on the device; a one-time code establishes identity, with a second factor where a release sends data outside the district.
- Both the signed bytes and the local record are hashed and chained into the existing audit log, with a server-issued timestamp rather than the signer’s clock.
- Write-back is scoped narrowly at first — the handful of fields a receiving system genuinely needs, each one reconciled and reversible, never a bulk push.
- Every write is authorized at the district’s connector, logged on both sides, and idempotent, so a retry cannot duplicate a plan or a service line.
- Ed-Fi is already here: implementing it was a build, and the badge that makes it meaningful still has a district-count bar that only real deployments clear. That is an honest sentence no roadmap can skip.
The reason to publish a sequence rather than a date: every one of these stages has at least one dependency held by someone else, and a roadmap that hides that is a roadmap that will slip without explanation.
Where an integration would go wrong.
These are design decisions, taken in advance, that a future feature request will not override quietly.
Bring your IT director to the first conversation.
The questions on this page — which SIS, which identity provider, whose partner agreement, what the district’s privacy process needs — are better answered in the first meeting than the fifth. Ask for the data-flow and security review packet with your pilot inquiry.
Start the conversationor read privacy & security and the district & IT FAQ