What Corpus holds about the people who use it, and for how long.

The distinction is worth drawing plainly, because the two hold different kinds of thing. A student information system holds student records a district supplies under its own authority. Corpus holds documents a district already published — board minutes, agendas, packets, budgets, audits, levy and bond filings, referenda, fee schedules, policies, reports — and serves passages and verified figures out of them.

Nothing behind a login, a portal permission, or an engagement is ever ingested, and row-level student data is excluded by rule rather than by review. A document whose provenance cannot be stated publicly does not belong in it.

There is no redaction layer at retrieval. No category of passage is suppressed, and no name is withheld from the verbatim quote a figure is checked against. What decides whether something is in the corpus is where it came from, never how sensitive it feels: a public body decided to publish it under the records law it operates under, and that decision is the district's rather than ours. A sensitivity judgement made here would be made once and then imposed on every district that connects, including districts under other states' law. Where a district wants a redacted version, the redacted version is its own document with provenance of its own, not a filter bolted onto retrieval.

What does change is findability, and it would be dishonest to pretend otherwise. A name on page 559 of a 561-page packet is public and effectively unfindable; the same name returned by a search is public and found. Corpus exists so that a district's records answer questions instead of sitting in a portal, and this is the cost of that working. The partial remedy is the withdrawal route below, exercised by the district that published the document, and it is partial for a reason given there.

The hosted copy behind every page-exact citation is served from a public address, the same way the district's own portal serves the original. That is also why a withdrawal reaches retrieval rather than the file itself.

There is no email address on it. A caller's address is read once, at the door, and tested against the list of addresses the district has entitled; that check is the whole job the address does, and nothing writes it down afterwards. The column that used to hold it was dropped on 2026-09-07, and the addresses it held were erased before the column went.

Two limits are worth stating. The question that lands in the log is the string the assistant sent, which is its own rewriting of what the person typed rather than the person's words. And an opaque sign-in id is meaningless outside the identity provider but it is still an identity, so what the log holds is a pairing: one identified caller against a line of inquiry in time order. That pairing is why a row expires whole rather than being stripped of its identity and kept.

The row records no IP address, no device, and nothing about a browser. The site at www.distcorpus.com serves prerendered pages with no analytics, no tracking script and no cookie set by us. What it does read is one header: the country our host derives from the network address of each request, which decides which of the three languages that request is answered in. That country is read per request to choose an address and is written to nothing of ours — no row, no log, no cookie of ours — though Vercel, which serves the site, records the request the way any host does, and a reader behind a proxy or a corporate network is answered for where that path appears to land rather than where they are. What it does carry is one form.

That form is the waitlist, and it is the second place in this database that Corpus holds a district staffer's address. It takes the five things the request-access page asks for and nothing else: a district, a name, a work email, and then two it will do without — a role, and the one question you would want asked first. A submission goes to a table of its own, which belongs to no tenant and sits outside the records system in a strict sense: no district role can read it, and a district session is refused the write by the policy on the table. Nothing from the form reaches the query log, and the entitlement check never reads it.

