Privacy

The Inquiry Atlas is operated by Inquiry Atlas, LLC, which decides what is collected here and why. The Method Project is our fiscal sponsor; it does not control this data. Last updated 20 September 2026.

If you only want one thing from this page: the only thing we store that identifies you comes from the feedback form, and if you have used it, email inquiryatlasaz@gmail.com and we will delete your feedback, and tell you what else we found keyed to you. Our host keeps its own server logs, which we do not control; that is the last section.

Nothing is required of you

You can read every investigation, print the teacher guide and the student handout, and use all of it in a classroom without giving us anything. There is no account, no sign-up and no email gate in front of any download. We never ask for student names, student work or anything about the students you teach.

The one place you could hand us something about a student anyway is the free-text box on the feedback form, which accepts whatever you type into it. We do not want it there. Please describe how the lesson went without naming anyone.

Counting visits

This site is set up to produce one number a day: how many distinct combinations of network address and browser reached it. It does that without storing who you are and without recording which pages you read.

That number is near a count of people without being one, and it is wrong in both directions. Two teachers on the same school network using the same browser count once between them; one person who opens the site on a phone and then a laptop counts twice. It is not a count of visits either: coming back ten times in a day from the same browser still counts once, because a repeat is recognised and discarded rather than added. Read “a visit” below as shorthand for one of those combinations on one day.

The first time a combination appears on a given day it writes one row to a table called metrics_visits, and every repeat that day writes nothing. That row holds four things: client_id, which identifies this site rather than you; day, the calendar date in US Pacific time; visitor_hash; and inserted_at, the moment the row was written. There is no column for the page you were on, so this count cannot tell us which investigations are read most. Our hosting provider’s request logs are a separate matter and are described below.

The visitor_hash is a one-way HMAC-SHA256 of your IP address, your browser’s user-agent string, this site’s identifier and the current date, mixed with a secret only we hold. No IP address is stored in this count — only the hash, which cannot be turned back into one. Because the date is part of what is hashed, the same person visiting on two days produces two unrelated values, so the hash cannot be used to follow anyone across days.

These rows are deleted automatically ninety days after they are written, by a job that runs once a day.

If your browser sends Do Not Track or Global Privacy Control, we do not count you at all. The request is never made.

The feedback form

At the foot of each investigation there is an optional form asking how the lesson went. It is the only place on this site where you can hand us an identifier, and nothing on the site is withheld from you if you skip it.

If you send it, we keep four things about you: the email address you typed, the answers you typed, your IP address, and the time you sent it. We also record which lesson the feedback was about, and a shortened version of your browser’s identifying string.

The email address is required. It is what stops the form being used to flood our database — not a way of getting your address. We do not add you to a mailing list and we do not send you anything you did not ask for.

None of it is deleted on a schedule. The visit counts above expire after ninety days; this does not. Your feedback stays until we delete it, and the same is true of the two anti-flooding counters the form writes — one keyed on a hash of your email, one keyed on your IP address in plain form. The limits themselves are modest and worth knowing before you hit one: 2 submissions per email address per lesson per 24 hours, and 5 per IP address per lesson per 10 minutes. The counters are kept separately for each investigation, so sending feedback on one lesson never uses up your allowance on another. Once a window passes the counter stops limiting anything, but the row is not removed, and if you never submit again it simply stays.

So: if you have ever sent us feedback, we are holding your email address and your IP address until you ask us to stop. Asking is one email and we will confirm when it is done — see the last section.

What is stored in your browser

One item, and it is not a cookie: a single flag in session storage that stops the visit count firing twice in one browser tab. It disappears when you close the tab. The site sets no cookies for ordinary visitors. Administrators signing in to manage the site have a login session cookie; that applies to us, not to you.

Who else can see this

The site runs on Vercel, which keeps standard server request logs for a limited period. Those logs are Vercel’s, not ours to design, and they record more than our own tables do — including the page you requested as well as your IP address. So while nothing we build records which investigations you read, our host’s logs do, for as long as it retains them. The tables described above live in a Supabase database. We use Resend to send administrative email. We do not sell anything to anyone, we run no advertising, and there are no third-party analytics or tracking scripts on this site.

One more, because this page asks you to write to us: our contact address is a Gmail account, so anything you send to it — your address, what you wrote, and whatever else your mail client attaches — is received and retained by Google on its own terms, not ours. That applies to a deletion request as much as to anything else. We mention it because a deletion request is the one message on this site you might send precisely because you would rather not be on file somewhere.

If this policy changes

We will change it on this page and change the date at the top. For most visitors that is the only way we could tell you: the site has no accounts and no mailing list, which is the point, and it also means we hold no way of contacting you. So if this matters to you, the date at the top of this page is the thing to check.

If you have sent feedback we do have your email address. We will write to you for exactly one reason beyond replying to what you sent: a change never applies retroactively to feedback you have already sent, so if we ever want to do something new with it, we will write and ask first. The address is also hashed to run the anti-flooding counter described above, which is a use, not a message.

Asking us to delete something

Write to inquiryatlasaz@gmail.com and say what you want removed. If you sent feedback, the email address you used is where we start: it finds your feedback and the counter keyed to that address, and both of those we can always remove. Your feedback also records the network address you sent it from, so usually we can find and remove that counter too. We will tell you what we found and what we deleted, rather than just confirming.

We say “usually” because two things can leave a counter with nothing tying it to you. An attempt that was refused, or that failed to save, leaves no feedback record at all. And the counters are keyed on your network address exactly as your connection presented it, which is not always the same form we store alongside feedback — so the two do not always match up. Tell us the network you were on and we will look; beyond that, those are counters we cannot connect to anyone.

The terms cover what this site promises, and rights and use covers what you may do with the lessons and the photographs.

Appendix: the exact columns

The same facts at the level of the database, if you would rather check than take our word.

survey_responses, one row per feedback submission: id, an identifier for the row itself; client_id, which identifies this site rather than you; survey_key, which names the lesson; email; answers; user_agent, your browser’s identifying string, truncated; ip, your address in plain form; and created_at. Two further columns exist because the table is shared with other sites, and this one never writes to them: pdf_first_downloaded_at and pdf_download_count.

metrics_visits, one row per counted visit: client_id, day, visitor_hash, inserted_at.

rate_limits: two independent counters, not two rows belonging to you. Per lesson there is one row per email address and one row per IP address, and neither knows about the other — so a second address adds an email row, a second network adds an IP row, and everyone sharing a network shares its single IP row. The bucket_key is a string naming this site, the lesson and then either a hash of your email or your IP address in plain form. The other columns are bucket_start, count and expires_at, after which the counter stops limiting anything — but see above, the row is not deleted.