Security Overview

1. Infrastructure

Google Cloud and Vercel host in the United States and both maintain SOC 2 Type II certifications. EdLight, PBC has not specified a data processing location. Scanned student work is sent to EdLight for scoring and may contain handwritten student names. Schools contract with Precision Start only, and Precision Start remains responsible to the school for that processing.

2. Data Security

2.1 Encryption

• In transit: All traffic encrypted via TLS 1.2+ (HTTPS)
• At rest: AES-256 encryption via Google Cloud's default encryption

2.2 Database Access Control

• All database reads and writes flow through server-side API routes using the Firebase Admin SDK
• Firestore security rules deny all direct client-side reads and writes
• Student work files are served through signed URLs with time-limited expiration
• The client-side Firebase SDK is used only for authentication and file uploads to Firebase Storage

2.3 Authentication

• Every API request requires a valid Firebase ID token verified server-side
• Edge middleware rejects requests without valid authorization headers
• Teachers join schools through single-use, transactional invite codes
• Failed authentication attempts are rate-limited

2.4 Authorization

• Teacher access is scoped to their own school and their own classes
• Coach access is scoped to assigned classes within a school
• School Administrator access is scoped to their assigned school(s) only
• Platform Administrator access (Provider personnel) is limited to one individual

2.5 Multi-School Isolation

When multiple schools use the platform, each school's data is strictly isolated. Every API route that accesses school-scoped data validates that the requesting user has been granted access to that specific school. There is no path through which one school's staff can access another school's student data, assessment results, or intervention records.

3. Application Security

3.1 Security Headers

All HTTP responses include:

• X-Content-Type-Options: nosniff
• X-Frame-Options: DENY
• X-XSS-Protection: 1; mode=block
• Strict Referrer-Policy
• Restrictive Permissions-Policy (camera, geolocation, payment APIs disabled)
• Strict-Transport-Security (HSTS — max-age 1 year, includeSubDomains)
• Content-Security-Policy (restrictive allowlist; default-src 'self')

3.2 Rate Limiting

API endpoints are rate-limited per user or IP address:

3.3 Input Validation

All inputs are validated server-side using strict schemas. Database queries use parameterized operations (Firestore SDK). File uploads validate MIME types and file size limits.

4. AI Service Security

4.1 How identifiers are kept out of AI prompts

Direct student-identifier fields — a student's name, ID number, email address, or a parent's contact information — are not interpolated into AI prompts by design; the code assembles prompts from the de-identified fields in 4.2. Individual student demographic data is never sent alongside identifying information.

As defense-in-depth, all AI requests pass through a single client that applies an automated redaction layer before transmission: it strips email, phone, and SSN patterns, and — for requests generated in a group context — redacts that group's student names from free-text fields. Redaction is enforced centrally rather than by per-prompt convention. Name redaction is best-effort matching against the group roster, not a guarantee that every identifier embedded in free text is detected; the primary control is keeping identifier fields out of prompts.

4.2 What IS sent to AI services

• Tier classifications and instructional approaches
• Math standard codes and descriptions
• Misconception types
• Student counts per group
• Aggregate confidence scores
• Educator-authored instructional free text (e.g., academic-language notes, teacher lesson notes), passed through the redaction layer above before transmission

4.3 AI Provider Training Policy

Anthropic contractually commits that data submitted via its API is not used to train its models:

• Anthropic: Commercial Terms (Section 5)

4.4 Pseudonymization

The codebase includes a formal pseudonymization module that can replace student names with generic identifiers (S001, S002, etc.) and reverse-map them after processing. It is available for future features that would process student-level data at the AI boundary; the redaction layer in 4.1 is what runs on every request today.

5. Audit and Monitoring

5.1 Audit Logging

Every significant platform action is recorded in an audit log, including:

• Login and authentication events
• Report viewing
• Student tier overrides
• Unit publishing and unpublishing
• AI content generation and editing
• Student group moves and regrouping
• Checkpoint creation
• Unit processing and student work uploads
• School joins
• Gap detection and closure events
• Student profile creation

Each entry captures: who, what action, which resource, which school, and when. Logs are available to schools upon request.

5.2 Monitoring

• Firebase Authentication logs (built-in)
• Firestore audit logs (Google Cloud)
• Vercel deployment and function logs
• Application-level audit log
• Rate limiting alerts on unusual volume

6. Personnel and Administrative Controls

6.1 Access to Production

Access to production infrastructure is limited to the Provider's principal (Andre Aina). Access to Student Data is limited to personnel who require it to deliver the Service and who are bound by written confidentiality obligations; contractors with limited access (e.g., bright spots report QA) sign NDA and FERPA acknowledgments before any data access is granted. Our assessment scoring subprocessor, EdLight, PBC, receives scanned student work under our agreement with it, as described in Section 1 and the subprocessor list.

6.2 Backup Incident Commander

In the event the Principal is unavailable during a security incident, LeShae Daniel (Partner) is authorized to coordinate breach response and external communications until the Principal is reachable.

7. Compliance Status

8. Incident Response

In the event of a security incident, Provider commits to:

• Notify affected schools within 72 hours of confirmed breach (or sooner if required by applicable law)
• Provide a written initial notification, supplemented as the investigation proceeds
• Cooperate with the school in any required parent or regulatory notifications
• Deliver a written post-incident report within 30 days of resolution

See our complete Breach Notification Plan for procedural details.

9. Insurance

10. Vendor Review Cooperation

Provider welcomes school IT teams' security review processes. We are happy to:

• Complete vendor security questionnaires (HECVAT, SIG, custom)
• Provide additional technical detail upon request
• Coordinate penetration testing during pilot phase
• Review and respond to any specific concerns raised by your security team

Reviewing our Data Processing Agreement?

Our Data Processing Agreement (DPA) is provided directly to school and district leaders during the procurement process, not posted publicly. This allows us to ensure each agreement is reviewed by the correct contact at your organization and tailored to your jurisdiction's specific requirements.

To request a copy of the DPA for review by your general counsel or procurement team, contact:

Andre Aina, Principal
Third Eye Education Analytics LLC
andre@thirdeyeanalytics.org

Please include:

• Your school or district name
• Your role
• Whether your organization uses the SDPC National DPA framework or a custom DPA template

We will respond within 2 business days with the appropriate documentation.

Contact for Security Inquiries

Andre Aina, Principal
Third Eye Education Analytics LLC
andre@thirdeyeanalytics.org

For general counsel: please reference our Data Processing Agreement
For privacy questions: please reference our Privacy Policy