Operational policy · version 1.4
Data governance and retention
Collect the least data needed for a named purpose, give access only to the role that needs it, retain it only under a disclosed rule, and do not promise deletion from a system the operator cannot control.
Data register
| Record | Location and purpose | Current retention rule | Authorized access |
|---|---|---|---|
| Same-tab chat | Browser memory and bounded request; gives immediate conversational context. | Until refresh, tab closure, or browser disposal. Not written to the app database. | The visitor’s browser; Cloudflare Worker during request; configured external model routes during attempted inference. |
| Chat security session | Signed Secure, HttpOnly, SameSite cookie; reduces repeated human checks. | Expires at the configured short session limit or browser handling; it contains no transcript. | Browser and Worker validation logic. |
| Support ticket | Dedicated domain email and Cloudflare Durable Object; lets a human answer and preserve a reference. | Database keeps no more than the newest 500 tickets. Older records are removed as new records exceed the cap. Human mailbox copies follow the mailbox provider and owner’s operating retention, which must be reviewed separately. | Christopher can access all. Andrew can access Corrections Management tickets under role controls. Service providers process delivery. |
| Support reply history | Bounded record attached to a support ticket. | At most the latest 25 sent replies per stored ticket. | The same authorized roles as the ticket. |
| Site-control and monetization revisions | Cloudflare Durable Object; permits review and rollback in separate settings histories. | All saved revisions plus current state; shown 25 per page. No automatic history pruning. Restoring a compatible revision creates a new revision rather than removing later history. | Authenticated owner and active Corrections Management account according to role. |
| Chat-configuration revisions | Cloudflare Durable Object; permits review and rollback while preserving safety floors. | All saved revisions plus current state; shown 25 per page, without automatic history pruning. | Authenticated site managers; server validation prevents removal of immutable safeguards. |
| Content drafts | Cloudflare Durable Object; stores site-update, newsletter, and social drafts. | Maximum 200 drafts. A disabled draft can be permanently deleted by an authorized manager. No automatic time-based deletion is currently claimed. | Authenticated site managers. Public visitors see only published site updates. |
| Security events and Andrew protection seal | Bounded administrative audit records for account-state changes plus a separate write-once record if Christopher permanently protects Andrew's Corrections Management account. | At most 100 events in the current audit store. If activated, the protection seal has no application deletion, unprotect, or configuration-rollback path. | Owner-only audit view; application authorization logic and service infrastructure as needed. |
| Annual AI safety counts | Cloudflare Durable Object; aggregate operational measurement. | One aggregate set per calendar year. The code currently does not set a time-based purge. | Authenticated site managers; no message or visitor identifier is stored with a count. |
| Newsletter subscriber record | Beehiiv after a visitor deliberately submits the first-party The Quiet Fight form. The address is transmitted to Beehiiv and is not added to this application’s database. | Under the publication settings, suppression/unsubscribe records, and beehiiv’s terms. This application does not hold the subscriber database or assert provider acceptance from the opaque cross-origin response. | Authorized publication managers and beehiiv under its service terms. |
| Purchase record | Etsy after a visitor chooses an external listing and transacts there. | Under Etsy and the seller’s legally required transaction-record practices. This application does not process card data. | Etsy, the applicable seller, payment providers, and parties disclosed by Etsy. |
| AdSense ownership metadata | The genuine public publisher ID may be stored in the site configuration and published through ads.txt. The site does not load advertising code, request an ad, or create a Google advertising log. | Until an authorized site manager removes or replaces the identifier. | Public visitors and crawlers, including Google. No visitor, chat, support, newsletter, purchase, child, or health information is included. |
Minimization rules
- No account is required for public reading, available free downloads, privacy requests, or accessibility reports. General AI chat may be public, require a verified member account, or require paid membership, according to its separate administrator control; other feature states still apply.
- Chris AI accepts only bounded plain text. The application does not accept chat uploads, persistent memory, user profiles, precise location, microphone, camera, or payment information.
- Support forms use fixed fields and length limits, reject arbitrary recipients, and do not store attachment contents in the site database.
- Safety measurement stores event counts, not the text that triggered them.
- No advertising provider receives a request or any Chris AI text, support-ticket content, newsletter address, purchase record, child information, or consumer health data from this application. A public
ads.txtpublisher identifier is ownership metadata, not visitor data. - Administrative secrets are not public content and must never be placed in reports, drafts, releases, or archives.
Purpose limitation
Information collected for chat, human support, owner administration, newsletter signup, or external purchase must not be silently reused for advertising profiles, eligibility decisions, unrelated websites, another client, or sale. A materially new purpose requires a data-flow review, revised notice, a valid legal basis, and new consent where required before release.
Optional member and billing records
The first-party digital store keeps immutable purchase details (member, seller, product/file, original price and currency, payment mode, and Stripe references) plus timestamps and the last payment-verification result. New order attempts stop at 10,000 records pending owner maintenance; existing orders are not silently deleted. Product-catalog saves and restores retain their own revision snapshots. Orders, catalog snapshots, and member-to-order mappings have no automatic time-based purge. Server-verified paid live orders release allowlisted private files; a public URL, account login, browser return, or test payment alone does not authorize delivery.
Member email and identifier records are stored separately from administrative credentials and chat text. Single-use sign-in links expire after 15 minutes and hashed sessions after seven days; bounded cleanup removes expired records during service use. Storage limits are 500 pending links, 5,000 sessions, and 10,000 established members; capacity errors do not silently delete established accounts. Member records and Stripe customer/seller mappings have no automatic time-based purge in this release. The owner must handle verified information/deletion requests and applicable retention obligations before public account activation.
Hosted Stripe pages collect payment details; this app stores identifiers, bounded checkout bookkeeping and the latest 500 webhook receipt references per configured mode, not card numbers, bank details or chat transcripts. Recurring access is checked against current Stripe subscription state. See the privacy notice. Account deletion, subscription cancellation, transaction-record retention, and email marketing unsubscribe are distinct actions.
Access and separation
Christopher is the protected owner. Andrew is Corrections Management for this website only. Public chat has no administrative authority. Support and owner sessions use separate security controls. Andrew remains revocable unless Christopher deliberately activates the separately confirmed one-way protection seal. That seal does not elevate Andrew's role; it removes the running application's ordinary unprotect and deactivation paths. All other access should follow least privilege, be removed when no longer needed, and be reviewed after any role, credential, provider, or ownership change.
Deletion and verified requests
A privacy request requires enough information to locate the record and verify that disclosure or deletion will not expose another person’s data. The operator should document the request, systems checked, action, exception, downstream provider request where available, decision date, and appeal. The operator must not ask for high-risk identification when a less intrusive method works.
Count-based limits are retention criteria, not a promise that a record disappears after a fixed number of days. The current application does not claim a complete time-based deletion system for mailboxes, annual counts, or all provider records. That limitation is deliberately public so it can be governed instead of hidden.
Processor and vendor gate
Before adding or materially changing a provider, the owner must record the feature, data categories, purpose, locations, retention, deletion support, security terms, subprocessor information, incident-notice terms, cross-border transfer basis where relevant, and who can configure the account. A provider change that affects health-related chat, subscriber data, purchases, or authentication is a high-risk change and requires updated notices before activation.
Review and evidence
Corrections Management maintains the data map and code-to-policy checks. Christopher approves purposes and material changes. Review is event-driven and scheduled quarterly. Evidence should include the deployed code revision, site-control revision, provider documentation date, test results, approval record, and unresolved items. No checklist result may be described as a legal, security, or accessibility certification.
Document owner: Christopher M. Caballero · Maintenance: Andrew, Corrections Management · Version 1.4 · Effective September 5, 2026