Tag: School Contact

  • Identity Solves Half the Problem. California Associates Is Our Answer to the Other Half.

    It’s 7:40 a.m. and a parent is typing a message to her daughter’s teacher: she’ll be out Thursday, dentist appointment. Some AI-powered scheduling assistant sitting inside the district’s messaging platform is going to read that, figure out which daughter, which teacher, and whether the person typing has any standing to make that request — and then act on it.

    School Contact can already tell the school that message really came from that parent. That’s identity, solved. But nobody has answered the second question sitting right behind it: is the tool reading that message, and the twenty other tools plugged into the same system, actually built well enough to be trusted with it?

    That’s the gap this piece is about — and it’s the reason we’re proposing something we’ve deliberately chosen not to run ourselves.

    What School Contact does, and where it stops

    How California Associates connects vendors, government, and the Contact Initiative identity layer EdTech vendors and Government & funders both connect into California Associates, an independent nonprofit with three functions: vendor vetting, AI sandbox, and pilot programs. California Associates then approves vendors down into the existing verified identity layer. EdTech vendors Want to connect Government & funders California Associates Independent nonprofit (proposed) Vendor vetting Security audits AI sandbox Synthetic data Pilot programs Small, evaluated Approved vendors only Verified identity Contact Initiative layer

    School Contact gives a parent a verified way to know a message really came from a teacher. It gives a school a reliable way to confirm a caller’s claimed relationship to a student. It closes off the impersonation and phishing that currently thrives on nobody being able to check anyone’s claims.

    What it doesn’t do is vet the dozen-plus other tools a district plugs into that identity layer — the student information system, the learning platform, the classroom apps, the messaging tool, the scheduling assistant starting to lean on AI. School Contact can confirm who is asking. It has no mechanism — and shouldn’t be the one building one — for judging whether the tool asking is secure enough to be trusted with your child’s data in the first place.

    That gap is bigger than it sounds. A 2024 industry survey (Center for Internet Security / K12 SIX) found that the large majority of K–12 districts experienced some form of cybersecurity incident over the prior eighteen months, and vendor-side compromises — not the districts themselves — are consistently cited as a leading cause. Most districts now run dozens of third-party EdTech tools, typically vetted, if at all, by whoever happened to be doing procurement that year. Identity verification stops someone from pretending to be your child’s teacher. It does nothing about a vendor with weak security getting breached and taking your child’s data down with it.

    Why we don’t want to be the ones grading this homework

    There’s an obvious shortcut: have School Contact itself decide which vendors are trustworthy. We considered it and ruled it out on purpose.

    Any organization that both runs the identity layer and decides which commercial products get to plug into it has a conflict of interest baked into its business model. It has every incentive to wave through partners, go easy on vendors it already has relationships with, or quietly redefine “compliant” to fit whoever’s already integrated. Electrical products get certified by UL, not by the manufacturers whose products the certification governs. Payment processors answer to PCI-DSS standards set by an independent council, not by whichever bank benefits most from a lenient reading. Identity infrastructure for schools deserves the same separation — which is exactly why we’re proposing a second, independent nonprofit for this job instead of building it into School Contact.

    What California Associates is actually proposing

    California Associates would be a 501(c)(3) nonprofit sitting between schools, vendors, and government, with three specific jobs:

    Vendor vetting and compliance. An independent clearinghouse that audits EdTech tools against identity and security standards before they touch a district’s systems — instead of every district separately, unevenly, or never evaluating the same vendors on its own.

    A sandbox for AI, kept away from real student data. As AI tools take on requests like the Thursday-absence message above, something has to correctly resolve which daughter, which teacher, and whether the person asking has the standing to ask. The proposal calls for a bounded testing environment — separate domains, synthetic data only — where developers can work through exactly that problem without ever touching a real student’s real records.

    Coordinating pilots, transparently, before wider rollout. If any of this gets tested in real schools, it happens through funded, evaluated pilots — not a quiet expansion — with philanthropic, corporate, and federal research funding secured and disclosed up front.

    Where this stands today

    California Associates is a proposal, not an operating entity: no vendor has been vetted, no sandbox is live, no pilot is underway in any school. But a proposal that only exists as a document is easy to ignore, so we’ve already started building. Our beta test site is live now at california.associates — because we’d rather show up with something real to react to than ask people to take a governance model on faith. If you want to see where this is headed before it’s finished, that’s the place to look.

    The honest version of the hardest questions

    We’d rather answer these plainly and let you disagree with the answer than dodge them and ask for blind feedback.

    If you’re a parent or teacher: does an independent vetting body actually make you more confident in your school’s tools, or is it one more layer between a good idea and your classroom? Our answer: on its own, a vetting body is invisible to you day-to-day — you’ll only notice it in the incidents that don’t happen. The test isn’t whether you feel it; it’s whether the tools your kid’s school adopts next year have fewer of the vendor-side breaches that are already happening today. Tell us if you think that trade-off is wrong.

    If you’re a school or district administrator: does this respect the procurement control you already have, or does it ask you to give up more than it gives back? Our answer: it’s meant to be a resource you can point to, not a mandate that overrides your own review — a vetted-vendor list that saves your IT team from re-doing the same security diligence fifty other districts already did. If it starts to feel like a mandate in practice, that’s a design failure we want to hear about immediately.

    If you work in education technology or AI: is there a realistic, non-burdensome way to actually meet a standard like this, or does it look good on paper and collapse at the pace software ships? Our answer: we don’t know yet, and that’s precisely what the sandbox is for — a place to pressure-test the standard against real development cycles before it’s locked in as a requirement anyone has to live with. If the standard doesn’t survive contact with how you actually ship code, we need to know that before we finalize it, not after.

    Where to send feedback

    The full proposal — governance structure, the open legal questions around FERPA and COPPA, and the specific questions we’re putting to academia, government, and the technology industry — is at california.associates. It’s marked as an exploratory draft, not adopted policy, on purpose: the goal right now is to find out what’s wrong with it, not to defend it.

    School Contact makes sure the people talking to your school’s systems are who they say they are. California Associates is our answer to the harder question behind that one: making sure the systems themselves have earned that trust before they’re allowed to ask. We think both problems are real, we think they need independently accountable answers, and we think you should be able to watch us build the second one instead of just reading about it.

  • The Contact Initiative in Action

    The Contact Initiative white paper lays out the architecture: a federated identity anchor and attestation model instead of a single national ID, query-response verification instead of a browsable directory, and a Machine-Intelligence Authorization Layer that governs every MI-initiated action with scoped grants, audit logging, and human oversight. The six scenarios below show what that architecture looks like in practice.

    Every scenario is hypothetical and illustrative. None describes a system that currently exists or has been adopted by any school, district, institution, or government body. Scenario 5 extends further than the others, into location-sensing capability the white paper does not specify — it’s flagged throughout as a candidate for separate privacy and governance review, not a solved feature.

    1. Fixing a District’s Vendor Bottleneck

    School Contact — When a faulty vendor update takes down hero images across every school homepage in a district, the web administrator’s attested operational-staff identity grants scoped, logged access to the hosting environment — not standing access to every district system. Instead of hunting for the vendor’s current contact info, the admin runs a query-response check against the vendor’s verified support channel and gets a same-day rollback.

    Read the full scenario →

    2. Resolving an MI Scheduling Conflict

    University Contact — A student asks their MI assistant to email “my biology professor,” but the student has both a course instructor and a lab director. Because the MI Authorization Layer only ever holds a single-message, time-limited grant — never standing access to the student’s full record — it can’t quietly guess. Two different verified roles resolve to two different people, which trips the human-approval threshold: the assistant asks which one is meant, then logs the scoped credential and lets it expire.

    3. Stopping a Phishing Attack on Families

    School Contact — A phishing campaign spoofs a district’s branding to demand a fake “transportation fee” from parents. Mandatory domain authentication (DNSSEC, SPF, DKIM, enforced DMARC) means the spoofed mail never delivers as genuine in the first place. And because parents use a retired-never-recycled guardian alias, the school can check any reply against current, active guardianship before trusting it.

    Read the full scenario →

    4. Cross-State Enrollment After a Disaster

    School Contact — After a hurricane displaces hundreds of families, a receiving district can verify a child’s grade level, enrollment history, and — subject to the IEP/Section 504 legal review the white paper flags — accommodation status in seconds, through a signed request to the sending district. No centralized database, no records rebuilt from paper, no student waiting weeks to be seated in the right classroom.

    Read the full scenario →

    5. Active Campus Threat and MI-Coordinated Response

    School Contact & MI Authorization Layer — A verified call from an attested staff alias triggers a pre-scoped emergency grant — configured and revocable by a human administrator in advance, since a live approval step isn’t viable when seconds matter. The assistant issues an authenticated, campus-wide alert and relays verified caller data to 911, with every step logged for later review.

    This scenario is presented with more caveats than the others: real-time location sensing of students is a significant, separate capability the white paper doesn’t currently specify, and it would need its own dedicated privacy, security, and legal review before any real deployment.

    Read the full scenario →

    6. Community-Led Enrollment After Wildfire Displacement

    School Contact — When wildfire displaces an entire neighborhood, families use their existing guardian aliases to enroll together at a receiving school, coordinate housing and transportation among themselves on a separate parent-to-parent channel, and — because each student’s identity anchor persists and is never reassigned — kids stay reachable to their existing friends after the move.

    Read the full scenario →

    Where This Goes Next

    None of this replaces the legal, privacy, and governance review the white paper calls for before any real deployment. See our thinking on costs, governance, and the road to a pilot and the risks we’re taking seriously. Questions? Check the FAQ or get in touch.