Your org's records, its money and its people. Here is exactly what happens to all of it.

Who we are, and who decides what

Two different parties are responsible for the data in a ChaptOS workspace, and telling them apart explains almost everything else on this page.

Your organization is the controller of its members' data. The chapter, team, club or council decides what to collect, which fields exist, who holds which seat, and how long records stay. It is responsible for telling its members what it collects and for having the authority to hold it.

We are a processor — a service provider. We store that data and compute over it on your organization's instruction. We do not mine it, sell it, profile anyone with it, or use it to build anything of our own.

Separately, we are the controller of a narrow set of our own: the Google account identity you sign in with, the email address on it, service logs, and the signals we use to stop abuse.

Organizations that need this in contract form — a data processing agreement with the sub-processor list in section 7 and a change-notice commitment — should ask us.

What we never do

Short list, and it is the plainest part of this page because every item is verifiable by inspection rather than by promise.

• We don't sell your data — and we don't share it for cross-context behavioural advertising, which is the specific thing California law gives people an opt-out from. There is nothing to opt out of here.
• We run no analytics or tracking. No Google Analytics, no PostHog, Mixpanel, Segment, Plausible or Vercel Analytics. No advertising pixels, no session recorders, no fingerprinting, no third-party cookies.
• We hold no payment instruments. Card and bank data never enters the product, so it can never leak from it. Your chapter’s own books have no processor behind them at all: “payment method” on a dues record is a word someone typed — venmo, cash,check. The one place real money moves is your subscription to us, and that is handled end to end by Stripe on their own pages — we store an identifier for your Stripe customer and nothing else.
• We don't train models on your data, and we have no model of our own. See section 6 for the precise position on the provider we call.
• We don't let one organization read another. See section 8.
• We don't email your members or contact them on your behalf. There is no mail-sending capability in the product.

What your organization keeps here

The complete inventory, grouped the way you'd actually go looking for it. Some of these fields exist only if your org turned that feature on.

Identity and account

Member records your org maintains

Attendance and absence

A record per member per event (present or not), plus excuses and semester-long exemptions. Excuses and exemptions carry free text written by the member — a reason, and optionally a note — along with who decided them and any rejection note.

Money