Two things the submission carries that the stored request does not. Your network address, spent by us against a rate-limit counter that meters how often one network path may submit while the counter answers, and recorded in no row of ours — where the counter is configured and fails to answer, a submission is taken rather than refused, because a form that turns people away with nothing to tell them why is the worse failure, and where it is missing altogether, which would be a fault in how we deployed the service rather than an outage in it, submissions are refused until that is put right, so an unmetered form is never the resting state, though the host that runs the endpoint logs the address of every request it serves the way any host does. And one hidden field that must arrive empty, which a person never sees and a script filling in every field does: a submission with it filled is answered exactly as a real one and written nowhere. Adding the form added no analytics, no tracking script and no cookie. A request has no clock on it: it is held until the district it names is onboarded or declines and is then deleted, by a person rather than by a scheduled job, which is a weaker promise than the ninety days below and is said here as the weaker thing it is. The first word back need no longer wait on a person, and three things have to hold for it not to. The sender behind it has to be configured. Your address has to be one a recipient list in force allows us to write to, that list being how sending is brought up district by district and how it is paused again. And the counter recording one acknowledgement an address a day has to be reachable and to hold nothing against your address for today — the bound that stops this form being used to send somebody mail repeatedly, and one your own second submission spends: a request sent again an hour later to correct the district you typed is not answered a second time. Where that counter cannot answer at all, nothing is sent, which is the opposite of what happens to the submission itself and is the safer error where what is at stake is mail going out. Where all three hold, a submission is answered by one email to the address that was typed, from a fixed template whose only variable text is your name and the district you named. That email takes no reply: it is sent from an address nothing reads, and it names the address at the foot of this page, which is where a deletion or a correction goes, as the way to reach a person. Where any of them does not — and with the sender unconfigured, which is the state this shipped in, the other two are never reached — nothing is sent and the first word back is a person's as it always was. Either way a person reads what you wrote and follows up. Keeping to that one-a-day bound costs one more thing to disclose: your work address itself is written to the rate-limit counter as the key recording that it has been answered, where it sits for about forty-eight hours and then expires. The sections below that count who holds what name it there as well. One gap is named here rather than left out: nothing watches for a bounce, so an address typed wrongly receives nothing while the request still reads to us as answered, sitting beside the requests that did get through and indistinguishable from them. One more thing happens to an answered submission, where the system behind it is configured, and it is the only part of this that carries your first question anywhere but the table above: the submission is filed as a lead in a customer-relationship system of ours. What is filed is a contact holding your name, your work address and your role where you gave one; a record of your district, created from the domain your address sits at; and two notes against the contact, the first carrying the district, the role and your first question in full and as you typed it, the second recording which of the outcomes above the email reached. That system is a second database, under a different provider and outside every protection this section states about this one. Filing is also what starts that system looking into you and into your district: one piece of work on you and two on the domain, each of them an agent that reads what was filed through a model gateway, and that can send your name and your work address out to two open-web research services where that system holds keys for them. The three sections below count all of it: who receives it, how long it stays, and who can read it. Where that system is not configured, nothing is filed and none of that happens.

The first is the reason anything is written at all: a claim about retrieval quality is only as good as the record of what was actually asked, so an operation that returns a result without recording who asked for it is not finished. The second and third are why a caller sits on the row rather than only a district.

The fourth is the only one that is not about the log. A waitlist address is used to answer the person who typed it and to arrange the pilot they asked about. The first of those is automatic where three things hold — the sender behind it is configured, a recipient list in force allows that address, and a reachable counter says none has gone to it in the past day: the address is written to once, by a fixed email carrying your name and the district you named — not a word of it composed for you, and none of it waiting on anybody — and where any one of the three does not hold the address is not written to at all. Nothing watches for a bounce either, so an address typed wrongly is never written to successfully and the request still reads as answered on our side. It goes on no mailing list, because there is none to go on. Nothing Corpus holds is sold, rented, or shared for anyone's marketing. Nothing Corpus holds trains a model: Corpus trains none and runs none. The only model in the serving path is a third party's embedding model, called to turn a question into a vector so the store can be searched; what that vendor does with what it receives is governed by its own terms, linked in the next section, and this policy does not restate or characterise them. A model does read a waitlist submission, and saying so plainly is better than leaving it to be inferred from the list in the next section: where the customer-relationship system a lead is filed in is configured, filing the lead sets that system looking into who you are and into the district the domain of your address belongs to, and the agents that do it read what was filed through a model gateway. Working out who you are is also a lookup in the open-web research market, and that is the part worth naming rather than leaving inside the words a model: the same work can send your name, your work address and that domain to two research services outside that system, one of them to resolve the person behind a work address and one to answer a question about you or your district off the open web. None of it trains a model on you, nothing it produces is sent to you, and not a word of the email you receive comes from a model. Where that system is not configured, no model reads your submission and neither service hears of you at all.

