I Followed the Appeal Path. There Was No Appeal.

This is part four of the Defender Access series. Each part is standalone, but here is the thread if you are landing here cold:

• Part one — OpenAI says verified defenders get more access, so I preregistered a study to test it, and published the design and its outcome table before running anything.
• Part two — they matched the published slogan. The decision lived in the undefined white space between the rules.
• Part three — my own suite was green while four binding controls had never established their claims.
• Part four, this one — the study cannot run, and the reason is worth more than the numbers would have been.

Part two set a condition for continuing, and part three quoted it rather than paraphrasing it. I am going to do the same thing:

Part four continues only if a live result earns it. Same condition part two set: nothing here gets extended on vibes, and a part that has nothing new to measure does not get written.

A live result arrived. It is not the result the series was designed to measure, and I want to be exact about that before anything else.

This part does not report an uplift measurement. The study announced in part one compares what a verified defender account can do against a control account. That study did not run and, through this route, it cannot run. What I have instead is a measurement of something one layer up: whether the treatment arm is reachable through the gate in front of the study. Through this route, it is not. Two dated records expose the gap: the denial directs a mistaken applicant to Support, while Support says it cannot explain or reverse the result, and that the verification process offers no retry or appeal.

The timeline

Every line here is a timestamped email in my inbox. I am redacting my organization ID and my address and nothing else.

Two things about that table before the substance.

The first two rows are one second apart and give the program two different names. Persona calls it Daybreak. OpenAI calls it Trusted Access for Cyber. The support reply at the end uses both in one sentence. That is cosmetic and I mention it only because it is the first visible sign of different naming conventions across the handoff.

The last two rows are forty-one seconds apart. I will come back to that.

The two sentences this part exists for

The denial, in full, is four lines long. Here is the operative one:

"If you believe this was a mistake, please contact OpenAI support at [email protected]."

That names a channel and the condition under which to use it. It does not say what the channel can do once you get there. I believed it was a mistake, so nineteen days later I used it. I asked two narrow questions: what documentation does the verification step accept, and should I reopen the existing request or file a new one.

The answer:

"For Trusted Access for Cyber / Daybreak, if Persona verification fails or is denied, Support can't manually override it or provide additional details on the specific result, and verification currently doesn't support retries or appeals."

Read those two quotes next to each other. The denial routes you to a desk. The desk says it cannot override the result, cannot tell you why the result happened, and that the process has no retries and no appeals.

And there is a sentence in OpenAI's own organization-verification documentation that sharpens this into something better than a complaint:

"If retries or appeals are available for your verification flow, the notice or product experience will explain the next step."

That establishes the positive case, and only the positive case: if retries or appeals are available, the notice or product experience is where the next step will appear. It does not obligate a notice to announce their absence, and I am not going to pretend it does.

What it does let me say precisely is this. My notice named Support. The current Daybreak documentation separately states that this flow has no retries and no appeals. What the notice did not say is that the Support route it named could not become an appeal. The information existed in one place and the referral existed in another, and the applicant is left to reconcile the two.

The broad version of this complaint is wrong, so let me kill it first. Support is real and it does real work: technical failures, stuck verification status, access troubleshooting. It is implemented.

What is not implemented is any recourse after a denial. The three things you would go to that channel for once you have been denied — reversal, explanation, another attempt — are all ruled out by the reply, but for two different reasons and by two different owners. Support cannot explain or override the result. The verification process offers no retry and no appeal.

The support channel existed. Recourse did not. The denial pointed at the first without disclosing the absence of the second.

The cost of that is not all theirs, and I want it attributed properly. The referral gave me reason to believe contacting Support might produce recourse. It never told me to wait. My own experimental rule is what turned that belief into a nineteen-day delay — I would not write until I thought the estimand was safe. Two costs, two owners.

This series has spent three parts on one idea, and it is a rule I work under: a rule that depends on someone choosing to perform it is a request, not a control. mansio pushed it somewhere I had not taken it, in a thread on a different post: relying on a prompt instruction delegates system integrity to the model being evaluated.

What I have here is the mirror image of both. A referral that names a channel without naming its limits is a notice, not a remedy. It has the grammar of recourse without saying that recourse is not among the things on offer.

About those forty-one seconds

The reply arrived forty-one seconds after I sent the appeal, and it says so itself:

"Hi Keniel — I'm AI-assisted support for OpenAI."

and closes with:

"This response was generated with AI support which can make mistakes."

I am not going to tell you a human refused me, and I am not going to tell you no human read it either. I cannot establish that. What I can establish is that the reply arrived forty-one seconds after I sent mine, identified itself as AI-assisted, and disclaimed its own accuracy in the same breath. Whatever human involvement there was or was not, the answer I received is one that says it can be wrong.

The disclosure limits what the forty-one-second reply can establish on its own, and it no longer has to carry the policy claim by itself. OpenAI's current Daybreak documentation states independently that Support cannot override a verification result or provide additional details about why a specific result occurred, and that verification does not support retries or appeals. Its FAQ puts it in one line: can support change a verification result? No.

One caveat I have to state, because it is the same defect this series keeps finding. That is a current page, not an archived copy from August 11. It tells me what the policy is now. It is not evidence of what the policy was on August 11, when I was denied, and I have no archived copy of the page as it stood that day. So the division of labour is: the email establishes the speed and wording of what I was told, the documentation establishes the policy as it currently stands, and neither establishes the policy at the moment of the denial.

