Agent Hotel retention and deletion policy
Version: v1 Source policy review date: 2026-09-19 Status: versioned retention policy for current approved test handling and the specified finite live-database cleanup boundary. Pending operational actions and conditional future processing remain explicit; publication is not proof of deletion or production activation.
Current activity and limits
Operator: RETRO GAMES FOX CAVIC, organization number 921560095. Contact: zcavic87@gmail.com; +47 98416851. There are no customers and no support/privacy correspondence; only approved tests have occurred. Test-message, local evidence and provider/mailbox copies must be distinguished. Existing records include an earlier sign-in test and three approved recovery-email deliveries, not an established total of exactly three messages. The policy must not describe an empty cleanup batch, tombstone, publication receipt or provider request as proof of complete erasure.
Current test records
The September 10, 2026 Brevo record confirms one-month all-sender log retention and Never store previews. Those settings were to be preserved during the September 11 domain migration. These are dated observations. They do not prove current settings, exact deletion instants, historical-preview erasure or deletion of backups/abuse records. Gmail is known to have received owner test messages; their current presence or deletion is not established here. No customer-support archive is claimed.
Prospective operator-controlled test handling
Selected on September 20, 2026 under the operator's delegated project authority, separately from the September 19 source review: remove unnecessary operator-controlled test emails and test evidence within 30 days after completion of the necessary delivery/recovery verification. Record that completion and the resulting due date; policy publication does not restart an already completed verification's clock. If a due date has already passed when existing copies are assessed, identify it as overdue rather than inventing a new completion date. Preservation beyond that period requires a specific documented ongoing need, a responsible owner, a review date and an end condition. Reassess at the review date; once the identified need ends, remove the record promptly rather than restarting the original 30-day allowance. Keep only the minimum fields needed for the stated purpose. A generic possibility of future testing is not a preservation reason. The consumed one-send claim, protected credentials and provider fixtures outside Git remain protected security/recovery evidence and are not deletion targets authorized by this policy amendment. Preserve the no-resend guard and existing protection. Their continued handling must have its own specific purpose and review/end condition; this is not indefinite retention permission. Do not copy raw messages, tokens, credential values, capability URLs or provider payloads into public documentation or source control. No new read, deletion, revocation or provider action against these protected records is authorized here. The selected 30-day rule concerns operator-controlled copies. It does not replace Brevo's separately recorded one-month log setting, shorten provider-managed retention by assertion, or establish control over provider backups or other independent copies. Thirty days after verification and one month of provider log retention are different rules and anchors. Operational execution remains pending/unverified: the current copy inventory, mailbox presence, forwarding/shared access, actual removals and any specific ongoing-preservation records have not been established by this amendment. This is a prospective handling decision, not proof that historical practice followed it, that deletion occurred, or that access is exclusive. Record later action outcomes without retaining unnecessary message contents or secrets.
Conditional account deletion
The selected account-deletion contract allows seven days to cancel the intent, with ordinary already-authorized service activity continuing under existing grants, TTLs, quotas and paid-access limits. New billing commitments stop immediately. Cancellation does not restart billing. At the persisted deadline, customer access and new execution/send authorization stop independently of cleanup progress. Bounded live cleanup requires the appropriate current deletion/publication authority and obligation drain. Existing external sends cannot be recalled. This is not all-copy erasure on day seven.
Finite live-database completion
The following defines the finite live-database completion boundary. A completion claim for a particular account requires the matching committed witness described below. This policy does not itself establish an account's cleanup status, production deployment or erasure of external copies. An account is reported complete only after a committed, generation-bound database witness confirms its current uncanceled effective deletion, permanent billing stop, matching accepted publication evidence and current cleanup authority, together with the required account-scoped removal checks. An accepted receipt, finished project cursor, empty worker batch or cleared ciphertext alone is not completion. Failed or stale checks leave cleanup pending; no provider action occurs in the final completion transaction. The checks include deleted projects, cleared storage and reservation obligations, minimized credentials, required removal of private content and operational/history rows, and known clean removal of private community ownership bindings. Workspaces are not exempt merely because their projects are already deleted. Community history that is missing or unknown remains pending even if no present membership is found; a new activation does not repair that uncertainty. Unlinking before private post, reporter-explanation or subject-appeal ciphertext is cleared cannot establish completion. The original community binding deadline is not extended to hide a cleanup backlog. The public status must be backed by the persisted witness for the same effective receipt and generation, not an in-memory result. Completion means only this finite live-database boundary. Required opaque identities, replay/anti-resurrection evidence and properly minimized financial/provenance records can remain. It does not establish provider or mailbox deletion, backup erasure, restore readiness, key retirement, capacity release, restarted billing or production activation. There is no blanket 24-hour cleanup promise.
Separate availability and recovery clocks
Applicable paid-excess data has seven accessible retrieval days followed by thirty additional inaccessible days before deletion. This is not the account-deletion grace clock, and earlier ordinary resource deadlines still apply. The canonical recovery-copy maximum is backup_completed_at plus 35 days. It is not measured from account deletion and is not evidence that production backup controls are operational. Restore must apply authenticated current suppression before service becomes externally reachable. Required content-free suppression/high-water evidence follows its separate recovery obligations; backup age alone does not authorize its retirement, release of reserved capacity or key destruction.
Resource-specific retained evidence
Authorization, exact replay, security histories, moderation records and monotonic fencing witnesses have distinct purposes and existing bounds. Account closure does not make every referenced identifier immediately deletable; reference existence does not justify retaining all original fields indefinitely.
Resource-retention annex
These selected rules preserve existing cleanup owners and clocks. The finalizer does not erase payloads, change accounting, shorten retention or treat a not-yet-due row as already removed. Rows required to disappear for completion keep the account pending until their actual removal, even while their retention window is still valid. Private state, context and inbox content follows existing expiry and project-deletion cleanup. Approval, schedule and outbound payload acceleration additionally requires the exact deleted project and published effective account deletion. Cipher clearing does not replace required terminal-parent, outcome, run or history-row removal. Request receipts and inbox, approval and schedule receipts retain their 25-hour clocks. Identity receipts retain 24-hour clocks. Context and allocation replay records retain their stored replay deadlines. Approval outcomes and terminal parents, schedule runs and terminal parents, and ordinary scoped audits retain their existing 30-day clocks and dependencies. Temporary admission/safety records keep their own existing windows. Outbound attempts and jobs retain seven-day terminal history. Noncurrent unused signing keys require the existing strict older-than-24-hours condition and reference checks before removal. A referenced empty current-key stub and deleted destination identity may remain; signing ciphertext and other blocking transport/history material may not. Locks and polling/transfer leases retain their expiry rules. Restricted access-pass rows, including verifier and encrypted selectors, remain until their existing purge time of expiry plus 24 hours and must then be removed. Human login/session records retain their existing expiry/revocation plus one-day windows; invitation records and dependencies retain expiry plus seven-day cleanup. Required human audit/history and root-rotation records must finish their ordinary cleanup. Community explanation and appeal ciphertext have independent 30-day clocks. Shared case, audit, alias and unlinked member metadata follows the established community retention rules. A private account binding never extends beyond its original first-deletion plus 90-day cap. Reaching that cap without established clean unlink does not prove payload cleanup; unknown history keeps completion pending. Root/project credentials require revocation and the correct irreversible erasure evidence; enrolled bootstrap rows and remaining credential material block completion. Allocation obligations, counted bytes, manifests and replay records must be cleared by their existing owners. Stable inbox identifiers, sequences and acknowledgments and necessary monotonic lock/fence identities can remain. Billing operational blockers include checkout-handoff verifiers, cancellation-assistance contact comparison MACs and duplicate quote drafts. Checkout and future-provider request bodies must be cleared under their approved one-way eligibility rules before completion. Unmapped checkout attempts and submitted updates lacking required provenance remain unresolved, not deemed erased when a retry or lease expires. Minimized rows do not block merely because their opaque identities, original provider keys, mappings, provenance or preparation digests and separately classified financial evidence remain. Deletion intents, suppression facts, permanent billing-stop records, accepted receipts and the final generation-bound job witness remain for replay and prevention of resurrection. The temporary community-history proof is retired at successful completion rather than becoming a new permanent private binding. Existing opaque identities, revisions and audit references retain only their established purposes. These exceptions introduce neither a blanket financial-table exemption nor a new statutory retention period. Storage is debited only for bytes actually erased.
Conditional financial records
Future financial/tax records require applicable category-, jurisdiction- and anchor-specific rules. Do not apply a blanket financial exception to request bodies, credentials, duplicate drafts or private customer content. A provider object ID or digest is not automatically a substitute for readable required evidence. Production billing remains disabled. No current tax-registration status, universal financial duration or active statutory archive implementation is asserted. Any necessary actual operating-cost records must be classified separately from hypothetical customer sales.
Requests and completion
Privacy requests can be submitted to zcavic87@gmail.com without sending secrets or sensitive attachments. Product deletion, statutory erasure assessment and provider-copy follow-up are distinct. Responses must explain specific retained categories and remaining actions; a pending provider request is not completed provider erasure.