Skip to content

Security & privacy

Celia never sees a name.

Every other AI enrollment tool processes student PII in some form. CeliaConnect is designed so it cannot. This is not a policy commitment we could choose to break — it is a structural property of the system, verifiable by any technical review.

The analyses, under the microscope

What Celia sees (and what she doesn't).

CeliaConnect produces three structured analyses — Engagement, Readiness, and Yield. Each reasons on a narrow slice of anonymized signals. None of them receive PII. Ever.

Engagement

SS_CELIA_ENGAGEMENT

What Celia sees

Anonymized timestamps of logins, opens, clicks, form interactions, and outreach replies. Channel labels (email, SMS, portal), never the content of any message.

What Celia doesn't see

Who the student is. What the email said. Who sent it. Where the student lives.

Readiness

SS_CELIA_READINESS

What Celia sees

Stage transitions, milestone completeness, document-checklist states (submitted / missing / pending), days-in-stage against your institutional baseline.

What Celia doesn't see

Document contents. Essay text. Recommendation letter text. Transcript text.

Yield

SS_CELIA_YIELD

What Celia sees

Cohort code, program code, financial-aid package stage, historical conversion rate for the profile cluster, anonymized outcome labels for past cohorts.

What Celia doesn't see

Family income numbers. Household PII. SSNs. Bank account or routing numbers. Dates of birth.

The anonymization contract is enforced at the Slate Query definition (preventive) and again at the prompt boundary inside cc-celia (detective, fail-closed). The full hop-by-hop control mapping is in the next section.

What we ingest

Only patterns, never people.

  • Anonymous Slate internal IDs
  • Behavioral signals (engagement, milestone transitions, form interactions)
  • Milestone statuses (application stage, FAFSA, checklist completion)
  • Demographic categories — first-gen flag, in-state, program type
  • Engagement patterns — days since last activity, response velocity
  • Per-Org Data Dictionary (field names + institution-defined semantics)
  • Institutional baselines (median days per stage, historical yield by cohort)

What we never ingest

Under any circumstances.

  • Names (first, last, preferred, or any variation)
  • Email addresses
  • Phone numbers
  • Physical addresses
  • Social security numbers or government IDs
  • Dates of birth
  • Health or disability information
  • Financial account numbers or routing information
  • Essay content, personal statements, or recommendation letter text
  • Photos, biometrics, or video recordings

Architectural boundaries

Every hop. What crosses. What does not.

Every boundary has both a preventive control (we don’t pass PII) and a detective control (runtime guardrails fail-closed if a violation slips through).

  1. 01

    Slate institution → cc-slate-integration (CeliaConnect edge worker)

    Permitted
    Anonymized student IDs, non-PII fields (engagement timestamps, stage transitions, scores).
    Forbidden
    Names, emails, phone numbers, addresses, SSNs, DOBs, financial account numbers.
    Control
    Query contract enforced at the Slate-side service definition. Preview-and-block on first-time field detection.
  2. 02

    cc-slate-integration → cc-celia (AI analysis worker)

    Permitted
    Anonymized rows + per-Org Data Dictionary + institutional baselines.
    Forbidden
    Nothing beyond what passed the first hop. No re-identification possible on our side.
    Control
    Per-tenant D1 database. Runtime guardrail that rejects prompts containing PII-shaped values.
  3. 03

    cc-celia → Anthropic (Claude API)

    Permitted
    Anonymized content + system prompt (cached).
    Forbidden
    No student names, no counselor names, no institutional-identifying free-text.
    Control
    Programmatic prompt scrubber runs before every API call. Violations raise and fail closed.
  4. 04

    Anthropic → cc-celia (return path)

    Permitted
    Structured output (Risk, Recommendation, Engagement, Readiness, Yield, drivers).
    Forbidden
    Echoed PII, even if Claude were to somehow produce it.
    Control
    Return guardrail checks every response for PII patterns; flagged responses are discarded and re-generated.
  5. 05

    cc-celia → Slate institution (Source Format POST)

    Permitted
    Writes SS_CELIA_* fields to the correct student record by anonymous Slate ID.
    Forbidden
    Any echo back of fields outside the CeliaConnect writeback allowlist.
    Control
    Audit log records before/after value of every written field; weekly hash-chain anchor published to R2.

Data lifecycle

From first query to final deletion.

At rest

Per-tenant D1 database encrypted by Cloudflare. Slate credentials live in KV with envelope encryption — a per-tenant Data Encryption Key wrapped by a Cloudflare-held Key Encryption Key.

In transit

TLS 1.3 everywhere, between every hop. No plaintext egress.

During processing

Celia runs at Cloudflare’s edge. No persistent student data leaves the edge during analysis.

Audit

Every read and write is logged with actor, timestamp, before-value, and after-value. A hash-chain anchor is published weekly to R2. Customers can verify the chain independently.

Retention

Active customer data is retained for the life of the subscription. On cancellation: 30-day grace (in case of re-activation), then deletion — with a 7-year encrypted compliance archive in R2 per FERPA baseline. Adjustable per DPA.

Export

Customer-initiated export on demand, delivered as a signed, encrypted bundle.

Why it matters

Four architectural benefits.

01

FERPA posture is dramatically simpler

We don’t process education records with identifiable information. Most FERPA concerns don’t apply — the conversation shifts from "how do we comply while using this tool?" to "we’ve reviewed the architecture and there is nothing to comply with."

02

Breach blast radius approaches zero

If we were breached tomorrow, the maximum data an attacker could access is anonymous IDs and scores. No names. No emails. No way to identify or contact a student.

03

Security review shortens

Sales cycles for AI tools in higher ed are often delayed by 3–6 months of security and legal review. Our architecture removes most of those blockers. Institutions that need board approval for FERPA-processing AI can often approve CeliaConnect at the department level.

04

Exit is painless

If you leave, there is nothing sensitive for us to delete. Scores written back to Slate belong to you. We retain anonymous behavior history for our models that is meaningless to anyone else.

Compliance posture

Built for the audits that matter.

FERPA

Architecture aligned with FERPA Directory Information handling; no restricted student data ever touches CeliaConnect by design.

SOC 2 Type II

On roadmap. Preparation documented in internal ADR. Targeted within the first 12 months of paid operation.

GDPR / UK GDPR

Data minimization by design (no PII). Sub-processor list published. DPA template available.

CCPA / state privacy laws

No sale of data. No advertising. No PII collection. Minimized exposure by design.

See the full sub-processor list →

Security whitepaper

Need the details for your IT review?

A full-length technical whitepaper covers the guardrail implementation, key management, audit chain verification, incident response, and sub-processor flow. Join the waitlist to receive the current draft and future revisions as they ship.

Request the security whitepaper See our sub-processors

Report a vulnerability: solutions@zentrosoft.com. We acknowledge within one business day.

Join the waitlist

Be first in line when Celia opens.

Tell us about your institution and your Slate setup. We onboard waitlist members in order, one at a time, so every team gets a real human walkthrough — not a self-service trial that ends in frustration.

Join the Waitlist Talk to us first