CommonGage Data Inventory
Last updated: 2026-09-06
What CommonGage Does and Does Not Store
CommonGage is an operational platform for district staff. It does not store grades, attendance records, disciplinary records, IEPs, 504 plans, student SSNs, or any direct student academic records. The data model is designed for school engagement coordination by and for adults employed by the district.
Data Categories
1. District Configuration
| Field | Purpose | Sensitivity |
|---|---|---|
| District name, slug | Tenant identification | Internal |
| ClassLink TenantId | SSO mapping | Internal |
| Google Workspace domain | Maps a verified Workspace domain to the organization, so a staff member signing in with Google reaches the right tenant. A public email domain; no personal data. | Internal |
| Whether password sign-in is enabled | Lets an organization on SSO close the password path | Internal |
2. Staff User Accounts
| Field | Purpose | Sensitivity |
|---|---|---|
| Name, email address | Account identity | Moderate (staff PII) |
| Role (org_admin / zone_coordinator / building_staff) | Authorization | Internal |
| Zone/school assignment | Scope limiting | Internal |
| Password hash (PBKDF2-HMAC-SHA256, 100,000 iterations — a fixed application constant, embedded per-hash in the stored value so a future increase would not invalidate existing hashes) | Authentication | High |
| Last login timestamp | Security audit trail | Internal |
| ClassLink UserId | SSO mapping | Internal |
| Google account identifier | SSO mapping for Google Workspace organizations. The stable account identifier Google issues, not the email address — Workspace addresses get reassigned, and keying identity on one would hand a new hire the departed employee's account. | Internal |
Staff email addresses and names are the principal dedicated personal-data fields in the schema — this is standard for any district-deployed SaaS tool (equivalent to what a Google Workspace or Microsoft 365 tenant would hold for staff). Several free-text fields across modules (event descriptions, in-kind contribution attribution, deliverable and measure notes) are not structurally restricted from containing a name or other identifying detail a staff member chooses to type — see the free-text caveat under Calendar Events and Expense / In-Kind Records, below.
3. School & Zone Structure
| Data | Purpose | Notes |
|---|---|---|
| School name, code, level | School catalog | Mirrors district roster |
| Zone name, type | Organizational grouping | District-defined |
| Zone senior director | Records which staff member leads a zone | Reference to a staff user account |
| Zone engagement assignee | Records which staff member is assigned to a zone | Reference to a staff user account |
| Hub name, short name | Sub-zone grouping | District-defined |
| Board directors (name, role, contact info) | Leadership directory | Staff/leadership PII |
These two fields hold a reference to a staff user account, not a second copy of the person's name. A person can only be recorded as leading or assigned to a zone if they have a CommonGage account, and the name shown is read from that account at display time. Erasure therefore reaches these fields structurally: anonymizing the account changes what they resolve to, with no separate cleanup step and no dependence on matching a name as it was typed. Until July 2026 these were free-text name fields; they were normalized specifically so that erasure could not miss a spelling variant.
4. Calendar Events
| Field | Purpose | Sensitivity |
|---|---|---|
| Event title, description, location | Event catalog | Operational |
| Start/end datetime | Scheduling | Operational |
| Engagement type (AI-classified) | Analytics | Derived, no PII |
| Source reference (iCal URL) | Provenance | Internal |
Calendar events are sourced from school-provided iCal feeds. They represent community events, school activities, and engagement opportunities — not student records.
5. Deliverable Tracking
Status and notes for district-defined deliverables (e.g., site council completion, engagement plan submission) per school per academic year. Tracks completion status and staff-authored notes. No student data.
6. Engagement Support Records
Logs of Engagement Support (Family And Community Engagement) support interactions. Contains visit type, date, notes, and assigning staff — operational records for coordinator accountability.
7. Invite Records
Short-lived invite tokens for staff onboarding (7-day expiry). Contains invitee email, role, and whether the invite has been used. Deleted on acceptance.
8. Expense / In-Kind Records
| Field | Purpose | Sensitivity |
|---|---|---|
| Category, amount, in-kind flag | Cost and in-kind contribution tracking | Operational |
| Contributed by (free text) | Attribution for an in-kind contribution | Operational — free text, may name a person or organization |
| Notes | Staff-authored context | Operational — free text |
9. Goals & Measures (Goals & Measures module)
Tenant-defined measures, targets, and observations (derived from core operational data or entered directly by staff) tracked against a scope (zone or school) and reporting period. Contains a numeric value, a source label, and an optional staff-authored note per observation. No student data.
10. Tenant-Defined Site Attributes
Tenant-authored key/value pairs describing schools (e.g., a locally-defined site classification), replacing what were previously fixed schema columns. No personal data — typed attribute values scoped to a school.
11. Obligation Definitions, Schedules, and Records
Tenant-defined compliance requirements (e.g., a site-council submission), their due dates per reporting period, and per-school completion status with staff-authored notes and an optional evidence URL. No student data.
12. Tenant Vocabulary and Locale Configuration
Operator-set, tenant-read-only display-text overrides (e.g., a tenant's preferred label for "zone") and the tenant's default locale and currency. Display text only — never compared, keyed on, persisted elsewhere, or used in an authorization decision.
13. Erasure and Anonymization State
A single erased_at timestamp on the staff user record, set once by the erasure process and never cleared. It is the proof-of-erasure record itself — see Data Retention and Deletion Policy, "Staff Account Deletion," for the full mechanism.
14. Participants and the Person Directory (Participants module)
CommonGage also maintains a directory of non-staff participants — volunteers, board members, and any other tenant-defined category of person who takes part in the organization's activities without holding a CommonGage staff account. For each such person, CommonGage holds: their name, an organizational email address if one is provided, and their category affiliation (e.g. "Volunteer," "Board Member"), the latter set by CommonGage operations staff rather than by the tenant. There is no date of birth, age, grade, student identifier, or guardian field on this directory, and none may be added — this population is adults-only by construction, not by policy.
For a participant who self-attests their participation in an event, CommonGage additionally holds a self-reported hours figure, the derived attestation status (expected, recorded, attested, confirmed, or disputed — the last meaning the participant's self-reported figure differs from what staff recorded, and both figures are kept side by side rather than reconciled), and an optional free-text note.
Where a participant's category is a governance category (e.g. board member), their recorded and self-attested participation is retained as a public record under the same classification described in the Data Retention and Deletion Policy's "Staff Account Deletion" section, below. For every other category it carries no such retention obligation and is covered by the same erasure mechanism as a staff account.
Attestation tokens and RSVP tokens follow the same pattern as calendar feed tokens (see "Calendar Subscription Feed," below): the plaintext exists only in the one-time email link sent at generation, and only a SHA-256 hash is stored. They are single-use, time-limited bearer credentials for unauthenticated attestation and RSVP by people with no CommonGage account. Each token is scoped to a single participation record. Used tokens are marked but not deleted; expired tokens expire naturally.
15. Communications Records (Communications module)
CommonGage's Communications module tracks outbound press and outreach activity (press releases, mailer submissions, newsletter entries, BCC-captured email threads) and inbound media scan results (keyword-matched articles from automated web searches). For each record, CommonGage holds: a direction (inbound or outbound), a type label, a title, an optional summary, a record date, an optional source URL and source name, optional recipients text, optional linked event and site references, matched keywords (for inbound scan results), and optional tags. Outbound email records captured via the BCC-to-log path (log@commongage.com) additionally store a message ID, in-reply-to header, and thread ID for threading.
The module also maintains watch profiles — keyword sets that drive automated media scans. Each watch profile holds: a topic label, primary and variant search terms, monitored source domains, adversarial (exclusion) terms, a recency window, and a scan frequency.
Access to Communications data is scoped to Org Admins by default. An Org Admin may grant access to specific non-admin users; each grant records who granted it and when.
No participant, staff, or student data is stored in Communications tables. The module's data subjects are press outlets, media sources, and organizational communications — not people.
Data That CommonGage Does NOT Store
- Student names, IDs, or any student-identifiable information
- Grades, test scores, or academic records
- Attendance records
- Disciplinary records
- IEPs, 504 plans, or special education records
- Student SSNs or government-issued identifiers
- Parent/guardian contact information
- Student demographic data (race, ethnicity, socioeconomic status)
Calendar Subscription Feed
The optional, read-only iCal feed (see Security Overview, "iCal Subscription Feed") exposes a narrower slice of Calendar Events than an authenticated view does: event title, start/end time, and site name only. It never includes an event's description and never includes any participant. This is a deliberate minimization for an unauthenticated, forwardable URL — a person-grain roster or free-text description behind such a link is a materially worse exposure than a title, time, and site.
The token itself (see Staff User Accounts, "Password hash") is stored only as a SHA-256 hash, never as plaintext, in a table separate from the account it belongs to. A revoked token's row is retained, without its plaintext, as the record that it existed and when it stopped working — see Data Retention and Deletion Policy.
Data Flows
District Staff Browser
│
│ HTTPS (TLS 1.2+)
▼
Cloudflare Workers (API)
│ │
│ TLS (sslmode=require) │ HTTPS
▼ ▼
Neon PostgreSQL Anthropic API
(primary store) (event classification only;
no staff/student PII field —
see free-text caveat below)
▲
│ iCal fetch (HTTPS)
School-provided calendar URLs
Inbound email (BCC-to-log)
│
│ Cloudflare Email Routing
▼
Cloudflare Workers (API)
│
│ Parsed → mod_comms_entries
▼
Neon PostgreSQL
Anthropic data path: CommonGage sends event title, description, hub name, and engagement type to Anthropic for classification. No staff name, email address, site identifier, or participant data field is included in the prompt; because titles and descriptions are free text authored by the customer's own staff or drawn from the customer's calendar feeds, they may incidentally contain names or other identifying details the customer chose to write into an event's title or description.
Find ordering data path: where a model is configured, the Find screen sends the user's question as typed, plus the names of the collections and fields that user's role and licensed modules permit them to reach, to Anthropic — which returns a structured search to run, never an answer. No record from the database is sent on this path; a follow-up that narrows an existing search additionally carries the filter values from that user's own earlier questions. The returned search is re-checked against the caller's modules, role, and field permissions before it runs. Because the question is free text, it may contain whatever the user chose to type into it.
Communications media-scan data path (Communications module only): CommonGage sends the organization's name, its location where one was supplied, and the watch topic an administrator typed, to Anthropic — which returns search phrases, and then runs them as public web searches through Anthropic's server-side search tool. The organization's name and the administrator's topic are therefore disclosed to Anthropic and to the search infrastructure behind that tool. No event, participation, person, expense, or obligation record is sent. What returns is public media coverage — headline, link, publication, publication date, and an extract — stored as Communications records for staff review.
Email data path: The Communications module's BCC-to-log feature receives inbound email at log@commongage.com via Cloudflare Email Routing. Cloudflare routes the message to a Worker endpoint, which parses the sender, subject, date, message ID, in-reply-to, and body, and stores a structured Communications record. The email body is parsed for content; attachments are not stored. This path processes the email headers and body text that the sender chose to BCC — no personal data beyond what the sender included in the email.
ClassLink data path: CommonGage receives UserId, Email, DisplayName, and TenantId from ClassLink's userinfo endpoint at login time. These are stored in the staff user record. No other data is pulled from ClassLink.
Google Workspace data path: at sign-in, Google asserts the account identifier, email address, display name, and Workspace domain in a signed token. Those are stored in the staff user record. The flow is inbound only — CommonGage sends Google no organizational, event, or programme data, and nothing about what the person does after signing in. No directory, roster, or group data is read.
Data Location
All production data is stored in Neon's AWS us-east-1 region. Cloudflare Workers execute at the edge globally but hold no persistent data; all state is in Neon.
FERPA Assessment
CommonGage's primary data subjects are district employees, not students. The platform does not maintain an "education record" as defined by FERPA (20 U.S.C. § 1232g). Districts should confirm that any school calendar events ingested via iCal feeds do not include student-identifiable event details before connecting a feed.
If a district chooses to add student-identifiable fields to event descriptions in their iCal feeds, those fields would be stored by CommonGage and would constitute education records under FERPA. Districts are responsible for ensuring their iCal feeds comply with their data governance policies before connecting them to CommonGage.
This is the same free-text surface referenced in the Anthropic data path, above: event titles and descriptions are sent to the classifier as written, so a student-identifiable detail a district placed in an event description would reach both CommonGage's database and, via classification, Anthropic's API — reinforcing why district-side iCal hygiene is the operative control, not a CommonGage-side filter.