Privacy · last updated [the date this version goes up]. That line is this page's change marker, and two sentences further down point straight at it: the one under the table of who else touches things, and the one under Changes. We change it by hand when we change the page. We went looking for a program of ours that stamps it and did not find one, so this marker carries the same caveat as every other promise on this page kept by a person rather than by a program — and this page's rule is that a promise and the thing enforcing it are two separate facts.
This page is short where it can be honest short. Where it cannot, it is long. If you have a minute, read the box.
⚠️ TWO THINGS FIRST, BECAUSE THEY WERE BURIED AND THEY SHOULD NOT HAVE BEEN. A cold reader went through this page on 2026-08-29 and said both of these were true, both mattered, and both were sitting a long way down. Each has a full section below; neither depends on your reaching it.
① If you have ever texted our number or written to us, a copy of your words is in a Google Drive we own. Not a summary — the words. We back this machine up whole-tree, and the trees that hold the record of text messages, the opt-out list, and our own working notes all go. That is a company which is not us holding a copy, and it happens automatically, not because we chose your record one at a time. The opt-out list is the one we keep for good, so a number that texted STOP to be left alone sits in that Drive permanently. We are not comfortable with that sentence either.
⚠️ And it does not come back. Once a copy has left this machine we cannot reach into it. If you ask us to delete something we can delete it here, and we cannot delete it out of a backup that has already gone — asking would mean going through the copies by hand, and we have never done that. Deleting on this machine and deleting everywhere are not the same act, and only the first is one we can perform. That is the sentence to weigh before you write to us, not after.
② There is a step meant to strip sensitive records out of the backup before it leaves, and we cannot prove it works. The command removes, then checks its own work — and the check looks for fewer shapes than the removal removes, so a removal that silently failed on exactly the directory we care most about would still pass its own check and print a clean line. A check narrower than the thing it checks is not a check. The wider one is written down as a change and has not been made. Until it is, treat the stripping as unproven, and read ① as though the stripping were not there.
First, what this page covers. We run more than one web address. Everything below describes this site, and the free grill on it. Other addresses of ours carry a form: an early-access page, and — inside our own tool, on an address of its own — a sign-up box on its front page and a waitlist box behind it. And addresses of ours carry no form at all: the second web address we own, the one that forwards here, and a machine-name address our hosting company gave this server, which we use as a door into our own machinery and which answers a stranger with a password prompt and nothing else.
⚠️ And there is a third shape. One of the addresses named above also answers on a path underneath it: the path our phone company's machines post to when somebody texts our number. It takes a write from whatever reaches it. It asks for no password, and it does not check that what reached it came from our phone company. That is how a text message becomes the record described further down this page, and it is the way into that record for anybody who finds the path. Our own code says so in as many words — the note above the limiter on that path calls it the only genuinely public, unauthenticated write surface we own, and the limiter is there because somebody here had already thought about what an open door costs. ⚠️ That sentence is our code's and not this page's, and we are not adopting it. It is a closed claim over a set — precisely the shape the section further down headed "How to read this page" is about. We quote it because it proves somebody here knew, and we leave it as a quotation because we have not gone and checked it against every rule that routes this machine. What that means for you is on the page already, one screen down, under what we keep of a text message — and the door it arrives through is open.
This page describes our front doors by shape rather than by count, because a web address is one line in a configuration file.
The forms take an email address. One of them also writes down the browser's own description of itself, the page that sent you, and a network address — in the same row as your email address. ⚠️ That network address is not yours. It is ours. Everything reaching that form arrives through our own front door first, and the handler writes down the connection it can see — which is our own doorway talking to our own program. We read that off the one row that exists as well as off the code, rather than reasoning about it, and the code has no way to read the address your browser actually made — so we expect the same value in every row, and one row is what we have to check that against. It is a fact about our plumbing wearing the shape of a fact about you. ⚠️ That does not make the field harmless and we are not going to argue that it does. The browser string is genuinely yours, the page that sent you is genuinely yours, and both sit in the same row as your email address, and nothing deletes that row. Our web server's log on this site holds a real address, a referrer and a browser string, and this page prints its exact format further down. That log holds no name and no email, and it rolls. The early-access database holds what it holds joined to a person, in one row, and nothing deletes it. Both are described in the table near the bottom, and the outside company that receives those email addresses is in the table under it.
The calculator on our homepage never sends your numbers anywhere. It runs entirely inside your browser. There is no form on that page and no request leaves it. Close the tab and it is gone.
The free grill is a different thing and we are not going to blur the two. It is a form. When you press the button the answers you typed are sent to our server, because the arithmetic that names your leak runs on our machine and not in your browser. Your answers themselves are not written to any file we keep — but that sentence is narrower than it sounds and we are not going to let it stand alone up here. Things MADE from your answers are written: a number in our spending line that moves with how much you typed, the broker's own receipt number for the request, and a fingerprint of the opening stretch of what you wrote together with how long it was. ⚠️ A fingerprint is not your words and it is also not nothing — anybody holding it who can guess what you wrote can test that guess against it instantly. Each of those has its own section further down naming where it lives and what it holds. "We do not keep your sentence" and "we keep nothing made from your sentence" are different promises, and only the first one is ours.
One question on that form is answered in your own words, and that one sentence leaves our building — every time. Not only on the hard ones. Not only when our keyword matching struggles. Every submission with anything at all in that box. That sentence, and nothing else — never your numbers, never anything that says who you are — is passed to a language model we rent, through a broker. The broker does not pick from everybody it carries. It is handed the names of a few companies that we keep written down in a file of our own, it is told to use only those names, and if none of them can take your sentence it is told to stop rather than to go and find somebody else.
⚠️ Which of those named companies actually answers is still the broker's call and not ours. We hand it our own order of preference; we do not hand it the decision. ⚠️ What we have actually watched is narrower than "it honours the list", and the difference matters. We cut the list down to a single company, and that company is the one that served, on a line of our own record. That shows the broker did not go OUTSIDE the list. It shows nothing about ORDER, because a list with one name on it is honoured by anybody who answers it at all. We have not watched it move past a busy first name to a second. Until we have, how much of that list is really in reserve is something we are describing rather than something we have measured — and the sentence that used to sit here claimed more than its own evidence carried.
⚠️ We tell the broker to work down our list and stop at the end of it, rather than asking it for whichever machine is quickest that minute. Those are two instructions it cannot follow at once — ask for the quickest with no permission to look elsewhere and it stops at the first name, which is one company and an outage rather than a list. We could not have both, and we kept the list. What the broker gets is an order we wrote ourselves, out of our own record of which companies have actually served this part of our machine — which is a reading taken once, where the broker's was taken fresh every time. Whether that makes your answer slower, and by how much, is not something we have measured well enough to tell you, so we are not going to put a figure on it. ⚠️ And the reason we chose one instruction over the other is our reading of what the broker's own documentation says those two instructions do — not a test we ran here. We have not put our own list under an outage and watched what it does. That is a hole in what we can tell you about availability, and naming it is cheaper than defending the sentence we would otherwise have written.
That is two separate promises and we are going to make them separately:
① It is sent. It goes to a company that is not us, on every run with words in that box, apart from the runs something on our side stops before anything leaves. ② We do not store it. No copy of your sentence is written into any record we keep. Not the line about the run, not our spending ledger, not the balance file, not our error output, not the web server's log, and not the receipt for the library look-up described below — which holds a fingerprint of the opening stretch of your answers and how long that stretch was, where the words would have been.
What promise ② rests on is a place in our own code, not a search. The words are stripped at the door our own programs go through to reach that library, so the programs on the far side of it are never handed your sentence and cannot write down what they were never given. That is a promise about code, and code gets edited — by us, on a day nobody is editing this page. We are telling you where it lives so you know what would have to change for it to stop being true.
⚠️ And there is a second kind of call to a company that is not us, which promise ① is not about. Before deciding whether to serve you at all, we may ask our broker about our own account — our balance, and what we have spent today. That call is about our money and carries nothing of yours. It is described in full in the refusal section and in the balance-file section below. We name it here so that "it is sent" and "nothing about you is sent when we refuse" are not read as the same sentence.
Some things stop the sending before anything leaves. All but one of them are about our machinery rather than about you — and the one that is not is the door, which gets its own paragraph directly below this one. Our budget for the grill can run out; the account it is all paid from can be too low; the day's total across everything we run can be spent; the part of our system that writes our own records can refuse a call it would not be able to write down. And the ones that are not about money: if we cannot get a reading of our own balance at all, or cannot read our own record of what we have already spent, the call does not go. That is not our budget saying no — that is our own instruments being broken, and we would rather refuse than spend blind.
⚠️ And "stops the sending" is too small a word for what most of those actually do. The wallet is not asked at the end, once your finding has been worked out, and then allowed only to hold back the last step. It is asked at the door, before a character of your form has been read. So an empty account — or an account we cannot get a reading of — does not hand you a finding with the sentence withheld. It refuses you at the door, and you get the same page as somebody who has run out of turns. They can close the door, and that is the honest word for it.
⚠️ And there is one more way to be refused. It is the only one on this page that exists because of a promise we made to you rather than because of our own money or our own broken instruments. If none of the companies on that list can take your sentence at that moment, the second reader does not run. You still get the finding the part of the grill that runs on our own machine worked out. What you lose is the second pass over the sentence you wrote.
⚠️ "Refused" there covers two different things, and only one of them means nothing left the building. The one we actually rehearsed is the one where something did, so we are separating them.
The one where nothing leaves. If our code cannot read the list at all — missing, damaged, empty — or every name on it is excluded for that call, it stops before the request carrying your sentence is built. Your sentence is not sent to anyone. (The call about our own account, described just above, is a separate thing and is not affected by this.)
The one we rehearsed. The list read fine, the names were handed over, and the broker could not get any of them to serve. Finding that out required asking — so by the time we knew, your sentence had already gone to the broker, which is OpenRouter, named in the table at the bottom of this page, and a company that is not us. What did not happen is a hand-off to a company that would answer it, and that is the promise this list exists to keep. What did happen is that your sentence reached our broker. Promise ① above already tells you it goes to a company that is not us; this refusal does not take that back.
⚠️ Our own spending ledger makes the same mistake right now, and we would rather show you that than tidy it. It writes the same words — refused before the call — on both shapes, so a call that was made is recorded as a call that was not. That is our record being wrong, not this page rounding it off. It is written down as a change to our code rather than argued away here. The refusal sentence our machine actually wrote is printed further down this page, and it says the broker answered 404 — which is a reply, and a reply is something you only get to a message that was sent. We would rather you read that line against this paragraph than against a sentence it does not survive.
Both halves of that are true and we are going to write both. The broker is told to use only the names on our list and not to substitute anybody else, and the set of companies that could receive your words does not grow on its own while nobody is looking — it changes when one of us edits a file. ⚠️ That is a control on the way out, not a guarantee about where your words end up. We also read back which company actually served the call and throw the answer away if it was somebody off the list — but that reading happens after your sentence has gone, so it can refuse to show you the answer and it cannot call the words back. And it can come back "we could not tell", in which case we show you the answer anyway; the weaknesses section says so in its own words. "There is no longer a way" is a claim about every path at once, and it is not a claim we can take — what we have is a block on the wire and a check after the fact. This page names both rather than adding them into a guarantee. It is also a worse day for somebody who wanted an answer. A page that sells you the guarantee and leaves out the cost is flattering you. Our own code gives this refusal its own word, kept apart from a timeout and apart from our budget, so that how often did that promise actually cost somebody an answer becomes a question our records can answer rather than one we would have to estimate.
⚠️ That word is written, and it has never once been recorded. We read every line of that file to check. The refusal we rehearsed was written down carrying the same ordinary word a run gets when the second reader simply had nothing to say — so in that file as it stands today, the run where this promise bit and a run where nothing much happened are the same row. The word that would tell them apart is not on any line of it. A count of how often the promise costs somebody an answer would read zero today, and it would read zero because nothing is counting — not because nothing happened.
⚠️ The part of our program that has that word is running now, and being exact about what that settles matters more than the good news. The grill reads our program when it starts, and the parts it does not need straight away it reads the first time it needs them — either way it keeps the copy it read. It has been restarted, and every part of our program on this machine is older than that start, so what it holds now is our code as it stands.
⚠️ What that does not tell you is what a refused visitor now reads, because we have not read it. Those words are not printed on any page a request can fetch — there is no address you or we can visit that shows them — so the only way to see them is to be refused. Our own record has no line for a refusal since the restart. That is what our record says, and it is not the same as knowing that nobody knocked. The program that writes them is current; the words themselves have not been read back off the door. We are writing the narrow sentence on purpose, because the wide one — "the new wording is live" — would be a claim no instrument we own can make, and this page's whole method is that a promise and the thing that checks it are two separate facts.
The honest state of both things named above is the same. The words a refused visitor would read, and the word our own record gives that refusal, sit in a part of our program the door is now running, and neither has been observed doing its job since. How often did that promise cost somebody an answer is a question our records can answer going forward and cannot answer backwards. The refusal we rehearsed is still filed under the ordinary word, because it was filed before, and a restart does not go back and re-file a row. That row is still printed further down this page with its date, so the sentence above is something you can check rather than something you have to take from us.
⚠️ The refusing itself was never the part that was waiting. We watched it happen and the record of it is printed below, dated.
Here is how the grill comes to hold older copies of its own parts. When one of our programs reads a part of itself, the language it is written in may save a machine-ready version of that part in a folder beside it, so that the next start does not have to do the reading again. That is not something we arrange for. It happens part by part rather than program by program, and it happens only for the parts a program pulls in — never for the single file it was handed to run. So that folder is not a record we keep; it is a by-product nobody sweeps, and what sits in it on any given day is decided by which program last read what.
What we did was open that folder and read the headers. Each saved copy names the date and the size of the file it was made from, which is what makes the rest of this paragraph checkable at all. Some of what is in there was made by a different reader than the grill, in a version of the language the grill could not load even if it wanted to. We are not going to add those together into a single number.
⚠️ The grill cannot write into that folder as things stand on the day this was written. That folder belongs to a different account than the one the grill runs as, and it is set so that only its owner may add to it; the grill's account has none of the extra powers that would let it past that. We asked the grill itself to create an empty file there, under a name of our choosing, and the machine answered permission denied and nothing appeared. So it is not that the grill is forbidden to save copies. It is that it has nowhere to put them. ⚠️ That says nothing about what was true at the moment the grill started. Ownership and permissions on a folder are one command away from being different, and nobody was watching that folder on the day the grill last started. The probe closes a reason. It does not close the question above it.
What all of this actually asks for is not a sentence. A program that can be behind on its own parts should write down, when it starts, which parts it read and what each one looked like. Then what is the grill holding is a question our own record answers, instead of one this page reconstructs out of a folder of by-products. That change is not made, and it is written down as a proposal, for the reason every code change named on this page is. A program that cannot say which parts of itself it read will be behind again the first time one of them is edited, and the only reason this page can tell you it is current today is that somebody compared dates by hand. A gap you can only find by hand is a gap that gets found late.
The one stop that is keyed on you rather than on us is the door, described in its own section below. There is a limit on how often one visitor can run a finding, and reaching it stops everything — including the sending. It is decided from your network address and from nothing else, before a single character of your form has been looked at.
None of them is a judgement about you or about what you wrote. Not even the door: that one is about how often a request has arrived from where you are, and it is settled before anything you typed is read. You cannot rely on any of them and you should not plan around them. Read promise ① as: assume it is sent.
If you leave that box blank, nothing you wrote is sent to anyone — there is nothing to send. That is your switch, and it is yours rather than ours. ⚠️ It does not switch off the other call. The question we ask our broker about our own account is asked before your form is read at all, so an empty box does not stop it. It still carries nothing of yours, and it is described in the refusal section and the balance-file section below.
We run no analytics scripts, no advertising pixels, and no cookies — not "only essential cookies", none — and we run nothing in front of this site that sets a cookie of its own. ⚠️ Read that as a reading of what is installed today, not as a thing that could not be otherwise. It is checkable by you in a minute, and it was checkable by us; it is not a guarantee about a configuration we can change without touching a line of code. The next paragraph is our own easiest way to break it, and it is there because an absolute that hides its falsifier is worth less than a smaller sentence that shows it.
⚠️ And that sentence carries its own falsifier, which is written out a few paragraphs down rather than left for you to find. It is a reading of what we run today, not a law of physics: the outside company that turns our web address into a machine address could be told to stand in the middle instead, with one switch, in a control panel we already hold — no code changed and nothing on this page edited. So read it as "none, and here is exactly how we could break it", not as "none, and it could not be otherwise." The two are different promises and only the first one is ours to make.
⚠️ "No cookies" is not "nothing is stored in your browser". The early-access page runs no script at all. The tool on our other address does: it keeps your streak and your check-offs in your own browser, and it installs a small program in your browser that keeps a copy of its own pages so it works offline. Neither of those reaches us — that is the point of them, and the tool says so on its own face. But if you open the developer tools there you will find entries, and we would rather you read why here than find them and wonder. And on cookies we went and asked rather than asserting: on the day this version was written we put a request to every address of ours this machine answers for, and read the replies, and not one of them set a cookie. ⚠️ That is a reading taken at our own front doors on a named day, not a promise about every address our name will ever be on.
⚠️ This site does not run on a machine we own. It runs on a virtual machine we rent from a hosting company — their hardware, their network, their building. The software on it is ours and the promises above are about the software. But the company we rent it from can reach the machine in ways we cannot prevent, and that is true of every rented machine and true of ours. We would rather write that sentence than let "our server" do work it cannot do. The company is named in the table near the bottom, with the others.
⚠️ And here is precisely how the no-cookies promise could go false. The records that turn our web address into a machine address are answered by an outside company. Today that company answers the question and stands aside: your browser is told where we are and comes to our machine directly. But the same account that answers the question can be told to stand in the middle of it instead — one switch, in a control panel, in an account we already hold. No code changed, nothing on this page edited. We know it works because it is already thrown for the second web address we own, the one that forwards here. We are naming our own easiest way to break this promise, because a falsifier we keep to ourselves is not a falsifier. If it is ever thrown for the address you are reading this at, this sentence changes the same day, and so does the section on our web server's log.
Don't take our word for either half of that — and note that the two halves are checked in two different places. The cookie half you can run right here: open your browser's developer tools — F12 in most of them — and find the panel listing what a site has stored. Chrome and Edge call that panel Application; Firefox calls it Storage. Look under Cookies: there are none. We name both because an instruction that only works in the browser we happen to use is a check half our readers cannot run. The calculator half cannot be run on this page, because the calculator is not on this page. It is at the top of our front page. Go there, open Network before you touch it, then work the calculator: nothing appears, because nothing is sent. We would rather send you to another page than tell you a check works here when there is nothing here to run it against.
⚠️ The same check on the grill is not something you can run yet, and we are not going to pretend otherwise. The free grill has no public address at the time of writing — it is not published. When it is, this paragraph will name where, and the instruction will be: use it with Network open, and read the destination of every line in that list rather than counting the lines — a browser fetches odds and ends on its own account, and a number we printed would send you hunting for a mismatch we would have to explain away. The thing that will mean something is that every line goes to us. Until that address exists, this is a promise about a check, not a check, and it is listed as such at the bottom of this page.
⚠️ One request for this page is not encrypted, and we are naming it rather than pre-explaining it away. Ask for this page without the trailing slash and our server answers by sending your browser to the address with the slash — written starting
http://rather thanhttps://. So your browser makes one plain, unencrypted request to us before being sent back to the encrypted address, which is where the page actually arrives from. What that costs: anyone watching the network between you and us — whoever runs the wifi, your internet provider — can see that somebody at your address asked our server for this page. What is not in it: the page itself, anything you typed, and any cookie, because this site sets none. It happens because a program of ours sits in front of the web server and does the encrypting, so the server builds that redirect using the plain scheme it can see rather than the secure one you used. And we do not send the instruction that would tell your browser never to try this site unencrypted in the first place — the same weakness from the other side. Both are ours, both are fixable, both are real.What no check in your browser can show you is what our server does next, because the sentence it passes on is sent machine-to-machine, out of your browser's sight. That is exactly why it is written above in plain words rather than left for you to find.
This is the first thing on this page that touches your network address inside the grill itself. So it gets its own section rather than a clause.
There is a limit on how often one visitor can run a finding, a limit on how many the page will run at once for everybody, and a hard stop for the day. To hold one visitor to his own limit, the door has to be able to tell one visitor from another — and that means it has to look at your address.
The door consults one more thing than those three: our own wallet. Before it decides, it asks the part of our system that watches our spending what is left in the account all of this is paid from. An account that comes back empty and an account that cannot be read at all are treated the same way — as the limit that binds — so either of them is a refusal at the door rather than a thinner answer. A limit we cannot read is not a limit with room in it, and building it the other way round is how a broken instrument turns into free spending. It is also why the wallet belongs in the door's section and not only in the paragraph about sending.
Here is exactly what it does with your address, and you can hold us to every clause.
When the door refuses you, here is precisely what happens and what does not. The bytes your browser sent are taken off the connection and thrown away without ever being read as a form — no field is pulled out of them, nothing you typed is priced, nothing you typed is sent anywhere, and nothing you typed is stored. (We take them rather than slamming the connection shut, so your browser gets a clean answer instead of a broken one it has to guess about.) No line about a run is written. No spending line. No library look-up made and no receipt for one. You get a page saying which kind of limit stopped you and roughly how long to wait — and on one of those pages, a sentence of ours that goes further than that and is false.
⚠️ Our own refusal page tells you no record of the refusal was written. One is. The wording our code serves when the limit you met is the one keyed to your own connection ends: "Nothing broke, nothing you typed was saved, and no record of this refusal was written." The first two clauses are true and this page stands behind them. The third is not. On that same path our error output records that the door refused a request and which of our limits did it — the note described in its own paragraph below — and it is written before the page you read is built. It holds no address, no code made from one, no browser string and not a character of anything you typed, which makes the denial unnecessary as well as untrue. The part of our program that carries that sentence is older than the door's current start, so the door is running it as it stands, and what is quoted above is what a visitor is served today — which is a reading of our code and its dates rather than a fetch of the refusal page itself. 🟢 REPAIRED IN THE MACHINE ON 2026-08-29, AND THE ADMISSION ABOVE STAYS. The false clause is gone from our code, and the door was restarted at 16:29:05Z — after the change was written at 16:27:49Z — so the part of the program now running is the repaired part. We did not simply delete the denial. All four refusal doors — the one keyed to your connection, the one for the whole page, the daily stop, and the one for a limit we cannot read — now name the record instead of denying it, because all four reach the same reading and cause the same write; repairing only the door that was caught is how the next one drifts. What a refused visitor is served today says that reading our own balance is written over a small file, the moment of the reading, and the number, with no address and not a character of anything typed, why it is kept, and that it rides our nightly backup. ⚠️ The paragraph above is not removed and will not be. A page that quietly drops the sentence it was caught on has learned nothing, and the record of having been wrong is the part that makes the rest of this page worth reading.
⚠️ A refusal is not a visit where nothing happens. Deciding whether to serve you means asking what is left in the account all of this is paid from — and that question is asked before the door decides, so it is asked on the visits we refuse exactly as it is on the ones we serve. If the reading already on our disk was taken moments ago, it is simply used and nothing further happens. Past that, your knock is what sends us to take a fresh one. There are two bounds, not one. Past the shorter, we answer you from the reading we already had and start a fresh one behind your back: you wait for nothing, and the write still happened because you arrived. Past the longer, we go and take the fresh reading before answering you at all — and you wait while we do, two questions to our broker, one after the other, each with its own patience before we give up on it. Either way it is your visit that caused it.
⚠️ And we are going to name which of the two you actually meet here. Nothing on a clock refreshes that file, so its reading is ordinarily older than the shorter bound by the time your request reaches it. So the case you should expect is the one where you wait, not the one where you wait for nothing. ⚠️ We are not going to tell you how busy this machine is. How many people knock is a fact about them and not about you, and a page that lets you infer it has handed you something that was theirs. Sentences that let you infer it have been taken out of this page wherever they appeared, including ones that were only there to make an argument — and we are not going to repeat them here in order to tell you they are gone, because a confession that quotes the sentence it withdraws has published it twice.
⚠️ And if that reading cannot be taken at all, you are refused rather than served. If our broker cannot be reached, or our own record of what we have already spent cannot be read, the part of our system that watches our spending comes back with no reading — and a limit we cannot read is treated as the limit that binds, never as a limit with room in it. The door then says no, and you get the refusal page instead of a finding. That is our own instruments being broken rather than any judgement about you, and we would rather you read it here than meet it.
When the reading is taken, this is what taking it does:
One thing is written on a refusal, and we would rather say it than have you assume otherwise: our own error output records that the door refused a request and which of our limits did it. It carries no address, no code made from one, no browser string, and not a character of anything you typed. It is a note about our machinery, in the same file described further down, and it ages out with it. ⚠️ It is also the write our own refusal page denies, quoted a few paragraphs above.
There is one other thing the door reads. When a request reaches us through a machine of our own standing in front of the grill, that machine passes along the address it received the request from, in a header. The door reads it — only when the request came from one of our own machines, only the first entry in it, only in memory, and only to make the short code described above. A value like that arriving from anywhere else is not read at all, because a header a stranger can type is not an identity anywhere. This is a different behaviour from our web server further down the page, which does not read that header at all, and we are not going to use one word for both.
⚠️ The honest weakness, and it is a real one. The counts the door keeps live in memory. A restart of the program sets them all back to zero, so somebody who happened to be at their limit gets a clean slate when we restart, and so does everybody else. And if we ever run more than one copy of this program at once, each copy counts on its own and the real limit becomes larger than the one we have told you about — by however many copies there are. Today there is one. The day's hard stop is the exception: it re-reads the run record from disk when it starts, so a restart does not reopen a day that was already closed.
⚠️ And a second one. The limits protect the expensive part — reading your form, doing the arithmetic, sending the sentence on. They do not stop somebody from knocking. A refused request still costs us a connection and the work of taking the bytes off it. The layer in front of the grill has no limit of its own yet. We are telling you where the guard is rather than implying it is everywhere.
Each place gets its own section below, with what is in it and where it lives.
We are not going to tell you how many there are. A count in a sentence is a promise about the future of code somebody is still writing. So there is no count here, and there is no "there is no sixth item" either.
What there is instead: every place we find gets named and described, and where a real line out of it can honestly be printed, it is printed. If another turns up, you will read about it here, with the date it was found and how it was missed.
Not one of the places named below contains a word of what you typed — and that sentence is about the places named below, not about a set we have closed. It is a reading of what we have found. ⚠️ Some of them carry something made out of what you typed, and that is not the same as nothing. Our spending line carries a number that moves with how much you typed and a receipt number the broker can use to look that request up at their end. The library look-up receipt carries fingerprints and lengths made from your answers, named one by one in its own section below. A fingerprint is not your words and it is also not nothing: anybody holding it who can guess what you wrote can test that guess against it instantly, and the answers to a short form are guessable. We would rather print that than have you find it.
One line is written for each run of the grill that reaches the end, whether or not it ends up naming anything. The line is written after the finding has been named — so if our own code breaks part-way through, you get the error page and there is no line about that run at all, while any spending we had already done that run stays in our spending ledger. We would rather point at that seam than let "one line per run" read as a guarantee the code does not make.
The file those lines are written into is state/grillme/runs.jsonl on our machine, and we are naming it because a record you cannot point at is not a record you can hold us to. ⚠️ This page described that file at length and never once wrote down what it is called. The name came out when we split this page in two on 2026-08-28, and nothing here noticed for a day: every check we had was reading the description and none of them was reading the name. The check that reads the name is the only reason this sentence exists, and it found the gap the day it was pointed at the right document for the first time.
Here are two lines out of that file, each carrying the date it was written. The date on each row is the whole of the claim, and the file takes a new line every time a run of the grill reaches the end.
The first is the refused run described further down — the one where the promise about named companies is what stopped the call:
{"utc": "2026-08-26T21:42:56Z", "run": "05873e228b7de737", "rehearsal": true, "demo_marker": null, "finding": null, "priced": false, "anchor": null, "claims_ok": true, "offtopic_refused": 1, "named_by": "none", "router_ran": true, "router_gate": "silent", "router_conf": 0.0, "router_refused": "none", "router_confirmed": false, "router_upstream": null, "router_billed_lane": "grill", "router_ms": 152, "router_usd": null, "router_attempts": 1, "matched_n": 0, "latency_ms": 501}And the run two seconds after it, once we had put the list back:
{"utc": "2026-08-26T21:42:58Z", "run": "cfdd396deff12fb9", "rehearsal": true, "demo_marker": null, "finding": "followup_cadence", "priced": true, "anchor": "automation_build", "claims_ok": true, "offtopic_refused": 1, "named_by": "model", "router_ran": true, "router_gate": "silent", "router_conf": 0.95, "router_refused": "named", "router_confirmed": false, "router_upstream": "Alibaba", "router_billed_lane": "grill", "router_ms": 1914, "router_usd": 6.18812e-05, "router_attempts": 1, "matched_n": 0, "latency_ms": 2256}⚠️ Now look at router_refused on the first of those two rows. It says none — which in our own record means the second reader ran and named nothing. That is not what happened. What happened is that the promise about named companies refused the call. Our code has a separate word for that, and the program running today is the one that has it — the row above was written by an older copy, before the door was restarted. We are printing the row that shows the gap rather than the row that hides it, and we are leaving it printed: a restart does not go back and re-file a row that was already written. The next refusal is the one that can be checked. ⚠️ And we are going to say how we know rather than say nobody has been refused, because we cannot see who knocks: our own record has not been written to since before the door restarted, its last line is dated 2026-08-27, and no line anywhere in it carries the word this refusal would now be given. That is what our record says. It is not the same as knowing what happened.
And here is an older one, from the same file, that shows the fields filled in when the model was actually consulted:
{"utc": "2026-08-22T14:29:09Z", "run": "447ae112af881a5e", "rehearsal": true, "finding": "missed_enquiry", "priced": true, "anchor": "automation_build", "claims_ok": true, "offtopic_refused": 0, "named_by": "lexical", "router_ran": true, "router_gate": "weak", "router_conf": 0.95, "router_refused": "named", "router_confirmed": true, "router_upstream": "Alibaba", "router_billed_lane": "grill", "router_ms": 2727, "router_usd": 0.000180096, "router_attempts": 1, "matched_n": 1, "latency_ms": 2753}Put them side by side and you will see the older one is missing a field: demo_marker. It was added to the record after that row was written. We are showing you that rather than hiding it, and it is why this page prints rows instead of counting fields: a count of them had already stopped being true, short by exactly the field that says which of our own staff ran a demonstration. So: no field counts on this page, and no invitation to make one.
Read down either row and see what is not there. No address. No browser string. No cookie. No identifier that follows you. Not a character of anything you typed. What is there is our own machinery talking about itself: which of our named findings came out, whether it was priced, which of our own anchors it used, whether our claims check passed, whether the model was consulted and what it said about its own confidence, which company's machine served it, how long each part took, and what it cost us.
Two of those fields are about us and not about you, and they are easy to confuse, so here is the difference. rehearsal marks a run of our own rather than a visitor's, and it is set before the row is counted rather than after — but it can be set by whoever is making the request, so it records an intention. demo_marker is the one that cannot: it is reachable only from our own command line, so a row produced by somebody using the web form always has nothing in it, and that is how we tell our own demonstrations apart from real traffic without taking anyone's word for it.
A separate line is written about the call itself — when it goes out, and also when our own budget stops it before it leaves, because a refusal nobody can count is a control nobody can audit. Here is a real one:
⚠️ BEFORE YOU READ IT: the file-and-line addresses inside the two records below are the machine's own, recorded by the program about itself at the moment it ran. We do not re-derive them and we do not correct them, because correcting them would falsify the evidence. They are the one place on this page where an address is not an invitation to go and look — and one of them is wrong about today's disk, which is the subject of the paragraph after the record. Every other address on this page is ours and is meant to be opened.
{"utc": "2026-08-22T14:29:06Z", "organ": "udl_grill", "lane": "grill", "provider": "openrouter", "model_requested": "deepseek/deepseek-v4-flash", "caller": "udl_grill_classifier.py:493:_spend", "caller_file": "/opt/data/scripts/udl_grill_classifier.py", "caller_line": 493, "caller_func": "_spend", "entry": "udl_grillme_server.py", "pid": 1, "route_rule": "METERED_AMBIGUOUS", "route_why": "(udl_grill, grill) is not on the internal allowlist — ambiguous routes to METERED, never to the subscription", "route_pin": null, "route_from": "openrouter/deepseek/deepseek-v4-flash", "tos_class": "AMBIGUOUS", "role": null, "provider_exclusions": null, "finish_reason": "stop", "gen_id": "gen-1787408947-wu2pueBoF4ZlpI9QTKSz", "model_served": "deepseek/deepseek-v4-flash", "upstream": "Alibaba", "tokens_in": 1044, "tokens_out": 150, "tokens_cache_read": 0, "tokens_cache_write": 0, "usd": 0.000180096, "cost_basis": "provider-reported"}No prompt text. What matters to you on that line is two things and we will name them rather than let you find them.
⚠️ And something on those rows is worth naming. Each row names a file of ours and a line number inside it. Open that file today and that line is blank — the thing it names sits further down. Take the later of the two rows: that file has not been written since 2026-08-26 21:30:26Z, and that row was made at 21:42:57Z, after it. So the program that wrote the row was not reading the copy of that file that is on our disk now. The lag it caught is closed and the row is not. The door has since been restarted onto that file as it stands, and this row still names a line that was true for a program no longer running. A record does not correct itself when the program does. ⚠️ A line number inside a record is a fact about the program that was running, not a place a reader can go and look. The earlier row cannot carry this argument — that file has been written many times since — and we are not going to let it, because one row proves it and two rows would only sound like more.
tokens_in moves with how much you typed — it is a measure of size, not of content, and it stops climbing at a cut in our own code the same way the look-up receipt's length does. gen_id is the broker's own receipt number for that request — a handle they could use to find their copy of it at their end. Our copy has no words in it. Theirs is governed by their policy and not by ours, which is the honest end of that sentence.
This record is where the answer lives to "which of our stops fired". The line about the run writes one word when our money stopped the call and a different word when our own record-keeper refused to write. Every one of the ways our money can say no arrives as that same single word, so that word tells you the family and not the reason. The record-keeper's refusal gets its own word on the line about the run, and there is a row in that file carrying it.
And that line has grown since the one above it was written. Here is one, dated 2026-08-26. ⚠️ THE SAME WARNING AS THE FIRST RECORD, REPEATED HERE RATHER THAN LEFT FORTY LINES BACK: the file-and-line address inside the record below is the machine's own, written by the program about itself at the moment it ran. We do not re-derive it and we do not correct it, because correcting it would falsify the evidence — and it is one of the addresses on this page that is not an invitation to go and look:
{"utc": "2026-08-26T21:42:57Z", "organ": "udl_grill", "lane": "grill", "provider": "openrouter", "model_requested": "deepseek/deepseek-v4-flash", "caller": "udl_grill_classifier.py:493:_spend", "caller_file": "/opt/data/scripts/udl_grill_classifier.py", "caller_line": 493, "caller_func": "_spend", "entry": "udl_grillme_server.py", "pid": 1, "route_rule": "METERED_AMBIGUOUS", "route_why": "(udl_grill, grill) is not on the internal allowlist — ambiguous routes to METERED, never to the subscription", "route_pin": null, "route_from": "openrouter/deepseek/deepseek-v4-flash", "tos_class": "AMBIGUOUS", "role": null, "provider_exclusions": null, "visitor_allowlist": ["alibaba", "novita", "sail-research", "parasail", "deepinfra", "gmicloud", "siliconflow"], "visitor_allowlist_why": "7 company(ies) allowed by the visitor allowlist, 4 denied", "visitor_upstream_verdict": "VERIFIED", "visitor_upstream_slug": "alibaba", "finish_reason": "stop", "gen_id": "gen-1787780577-hJlyMl43atKYRk00vZd2", "model_served": "deepseek/deepseek-v4-flash", "upstream": "Alibaba", "tokens_in": 1039, "tokens_out": 121, "tokens_cache_read": 0, "tokens_cache_write": 0, "usd": 6.18812e-05, "cost_basis": "provider-reported"}That row was made by us, on purpose, by putting a submission through the real grill to watch this work — it is not a stranger's. It still has no prompt text on it, which is the thing worth checking, and it is a real line out of the real file rather than an example we composed.
Three of those fields are the ones this section is about. One carries the names that were offered to the broker for that call — the list as it stood at that moment, written onto the record rather than asserted in a sentence. One carries the reading our code took of who actually served it, and the third carries which company that was. Put that beside the older line printed above, which has none of them, and you can see the change arrive. ⚠️ The names on that row are what the file held when that call went out. They are not a promise about what it holds today — the whole reason they are on the record is that a record can be dated and a sentence cannot.
⚠️ And when the promise bites, the row says so in words rather than by going missing. A refusal of that kind is written with nothing spent, with the names that were offered, and with a sentence naming what happened. We made one happen deliberately — by cutting the list down to a single company we knew the broker was not carrying that day — and this is the sentence our machine wrote:
provider allowlist: none of the 1 permitted companies could take it (offered sail-research; the
broker answered 404). Nothing was handed to a company outside that list.Read that as a rehearsal and not as an outage: we narrowed our own list on purpose, watched the refusal happen against the real broker, and put the list back. The point of doing it that way is that the last sentence is the one thing the whole arrangement rests on, and we would rather have watched it than remembered it.
Before a call is allowed, the part of our system that watches our spending checks what is left in the account it is paid from. It does not ask our broker every time. It keeps its last reading in one small file and answers from that while the reading is fresh. Once the reading is older than that, the next thing to ask — which may well be your submission, served or refused — is what makes it go and get a new one. Two visits arriving within moments of each other share one reading and cause no write. Two arriving further apart do not: the second is answered from the older reading and starts a fresh one anyway.
What is in that file, named by what each thing is rather than counted: the balance itself, what we have spent today, where each of those two figures came from, a position in our own spending ledger, the number our operating system gave the program that wrote it, and the moment the reading was taken, recorded in more than one form.
What is not in it: no address, no browser string, no cookie, no identifier of you of any kind, and not a character of anything you typed. Nothing in it is copied from your visit.
⚠️ And here is the sentence we are not going to write, because getting it wrong is how a privacy page becomes a liability. It would be tidier to write "no part of that file derives from your visit." That is not true. The moment the reading was taken is a clock reading, and when your knock is what sent us to take it, that clock reading is a record of roughly when you knocked — to the second, and in one of its forms to a fraction of one. It is not your address and it is not your words, but it is not nothing either, and "about our money, never about you" would have quietly covered it up.
One thing bounds what that could tell anybody:
And here are two things that would bound it further and are not true, printed because the false versions are the comfortable ones:
⚠️ So here is the edge with the padding taken off. On a busy day the timing of that reading tells you nothing. We are not going to tell you how busy this machine is — that is a fact about other visitors. The shape of the risk does not depend on your knowing it: whenever little else is running, a fresh reading in that file is close to a record that somebody knocked, accurate to the second and, in one of its forms, finer. That is the disclosure, and it is a property of the mechanism rather than a report on our traffic. We think the right answer is a change to our code — taking that check off the path a visitor's request travels, so a visit can never be what causes the write — and that change is written down as a proposal rather than described here as though it were already made.
We do not print a line of this one, and that is a decision rather than an omission: it holds one reading at a time and each new reading is written over the top of the last, so a line printed here would be describing something the file no longer contains — and a printed record you cannot go and check is a decoration wearing the clothes of evidence. This file is moved by something spending money, and this machine can go hours without spending any. Everything the file holds is named above instead.
It travels off this machine in our backup, along with everything else in the tree it sits in. The off-box section below says so in the same list as the rest.
A clock of ours takes a reading of our own money on a fixed short interval, all day, whether or not anybody has visited — and it writes each one down. That record is a bounded list, one row per reading: there is a limit written into our code, and when the list reaches it the oldest rows are dropped as new ones arrive — a bound by volume rather than by a clock, which is the shape the web server's log ages out by. ⚠️ We have not watched that happen. The file has not reached the limit, so the dropping is a mechanism we have read in our code rather than a behaviour we have seen — unlike the web server's log, which does roll. It is not the file described immediately above.
What is in a row, named by what each thing is: the moment the reading was taken, what our balance was, what our account has spent in total, what our key has spent across each of the trailing windows our broker reports — a day, a week and a month, each of them a figure of its own — and, beside those, what that key has spent since the day it was made, which is not a trailing window at all. ⚠️ That last figure is a running total with no window on it, so it does not age out the way the others do. That is the shape of a row, and every item in it is a figure about our money.
What is not in it: no address, no browser string, no cookie, no identifier of you of any kind, not a character of anything you typed, and no field copied from a visit. We read the code that writes it, field by field, before writing this paragraph.
⚠️ And here is the part that is not nothing, said before somebody else says it about us. The moment on each row is the clock's, not yours: it lands on the clock's own interval whether anybody knocked or not, so it is not a record of an arrival the way the file above can be. But the money figures on a row move when money is spent, and somebody using the grill is one of the things that spends it. So when little else is spending, two rows either side of a gap can show that money went out in that stretch of minutes. That is coarser than the file above by a wide margin — a stretch of minutes rather than a second — and it does not say who knocked, what was asked, or what came back. It is still more than nothing.
We do not print the interval, and the reason is the one this page gives for keeping measurements out of its own sentences: it is one edit away from being wrong.
It travels off this machine in our backup, in the same tree as the file above, and it is on the off-box list below.
We do not print a row of it either, and the reason is different from the file above. The rows are ours. Printing a real one would put our own account balance on a public page and tell you nothing about yourself. The shape is named above instead, item by item, which is the standard the rest of this page holds to.
When something inside the grill breaks in the middle of a submission, our program writes the error out, and the machinery that runs it keeps that output in a file on this machine's disk with a timestamp. It is our own code talking about itself — which program, which line, what went wrong.
It is very nearly not a request log, and "very nearly" is the honest word. The grill's own request logging is switched off in its code — no addresses, no browser strings, no paths with answers in them. But since the door got a spring, one line does land here for a request: a note that the door refused one, and which of our own limits did it. No address, no code made from one, no browser string, nothing you typed. Here is what one looks like:
GRILL SPRING REFUSED: PER_IP_BURST (per-identity) retry_after=59sThis file is not printed in full and it is not fixed: it rolls. Old lines are discarded as new ones arrive, by size rather than on a clock, so how far back it goes depends on how noisy we have been rather than on a number of days. We will not print a number of days for it, because we do not control one.
⚠️ And the part we could not close. We could not fully enumerate everything that can reach this file. We could not construct a way to get a visitor's sentence into it, and we are not going to turn we could not find one into there is none.
Before the grill answers you, it looks your joined answers up against a library of our own mined notes, and it writes a receipt for that look-up. This happens on its own, every time, before anything is sent anywhere — including when you leave the free-text box blank, because the look-up is made on all of your answers joined together rather than on that one box. A blank box is not a blank visit.
Most of that receipt is ours, and this page is going to name the dull half as well as the interesting one: the unit identifiers we matched, our own scores, the claims those units make, the paths and character offsets in our own files, and the passages themselves. Beside those it carries bookkeeping of our own — and what follows is what the program that creates the receipt writes, which is not the same thing as what ends up on one: a word naming which of our programs asked, a word naming the shape of the receipt itself, a word recording which door the question came in by (that is the marker deciding whether your words are kept or withheld, and for the grill it reads visitor), when our library of notes was last rebuilt, how many notes are in it and how many of those are indexed, and the fields left blank at the moment of writing and filled in afterwards if the look-up ever reaches something we produce: whether it reached an output at all, and which file that output was.
⚠️ The distinction inside that sentence is not pedantry. Other work of ours writes onto a receipt after the receipt exists, and reading the ones sitting on our disk turns up fields the creating program never puts there. Naming them by what each one is:
⚠️ All of those are our own bookkeeping rather than a word of yours — and the ones that are timestamps are timestamps, on a page that spends a section arguing that a moment beside an identity is not nothing. Some of them sit on receipts stamped visitor. This is a reading of the receipts on our disk on the day this version was written rather than a closed set.
⚠️ The fields filled in afterwards are join handles — a pointer out of this receipt and into another record of ours — and the section below headed "The fields that let two records be joined" is about exactly that: an identifier, a timestamp, a reference number; the bookkeeping fields are precisely the ones that let two records be joined together. This page carries a line inviting you to tell us when one of our records holds a field this page does not name. This record was holding some, in the section this page uses to explain why that happens.
What comes from you is not one thing, and we are going to name each of them rather than count them. From you, the receipt holds:
⚠️ And one more thing that is not "from you" and belongs in this list anyway. The receipt carries the moment the look-up was made — and the file's own name carries that moment as well, down to the second. Nothing in either is copied from you. But the look-up happens because you pressed the button, so when little else is running that stamp sits close to a record of when you did. This is the identical shape to the balance file described above.
How the words themselves are kept out, precisely. The program that writes that receipt takes a word saying what kind of traffic this is. The only word that unlocks a verbatim receipt is internal. Anything else — a caller that says nothing, a caller somebody adds next year, a typo, the wrong capitalisation, a blank — lands on the redacted path. That polarity is the whole fix: the caller who never thought about it gets the safe one. The grill's traffic is declared visitor, so what is stored is a marker saying the words were withheld, and the fingerprints and lengths listed above — never the words.
And it redacts the words the sentence was made of, not only the sentence. The look-up also produces the list of terms your text and our library had in common — your own words, pulled straight out of what you typed. Redacting the sentence and keeping the words it was made of is not a redaction, so those are replaced too. We know that half-fix does not hold, because we built it deliberately and ran our own checks against it: the version that redacts the sentence and keeps the terms fails our test, on the test that exists to catch exactly that, and the real version passes it — along with a second test that proves the honest internal path still records normally, so the redaction cannot be passing by breaking everything.
⚠️ The fingerprint and the length are taken from the opening stretch of your joined answers, not all of them. Past the cut the length stops climbing and sits there. Read that number as how much of your answers we looked at, rather than as how much you wrote — and past the cut it stops telling you even that. The cut is a number in our own code, and we are not printing it for the same reason we keep measurements out of our own sentences: it is one edit away from being wrong.
⚠️ And the part we are not going to soften. A fingerprint is one-way — nobody turns it back into your sentence. But anybody holding it who can guess what you wrote can check that guess against it instantly, and the answers to a short form are guessable. Read it as: we do not hold your words, we hold something that could confirm a good guess about them. The join this receipt exists for — this look-up to that run — does not need a fingerprint of your answers in order to work, and that is a fair thing to hold us to.
⚠️ Nothing deletes these, and there is no program that would. We went looking for one — for something on this machine whose job is to trim old files — and we did not find one that knows about these receipts at all. They are not protected from deletion and they are not scheduled for it. They simply accumulate, and they will keep accumulating until somebody writes the thing that stops them. That is the same answer as the line about the run, and we would rather give you the same answer twice than dress one of them up.
We do not print one of these. It is a whole file rather than a line, most of it passages quoted out of our own library — and some of the copies on our disk were rewritten after they were made, by us, on the day we found what they had been holding. ⚠️ Most were not, because most never held the words in the first place. So a copy printed here might be the record as first written and might not, and we could not tell you which without printing one. What you get instead is the list above, hedged as a reading of the file today rather than a closed set.
Separately from all of that, our web server writes an ordinary access log for the site itself. We are not going to summarise it. Here is the format line, straight out of our own web server's configuration:
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';Read the parts off it yourself. It includes where you came from ($http_referer) — a fact about you, and precisely the sort of thing a privacy page exists to disclose rather than leave off a tidy list.
And the last part is not simply "your address". It is whatever was in the forwarded-for header, written into our log exactly as it arrived. Our web server has not been told to trust that header — it never uses it to decide who you are, and the address in the first column of that line is still the one the connection actually came from.
⚠️ But it is not thrown away. Not believed is right. Discarded is wrong. Whatever is in that header is written to disk, verbatim, including a value a stranger chose and typed. We checked our own configuration to write this paragraph, and it is the configuration that settled it, not our memory of it.
When the value there is not something a browser invented, it is the address of whoever handed us the request. Usually that is you. Sometimes it is a company whose network you came through — and when it is, what we hold is their address and not yours.
(This is the web server. The grill's door is a different piece of machinery and behaves differently: it reads that header only when the request reached it through one of our own machines, and its section above says exactly how. We are not going to use one word for both.)
⚠️ We went looking for something on our side that reads that logged value, and did not find it. It is written because it is in a standard log format, not because we use it. That is a reading of our own machine as it stands rather than a closed claim about it. Writing down a stranger-supplied string we have no use for is a thing to stop doing rather than a thing to explain, and that is filed as a proposed change to our configuration rather than defended here.
Where that log actually sits. The web server does not keep a log file of its own. It writes each line straight out to its standard output, and the machinery that runs it catches that and puts it in a file on this machine's disk — outside the web server, in a part of the machine that belongs to the machinery rather than to us. It is the same arrangement as our own error output above.
We will not print a number of days for this record either. It ages out by volume rather than on a clock — old lines are discarded as new ones arrive — so how far back it reaches depends on how busy we have been. A retention promise we do not enforce with a program is not a promise, and we would rather tell you the mechanism than a number we cannot keep.
We run a rail of our own over one address and one subject line — the ones that go on our own offers — and when a message arrives on it, our machine takes a copy of parts of it and keeps them here.
What our machine keeps, named by what each thing is:
From: line — your name and your email address, as your mail program wrote them — your subject line, and the first line of your message, in your own words. ⚠️ All three are cut at lengths set in our code, and on the way into the row a run of spaces is squeezed to one and the pipe character is swapped for a slash, because the row is a line in a table and a pipe would break the table. We hold as much of your sender line as fits the cut, not the whole of it. Beside those, the row carries our own working marks: an identifier we make out of the identifier our email provider gave your message, cut short, with a letter of ours in front — so it is a borrowed handle rather than an invention — when we first saw it, what we have marked the row as, when we last touched it, how long it has been sitting there counted in waking hours, and whether the row is a test one of ours rather than a real person. ⚠️ The ageing mark is worth naming on its own — it is a duration measured from the moment you wrote to us, which is another way of holding when you wrote. ⚠️ And that first moment is not always yours. The stamp we keep is the one our email provider put on your message when it accepted it. When that stamp cannot be read, the row falls back to the moment our own program looked — our clock, in a column named for yours, and it can be hours later. The small index below records our own looking separately, which is how the two can be told apart. We are naming it because the fallback is silent: nothing on the row says which of the two moments it holds.From: line, it carries your subject line inside it, and it quotes the first line of your message back at you, because that is what makes it a reply rather than a form letter. So it holds your name and your words too.Every one of those travels off this machine in our backup, and not because we picked them one at a time. Each of them sits inside a tree the backup stages whole: the working notes file in the tree our own notes live in, and the index, the drafted reply and the file about nudging in the tree our working state lives in. We went and read the staging command, and then the step that removes things after it, and neither one excludes any of them. They are all on the off-box list below.
⚠️ There is a step whose job is to take things back out of that copy before it leaves, and none of the shapes it looks for is any of these. Adding them to it is written down as a proposed change to our code, and it is waiting on the owner of this business. It is pending, not done — until it is made, every one of these rides.
⚠️ When a reply of ours goes past our own target for answering, a clock of ours sends a message to ourselves through an outside messaging company. It goes to a channel that is ours. What that message carries, read at the bytes it builds rather than at the paragraph describing them: the identifier of the row, how long the enquiry has been waiting, what we have marked it as, whether it is one of our own test rows, where on this machine the row and the drafted reply sit, and a word saying what became of the draft our machine tried to put into our own mailbox. ⚠️ That last item is not a category. When that sweep is run by hand with drafting switched on and a draft is actually made, that word carries the identifier our email company gave the draft. That is a handle at another company, and it resolves to a record holding the enquirer's name, his subject and the first line of what he wrote. It is not a category, and it is not a path on this machine. The clocked half of this never reaches that branch — the clock runs with drafting switched off, and what it sends carries the "not requested" word instead. The hand-run half does. Your name, your address, your subject, your sentence and the drafted reply stay here. The message says where to look, and somebody here opens it on this machine.
⚠️ It did not always, and we are leaving that on this page rather than describing today's behaviour as though it had always been the behaviour. That same message used to carry the sender line, the subject, the first line of what the person wrote, and the whole drafted reply — every time the clock came round, for as long as a reply stayed late. So a stranger's name, address and words did leave this machine to a company that is not us, because we were slow. The code was changed the day it was found. A record that hides its own correction cannot show you that anything was fixed, which is why this paragraph is here rather than deleted. (What we hold as proof is a before-and-after reading of the bytes that would actually have gone out — not of the code that builds them, and not of a summary of the code.)
⚠️ And a pointer is emptier than what it replaced, which is not the same as empty. The identifier in that message is the one described in the row above: made out of the identifier our email provider gave your message, cut short, with a letter of ours in front. It is not your name and it is not a word you wrote. We know of no way to turn it back into either without the keys to our own mailbox — and that is a reading of how it is used, not a guarantee about what somebody else could do. Minting our own identifier instead of borrowing a piece of theirs is written down as a proposed change to our code. The file name in that same message is built from it, so the change would move both.
⚠️ Something else used to travel in that message and no longer does. When our machine tries to put its drafted reply into our own mailbox and our email provider refuses, the refusal arrives as a sentence, and that sentence went out in the alarm too. The alarm now carries what kind of failure it was and nothing further. This one only ever opened when something went wrong, which is why nothing that exercised the ordinary path would have shown it.
The reason that guard exists has no company's name in it and no exception we know of: nothing constrains what a failure carries. A failure that rejects a value usually quotes the value. A failure wrapping another failure quotes its argument. The failure our own machinery raises about a badly-formed address quotes the address. (We caused one and read what actually arrives: our own code never opens the reply our email provider sends back, so what it holds is a bare status line with nobody's address in it. The guard is right; that particular reason for it does not hold, and a guard held up by a wrong reason is a guard the next person deletes.)
⚠️ There are two different things our machine says about a failure, and they are not the same size. The alarm that crosses to a company that is not us carries only what kind of failure it was — that is the paragraph directly above, and it is the short one. The other is the fuller note our program prints, which is longer. Neither of them is a filtered version of what the failure said. The fuller one is built out of a short list of things we allow ourselves to print: what kind of failure it was, a status number where there is one, a single-word code standing for the company's own reason where that reason is one word, our own reference for the enquiry, a fingerprint and a size for the full text, a path on this machine, and — where whatever called it handed one over — the command that would open that path. The line is built out of that list of slots rather than out of the failure's sentence — which is a different kind of protection from a filter, and a stronger one: a filter is a guess about what to look for, and a list of slots is a decision about what may be said.
⚠️ That last slot is the one slot the list does not itself protect. The part of our machine that builds the line echoes that command back exactly as it was handed over. It checks the shape of the company's reason code, and the path it writes is one it made itself — this one it passes through. So what keeps that slot clean is the discipline of whatever called it, not the list. Today the one caller that fills it builds the command out of a path on this machine and the same enquiry reference already named two slots earlier: no name, no address, and not a character of anything anybody wrote. We would rather say where the protection actually lives than let the list take credit for a slot it waves through.
⚠️ One of those slots is filled from the failure itself. Where the company's own reason comes back as a single code with no spaces in it, that code is the company's word and it goes on the line. Anything longer or looser than a single code is dropped rather than shortened — a company that writes a sentence, or an address, where a code belongs gets that slot left empty, and our own test for this does exactly that with a planted address and watches it fail to come through. So it is not true that nothing of the failure reaches the line. What is true is that only a code-shaped thing can, and that a shortened sentence is not one of the things it can be. ⚠️ A slot filled from a stranger's failure is still a slot filled from outside, and this page would rather name it than keep the tidier sentence.
⚠️ There is no log file for that fuller note. It is printed, and where a printed line ends up depends on how the program was run. Run by hand, it goes to the screen of whoever ran it. Run on a clock, it goes into the book described next. The half of this rail that can produce that refusal at all is the half a person runs by hand: the clocked half runs with the mail-drafting step switched off, so it has no refusal to print, and we read that off the clocked job rather than off the rail it calls.
⚠️ So here is that record class: our machine keeps a book of what its own clocked jobs print. The place a clocked job's printed output first lands keeps only the newest runs for each job and then drops the rest, so a copy of each run is made into a book that sits with our own notes — the copy is what makes a run permanent, and that is the point of it. That book sits inside one of the trees our backup stages whole, and the step that removes things from the copy before it leaves looks for none of its shapes. So whatever one of our clocked jobs prints, we should expect to find in a Drive held by a company that is not us.
The copy is read on its way past, and it can be stopped. The program that makes the copy is scripts/udl_record_mirror.py. Before a run is copied, the whole of what that run printed is read — and it is read for one thing: the markers we put on our own practice runs, so that a rehearsal cannot be laundered into the record as though it were real. Two things can come back from that reading. If the marker is in the run's name or its file path, the run is dropped whole — no copy is made, and the program writes down what it dropped and why. If the marker is only somewhere in the body of what the run printed, the run is copied anyway and flagged for a person to read, because talking about a practice run is not the same as being one. So the copying reads, and the copying can remove. The reading is at :263 sch = reg.suspects(raw), the dropping at :259-262 ch = reg.refuses(meta["identity"]), and what each of them asks at :127-142 def refuses(self, identity):. Those are lines in a file on our machine, and the reason for printing them is that you can check this paragraph against the thing it describes instead of believing it. ⚠️ Line numbers move when code is edited. The file and the two behaviours are the durable half of that pointer, and the numbers are where they were on the day this version was written.
⚠️ What that reading looks for is a list of markers we keep for our own practice runs, and nothing outside that list. It is not a search for a name, an address or a phone number. ⚠️ But the honest form of that is about the list, not about you: the reading finds whatever words are on it, and we are the ones who put words on it. The book gets what our programs printed, less any run we had labelled as our own practice.
⚠️ On the day this version was written, the dropping side had never dropped a real run. The program keeps its own record of every drop, and that record holds no such line; the only place this has been seen to work is the test that exists to prove it can.
⚠️ And what is in the book today — checked by a program, on a clock, not by us on one afternoon. A cold reader called the sentence that used to sit here the worst on this page, and it was right. It said we had read the book and found no email address and no phone number in it. That was true on the day it was written and it was not a fact about any other day — the book is written to continuously by our clocked jobs, so a reading taken once and left in prose quietly turns into a claim about a present it has never seen. It looked like evidence and it was a snapshot.
So it is a program now. scripts/udl_book_watch.py reads every file in the book — 1,830 of them on its first pass — and looks for e-mail addresses, including the disguised name (at) host form, and telephone numbers in the ordinary shapes. It runs every morning at 07:00 Eastern, it writes its verdict and the moment it read to state/book_watch.json whether that verdict is good or bad, and it says nothing at all when the book is clean — so a quiet morning is a reading that happened, not a check that stopped. Its first verdict, 2026-08-29: 1,830 files read, none found.
⚠️ And it is proved in both directions, because a detector that has never said yes is not a detector. Against a planted set it caught a plain address, a disguised one, and two shapes of telephone number, and it stayed quiet on version numbers, record numbers, dates and machine addresses that merely look similar. Our own address is not exempt from it — if one of our jobs prints it into the book that is a real finding, reported separately so it can be read either way and never subtracted, because "it is only ours" is the sentence every leak of this kind begins with.
⚠️ What this does not promise. It does not say the book will stay clean, and it is not a replacement for the change described below. It replaces a sentence about one afternoon with a check that keeps running, and it is not a promise about what the next job somebody writes will print. The right fix is a change to our code — either the job stops printing the part that could carry an address, or the book stops riding the backup — and both are written down as proposals rather than described here as though they had landed.
⚠️ One half of that has landed, and it is the smaller half. The line this rail prints no longer carries the failure's own sentence — it carries the short allowed list described a few paragraphs above. So the one path we had actually traced into that book is closed at the end that writes. ⚠️ Nothing about the book changed, and nothing about the copying changed. Every other program that prints into it prints into it exactly as before. We stopped one program handing it a sentence we did not control. We did not make the book safe.
⚠️ And closing it that way created a new place on this machine. The full text of that failure — all of it, including whatever a future failure decides to quote — is written to a file of its own, readable only by the account our machinery runs as, in the directory where that rail's own working records already live. That last part was deliberate: we did not want a new corner of the machine where a person could be found, so it goes where the person already is. The alarm names that file and the one command that opens it, so an alarm we can act on did not have to become an alarm that carries a person. ⚠️ That directory sits inside the tree our backup stages whole, and the step that removes things from the copy before it leaves looks for none of its shapes. So it would ride, and it has its own line on the off-box list below. ⚠️ No such file exists on this machine on the day this version is written — one is created by a failure, and there has not been one since the change. That is a place we are naming before it fills rather than after.
We are not writing any of that down as though the change makes it fine. It ran the old way for as long as it ran. What we can say is what the alarm needs in order to do its job — which enquiry, and how late — and that it now carries that and stops.
One more thing about that rail, because it changes what all of the above means in practice. The step that goes and reads our mailbox is not on a clock at all. It runs only when one of us runs it by hand, and our own code refuses to run it any other way — a decision taken deliberately about a credential that can send mail as well as read it. The alarm step is the half that is on a clock. So nothing above gets written unless somebody here has gone and fetched the mail; after that, the clock takes over.
We back this machine up, and the backup is stored in a Google Drive we own. That is a company that is not us holding a copy of our machine, and it belongs on this page rather than in a footnote.
The backup does not cover the machine evenly, and here is the honest shape of it. It stages whole trees. The tree our working state lives in is one of them, and the tree our own notes live in is another. So, naming them one at a time:
What travels off this machine inside the backup:
state/grillme/runs.jsonl, the file named further up this page. It sits in the tree our working state lives in, so it rides out with everything else in that tree.⚠️ There is a pending change against those enquiry lines, of the same kind as the one against the look-up receipt above: the step that removes things from the copy before it leaves looks for none of their shapes, and widening it is waiting on the owner of this business. Until it lands they ride, and this list says so rather than describing the change as though it had been made.
What does not:
If you find a record that leaves this machine and is not on this list, that is a defect and we want to hear about it. The right question is never "which records did we mean to send" but "what is in that tree" — the command stages a whole tree, not a list of records.
Two things about that backup that we would rather say than have found.
It is not automatic. We read our own list of scheduled jobs to write this, and none of them takes a backup — so a backup is taken when a person here runs the command, and the copy is pushed to that Drive afterwards on a schedule. ⚠️ That is a reading of the job list as it stands today, written as what we read rather than as "nothing on a timer takes one." So the answer to "is today's record off this machine yet" is "not until somebody takes one", and that is a fact about a person's week rather than about a program.
And the part of it that removes things. There are two piles of look-up receipts, not one.
⚠️ But we cannot prove the first half, and that is the sentence that matters. Immediately after the removal, the command checks its own work — and the check looks for fewer shapes than the removal removes. The shape that matches the quarantined originals is one of the ones the check does not look for. So a removal that silently failed on exactly that directory would still pass its own check and print a clean line. A control that cannot fail on the thing it exists to catch is not a control.
So the honest sentence is longer than a comfortable one, and every part of it is load-bearing: the command that prunes removes them; it cannot prove it did; and it is not the only command that can build a copy able to leave. We are not going to write that the quarantine is stripped as though the stripping were verified.
A widened version of that command exists, and it is not the one anybody runs. It is a copy in a working directory, and it carries an edit to two lines rather than one. The first widens what the command removes: it adds the directory the live look-up receipts are written into, so that directory would be taken out of the copy being built. The second widens the check that runs straight after, so that the check looks for the shapes the removal removes instead of for some of them.
⚠️ The difference is yours and not only ours. The day that edit lands, the look-up receipts stop riding this backup — so it changes the list further up this page of what leaves this machine, and not only the paragraph about what we can prove. The off-box list carries that pending change on its own line.
What was tested was that edited copy, against a copy of a tree — not the live command, and not a real backup. So what has been proved is that a proposed edit does what it says. Nothing at all has been proved about the command a person actually runs. The live file belongs to this machine's administrator and this system's own programs are not allowed to edit it. The edit is written down and it is waiting on a person.
⚠️ We are not going to describe that widening as done. It has not been made. When it is made and run, the sentence above changes and this page carries the date it ran — the date it ran, not the date somebody wrote the edit down. Until then, what is written above is what the command does today.
For what it is worth about those kept copies: every submission this machine has recorded so far was one of ours. The grill has never been published. They are dated and they are our own test text. That is a fact about today, not a promise about tomorrow, and it is why the sentence above is about the mechanism rather than about a count.
Where you would expect a number, you will find the thing itself and a pointer to where it lives. A count in a sentence is a promise about the future of code somebody is still writing. The two rows printed above are the proof: one of them is missing a field the other has, and both came out of the same file. A record printed in full, with a machine that checks it still matches the file, does not go stale that way.
The numbers this page writes into sentences of its own are commitments we make to you rather than measurements we took — how long we keep what you give us, how fast we answer, and the age below which we do not knowingly collect anything. Where one of those commitments is kept by hand rather than by a program, the page says so in the same breath as the number, because a promise and the thing that enforces it are two facts. There are measured numbers on this page, and they are inside the records printed further up, which are printed whole precisely so that this page does not have to describe them: how many tokens a call carried, what it cost to several decimal places, how many milliseconds each part took, what the model reported about its own confidence. Those are the record rather than our account of it.
A word like only, every, none, or the whole of goes stale the same way a count does — and it is harder to spot, because it reads like a promise when it is really a census. A census of a machine somebody is still building is out of date the moment the next ordinary feature lands, and nobody edits this page on that day. So:
internal." — it stays absolute too, and names the thing it rests on, so you can see what would have to change for it to stop being true.If you find an absolute on this page that is really a census, that is a defect and we want to hear about it.
A record described inside a paragraph about something in particular gets the fields that matter to that paragraph. The rest are dull: an identifier, a timestamp, a reference number another company gave us, the fact that a long field was cut short. They are easy to leave out, and the description then reads complete.
The bookkeeping fields are precisely the ones that let two records be joined together.
So the rule this page holds itself to for records is different from the rule for lists. A record is described by reading the code that writes it and naming every field that code writes — including the ones that are about our own bookkeeping rather than about you, and especially the ones we would then have to explain. Where a field is a handle that another company, or another file of ours, could use to find you, this page names it as that rather than calling it an identifier and moving on.
If you find a field in one of our records that this page does not name, that is a defect and we want to hear about it.
This table is our account of the ways we hold information about you, across the web addresses we run and not only this one. If we ever hold something that is not in this table, that is a defect on this page and we want to hear about it.
| When | What we get | Why, and how long |
|---|---|---|
| You visit the website | Our web server writes an ordinary access log. Its format is printed above rather than summarised, and it includes where you came from. | This is how a web server works and how we notice if the site breaks or is attacked. It ages out by volume rather than on a clock, and we will not print a number of days we do not enforce. We do not build profiles from it and it is not linked to anything else. |
| You use the calculator | Nothing. | It is arithmetic running in your browser. There is no form and no request. |
| You use the free grill | The answers you typed, sent to our server when you press the button. The one you answer in your own words is then passed on to a language model we rent, through a broker — every time it has anything in it. | We need the answers to work out your finding; that arithmetic runs on our machine and none of them is written to disk. Several things on our side can stop the sending before it leaves and they are named in the box at the top — they are about our machinery rather than about you, except for the door, which is decided from your address before your form is read. It is sent, and we do not store it: those are two promises, not one. ⚠️ And one of the things that can stop it is a promise rather than a limit: if no company on the list we keep can take your sentence, it is not handed to any of them to be answered. ⚠️ Whether it reached our broker before that was settled depends on which of two refusals happened, and the box at the top separates them — in one, nothing of yours leaves at all; in the other, your sentence has already gone to the broker, and it is the broker that came back empty. The box also says what the refusal costs you. What we keep afterwards is set out above, place by place, with real lines printed where a printed line can honestly be checked. No address, no browser string, no cookie, and not a word of what you typed — but the spending line carries a number that moves with how much you typed and the broker's receipt number, and the look-up receipt carries the fingerprints and lengths named in its own section. We keep them. |
| The grill's door refuses you | Your address, in memory, for as long as it takes to turn it into a short code that cannot be turned back. Nothing else out of your form — its bytes are taken off the connection and thrown away without ever being read as a form. That is not the same sentence as "nothing else happens", and the rest of this row is what else happens. | To hold one visitor to his own limit. Not a character of what you typed is written to disk, and the short code made from your address is not written either — it lives in memory and dies with the program. ⚠️ But a refusal is not a visit that writes nothing. Deciding whether to refuse you happens after we have asked our broker what is left in our own account, and that answer is written over the balance file described above — a file that carries the moment the reading was taken, which, whenever little else is running, is close to a record of when you knocked. Our error output also records that the door refused a request and which of our limits did it. Both are described in their own sections above. |
| You fill in the form on our early-access page — a different web address of ours, not this site | Your email address — and in the same row as it, the browser's own description of itself, the page that sent you, and a network address; the first two cut at a length set in our code, the way the other long fields described on this page are cut, written into a small database on this machine. ⚠️ The network address in that row is not yours. It is our own machine's. Requests to that form reach it through our own front door, and the handler writes down the connection it is actually holding — our doorway, not your browser — so the same value lands in every row whoever fills the form in. We read that off the one row that exists as well as off the code, rather than reasoning about it. Of everything we have found and described here, this is the record where a browser string and a referrer sit beside an email address — and that is a reading of the machine as we have found it, not a closed set. We know of no other. We are not writing "the only one". Our web server's log holds the same three facts and no identity at all, and it rolls; this row holds them joined to you, and nothing deletes it. The row carries more than that. It also holds the moment you pressed the button, to the second — which matters more than it looks, because the section a little further down is about exactly how timestamps line up — a mark recording that you ticked the consent box, a number of its own that counts up as rows are added, markers saying which page and which offer the form was on, and a marker saying whether the form was running as our staging copy or the live one. The handler will store a name as well, if the form asks for one; nothing in that record carries a name today. | To email you when the thing is ready. What is here is worth naming: a browser string and a referrer, beside an email address, in a row nothing deletes. We know of no other record of ours shaped that way, and we are not writing "the one place". We went looking for a program of ours that reads those three fields and did not find one — they are written because a form handler was written to write them, which makes them a thing to stop writing rather than a thing to justify; that change is written down as a proposal. "We did not find one" is a reading of our code as it stands, not a promise about it, and one new query in one new program would falsify it with nobody editing this page. It does not travel off this machine in our backup — and the reason matters more than the answer. The backup takes one named directory from that address: the public page. The database is a sibling of that directory rather than something inside it, so what keeps it off the backup is how narrow the scope is, not the list of things we exclude. The exclusion for database files is real, and it is a belt that never reaches this buckle — it can only exclude things from inside a directory we are already taking. ⚠️ The file holding the waitlist's words is kept off by that same narrowness and by nothing else whatever: it is not a database file and it matches no exclusion we have. So the protection is one edit to one line away from changing, and a sentence crediting the exclusion list is describing a guard that is not the one on duty. We read the command to write this, and then read it again to find out which half of it was doing the work. It falls under the by-hand 24-month promise below, and like the rest of that promise, no program enforces it. |
| You join the waitlist inside our own tool — again, a different web address of ours | From the waitlist form: your email address; anything you write in the box asking what you want built, in your own words, kept whole up to a cut in our code; the moment you sent it; a marker saying which of our forms it came from; the identifier the outside email company gave you when we handed them your address; and a note of whether that company accepted our mark on your record. ⚠️ That identifier is another company's number for you, written into a file of ours — so our row and their record can be joined back to each other by anybody holding both. From the sign-up box on that address's own front page: your email address, which goes straight to an outside email company and never touches this machine at all. | To email you, and to read what people are asking for. ⚠️ Your email address is handed to an outside email company the moment you press the button — it is named in the table below with the others. Your words are kept in a file on this machine beside the database above, and that file is not staged by our backup either. ⚠️ The words in that box are kept verbatim. That is the opposite of what the grill does with its free-text box, and we would rather print the difference than let the grill's paragraph be read as covering both. Same by-hand promise, same absence of a program that enforces it. |
| You book time with us | Your name, email and time zone — collected by our scheduling provider under their policy, not by us. We then see the booking. | To meet you at the agreed time. Kept for 24 months from the booking, then deleted. The provider keeps its own copy under its own policy. |
| You email us | Whatever is in your email, held by our email provider — and, if you write to the address on our offers about the offer, a copy of parts of it on our own machine as well: your sender line, your subject, and the first line of what you wrote. A drafted reply written by our machine quotes that first line back. Its own section above says what is kept, where, and what leaves. | To reply, and to remember what we said. Kept for 24 months, then deleted unless we are working together, in which case for the life of the engagement plus 24 months. ⚠️ The copies on our own machine ride our backup off this machine, and a by-hand promise does not reach a copy already sitting in a backup. ⚠️ When our reply is late, an alarm of ours goes to an outside messaging company. It carries an identifier, an age, a status and paths on this machine — and, on the hand-run sweep with drafting switched on, our email company's identifier for the drafted reply, which is a handle at that company rather than a category. Both behaviours are described above. The copies riding our backup still have a proposed change to our code waiting on a decision rather than a paragraph defending them. ⚠️ And our machine copies what its clocked jobs print into a book of our own notes, and that book rides the backup too. The clock that watches for a late reply is one of those jobs. What is in that book is what those programs printed, less any run we had labelled as our own practice. The copy is read on its way past, and what it is read for is those practice labels and nothing else. Its own section above gives the file and the lines, and says what we found in the book and when. |
| You text or call our number | Your phone number, the number of ours you wrote to, the message text, the moment, the messaging company's own receipt number for it, and a word recording what we did with it. Carried by our messaging provider, and then written on our own machine in more than one place: into a record of its own, into the output of the program that answered you, which the machinery keeps as well, and — your number, together with the moments it wrote to us — into a file our machinery uses to notice one number writing over and over. Each of those is named in the sections above, and we are not closing the list with a word like "both" — or with a word like "every", which is the same mistake one size larger. The ones written into our working state travel off this machine in our backup; the machinery's own output does not. See the section above. | To answer you. Kept for 24 months, then deleted — except an opt-out record, which we keep indefinitely so we never contact you again. ⚠️ That 24 months is kept by hand and no program enforces it, and it does not reach the copies already in the backup. ⚠️ The opt-out record is permanent, and it travels off this machine too — the opt-out section says so plainly rather than leaving it here. ⚠️ And the door this arrives through is open: the path our phone company posts to takes a write from whatever reaches it and we do not check that what reached it came from our phone company. So a row here is a row somebody posted. The box at the top of this page names that door among our front doors, and the weakness section says what we are not checking. |
No record a visit to this site leaves behind carries your name, as far as we have found — and "as far as we have found" is doing real work in that sentence. Several of them carry a timestamp, and timestamps line up. ⚠️ The sign-up forms on our other addresses are the exception and they are the obvious one: you typed your email address into them deliberately, so those rows are about you by design and nothing has to be worked out. This section is about the records that are not.
Somebody with access to all of them at once — that means us, and anybody who ever got hold of the machine — could put the line about a run beside the spending line beside the look-up receipt and know that those three describe one visit. That is not a name, an address or an email. It is a shape: a submission at a moment, of roughly a certain size, that produced a certain finding.
Where it gets closer to you than that is the web server's log, which does hold an address and does hold a moment. We are not going to tell you that lining those two up is impossible, because it is not. We do not do it, we have no reason to, and nothing in our system joins them. But "nothing joins them" is a statement about how we built it, not a law of physics, and you should read it that way.
The straightest answer available, with the part we nearly left off: the free-text box is your switch for your words. Leave it blank and nothing you wrote reaches another company.
⚠️ It is not a switch for the whole visit. Before your form is read at all, we may ask our broker about our own account — and that question goes out whether the box is full or empty. It carries nothing of yours, and it is described in the box at the top and in the refusal section above.
This section stays on this page permanently. It is a feature, not an apology. Every item here is something we found in our own machine and would rather you read from us.
If you text our number you are asking us to reply, and we will. You are not signed up for anything else — we do not run marketing text campaigns and we will not add you to one.
Before the list: what happens to the message you send. It is carried by our messaging provider, and on our machine it is written into a record of its own, into the output of the program that answered you, which is kept as well, and — your number, together with the moments it wrote to us, though not the message — into a file our machinery uses to notice one number writing over and over. The ones written into our working state also travel off this machine inside our backup. Each is described further up this page, and they are named here rather than left to a row in a table, because a row in a table is not where you should have to find this. If there is another we have not found, that is a defect on this page and we want to hear about it.
Your opt-out is stored as a phone number on a suppression list. That is the one piece of data we keep specifically so we can leave you alone, and deleting it would defeat its purpose.
⚠️ And here is the part that does not flatter us, said in the same breath rather than buried further down. That list sits in the tree our backup stages whole, so the number you sent STOP from also leaves this machine and sits in a Drive held by a company that is not us — and because we keep the opt-out for good, so does that copy. A page careful enough to tell you that a deletion promise cannot reach a backup, and silent where the backup means an extra permanent copy of your number, is being careful in one direction only. Whether that file should be kept out of the backup is a decision the owner of this business has to make, and it is written down as one.
Anything you give us directly: 24 months, then deleted — by a person, on the day a person does it. ⚠️ So the honest form of that sentence is a ceiling, not a schedule: nothing on this machine deletes it when the clock runs out, and if nobody acts it stays. We would rather write that than let "24 months, then deleted" read like a program you can rely on. If we are working together, your business's records are kept for the life of the engagement and 24 months after it ends. You can ask us to delete sooner. These are commitments we keep by hand — no program enforces them, and we would rather say so than let a number imply a machine. ⚠️ And they do not reach a copy already sitting in a backup, which is a real limit on that promise and not a small one.
⚠️ How many times has this promise been carried out? None, and the reason is the honest one. This business was formed on 2026-07-29. Nothing we hold has reached twenty-four months, so no deletion has fallen due and none has been performed — there is no record of one because there is nothing yet to record. A promise nobody has had occasion to keep is not the same as a promise kept, and we would rather write that sentence than let the paragraph above imply a routine that does not exist. When the first one falls due it will be done by a person, written down, and named here.
The single permanent exception is an SMS opt-out record, which we keep for good — that one exists so we can leave you alone, and deleting it would defeat it. Permanent here means permanent wherever it sits — on this machine, and in the backup copies that have already left it.
The machine-written records described above are different and this page does not give them a number of days, for the reason each of their sections gives.
Each of these does one job, and each has its own privacy policy. This list is today's answer. Nothing promised on this page depends on which company is in which row — if one changes, the promises above are unchanged and this row changes with the date at the top.
| Job | Today |
|---|---|
| The machine this site and the grill run on | Hostinger — a virtual machine we rent. Their hardware, their network, their building; our software on it. |
| Booking | Calendly |
| Our email | Google Workspace |
| Phone and text delivery | Twilio |
| Turning our web address into a machine address | Cloudflare |
| The email list our own tool's sign-up forms feed | Systeme.io — it receives the email address you type into the sign-up box on our tool's front page, which your browser sends to that company directly, and the one you type into the waitlist box behind it, which our machine hands to them. It receives nothing from this site and nothing from the grill. ⚠️ And it receives nothing from our early-access page either: that form writes a row into a database on this machine and stops there. |
| The broker that routes the one sentence from the grill | OpenRouter |
| The company whose machine answers that call | One of a few named companies. The names are kept in a file on our own machine; our code reads that file and puts the names into the call itself, tells the broker to use only those, and tells it not to substitute anybody else when a name we offered cannot serve. ⚠️ If our code cannot read that file at all — missing, damaged, empty — your sentence is not sent. An unreadable list refuses; it does not open the door. ⚠️ Of those two refusals, it is the one where nothing of yours leaves — and it is not the only place on this page where nothing of yours leaves: the door and our own budget each stop a run earlier still, in their own sections. If the list reads fine but the broker cannot get any of the named companies to serve, your sentence has already reached the broker by the time we find that out — the box at the top of this page separates the two. The record of which company actually served is on the line printed above, and our own code reads that back and throws the answer away if it came from a company that was not on the list — it cannot call your words back by then, and what it can do is refuse to show you an answer we got by breaking this row. We are not typing the names into this sentence: a set of names in prose is the thing that goes stale first, and the names that were offered are written onto the record of every single call — one of those lines is printed further up this page, with its date on it. |
| Our own alarm channel | Telegram — it carries messages from our machine to us about our own machinery. ⚠️ The late-reply alarm described above carries an identifier, an age, a status and paths on our own machine. ⚠️ And one item on that list is not a category. When that sweep is run by hand with drafting switched on and a draft is made, the message also carries our email company's own identifier for that draft — a handle at another company, not a category and not a path on this machine, and it resolves to a record holding the enquirer's name, subject and first line. The clocked sweep runs with drafting switched off and never reaches that branch; the hand-run one does. The old behaviour is described above rather than deleted from this page, because a row that only ever shows today's answer cannot show you that yesterday's was worse. |
| Our own backup | Google Drive — a copy of parts of our machine, including the records named in the off-box section above |
We do not sell, rent, or share your information with anyone else, and we do not buy contact lists. We never use your sentence for advertising, never for marketing, never to build or sell a list. What the broker and the machine serving the call keep is governed by their policies, not by ours, and this page cannot make a promise on their behalf.
Doing the work means handling your business's information — enquiries, quotes, customer messages. That is not covered by a page on a website. It gets a written agreement with you before anything is connected, naming what we touch, what we keep and what happens when we stop.
Email [nick@ultimatedisciplelegacies.com](mailto:nick@ultimatedisciplelegacies.com) and ask what we hold about you, ask for a copy, or ask us to delete it. We answer within five business days, and there is no form to fill in.
This is a service for businesses. It is not directed at children and we do not knowingly collect information from anyone under 13.
If this page changes, the date at the top changes with it. We will not quietly broaden it, and when we correct something we got wrong, the correction says so rather than replacing the sentence silently.
Ultimate Disciple Legacies LLC, trading as Hundredfold Systems, a South Carolina limited liability company based in Pickens County, South Carolina. [nick@ultimatedisciplelegacies.com](mailto:nick@ultimatedisciplelegacies.com)