A ledger of income and expenses (amount, category, description, date, the payment-method word, and optionally which member it's attributed to), dues payments and reimbursement requests with their approval status and any rejection note, semester budgets, and party door revenue and expenses.

Ledger entries are never hard-deleted — deleting one marks it deleted and keeps the history, so the books can be audited and a mistake can be undone.

Governance and participation

Roles and who holds them, permission assignments, tasks and who they're assigned to, invite links and every redemption of them, and poll questions, options and votes.

Content and events

Calendar and programming events with descriptions, locations, owners, prep checklists and wrap-up notes; meeting notes and the AI summaries generated from them; community-service events and participation; a docs library of external links with preview metadata fetched from those links; Instagram content plans; pinned announcements; and party details including theme, collaborating org and notes.

Audit and service logs

What not to put here

Custom fields and free-text notes will hold anything you type. A few categories create real obligations — for your org, and for us — the moment they land in a database, so they are out of bounds.

Don't use ChaptOS to collect any of this

• Health, medical or disability information, including allergies, dietary restrictions recorded as medical needs, medications, or accommodation details
• Biometric data of any kind
• Racial or ethnic origin, religious or philosophical beliefs, political opinions, trade-union membership, sex life or sexual orientation
• Government identifiers — Social Security or national insurance numbers, passport or driver's licence numbers, immigration status
• Financial account details — card numbers, bank accounts, routing numbers. There is nowhere legitimate to put them and no reason to.
• Precise geolocation, or anyone's home address as a tracked field

If your org needs to hold something on this list, hold it somewhere built for it. An emergency contact list belongs with your advisor or your national organization, not in a custom roster column.

Grades and student records

GPA is a field your organization fills in itself. We never receive it from a university, a registrar or any student information system, and we have no integration that could. That keeps ChaptOS outside the US federal student records regime (FERPA), which binds schools rather than the tools a student group chooses.

Two situations change that, and both need a conversation with us first: a university adopting ChaptOS institutionally, which needs a written arrangement designating us appropriately; and an org loading grades obtained from the school rather than self-reported by members, which may not be permitted regardless of what we do.

Age

ChaptOS is built for organizations run by adults and by post-secondary students. You must be 16 or older to hold an account, and organizations must not use ChaptOS to collect information about children under 13. If you run a school group with members under 16, contact us before you set anything up — the answer may be yes, but it needs the right agreement with the school rather than a founder clicking through.

Who can see it

Inside an organization, access is decided by seats. Being specific here is more useful than reassuring, including where the honest answer is “more people than you might assume”.

The tiers

The fourteen permissions

Each role is a named bundle of these: manage members, treasury, events, parties, Instagram, service, attendance, semesters, roles, docs, announcements, settings, tasks, and polls. Roles also carry a rank, and an officer can only grant or edit roles ranked strictly below their own, so nobody can promote themselves or their peers past their own authority.

Our staff's access

A small number of our platform administrators can enter any organization's workspace with full permissions. This exists so we can investigate a bug you report, recover something you deleted by accident, and respond to incidents. We use it for those reasons and not to browse.

Two things constrain it: those actions are written to the same audit trail as an officer's, so they are visible in your own logs rather than in a private one; and access requires our production credentials, which are not shared outside the people who operate the service.

How the assistant works

Ask Chapt answers questions about your org by reading your actual records, and it can draft changes — but it cannot make one. A human with the right permission does that, every time.

It proposes; you decide

• The assistant's write tools validate but never write. Confirming a card is what performs the action, through the same permission-checked path a button would use.
• Each draft is checked against your seat before you see it. Lacking the permission means the card is blocked, not routed onward — and it names who does hold that authority.
• Each draft is cryptographically signed, so what you approve is what the server proposed and nothing tampered with in between.
• Every approval becomes a durable record — what was approved, by whom, under which permission — so an AI-assisted change is at least as auditable as a manual one.
• Answers cite the records behind them, and those citations are assembled from the queries that actually ran rather than from anything the model claims.

No decision with any consequence for a member is made solely by a machine. There is a person holding the relevant office at the end of every path.

What is sent to our AI provider

The assistant is powered by OpenAI's API. Answering a question means sending them the question, a short window of the recent conversation, and the results of the lookups the model asked for — which contain real member names, dues balances, attendance and ledger rows. A small cached summary of your org also travels in the instructions: member count, how many owe dues and roughly how much, average attendance and GPA, and the treasury balance, all deliberately rounded.

Three other features use the same provider:

• Meeting summaries — your raw meeting notes are sent, and the summary is saved back onto the event.
• The weekly digest — this week's deadlines, events, parties and at-risk members.
• Setup help while creating an org — and this one runs before you have an account. What a founder types into the setup interview is sent to interpret it. Don't put anything sensitive in that box; describe your org, not your members.

What we can and can't promise about it

Where your data lives

The complete list of companies that can hold your data on our behalf. If this list changes we will update this page and note the date.

These providers run on infrastructure in the United States. If your organization or its members are in the UK, the EU or another region with transfer requirements, that means data is processed outside your region and we should put the appropriate transfer terms in place — tell us and we will.

How isolation and security are enforced

Specific mechanisms, and then an honest list of the things people commonly claim at this point in a page like this which we are not going to claim.

Organizations are isolated twice, independently

The first layer is the data layer: every single database operation runs through a wrapper that attaches your organization to it automatically. Reading one record by its id is silently rewritten into “read that record within this org”, and updates and deletes verify ownership before they touch anything. A developer cannot accidentally write a query that reaches across orgs, because the query they write isn't the query that runs.

The second layer is the database itself. PostgreSQL row-level security policies restrict every org-scoped table to the organization the current request belongs to, and the connection declares that org on every query. If the first layer were ever bypassed by a bug, the database would still return nothing. A dedicated test suite exercises this boundary.

Other controls in place

• Encryption in transit and at rest, provided by our infrastructure providers, plus HTTP Strict Transport Security so browsers refuse to talk to us unencrypted.
• Cross-site request forgery protection at a single choke point every state-changing request passes through, including the sign-up paths that run before you have an account.
• Clickjacking and sniffing protections — the app refuses to be embedded in a frame, declares strict referrer behaviour, and denies camera, microphone and geolocation to itself outright.
• Every write is schema-validated before it reaches a database, and permissions are re-checked on the server for every request — hiding a button is never the security control.
• Money can't move without an approval. Dues payments and reimbursements are requests; no balance and no ledger entry changes until a treasurer approves, and then both change together or neither does.
• Link previews can't be used to probe our network. When a member saves a doc link, we resolve the destination and refuse private, internal and cloud-metadata addresses, re-checking at every redirect.
• The ledger export is neutralized against spreadsheet formula injection, so a hostile transaction description can't become executable when the CSV is opened in Excel.
• Uploads are constrained to images under 2 MB, and storage rules confine each person's writes to their own folder.
• Credentials never reach the browser. Database and AI keys are server-only. The impersonation tool our developers use to capture screenshots is inert in production — it is gated on a development-only environment check and additionally requires a cryptographic signature, so a stray cookie can't impersonate anyone even locally.

What we don't claim yet

Everything below is either not built, not audited, or not ours to assert. We would rather you read this list than discover it.

• Our content security policy is in report-only mode. It watches for violations and reports them; it does not yet block. Promoting it to enforcing is on the list.
• Rate limiting is coarse. It holds within a running server instance and resets when one starts cold. It stops runaway loops and casual spam; it is not a hard distributed guarantee.
• No SOC 2, ISO 27001 or HIPAA compliance, and no business associate agreements. We have not been independently audited or certified.
• No third-party penetration test has been performed.
• No uptime guarantee, backup commitment or disaster-recovery commitment. Our providers keep backups; we have not yet published a policy of our own, so don't treat ChaptOS as your only copy of anything you can't lose.
• No formal breach-notification window. Our commitment today is to tell affected organizations promptly and in plain language once we understand what happened, and to tell you what we don't know yet rather than wait to know everything.

Cookies and device storage

There is no cookie banner because there is nothing here to consent to. Every cookie we set is required to run the product. None of them are used for advertising, and none are third-party.

Stored on your device, never sent to us

A few things live in your browser's local storage so the product behaves sensibly across visits. Clearing your browser data removes all of it.

• Your assistant conversation history — this is the only copy of the transcript; we keep none. The one exception is a question you explicitly rate helpful or not, which we keep in order to fix bad answers (see section 3).
• An in-progress org setup draft, so the flow survives being bounced through Google sign-in. It is validated and expired when it comes back.
• Small interface preferences: which org you were last in, dismissed checklists, and a cached copy of the weekly digest sentence.

Public links and shareable secrets

Three things in ChaptOS are protected by a URL being hard to guess rather than by a permission check. That is a normal engineering trade-off, and you should know which three.

Profile photos and org logos are publicly reachable

Uploaded photos and crests are served from public storage. Anyone holding the URL can open it, signed in or not, member or not. The address is not guessable in practice and is never listed anywhere, but it is not access-controlled either. Treat a profile photo as public, because functionally it is.

Invite links are bearer credentials

Anyone with an invite link can join your organization until it expires or you revoke it. A link can be set to never expire and to allow unlimited uses, and the usage cap is approximate — two people joining at the same instant can both get in on the last seat.

So: treat an invite link the way you'd treat a door code. Prefer short expiries, revoke links after rush, and check the redemption list — every join through a link is recorded with who and when.

Joining by name match

When officers pre-seed a roster, a person signs in and claims their row by typing their name. That means someone who knows a name on your unclaimed roster could claim that row. Officers should seed rosters only with people they expect, and review the member list after a joining period.

One outbound request you should know about

When a member saves a link in the docs library, our server fetches that page once to build a preview card. The destination site therefore learns that someone using ChaptOS saved the link. We identify ourselves honestly in that request, read only the page head, and never fetch internal addresses.

How long we keep things, and deletion

The straight answer: as long as your organization exists, unless someone deletes it. Nothing expires on a timer today, and we would rather tell you that than imply a schedule we don't run.

Deleting an organization

An org admin can delete the whole workspace from settings, confirming by typing its name. This removes members, attendance, the ledger and budgets, events, tasks, polls, docs, roles, invites, announcements, the activity feed and the audit trail — in one transaction, so it either all goes or none of it does. The org's logo is removed from storage too.

One nuance worth stating, because the confirmation screen's member count can otherwise be misread: a member who also belongs to another organization keeps their account and simply loses this membership. Only people for whom this was their sole org have their record removed. Nobody loses access to an unrelated org because you deleted this one.

What a member can do themselves

• Leave an organization — drops your membership and role grants. The last remaining admin can't leave, so an org is never orphaned.
• Unlink your account — disconnects your Google identity and signs you out. Be clear about what this does and doesn't do: your member record and its history stay with the organization, because they are the org's records rather than yours alone. It removes your ability to sign in, not the roster.
• Remove your profile photo — deletes the stored image.

What survives a member being removed, and why

• Ledger entries stay, detached from the person. Removing someone from a roster must not erase the record that they paid their dues — that would let a roster edit silently rewrite the books.
• Audit and activity entries keep their name. A log that can be edited after the fact isn't a log, and it is what protects officers in a dispute as much as anything.
• Approval records keep the approver's name and role as they were at the time.

Your rights, and how to use them

Depending on where you live you may have formal rights over your data. We extend the substance of them to everyone, regardless of where you are, because sorting members by jurisdiction would be worse than just honouring the request.

Write to [privacy contact address]. We acknowledge within 5 business days and complete within 30 days, which is the shorter of the windows the major privacy laws set. If a request needs longer we'll tell you why before the 30 days are up rather than after. We may need to verify you control the account — usually by having you write from its email address.

If we get it wrong, you can complain to your local data protection authority. In the UK that's the ICO; in the EU it's your national supervisory authority. We'd rather you gave us a chance to fix it first.

Why we're allowed to process this

For readers who need the formal grounds — mostly relevant under UK and EU law. Where your organization is the controller, it relies on its own grounds and we act on its instruction.

We are based in [jurisdiction], and this page is governed by the law there, without limiting rights you hold under the law where you live.

Changes to this page

This page will change as the product does, and the changes that matter are the ones that make it less generous.

The effective date at the top moves whenever the substance changes. For a change that expands what we collect, adds a provider to section 7, or reduces a protection described here, we will notify organization admins before it takes effect, not after — and we will say what changed rather than only that something did.

Fixing wording, adding detail, and moving items out of “what we don't claim yet” as they get built are ordinary updates and just move the date.

Contact

A real person reads these. Privacy questions, rights requests, security reports and “is this a hidden account in my org” all go to the same place.