There is no advertising on the site or behind the connector, no ad network, no tracking pixel, and no profile built about anyone.

Voyage AI receives the text of the question. Every search call, and every overview call that carries a topic, posts that string to Voyage's embedding API to turn it into a vector before the store is queried. What is sent is the string and the name of the model — not the caller, not the caller's district, and nothing else about the request. Voyage's handling of what it receives is Voyage's own and is described at voyageai.com/privacy.

Resend sends the one email the waitlist produces, and it is no part of answering a question. It is the only recipient on this list that receives your name and address in order to address a message to you. Where a request is answered, your name, the district you named and your work address are posted to Resend's sending API so that the acknowledgement can be addressed and delivered to you. Your role and your first question are not sent, nothing else about the submission reaches Resend at all, and no mail of any kind goes out while that credential is unset. One other thing does leave for somewhere else, and it is counted in the Upstash entry below rather than here: the address on its own, as the key of the counter that allows one acknowledgement a day. Resend's handling of what it receives is Resend's own and is described at resend.com/legal/privacy-policy.

Neon and the Vercel AI Gateway sit behind the second thing a waitlist submission reaches, and like the sender they are no part of answering a question. Where the customer-relationship system behind it is configured, a submission that is answered is also filed there as a lead: your name, your work address, the district you named, your role where you gave one, and the first question you wrote, in full and as you typed it. The domain your address sits at is filed beside it, as that system's own record of your district. That system is ours rather than a vendor's, and it runs on a database that is not the one above — Neon hosts it, so Neon receives everything named in this paragraph, and none of the protections this page states about the records database are statements about that one. Filing is also what sets that system's own agents looking into who you are and into that domain, and they reach a language model through the Vercel AI Gateway, which is how your name and your work address are read by a model. It is read to find out who you are and not to write anything back to you, nothing about a district's records is in what it reads, and no model is used anywhere in composing the email you receive. Neon's handling of what it receives is described at neon.com/privacy-policy and the gateway's at vercel.com/legal/privacy-policy. Where that system is not configured, which is the state this shipped in, nothing is filed and neither of them receives anything at all.

Context.dev and Perplexity are where that lookup goes outside, and they are the furthest anything you typed travels. Resolving who you are sends your name, your work address and your district's domain to Context.dev, whose business is returning the person behind a work address and their public profile. Researching you or your district has that system's agent compose a question about one of you and post it to Perplexity, which answers it off the open web with citations. Both are reached with keys that system holds rather than with anything Corpus holds, so an unset key is a call that does not happen; both are reached because a lead was filed, which is to say because this form was filled in; and neither of them is told anything about a district's records. Context.dev's handling of what it receives is described at context.dev/privacy and Perplexity's at perplexity.ai/hub/legal/privacy-policy. Where the customer-relationship system is not configured, no lead is filed and neither service hears anything at all.

Supabase hosts the database and the file storage: the corpus, the verified figures, the entitlement list, the query log, and the waitlist. WorkOS provides sign-in — a person authenticates with WorkOS directly, and Corpus verifies the resulting token against WorkOS's published keys. Upstash holds the rate-limit counters and receives, as counter keys, the caller's network address, after verification the opaque sign-in id, and — where a waitlist submission is answered — the work address it was sent from, which is the key of the counter allowing one acknowledgement an address a day and which that counter keeps for about forty-eight hours before it expires on its own. The key is the address as it was typed, lower-cased and trimmed and otherwise untouched, so a tagged or differently spelled variant of one mailbox is a key of its own rather than the same one. Vercel hosts the site, the connector endpoint and the waitlist endpoint. For the site it derives, from the network address, the country that chooses which language a page is served in, and it does that in the request itself rather than in a store; for the connector it sees request metadata the way any host does; for the waitlist it is a processor of the submission itself, because the form posts to a function Vercel runs, so the name, work address and question pass through its compute and the network address appears in its request logs.