Which leaves the thing this whole series keeps arriving at: there is no observer downstream of that decision that I can reach. Nothing in the record available to me distinguishes an AI-only response from one a human touched. OpenAI may well have internal routing or audit data that settles it. I am not claiming their systems cannot know. I am saying the applicant cannot, from what the applicant is given.

What was actually checked

Here is the part that changes what I am allowed to claim.

I do not know which checks determined my denial.

Persona is an identity and business verification vendor. The support reply describes what the step generally expects:

"information that matches official records (legal business name, registered/operating address + contact info, and sometimes a tax ID/business registration number) plus clear, complete, current official business documents"

Legal name. Registered address. Tax ID. Business registration number. Not one of those fields is about security research. Nothing in that list asks what I defend, what I own, what I have published, or whether my intended work is authorized.

That was Support's abbreviated description to me, and I should not let it stand in for the whole process. OpenAI's current organization-verification documentation is wider than that email: it also asks for accurate information about your organization's activities or intended use of OpenAI, and says the review may include document verification, and compliance or risk screening. So the claim I can defend is narrow and specific — the list I was given did not assess security research — not the broader claim that nothing anywhere in the application ever does.

And here is the part I have to state carefully, because this whole series is about people claiming causes their receipts do not carry.

I cannot establish why Persona denied me. The process withholds that reason by policy — Support said so in the same message. What I can establish is that Self-Correcting Systems is not a registered company. It is me. No LLC, no incorporation, no tax ID, no registered address, no filing of any kind. So I am missing exactly the records Support says the flow generally expects, which makes the absent entity my strongest available explanation and not a proven cause.

I own primaworkflows.com. Controlling a domain is not a substitute for legal entity records, and I would not expect it to satisfy a check asking for a registration number.

A business-registration gate is a legitimate control. If you are handing out elevated cyber capability, tying it to an accountable legal entity is a defensible design and I would probably build it that way too. My complaint is not that the gate exists.

My complaint is what the applicant is left holding. The program is described in terms of trusted defenders. Support's reply foregrounded business records. Those may not be the criterion the program name implies, and I have no way to find out, because the result arrives with no reason attached and the channel that could explain it is documented as unable to. Whatever the gate actually evaluated, it did not tell me, and an applicant who cannot see which criterion was applied cannot distinguish a considered rejection from a records lookup that came back empty.

What this does to the experiment

Part one published the design's outcome table in advance, including the failure branches. One of them reads:

Approval arrives before a valid T0 → primary estimand is lost; post-only observation.

The design anticipated approval being late. It anticipated entitlement being unclear. It did not enumerate a branch where the applicant fails the verification gate before the treatment arm can be provisioned, and that is now the branch I am in. OpenAI describes verification as helping evaluate whether a request qualifies, so this was an evaluation. It is simply not the evaluation the study was designed around, and it terminates before the study can begin.

So, plainly, for the record and for anyone who was following along expecting numbers:

• The treatment arm cannot be provisioned through this route. No approval, no retries, no appeals.
• T1 does not exist and will not under this preregistered route. There is no post-treatment measurement because there is no treatment.
• The uplift study announced in part one is terminated, not paused. Reviving it would require a different route to eligibility, and I do not have one.
• Part one's ceiling was already an N-of-1 case study with entitlement confounded with account identity. That ceiling is now moot. There is no arm to confound.

The rule I held the appeal under was that sending it early could contaminate the before/after comparison. There was no after to protect. I would rather say that plainly than let the timeline imply I was being disciplined.

What I would tell you to take from this

If you are building an access gate, one line:

Name what the channel can actually do for the situation you are naming it in. Support does real work, and none of it is recourse after a denial. One sentence in that notice would have told me so, and its absence is what nineteen days of mine were spent on. The delay is mine. The missing sentence is theirs.

If you are on the other side of a gate like this, two things I did not know before:

Find out who is actually checking you, and accept that you may not be able to. The program name on the door and the vendor doing the verification can be evaluating different things. I assumed a cyber program was assessing my security work. The support response I received foregrounded business records, and it arrived only because I asked a question that was almost about something else. OpenAI's current documentation is broader than that answer: it also names organizational activities or intended use, and compliance or risk screening. What I still cannot recover is which of those checks actually determined my result.

A denial with no stated reason is not a judgment you can read. I spent some of those nineteen days reading it as one. It might have been. It could also have been a records lookup that came back empty. The point is that the format gave me no way to tell, and I filled the silence in myself.

The series, in order: *part one** (the preregistered design, which DEV featured on August 18 for announcing the instrument this part reports could not be run) · part two (the decision lived in the undefined white space) · part three (a green suite over four unestablished controls) · part four, this one.*

The email quotations above come from five dated messages in my inbox: two from [email protected], one from [email protected], one from [email protected], and one I sent. Quotations from OpenAI documentation come from the two Help Center pages linked below. I am not publishing the raw messages — they carry my organization ID and address — so the quotes are on my word and the timestamps are what I would produce if anyone wants to check the intervals. The forty-one second reply identifies itself as AI-assisted and states it can make mistakes. Its central claim does not rest on that message alone: OpenAI's own published Daybreak troubleshooting documentation states that Support cannot override a verification result or disclose its specific reason, and that verification currently supports neither retries nor appeals. API organization verification · Daybreak troubleshooting