clearAMS / Privacy Policy
clearAMS — Privacy Policy
Version 1.2 Effective date: October 28, 2026 for districts that join from that date; November 27, 2026 for districts that accepted an earlier version Last updated: October 28, 2026
Version 1.2 states the backup cycle in § 8 as thirty-five (35) days, which is how long our encrypted off-site backup copies are kept. Version 1.1 added the in-app help assistant to the AI purposes in § 6, and described the sign-in records and the administrator browser identifier in § 3.1.
This policy covers clearAMS as offered to any California local educational agency. It is the only privacy policy clearAMS is offered under.
The short version
clearAMS is built by Pulse Pedagogies, LLC, a California limited liability company, for California local educational agencies planning Proposition 28 arts and music expenditures.
- We hold no student data of any kind. Not names, not identifiers, not records, not enrollment, not demographics. This is a permanent design commitment, not a current state. The only figure about students is the number a program serves, kept as an aggregate count.
- We store no passwords. Sign-in is through your district's own Google accounts, or a one-time code emailed to your work address.
- We sell nothing, advertise nothing, and track nothing across sites.
- Our intelligence engine never trains on your district's data. That is in our Terms of Service, not a setting.
- Every district signs a data privacy agreement with us.
- Your district owns its data and can export all of it at any time.
The detail follows.
1. Who we are and what this covers
This policy covers the clearAMS platform, the clearams.app website, and the documents clearAMS generates.
Data controller / business: Pulse Pedagogies, LLC 1325 Valley View Rd., Suite 205, Glendale, CA 91202 · support@clearams.app
Our customers are public agencies. For most purposes the district is the owner and controller of the information in its account, and Pulse Pedagogies acts as a service provider processing it on the district's instructions.
2. No student data — the commitment
clearAMS does not collect, receive, store, transmit, or process student records of any kind, including: student names or identifiers; enrollment, attendance, or discipline records; grades, assessment, or transcript data; demographic or special-population indicators; IEP or health information; or student-generated content.
clearAMS plans at the level of allocations, positions, line items and narratives — not at the level of individual students. A plan records the number of students a program serves as an aggregate count, which is not a record about any student.
What this means legally
Because no pupil records are involved, the statutes that govern student data largely do not reach clearAMS:
| Law | Why it doesn't apply |
|---|---|
| FERPA (20 U.S.C. § 1232g) | We receive no education records. |
| California Ed. Code § 49073.1 (AB 1584) | Governs contracts for services handling pupil records. We handle none. |
| SOPIPA (Bus. & Prof. Code § 22584) | Applies to operators of sites used for K–12 purposes that collect covered student information. We collect none. |
| COPPA (15 U.S.C. § 6501) | Not directed to children; no information collected from children. |
| PPRA | No student surveys or evaluations. |
Every district signs a data privacy agreement. We sign the California Student Data Privacy Agreement (CSDPA), or a district's comparable agreement, with every district as part of onboarding (Terms of Service, Section 15). Signing it does not imply that any student data is collected.
Keeping it true
If the District enters student personal information into a free-text field anyway, that is outside intended use. Tell us at support@clearams.app and we will work with you to remove it.
3. What we actually collect
3.1 From district staff
| Category | Examples | Why |
|---|---|---|
| Identity | Work email address, name as provided by Google sign-in or as set by your district administrator, district affiliation, role | To authenticate you and attribute plan decisions |
| Authorization | Your presence on the district's approved list, role and permissions | To decide what you may see and do |
| Activity | Review notes, comments, approvals, rejections, edits, version history, School Site Council dates | The audit trail — this is the product |
| Access records | When you were added to the approved list, when you first and last signed in, and who deactivated an account and why | So your district administrators can see who still uses clearAMS and remove access that is no longer needed, including automatically after a period without signing in if the district turns that on |
We collect no passwords. Authentication is either delegated to Google or done by a one-time sign-in code emailed to your work address. We store only a hash of each code, never the code itself; a code works once and expires after ten minutes. Where a district uses emailed codes, the name that appears on your signature is the one your district administrator recorded for you, and you cannot change it yourself.
Cookies in the application. Signing in sets one cookie, which holds your session and ends when it expires or you sign out. A district administrator's browser also gets a second cookie holding a random identifier; we keep only a hash of it, so that we can email the administrator when their account is signed in to from a browser it has not used before. Neither cookie is used for anything else, and neither is shared.
A district administrator also holds an administrative key for their district. We store only a salted hash of it — PBKDF2-HMAC-SHA256, 200,000 iterations, with a random 16-byte salt generated per key — never the key itself. We cannot recover or display it; a lost key is replaced by issuing a new one.
3.2 District planning content
Plan lines, narratives, amounts, allocations, expenditure totals, waiver records, signature records, and generated plan documents and record copies. This is district business information, not personal information. Funded positions are recorded by role and total cost, never by the name of the person who holds them.
3.3 Technical data
The application server writes two kinds of log, both read out of the code rather than assumed:
- Request log. One line per request: time, method, path including any query string, response status and size, the referring page, and the browser's user agent. It records the address of the network hop that delivered the request, which is our own edge infrastructure, not your device.
- Application log. Warnings and errors. Some name the staff account involved — for example, which administrator released a lock — so this log can contain a work email address. It never contains plan content.
Logs are held by our hosting provider for a short operational retention period set by that provider's plan, and are used only for security and debugging. They are not exported, sold, or used for any other purpose.
3.4 The clearams.app marketing website
The public marketing site is deliberately minimal:
- No cookies are set.
- No analytics or tracking of any kind. No Google Analytics, no tag manager, no pixels, no session recording.
- No accounts. Browsing the site requires none.
- The contact form sends what you type (your name, work email, and optionally your district, role and message) to our server, which stores it and forwards it to our support mailbox by email. We do not store your IP address or browser details with it. We delete the stored copy two years after you sent it. Our replies, and anything you send us by email, sit in our support mailbox and are governed by its own retention. If our server cannot be reached, the form falls back to composing an email in your own mail client.
- Hosting: Cloudflare (Workers static assets). Cloudflare processes request metadata, including IP address, as part of serving and protecting the site.
- Typefaces are served from clearams.app itself. No font, script or stylesheet is requested from any third party.
- Video walkthroughs: the product walkthroughs are served from clearams.app itself and play in your browser. No third party is involved and nothing is requested from one, whether or not you press play. Captions are served from clearams.app as well, and are on by default. The video file is only downloaded if you press play.
3.5 Signing up and claiming a district
A district's space on clearAMS is created only after a person at that district asks for it and a person at Pulse Pedagogies verifies the request. To make that possible we collect:
| Category | Examples | Why |
|---|---|---|
| Registrant | Name, work email, role, your LEA, and your acceptance of the Terms and this policy (with version and time). Collected from everyone who signs up, whether or not they claim a district | To create the request or account and contact you about it |
| Role evidence | A link to a staff directory, organisation chart or board document naming you; your LEA's employment-verification service; or an HR contact's name and work contact details | So we can confirm you hold a district-level role |
| Decision | Who at Pulse Pedagogies decided, when, the channel used to verify, and a short note | The record of why a district's space was handed to a particular person |
How verification works. We confirm a claim through a channel we look up ourselves, such as the district's public website or the main number in the California Department of Education's directory. We do not rely on contact details the registrant supplied. If you name an HR contact, we may contact them only to confirm your role.
How long we keep it. Role evidence is kept until the request is decided plus ninety (90) days, then deleted, leaving only the decision record. A declined request's district space is removed at once; the record of the declined request (who asked, for which LEA, and the decision) is kept for two years. An approved claimant's details stay for as long as the district uses clearAMS, because they record who was given control of it. A sign-up that claims nothing is kept for two years after the person last signs in.
If your district already uses clearAMS, you can ask to join it. We send your name, work email and role to that district's administrators so they can decide; we do not add you ourselves.
Inviting your district. Staff who cannot claim a district themselves (for example teachers) may name a district contact. We send that person one invitation email naming who suggested it, and keep a record of the suggestion (your name and email, the contact's name and work email, the LEA, and dates) so we can follow up. We do not add the contact to any mailing list. If that district later joins clearAMS, the person who suggested it is offered to the district's administrator as a pending user, with no access until the administrator confirms them. Tell us at support@clearams.app to have a suggestion deleted.
Practice districts. A practice district holds only the fictional sample district. Nothing you do in it is saved; we keep only your account and when you signed in. It is deleted after thirty (30) days without use.
Public school data. School names, CDS codes, grade spans and Arts and Music in Schools allocations come from the California Department of Education's public files. We drop the directory's administrator names, emails and phone numbers when we read those files and never store them.
3.6 Billing
When a district requests an invoice we collect a billing contact (name and work email), the district's billing details, and an optional purchase order number. Invoices are issued and payments collected by Stripe (§ 7). If a district pays by card or bank transfer, it enters those details on Stripe's own payment page: we never receive or store card numbers or bank account credentials. We keep billing records for as long as the law requires us to keep business records.
3.7 What we never collect
Student records of any kind · passwords · bank account or payment card credentials (Stripe receives these directly, § 3.6) · Social Security or government identification numbers · requisition-level financial transactions · precise geolocation · biometrics.
4. How we use information
We use it only to: provide and operate clearAMS; authenticate users and enforce the district's access rules; produce plans, checks, evidence and exports; maintain the audit trail; secure the service and investigate abuse; provide support; comply with law; and — in aggregated, de-identified form — understand product usage.
We do not sell personal information, share it for cross-context behavioural advertising, use it for advertising, or use district content to train machine learning models.
5. Google integration
clearAMS depends on Google in three distinct ways. District IT teams review this section most closely.
5.1 Sign-in
Staff authenticate with district Google accounts through Sign in with Google. clearAMS requests only the openid, email and profile scopes, and receives an email address, name, and a stable account identifier. We never receive your Google password. A valid Google sign-in alone grants no access; the person must also be on the district's approved list.
5.2 Google Drive
Generated plan documents and decks are written to your district's own Google Drive, under your Workspace's sharing rules and retention policies. They are your files in your tenancy.
clearAMS requests no Google Drive access. Documents are created by a Google Apps Script that your district deploys and runs under its own account. clearAMS sends plan content to that script; the script creates the file in a folder your district chose. The permission to write into your Drive is granted by your district to its own script, inside your Workspace, and clearAMS never holds it.
5.3 Limited Use commitment
clearAMS's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Specifically, we use Google user data only to provide and improve user-facing features of clearAMS; we do not transfer or sell it for advertising, credit assessment, or lending; we do not use it to train generalised AI or ML models; and humans do not read it except with your explicit consent, for security purposes, to comply with law, or on aggregated and anonymised data for internal operations.
6. AI processing
clearAMS uses Google Gemini for a defined set of purposes. All but the last are about the content of expenditure plans. Each is listed below with what is sent for it. Nothing is sent to the model for any purpose not on this list.
| Purpose | What is sent |
|---|---|
| Checking line items for allowability and quality | The line items under review, and any district waiver that applies |
| Answering "is this purchase already in the plan?" | The wording and amount of the plan's line items |
| Reconciling a site's plans across fiscal years | The plan records for those years, with identifying fields removed |
| Projecting a following year from a filed plan | The filed plan, with identifying fields removed |
| Drafting balance notes for a site | The plan as it stands, with identifying fields removed, and the year's figures |
| Judging whether a revision answered a reviewer's request | The reviewer's comments and the before/after wording of the lines they named |
| Transcribing an existing plan document a district uploads | The document — see below |
| Drafting correspondence to a site principal about their plan | The changes made, and the principal's name, because the message is addressed to them |
| Answering questions in the in-app help assistant | Your question and the conversation so far; the district's tier, sign-in methods and our published prices. For a district administrator only, a summary of the district's account: tier, term dates, billing status, how many people are on its approved list in each role and how many have not signed in recently, its school names and setup checklist. No email address and no plan content is sent |
No student data is ever sent, for any purpose, because we hold none (§ 2). That is the commitment that does not move. The help assistant refuses a message that looks like it contains a student's record before anything is sent, and says why.
The help assistant cannot see your plans. It answers from our published guidance and the facts listed above. If you choose "Talk to a person" (paid tier), your message, name, role and district are emailed to our support mailbox; the conversation with the assistant is included only if you tick the box to include it. That email is not sent to the model.
Where district staff names are involved, and where they are not. For the purposes marked "identifying fields removed", the plan's principal name, submitter, signature record, comments and document links are stripped before the plan is sent. Two purposes do involve a name:
- Transcribing an uploaded plan document. A district's existing plan document is sent so its contents can be read into clearAMS. Where we can extract the document's text we send the text rather than the file, which keeps file metadata, authorship properties and any earlier revisions stored inside it from being sent at all. Some documents — scans in particular — cannot be extracted, and those are sent as the file. Either way, a plan document may name the site principal in its header or signature block, and the transcription reads that name deliberately, because it belongs on the plan record the district is importing.
- Drafting correspondence. An email to a site principal about their own plan is drafted with their name in it, because an unaddressed letter is not the deliverable. These drafts are produced only at the request of a district administrator who already has that information, and are reviewed by that administrator before anything is sent.
In both cases the person is district staff acting in a professional capacity, and the information is their name — not a personal record about them.
- The model's output is advisory, may be wrong, and fails open: if it is unavailable, plans can still be built, reviewed and submitted, and your own reviewer remains the backstop.
- The intelligence engine never trains on district data. This is a term of our Terms of Service (Section 6.7), not a setting, and no configuration or account option can turn it off. We use the Gemini API only on paid terms, under which customer content is not used to train or improve Google's models, and we never use a model key, including one supplied for a district, whose terms would allow it. We will provide that commitment in writing for a district's IT review on request.
- No automated decision with legal effect is made about any individual.
7. Subprocessors
| Subprocessor | Role | Location |
|---|---|---|
| Google LLC | Sign in with Google; Gemini, for the purposes listed in § 6 | United States |
| Render Services, Inc. | Application hosting, and storage of district data on a disk attached to the service | United States (Oregon) |
| Resend, Inc. | Transactional email: sign-in codes, account invitations, review notifications, notices to district administrators (new allocations loaded, spending-data reminders, a new administrator, a sign-in from a new browser, accounts deactivated for inactivity, the yearly reminder to confirm the approved list), sign-up and claim messages, and forwarding contact-form inquiries and "Talk to a person" requests to our support mailbox | United States |
| Stripe, Inc. | Invoicing and payment collection for paid terms: the district's billing contact, billing details, purchase order number and invoice amounts. Card and bank details are entered on Stripe's pages, never ours | United States |
| Cloudflare, Inc. | Marketing site hosting; DNS, TLS and request routing for district addresses | United States |
There is no separate database provider: district data is stored as files on the hosting provider's disk. clearAMS uses no third-party error monitoring, analytics or session recording. Document delivery is not a subprocessor relationship — it runs in your district's own Google Workspace (§ 5.2), under your district's agreement with Google.
The application serves its own scripts and typefaces. Apart from Google sign-in, a page of clearAMS makes no request to any third party.
We will give notice before adding a subprocessor that processes district data. All data is processed in the United States.
8. Retention and deletion
- While active: we keep district data for as long as the district uses clearAMS. The audit trail is the point of the product — it is retained across the full three-year Proposition 28 cycle and beyond.
- When a paid subscription ends: nothing is deleted. The district drops to the free tier; plans, dashboards, approval records and previously generated record copies stay readable and keep their status.
- On request: we will delete district data within thirty (30) days. Backups expire on their ordinary cycle within a further thirty-five (35) days. Export first — deletion is irreversible.
- Districts have their own records retention obligations. Ours do not replace yours.
9. Security
Per our published security posture: each district is resolved and isolated before any data access; sessions are scoped to a single district; administrator credentials are stored as salted hashes with no global fallback; a district with no administrator configured exposes no administrative surface; capabilities are enforced server-side rather than by hiding controls; storage is encrypted; and releases pass an automated check suite before deploy.
No system is perfectly secure. We do not guarantee absolute security.
Breach notification. If a security incident affects district data, we will notify the affected district without unreasonable delay and cooperate with its response, consistent with California Civil Code §§ 1798.29 and 1798.82 and any executed data privacy agreement, and in any event within 72 hours of confirming an incident affecting district data.
Vulnerability disclosure. A security contact and disclosure path are published at https://clearams.app/.well-known/security.txt.
10. Rights and choices
Districts may access, export, correct, or request deletion of their data at any time — export and restore are built in.
Individual staff should direct requests to their district first, since the district controls the account. We will support the district in responding. To contact us directly: support@clearams.app.
California privacy law. clearAMS is sold to public agencies for administrative use, not to consumers, and we act as a service provider to the district. We do not sell or share personal information as those terms are defined in the CCPA/CPRA. Pulse Pedagogies does not meet the CCPA's thresholds for a "business," and we do not rely on that for the commitments in this policy: they apply regardless.
Public Records Act. District data may be subject to CPRA requests. Responding is the district's responsibility; we will cooperate reasonably.
11. Children's privacy
clearAMS is a district administrative tool for employees. It is not directed to children, is not intended for student use, and collects no information from children. If we learn that a child's information has reached the service, we will delete it.
12. International users
clearAMS serves California local educational agencies and processes data in the United States. It is not offered to users in the European Economic Area, the United Kingdom, or Switzerland, and this policy does not address GDPR.
13. Changes
We will post changes here and update the date above. For material changes affecting district data we will give at least thirty (30) days' notice to district administrators.
14. Contact
Pulse Pedagogies, LLC 1325 Valley View Rd., Suite 205 Glendale, CA 91202 support@clearams.app