SCHOOL CONTACT

Author: School Contact Iniciative

  • Map

    Contact Initiative Domain Map — Complete Overview

    Complete Domain Directory for K–12 Schools, Colleges, and Universities

    Production, in use today
    MI beta, for testing only
    K–12 Schools

    location_citySchools

    elementary.school
    elementaryschools.email

    schoolStudents

    highschool.email highschools.email
    middleschool.email middleschools.email

    cast_for_educationTeachers

    teacher.contact technologies.contact
    teachers.email technology.email
    schools.email

    badgePrincipals

    principal.email principals.email

    family_restroomParents / Guardians

    parent.email parents.email

    account_balanceAcademies (Charter / Private)

    academy.email academies.email

    verified_userK–12 Verification

    school.contact technologies.contact
    Colleges (Teaching / Community)

    schoolStudents

    college.email colleges.email

    personFaculty

    faculty.college professors.college
    professor.college professors.colleges

    co_presentLecturers

    lecturer.college lecturers.college

    verified_userCollege Verification

    college.contact technologies.contact
    Universities (Research / Doctoral)

    schoolStudents

    university.email universities.email

    personFaculty (Ranked / Tenure-Track)

    professor.university professors.university

    co_presentLecturers (Non-Tenure Track)

    lecturer.university lecturers.university

    verified_userUniversity Verification

    university.contact technologies.contact
    Department of Technology

    account_balanceDepartment / Administration

    department.technology
    technology.email
    technology.contact

    groupsTechnology Personnel

    technology.email technologies.email

    verified_userVerification Services

    technology.contact technologies.contact

    computerMI Sandbox (System-Wide)

    For testing and development only

    principals.email teachers.email parents.email professors.colleges professors.university lecturers.college lecturers.university technologies.email technologies.contact universities.email colleges.email middleschools.email highschools.email elementaryschools.email academies.email
    Cross-Category Services

    shield_personGlobal Verification Endpoints

    school.contact
    college.contact
    university.contact
    teacher.contact

    mailCommunication Aliases (Global Patterns)

    parent.email
    students.email
    teacher.email
    professor.email
    principal.email
    lecturer.email
    faculty.email

    publicWeb / Infrastructure Roots

    elementary.school
    academy.email
    department.technology

    Production Domains

    Actively used for real communication, verification, and identity services.

    MI Beta Domains

    Sandbox environments for machine intelligence testing and development only — not used for live/production actions.

    Verification Model

    All .contact domains provide query-response verification (not browsable directories).

    Note

    All domains follow mandatory security standards: DNSSEC, SPF, DKIM, DMARC (reject), and registry lock.

    Domain Glossary

    What each domain does, grouped to match the map above.

    K–12 Schools

    elementary.school

    Standardized web-hosting root for elementary school sites and content management.

    elementaryschools.email

    MI sandbox mirror of the elementary school domain pattern, for testing only.

    highschool.email

    Verified alias domain for enrolled high school students.

    highschools.email

    MI sandbox mirror of the high school student alias pattern.

    middleschool.email

    Verified alias domain for enrolled middle school students.

    middleschools.email

    MI sandbox mirror of the middle school student alias pattern.

    teacher.contact

    Query-response endpoint confirming a teacher’s current, attested role.

    technologies.contact

    MI sandbox verification endpoint for testing automated vendor and technology lookups.

    teachers.email

    Verified communication alias for classroom teachers.

    technology.email

    Verified alias for a school or district’s operational technology staff.

    schools.email

    District-level alias for operational and administrative staff coordinating across school sites.

    principal.email

    Verified communication alias for a school’s principal.

    principals.email

    MI sandbox mirror of the principal alias pattern.

    parent.email

    Retired-never-recycled guardian alias used for verified guardian-school communication.

    parents.email

    MI sandbox mirror of the guardian alias pattern.

    academy.email

    Verified alias domain for charter and private academy communications.

    academies.email

    MI sandbox mirror of the academy alias pattern.

    school.contact

    Query-response endpoint confirming a school’s identity and current status — not a browsable directory.

    Colleges (Teaching / Community)

    college.email

    Verified alias domain for enrolled college students.

    colleges.email

    MI sandbox mirror of the college student alias pattern.

    faculty.college

    Verified alias for a college’s general teaching faculty.

    professors.college

    MI sandbox mirror of the college faculty alias pattern.

    professor.college

    Verified alias for an individually attested college professor.

    professors.colleges

    MI sandbox domain for testing cross-institution professor lookups.

    lecturer.college

    Verified alias for a non-tenure-track college lecturer.

    lecturers.college

    MI sandbox mirror of the college lecturer alias pattern.

    college.contact

    Query-response endpoint confirming a college’s identity and current status.

    Universities (Research / Doctoral)

    university.email

    Verified alias domain for enrolled university students.

    universities.email

    MI sandbox mirror of the university student alias pattern.

    professor.university

    Verified alias for ranked, tenure-track university faculty.

    professors.university

    MI sandbox mirror of the university professor alias pattern.

    lecturer.university

    Verified alias for a non-tenure-track university lecturer.

    lecturers.university

    MI sandbox mirror of the university lecturer alias pattern.

    university.contact

    Query-response endpoint confirming a university’s identity and current status.

    Department of Technology

    department.technology

    Root administrative domain for the Department of Technology.

    technology.contact

    Query-response endpoint confirming the Department of Technology’s identity and its personnel.

    technologies.email

    MI sandbox mirror of the technology-personnel alias pattern.

    Cross-Category Services

    students.email

    Global verified alias pattern for students, used across all institution types.

    teacher.email

    Global communication alias pattern for teachers across all institution types.

    professor.email

    Global communication alias pattern for professors across all institution types.

    lecturer.email

    Global communication alias pattern for lecturers across all institution types.

    faculty.email

    Global communication alias pattern for general faculty across all institution types.

    history
    Proposed Special Area Code Concept A three-digit prefix — 111 for institutions, 222 for teachers and principals, 333 for operational staff, and the 444/555/777/999 block for students — carried role and population directly in the address itself, removing the need to cross-reference a separate directory just to know whether a sender was a district office, a credentialed educator, or an enrolled student. The reserved 199–899 sandbox block served the same purpose for machine intelligence testing: developers could build and test MI tools against realistic-looking identifiers without any risk of touching live student or staff communication.

    K–12 National Numbering Plan & Parent Recycling Protocol

    Legacy Five-Tier Area Code Structure (Pre-V5 Draft)

    Production tier
    Reserved — MI sandbox

    account_balanceInstitutions & Agencies

    111

    Assigned to the institution itself (district, state, or federal agency), not an individual. Local districts use their 7-digit NCES Federal District ID; agencies use a 2-digit Federal State ID. This tier explicitly includes the Department of Technology, utilizing the 111 prefix.

    Associated domain:department.technology

    cast_for_educationClassroom Teachers & Principals

    222

    Classroom teachers and principals, split across @teachers.email and @principals.email, built from a state ID plus the educator’s state-issued credential number.

    Associated domains: teachers.email principals.email

    groupsClassified & Operational Staff

    333

    IT, facilities, human resources, and paraprofessional personnel — e.g. @lausd.schools.email.

    Associated domain:schools.email

    schoolK–12 Students (Primary Pool)

    444 555 777 999

    A unified student block, backed by six expansion pools, for a total capacity of roughly 80,000,000 identifiers against about 54.6 million enrolled U.S. students.

    Associated domains: highschool.email middleschool.email elementary.school

    Expansion pools

    499 599 799 488 588 788

    computerReserved — MI Research & Development

    199 299 399 699 799 899

    A non-colliding sandbox that mirrors the production tiers, so developers can test MI-driven tools without any possibility of touching live school communication.

    flag
    MI Research area codes can be released into K12 Primary pool if needed.

    family_restroomParent Identity Recycling Protocol

    e.g. [email protected]

    Parents and guardians bring their own verified mobile number as their handle. This is a human-facing mail identity for school parents. Once their child graduates high school, the email is recycled for future use by other parents — unless the parent still has a younger, not-yet-school-aged child, in which case the address is retained for that pending enrollment.

    Associated domain:parent.email

    Status

    This structure is retained here purely as a historical reference for how the tiering concept originated. The currently proposed architecture is the four-layer model in White Paper V5, Section 5 (identity anchor, attestation layer, alias layer, relationship layer), which keeps the same five population tiers as an organizing pattern (Section 5.2) but does not assign them specific numeric prefixes or use a reassignable national number.

  • 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.

  • Risks We Took Seriously — And How We’re Addressing Them

    Version 5 of the white paper incorporates the findings of an external red-team review conducted against the prior draft. Each identified risk is paired with who is likely to raise it and the specific mitigation now built into the architecture.

    • Identifier reassignment could misdirect sensitive communication to the wrong person — mitigated by retiring, never reissuing, identity anchors and parent aliases.
    • A centralized breach target would concentrate an entire population’s identity data — mitigated by a federated model where the national layer holds only short-lived attestations, and personal data stays with local systems of record.
    • Directory enumeration would turn a browsable list of verified educators into a target list — mitigated by query-response verification only, rate-limited to prevent scraping.
    • Guardianship and custody changes are common and were unaddressed in earlier drafts — mitigated by a separate, mutable relationship/authorization layer.
    • MI agent overreach would create a new insider-threat class — mitigated by scoped, short-lived, human-revocable credentials.
    • Perception as a national tracking database — mitigated by explicit statutory scope limits, sunset and oversight clauses, and consistent public framing as an interoperability standard, not a database.
    • Vendor lock-in via domain ownership — mitigated by a public-trust or licensing structure for domains, overseen by a multi-stakeholder body.
    • Unfunded mandate resistance — mitigated by strictly opt-in participation, a phased pilot, and an explicit funding-model proposal.

    Publishing the risks alongside the mitigations, rather than only the finished architecture, is intentional — it’s the same standard the framework asks legal reviewers and pilot districts to hold it to.

  • Costs, Governance, and the Road to Pilot Programs

    Costs Are Hypothesized, Not Assumed

    The white paper is explicit that any future ROI or savings projection must come from real pilot data and should never be presented as established fact before that data exists. Hypothesized benefit categories — reduced breach costs, reduced help-desk burden, faster emergency response — are named as things to be measured, not claimed in advance.

    Governance With Built-In Limits

    The proposed multi-stakeholder oversight body sits at a national layer while local and institutional systems remain the system of record for day-to-day identity issuance, attestation, and revocation — preserving the local control emphasized throughout the framework. Critically, the oversight body’s authority and the registry’s scope are proposed to be subject to periodic legislative or regulatory review, not open-ended by default.

    A Phased, Opt-In Path Forward

    Policy recommendations call for establishing the Contact Initiative as a voluntary interoperability standard endorsed — not mandated — by federal education authorities, preserving state and local control. Any adopting state or district would be required to complete the open legal-review items before handling real student data, and initial pilots would be funded through a competitive grant mechanism rather than an unfunded mandate, with results published regardless of outcome.

  • Rebuilding School Communities After Wildfire Displacement

    The Challenge

    Following a wildfire, residents of a single neighborhood are displaced to a nearby, overwhelmed county. Parents face re-enrolling their children in an unfamiliar school district while managing insurance claims and housing logistics. Without a unified system, information sharing is fragmented, and children risk being separated from their existing peer groups during a high-stress transition.

    The School Contact Solution

    The same retire-never-recycle guardian alias used to defeat phishing attacks also simplifies this transition. Displaced parents use their existing verified guardian aliases to coordinate with the receiving school and with one another.

    • Coordinated enrollment — because each student’s identity anchor is already linked to their guardian’s alias, a whole group of neighborhood families can independently enroll their children at the same receiving school, with the registrar verifying each family’s guardianship attestation.
    • Real-time information loop — a verified channel delivers authenticated district updates, while a separate parent-to-parent channel — never conflated with the school’s own broadcast alias — lets neighbors share transportation and housing information.
    • Continued peer connection — because each student’s identity anchor persists and is never reassigned, children can keep reaching established classmates through existing aliases after relocating, with no new accounts and no lost history.

    Demonstrates the relationship layer linking guardian and student identity anchors, and the persistence-without-reassignment principle at the center of the whole architecture.

  • Coordinated Emergency Response with Verified Communication

    The Challenge

    A coordinated incident begins at a large, multi-building high school campus. In a traditional environment, the first moments are defined by chaos: frantic calls from unverified numbers yield conflicting reports, staff struggle to trigger building-wide alerts, and first responders arrive without knowing which areas are secured.

    The School Contact Solution — With Caveats

    This scenario illustrates how the architecture’s reasoning could extend to emergency response, and it’s presented with more caveats than any other in our scenarios collection: real-time proximity or location sensing of students is a significant, separate capability the white paper does not currently specify, and it would require its own dedicated privacy, security, and legal review before any real deployment.

    • A staff witness places a call using her attested operational-staff alias to the school’s verified institutional line.
    • A pre-scoped, human-configured emergency grant — not a discretionary decision made in the moment — lets the MI assistant act only when a call originates from a verified alias and specific trigger language is used.
    • Once triggered, the assistant issues an authenticated, campus-wide alert, notifies the assigned officer, and relays verified caller and location data to 911 — every step logged for later review.
    • Any device-based, opt-in proximity capability is flagged as requiring its own separate consent model, strict retention limits, and independent privacy review before it could ever be built.

    Responders arrive with verified, authenticated information about where the alert originated and what has already been communicated — without this document making any claim about detecting, tracking, or neutralizing an intruder, which fall outside the scope of an identity and communication framework.

  • Cross-State Enrollment Without the Paperwork Flood

    The Challenge

    A family relocates across state lines, and a receiving district needs to confirm a student’s enrollment history, grade level, and any applicable accommodations before placement — usually a slow, paperwork-heavy process that can leave a student in limbo for weeks while records requests move between districts.

    The School Contact Solution

    Because the student’s identity anchor and its attestations persist across the transfer, the receiving district can submit a scoped query confirming current enrollment status and — flagged as one of the open legal-review items in the white paper’s appendix — any applicable accommodation status, alongside confirmation from the relationship layer that the accompanying adult currently holds guardianship rights.

    Within seconds rather than weeks, the attestation is returned and independently verifiable, without either district needing standing access to the other’s underlying student records. The student can be seated in the correct classroom on day one, and the paperwork that would otherwise need to survive a records flood becomes unnecessary for the initial placement.

    Demonstrates the federated attestation model replacing a centrally issued national number and the relationship layer’s guardianship confirmation, consistent with the open legal questions on cross-state data sharing.

  • Stopping a Phishing Attack Before It Starts

    The Challenge

    A phishing campaign targets parents at a local high school. Bad actors send SMS messages and emails spoofing the school’s branding, claiming an active emergency and demanding a “transportation fee” to safely bus students to a reunification site.

    The School Contact Solution

    Under School Contact, the attack fails structurally rather than depending on parents noticing something is wrong. Every domain the district uses carries the mandatory email-authentication baseline — DNSSEC, SPF, DKIM, and enforced DMARC — so a spoofed message impersonating the district’s domain simply doesn’t deliver as genuine mail. The district pushes an authenticated, one-way broadcast confirming the earlier messages were fraudulent.

    Because parents communicate using their retired-never-recycled guardian alias, the school’s system can check any inbound reply against the relationship layer — confirming both that the alias is active and that the sender currently holds guardianship rights for a specific enrolled student — before treating it as trusted. And because the verified channel was never publicly browsable, it was never a target the attackers could spoof in the first place.

    Demonstrates the domain security baseline, the retire-never-recycle guardian alias policy, and query-response verification working together against a real attack pattern.

  • From Chaos to Clarity: Fixing a District’s Vendor Bottleneck

    The Challenge

    At a mid-sized K–12 district, the IT department wakes up to a flood of help-desk tickets: hero images aren’t displaying on any school homepage. In a legacy system, the web administrator would have to log into a dozen disparate content management systems, verify credentials for each school’s sub-vendor, and troubleshoot each domain individually.

    The School Contact Solution

    The district has unified its digital presence under the elementary.school hosting root. The lead web administrator logs in using their identity anchor, attested to the “Classified & operational staff” tier, and reachable at their institution-issued alias. Because the attestation layer is federated across the district’s hosted sites, this single verified login grants scoped, logged access to the hosting environment — not standing access to every system the district owns.

    The administrator traces the outage to a third-party design plugin’s faulty overnight update. Instead of hunting for the vendor’s current contact information, they submit a query-response verification request confirming the vendor’s registered support channel — a confirm/deny lookup, not a browsable listing. The vendor, seeing a digitally signed request from an attested sender, pushes a rollback patch. The hero images are restored across every elementary school site within minutes.

    Demonstrates the alias/attestation pattern and query-response vendor verification, not a browsable directory.

  • Building an Accessible System for Every Family

    Because the Contact Initiative is proposed as infrastructure that every parent, student, and educator must be able to use — not an optional convenience layer — accessibility is treated as a design requirement, not an enhancement to add later.

    • All public-facing verification and directory interfaces should conform to WCAG 2.2 AA at minimum, consistent with Section 508 obligations.
    • Alias-based communication should support non-email channels, such as SMS-based verification, for households without reliable email or broadband.
    • Verification and recovery flows should not assume a smartphone, a specific browser, or continuous internet access; a low-bandwidth, assisted in-person recovery path through a school registrar should always exist.
    • Materials and interfaces should be available in the languages a district or institution already serves, consistent with Title VI obligations.
    • Any biometric or novel authentication mechanism should be evaluated for disparate accessibility impact before adoption, not after.

    None of this is presented as solved. It’s presented as a checklist the architecture is required to satisfy before any real deployment — the same standard the white paper applies to legal compliance and cybersecurity.

  • Privacy, FERPA, and COPPA: What Families Should Know

    This section of the white paper does not provide legal advice, and nothing in it should be read as a completed compliance determination. Every mechanism described is a proposed approach, offered for review by qualified counsel and the relevant regulators before any pilot handling real student or family data proceeds.

    FERPA

    FERPA governs both halves of the initiative, in different directions. K–12 School Contact is designed around FERPA’s district-defined, opt-out directory-information framework. Higher-education College and University Contact treat the adult student as the default rights-holder, consistent with FERPA’s transfer of rights at eighteen or postsecondary enrollment.

    COPPA

    COPPA is proposed to be addressed in K–12 through a front-end tokenization pattern, so vendors receive a scoped token rather than a student’s actual identity or record — offered as a mitigation pattern requiring review against COPPA’s specific verifiable-parental-consent requirements, not a claim of current compliance.

    IDEA, Section 504, ADA, and State Law

    A national student-identity system will necessarily touch special-education status and accommodation records for some students, and this paper flags that IDEA, Section 504, and the ADA apply and have not yet been reviewed against the proposed architecture. State student-privacy laws vary and are often stricter than federal law, so any national architecture must accommodate the strictest applicable state requirement in a given jurisdiction — a significant open design question. See our FAQ for more.

  • Cybersecurity by Design: The Contact Initiative Approach

    The Contact Initiative treats cybersecurity as an infrastructure-level property, not an add-on, through a defined set of controls:

    • Verified, role-based identity for every user, separate from any reassignable number.
    • Zero-trust access to the resolution layer — no standing access for any relying party, vendor, or MI agent.
    • Non-enumerable, rate-limited query-response verification, preventing bulk scraping of the identity graph.
    • Mandatory DNSSEC, SPF, DKIM, and enforced DMARC on every issued domain.
    • Aliases that hide the administrative address, shrinking the target for spear-phishing.
    • Scoped, short-lived credentials for vendors and MI agents instead of raw record access.
    • Persistent, tamper-evident logging at both the institution and national-registry level.
    • Mandatory dual control for high-impact actions like bulk data export or identifier retirement overrides.
    • A public security-disclosure and bug-bounty commitment for the registry and its reference implementation.

    That vendor-focused control matters most: reported research indicates a majority of disclosed K–12 breaches trace back to a compromised vendor, not the district itself. Tokenized, scoped, short-lived vendor credentials are aimed squarely at closing that pathway.

  • Machine Intelligence and the Future of School Communication

    Consider a simple instruction given to an MI assistant: “Email my professor about the extension.” Without reliable identity infrastructure, the system has to guess which course, which professor, which section, and whether the requester is even enrolled — and it sometimes guesses wrong.

    Why “MI,” Not “AI”

    The Contact Initiative deliberately uses Machine Intelligence (MI) instead of Artificial Intelligence (AI) wherever reasonably possible, to describe capability that operates strictly within a human-governed structure — able to act only after a person or institution is verified, and only within limits a human governance body has set and can revoke at any time.

    How the Authorization Layer Works

    Before an MI assistant can act, it must request a scoped grant limited to the specific task at hand — never standing access to a person’s full academic or communication record. If a request is ambiguous, a human-approval threshold is triggered and the assistant asks for confirmation instead of guessing. Every credential is short-lived, and every action is logged for audit.

    This is also the foundation for the Machine Intelligence Assistant (MIA) — a proposed persistent, personalized tutoring and mentoring assistant for students and researchers, operating entirely within these same scoped, revocable, and auditable boundaries.

  • How Aliases Protect Students and Parents from Phishing

    Earlier drafts of the Contact Initiative imagined a public, browsable directory where anyone could look up a verified teacher or administrator. Review identified an obvious problem: a browsable list of every verified educator in the country is also a ready-made target list for harassment.

    Query-Response, Not Browsable

    Version 5 replaces the browsable directory with query-response verification. A relying party submits a specific claimed identity — “is this person currently a teacher at this school?” — and receives a confirm or deny answer, rate-limited to prevent bulk scraping. This preserves the entire anti-phishing benefit of the original idea while removing the enumeration risk.

    Aliases That Can Be Replaced Without Losing Identity

    Institution-issued aliases follow role-based, human-readable patterns and can be rotated or reissued at any time without affecting the underlying identity anchor or its attestation history. A compromised or leaked alias can simply be retired and replaced — no loss of identity continuity, and a much smaller practical target for spear-phishing.

    A Non-Negotiable Security Baseline

    Every domain issued under the Contact Initiative — production or sandbox — is proposed to carry DNSSEC and registry lock to prevent hijacking, enforced SPF, DKIM, and DMARC with a reject policy to stop spoofed mail from delivering as genuine, and a published, cryptographically signed list of real Contact Initiative domains so relying parties can spot look-alikes.

  • The Four-Layer Identity Model, Explained

    Earlier drafts of the Contact Initiative proposed a single, centrally issued national identifier — a ten-digit number assigned at enrollment and later released back into a national pool for reassignment. Technical and legal review flagged two serious risks: a reassigned identifier can carry forward old associations, and a single national identity store is one high-value breach target for an entire population’s personal data at once.

    Version 5 replaces that design with a federated, four-layer model that delivers the same fast lookup and clear tiering — without either risk.

    The Four Layers

    • Identity anchor — a locally issued, opaque identifier for each person, controlled by the state or district (K–12) or institution/federation (higher ed). Never reused — retired and archived instead.
    • Federation / attestation layer — short-lived, cryptographically signed claims (“this anchor currently maps to an enrolled student”) held by the national registry. No bulk personal data.
    • Alias layer — the human-facing address people actually use day to day, freely rotatable without touching the anchor beneath it.
    • Relationship / authorization layer — a mutable table of who currently holds guardianship or delegated authorization for a given anchor.

    This separation is what lets the system handle situations the old single-number model couldn’t: a custody change becomes an update to the relationship layer, not a reissued child identity; a name change updates the alias without disturbing the anchor; and one person — say, a parent who is also a graduate instructor — can hold multiple independently scoped attestations under a single anchor.

  • Why American Schools Need a Verified Identity Layer

    The United States runs the largest and most decentralized education system in the world — roughly 13,000 K–12 school districts and several thousand colleges and universities, each building its own communication and identity infrastructure independently, platform by platform. No shared layer of verified identity connects any of it.

    The result shows up in ordinary moments that should be simple. A parent can’t always confirm that a message claiming to be from their child’s teacher is genuine. A receiving school can’t instantly verify a displaced student’s enrollment history. A voice assistant or classroom MI tool has no authoritative way to resolve an instruction as basic as “email my teacher.”

    Not Just an Inconvenience

    This fragmentation is the underlying condition that makes phishing, impersonation, shadow IT, and slow emergency response possible at scale across American education. Reported industry research indicates that a large majority of K–12 schools have experienced a cybersecurity incident in recent years, and that most publicly disclosed K–12 breaches trace back to a compromised vendor rather than the district itself.

    Beneath the statistics sits a simple structural gap: no unified framework exists to verify the identity of a sender in K–12 communication. A phishing email can convincingly imitate a district’s branding. A caller can claim to be a parent with no way for office staff to check the claim. A bad actor can register a fake teacher-style address and message students directly.

    School Contact proposes treating identity — for students, parents, teachers, and administrators alike — as shared infrastructure: persistent, verifiable, and portable across every transition in a person’s path through the education system. Read the full architecture in our White Paper Overview.