SCHOOL CONTACT

Category: Uncategorized

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