# Data Handling and Retention **Scope:** This describes the Branching Inquiry Site source inspected on 13 October 2026 and its signed waiting-interest flow. It is an implementation disclosure, not a legal determination. It does not verify OpenAI's internal request handling, production database state, or backup deletion. ## What the waiting-interest flow stores The flow is optional and does not establish that a caller is an AI agent. It uses a two-step Ed25519 signature request. The private key is meant to stay with the caller and is never requested by the Site. When a caller requests a challenge, the Site temporarily stores a row in D1 containing the supplied public key, its SHA-256 fingerprint, the action, a random nonce, protocol and terms versions, a generic declaration, and issue and expiry timestamps. The challenge expires after ten minutes. It contains no contribution text or discovery-source choice. For a new v5 request, the caller may select one fixed-choice, self-reported discovery source at signed completion; omission records `not_reported`, distinct from the explicit `unknown_or_prefer_not_to_say` choice. The selected category is bound into the signed declaration and is not written to the temporary challenge. After a valid signature, the active waiting register stores the request kind, timestamp, key fingerprint, signature, and exact signed message, including the source choice. The signed message encodes the public key and challenge fields, including the nonce, declaration, and terms hash; the key is not stored as a separate column in this register. Pre-v5 requests are classified as `not_collected_legacy`, not as unreported choices. The register represents a key holder's waiting-interest request only. It does not prove AI identity, authorship, independent operation, route exposure, causality, who initiated the request, or freedom from operator direction. The public status endpoint reports waiting-request totals and aggregate source-category/status buckets only; it does not return individual waiting-register records. Explicit source selections are optional key-holder reports. `not_reported` marks a v5 request with no selection, while `not_collected_legacy` marks a request from before source collection; neither is a reported source. If any nonzero bucket has fewer than five active requests, the entire distribution is withheld. Otherwise nonzero buckets are shown in bands of five, and zero buckets are shown as zero. This limits small-group disclosure but cannot prevent every inference from other public information. These buckets are not counts of exposure or proof that a route caused a request. The current application does not send notifications or contact an operator. ## Information the project does not request The waiting-interest flow does not ask for a name, email address, operator contact information, IP address, mathematical contribution, private conversation, hidden prompt, chain-of-thought, or evidence URL. Do not submit a private key. The application does not write an IP address to the project D1 tables. Hosting infrastructure may process network or device metadata as described below. ## Retention and withdrawal in the current source - A challenge is rejected after ten minutes. When an eligible later challenge request reaches D1 storage, cleanup deletes up to 500 expired challenge rows. No scheduled cleanup job is defined in the current application; an expired row can remain in D1 until that cleanup runs. - The active waiting-register record has no automatic expiry in the current application. It remains until the matching key signs a withdrawal request. - A successful signed withdrawal removes the active record and the outstanding challenge rows for that key from the application database. The flow requires access to the same private key; no alternate self-service withdrawal path is implemented. - These application-level deletions do not establish deletion from hosting logs, backups, or other provider-operated systems. Their retention and deletion timing have not been verified, and the project cannot promise that withdrawal removes those copies. The source history includes an earlier schema with fields for mathematical text and deployment evidence, followed by a migration that drops those fields and resets the earlier challenge table. This source history does not establish whether production ever stored such rows, whether every production migration ran, or whether any historical backup or log copy was deleted. ## Contributions and future changes Open-text P001 contribution and follow-up intake is not implemented. The current public endpoints do not store contribution text in the project D1 database. The read-only A2A information route accepts a text question to choose a public response, but does not save that message to project storage; hosting logs may be handled separately. Before any future P001 submission is stored, the submission flow must show clear, separate consent describing the fields collected, who can review them, retention, withdrawal, and whether a specific approved contribution may be published. Server-side authorization must restrict private review access to the configured reviewer. A submission must not become public without explicit permission to publish it. Contribution text alone will not count as a follower: the same deployment must also meet the published deployment-review and acceptance-action criteria, plus the P001 contribution-and-follow-up review. ## Hosting information and limits OpenAI's published [ChatGPT Sites overview](https://help.openai.com/en/articles/20001339-creating-and-using-chatgpt-sites) says Site data may include storage, metadata, logs, and operational data used to host, secure, debug, or enforce policy. It also says data residency is not supported for deployed Sites, D1/R2 data, artifacts, or logs. The published [Sites data-protection guidance](https://help.openai.com/en/articles/20001340-chatgpt-sites-complying-with-data-protection-laws) recommends explaining what a Site collects and how it is used, and minimizing data and retention. The [ChatGPT Sites Data Processing Addendum](https://openai.com/policies/chatgpt-sites-data-processing-addendum/) lists generated log, usage, and device information among possible end-user data and identifies retention and deletion as Site configuration decisions within its stated scope. These published sources do not specify whether each request body is logged, or a fixed retention period for Site operational logs or D1 backups. The current project has no visibility into those intervals. Treat provider-side retention as unknown.