No other service receives anything from us. There is no analytics vendor and no error-reporting vendor, and no marketing platform of any kind: the one email platform on this list is the sender named above, which carries the acknowledgement and nothing else. The system a lead is filed in is a customer-relationship system of our own and not a marketing one — nothing is sent from it, and the four services it brings with it are the database, the gateway and the two research services named above.

One page a visitor can reach from here is named rather than left to the ten above to cover, because what it collects, it collects for us. Book a demo opens a scheduling page we keep at cal.com. Corpus posts nothing to it, hands it no copy of anything and tells it nothing about you, which is why it is not an eleventh entry on a list whose test is what a service receives from us. What that page receives, it receives from you: book a slot and the name, address and times you type in are held by Cal.com on our behalf under its own terms, and nothing this page says about the services above is a statement about that one. Following the link is a thing you choose, which is the other reason it sits beside the list rather than in it.

A retention rule that depends on someone remembering it is not a rule, so this one lives where the rows are. No role the service runs as holds permission to delete a log row; the scheduled job is the only way one ever leaves. What ninety days gives up is stated rather than glossed: an audit opened in month five cannot establish what was asked in month one, a report that arrives late arrives to an empty table, and no trend older than a quarter can be reconstructed after the fact.

What has no expiry is the corpus. Documents, passages and verified figures are append-only — a correction is a new row pointing back at the one it replaces, and a document that was ever cited is not removed from retrieval except at its publisher's request — so an answer given a year ago can still be explained rather than denied. The entitlement list holds an address for as long as the district keeps that person entitled. When a district leaves, its log empties on the same clock as everyone else's: ninety days after its last call, and nothing re-creates it.

The waitlist is the one thing here with a rule and no clock. A request is held until the district it names is onboarded or declines and is then deleted, and that deletion is a person doing it: no scheduled job removes a waitlist row, and if nobody performs the deletion the row stays. That is the honest description of the arrangement, and it is deliberately not written as a schedule we would be describing rather than running.

One limit no code reaches. Deleted rows — a purged query-log row and a deleted waitlist request alike — and the caller-address column that was dropped, persist in the database provider's backups and point-in-time-recovery window until it rolls past them. Saying so is more useful than claiming an erasure the storage layer does not perform. Four copies sit outside every rule above, and all four are counted here rather than left for a reader to infer. Where the acknowledgement is sent, your name, your district and your work address have gone to the sender that delivers it, and that copy is held for as long as that sender's own terms say: no deletion of ours reaches it — not the operator deleting the row, not a request from you to delete it. The second is smaller and is a copy of your address all the same. Answering a submission writes the address itself into the rate-limit store, as the counter key recording that it has been answered today, and that key expires there about forty-eight hours later. No deletion of ours reaches that one either, and it is the only copy named on this page that goes without anybody doing anything. The third is the largest and has the weakest rule on it. Where the customer-relationship system is configured, the lead filed there holds your name, work address, district, role and first question in a second database, and that database has no clock on it at all: nothing expires, no scheduled job removes it, and there is no rule of its own above the one in the next line but one — a person deletes it, on the same ask that deletes the request. Whatever that system's own agents read about you while looking into who you are, whatever the model behind the gateway kept of the prompt it was sent, and whatever the two research services named above kept of what they were asked, is governed by those services' own terms and not by anything on this page. The fourth copy is the smallest and the most awkward, because it is what deleting the third one leaves: that system puts a deleted contact's address on a suppression list, with the name in the reason it keeps beside it, and that list has no clock on it either — so the ask that takes a lead out writes this row rather than clearing one, and nothing expires it. The one thing that clears it is a later submission from the same address, which files the lead again and takes the record of the deletion with it. Where that system is not configured, nothing is filed and neither of these two copies exists.

The ingest job's read was taken away deliberately, so the only remaining reader is the operator credential for the database, which is to say us.

