For ESCs, BOCES and regional co-ops: one agreement, many districts, zero shared visibility
A regional service agency's problem is not features. It is that twenty member districts want the benefit of a shared contract and none of them will accept the possibility that another member can see their families. That is an architecture question, and it has a verifiable answer.
| Action | Permitted | What enforces it |
|---|---|---|
| See member district A's people, messages and logs while supporting A | Yes | A role scoped to A's organisation, effective-dated so support access can be time-bounded |
| See member district B's data while supporting A | No | Row-level security filters in the database; a query for B's rows from A's context returns nothing |
| See a member's data with no organisation context set | No | Policies evaluate against NULL and return zero rows — it fails closed, not open |
| Bypass isolation through table ownership | No | Application queries run under a non-owner, DML-only role, so owner exemption does not apply |
| See a member's child schools while scoped to that member | Yes | Isolation is hierarchy-aware: parent sees children, never siblings |
| Send on behalf of a member | Yes | Permitted where the member grants it, and recorded with the true author's person ID |
| Aggregate reporting across all members | No | There is no cross-organisation reporting surface. Isolation cuts both ways |
| Alter or delete a member's audit history | No | Append-only at two layers, and hash-chained, so alteration is detectable and unavailable |
The row that co-op administrators dislike, and why it stays
"Aggregate reporting across all members: no" is the row that comes up in every conversation. A service agency wants a regional dashboard, and the request is entirely reasonable.
The reason it does not exist is that the isolation guarantee above is only worth something if it has no exceptions. A cross-organisation reporting surface is, architecturally, a query that reads across tenant boundaries, and once that path exists the honest answer to "can another member see our data" becomes "not through the interface". Member districts are right to find that answer unsatisfying, and a co-op that has to give it loses the argument it was formed to win.
The path that stays open: each member's own data is available through the 28-endpoint org-scoped REST API using that member's own credentials, so a member can choose to send its numbers to a regional aggregation the co-op maintains. That makes aggregation a decision each district makes rather than a capability the co-op holds by default, which is also the correct governance position.
How the price works across members
| Co-op shape | Aggregate enrolment | Band applied | Annual | What an individual member would pay alone |
|---|---|---|---|---|
| 6 rural members averaging 700 | 4,200 | $3.50 | $14,700 | Below the published 1,000-student floor — several could not buy alone |
| 12 members averaging 800 | 9,600 | $3.25 | $31,200 | $3.50 each, so the co-op saves 7% and unlocks the floor |
| 20 members averaging 1,400 | 28,000 | $3.00 | $84,000 | $3.50 each — $98,000 — so the co-op saves $14,000 |
Aggregate enrolment across participating members determines the band. That is the whole commercial argument for a co-op agreement in this category, and it is worth stating that it is also how a six-district rural consortium gets access at all: individually, several members sit below our published 1,000-student floor.
One tier applies to every member regardless of size. There is no arrangement where the largest member gets features the smallest does not.
Onboarding eight districts in one summer
The sequence that works, in the order it has to happen, with the two long-lead items first:
- 10DLC brand and campaign registration — start in April. Two to six weeks of carrier lead time before SMS moves at volume, and it is per-brand. This sits on the critical path of every deployment in this category and is the item most often discovered in August.
- Data privacy agreements — April to May. Members frequently sit under different state DPA forms, and a co-op agreement does not remove the member's own obligation. Expect to run these in parallel rather than sequentially.
- Roster path, per member — May. There is no native SIS connector. Each member needs something that POSTs to
/api/v1/roster/syncon a schedule. Where members share an SIS instance or a rostering intermediary, one job can serve several; where they do not, this is per-member work and it is the largest line in the plan. - Contact hygiene — June. Run each member's contact data and look at validation state before anyone sends anything. The first send is the wrong moment to discover that a member's mobile numbers were never normalised.
- Roles and effective dates — July. Scope co-op support staff to the members they actually support, with end dates, rather than granting standing access to everything.
- One member live in July. Choose the member with the cleanest roster, not the loudest one.
- Remainder through August, two per week, each with its own test send and its own signed-off audience presets.
Major product releases land in May with professional development material, and September through May is polish only, so a summer onboarding does not collide with a redesign in October.
Exit, per member, without disturbing the others
A member leaving a co-op is an ordinary event and the agreement should treat it as one. Clause §7.1 gives a right to machine-readable export of everything, at any time, without fee or notice — and it attaches to the data of the organisation, so a departing member's export is its own. Being precise: there is no self-serve export screen, so we run it on request. The right is contractual; the button is not built.
The departing member's audit history stays hash-chained and verifiable in the export, which matters if that member is mid-way through a truancy proceeding or a records request when it leaves. Clause §11.2 applies to each member as well as to the co-op: on acquisition or a material change to data terms, a 90-day exit with export and prorated refund.
What a departure does to the band is the one commercial point to settle at signature rather than at exit: aggregate enrolment falls, and if it crosses a band boundary the remaining members should know in advance whether the rate re-bands at the next anniversary or holds for the locked term. Ours holds for the locked 36 months.
Questions people actually ask
Can our staff support a member district without seeing another member's families?
Yes, and it is a database property rather than an interface one. Row-level security filters rows inside Postgres, applied under a non-owner role so table ownership cannot bypass it, and it fails closed — with no organisation context set, queries return zero rows. A cross-tenant leakage suite runs in continuous integration against real Postgres 16.
Does aggregate enrolment across members determine the price band?
Yes. Total participating enrolment sets the band, so twelve members averaging 800 students land in the $3.25 band rather than each paying $3.50. It is also how members below our published 1,000-student floor get access at all.
What happens when one member district leaves the co-op?
That member exercises its export right under §7.1 and takes its own data, including a verifiable audit history. The remaining members are unaffected operationally. Commercially, settle at signature whether a drop in aggregate enrolment re-bands the rate — under our agreement the rate holds for the locked 36 months regardless.
Can each member keep their own audit record?
Yes. The hash chain is per-organisation, so each member has its own independently verifiable sequence rather than a shared log filtered by a column. That also means a co-op administrator cannot alter a member's history, which is the property a member's counsel will actually ask about.
Can the co-op run a regional dashboard across all members?
Not from inside the product. There is no cross-organisation reporting surface, deliberately, because an exception to isolation makes the isolation claim unverifiable. Members can push their own data to a regional aggregation through the org-scoped REST API using their own credentials, which keeps aggregation a member decision rather than a co-op capability.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers, no add-on modules, no per-message fees. Published on the site because you should not have to book a call to learn a price.