The waitlist is held the same way. No role in the serving path can read it: a district session is refused the table, and the identity the form's endpoint signs in as can append a request and cannot read one back, its own included. That identity is otherwise an ordinary district-facing session holding the same grants any of them has, every one of which resolves to nothing because it claims no district. The operator credential is again the only reader.

The gap in that is worth stating rather than hiding: there is no per-operator audit of who read the log, and no separation between operators. Ninety days bounds how much there is to read. It does not remove the access.

One set of readers sits outside the database altogether, and it is a different set. Where the acknowledgement is sent, the name, the district and the work address of every submission are visible in the sending platform's own dashboard to anybody holding an account on it, under no grant of ours and with no audit of who looked. Nothing on this page bounds that list; it is named here so that it is not read as covered by the paragraphs above.

A second set sits outside the database in the same way, and it is wider. Where the customer-relationship system is configured, the lead filed there is readable by anybody holding an account on that system, under no grant of ours and with no record kept of who looked — and by anything holding a key an account on it created, because a key there carries the whole authority of the person who made it and nothing anywhere reads a key's permissions. The one this endpoint holds is the one it needs to file a lead, and that is a description of what it is used for rather than a bound on what it could do. The address stays readable to that set after the lead is deleted, on the suppression list the deletion writes. None of the database protections above reaches any of this, and where that system is not configured nothing is filed and the set is empty.

A district decides who may connect. Names go on and come off one at a time, against a list on the district's own record, and a removal takes effect for that person and nobody else within about thirty seconds. No shared password and no API key is handed to staff, so revoking one person revokes exactly one person.

A district may withdraw one of its own documents from the store, and only the publishing district may. What a withdrawal does today is take the document out of retrieval: it can no longer be searched, quoted, or cited, a citation already handed out stops resolving through Corpus, and where the document carried verified figures those figures go with it. What it does not do is take the published file off the internet. The hosted copy sits at a public address, a withdrawal does not delete it, and anyone still holding a link handed out earlier can download it. That gap is known and open work rather than a property of the system, and this page will say so until it is closed.

Someone named in a record raises it with the district that published the record. There is no document Corpus can un-publish — the original sits on the district's own portal or in a public archive, and the corpus reproduces what the district put there — so the decision belongs to the publisher under the records law that made the document public. If the district decides to withdraw it, the route above runs. Corpus does not prune a district's records on its own reading of what is too sensitive to serve.

The query log has no per-person control, and each row expires at ninety days regardless of who asked. There is no automatic route out sooner; anything earlier than the schedule is a manual operation on our side, so ask.

A waitlist request comes out whenever the person who sent it asks, at the address at the foot of this page, which is the address the acknowledgement itself names because that email is sent from one nothing reads. It would go when the district was onboarded or declined in any case, and asking brings that forward rather than making an exception. What that deletion does not reach is the copy the acknowledgement left with the sender that delivered it: the row goes, and the name, district and address sitting with that sender stay. That gap is known and open work rather than a property of the system, and this page will say so until it is closed. The lead is the one further thing the ask covers and the one thing nothing automatic performs. Where the customer-relationship system is configured, asking deletes the lead filed there as well as the row — a person doing it by hand, in that system, with no job and no schedule behind it — and because nothing expires a lead on its own, that deletion is the only way one ever leaves. Anything that system's agents recorded about you while looking into who you are goes with the lead; what the model behind the gateway and the two research services were sent does not, on the same terms as the sender's copy above. What the deletion leaves behind is worth stating rather than rounding off: that system keeps your address afterwards on a suppression list, with your name in the note beside it, so the ask removes the lead and leaves a standing record that this address asked to come out — and a later submission from the same address clears that row, files the lead again, and takes the record of the ask with it. Nothing automatic performs any part of this.

The retention window and the identity the log keeps are enforced by the database rather than described here, so this page reporting them wrongly would be a defect rather than a difference of opinion. If the two ever disagree, the database is what is true and this page is the bug.