Data Retention and Deletion Policy

Email verification and Fit Check authority

• The candidate source design requires email-verification challenge rows to be deleted after seven days.
• It requires verified sessions and unused Fit Check authorities to expire and be deleted approximately 30 days after expiry when not linked to a valid later-approved order.
• If later activated, a Fit Check authority linked to a valid paid order would become part of the paid-order integrity record and follow the paid-order metadata period below.

Request-fit files

The source contract handles buyer-request bytes submitted to the free request-fit check inside the processing request without authorizing reusable working-upload storage. Exact runtime operation requires release-bound evidence. The fit result and limited operational metadata may remain with security, support, or order records as described below.

Source uploads

The source contract handles buyer-request and source-file bytes inside the processing request without authorizing reusable working-upload storage; exact runtime operation requires release-bound evidence. Files explicitly marked as downloadable evidence may be copied into the generated private ZIP.

Generated output

The contract scopes customer download access for a generated ZIP to the earlier of the paid order's 30-day access-window expiry or 30 days after that ZIP was generated. The Console is designed to enforce this access deadline even if storage deletion has not completed yet. Universal private-storage and deletion-lifecycle operation is not claimed.

The candidate storage policy calls for asynchronous lifecycle deletion after access ends and a seven-day provider soft-delete recovery window, with Console access disabled during that recovery period. Exact bucket configuration, deletion execution, and recovery behavior require dated release-bound production evidence. Order, package-identifier, billing, and integrity metadata may be retained separately where a later approved order and law require it.

The same-request re-run window lasts 30 calendar days from the original purchase. Each re-run requires the customer to submit its authorized source records again because prior request and source bytes are not retained as reusable working uploads.

Human-support records

A human-support ticket may include the requester's business contact details, message, safe route and order references, selected decision concern, assigned queue, response state, and provider delivery events. The selected concern is only a classification and versioned response aid for the human operator; it does not choose the assigned queue and is not used for routing the request or changing Fit Check, price, eligibility, or evidence classification.

The candidate support-record policy requires tickets marked resolved or closed, their delivery records, and their selected concern to become eligible for deletion one year after recorded resolution and to be deleted no later than two years after creation. Open or reopened tickets use the two-year maximum rather than being treated as resolved. An active documented legal hold with its actor, reason, approval reference, and end time pauses both limits only until that end time; an expired hold no longer pauses deletion. These periods are separate from the seven-year paid-order and accounting period below.

Measurement and optional public analytics

The candidate measurement policy limits Fit rows for fit_started, fit_passed, and fit_failed_reason to no more than 30 days. These measurement rows are distinct from separately governed paid Fit, order, invoice, and entitlement authority metadata. Other privacy-bounded first-party server measurement rows are retained for no more than seven years.

The candidate optional-analytics design uses a consented same-origin first-party relay only on these approved non-sensitive public routes: /, /buyer-review-pack, /choose-the-right-workflow, /faq, /how-it-works, and /what-you-receive. The browser loads no PostHog browser SDK or other third-party analytics code. The browser sends no buyer-request, source-record, evidence, evidence-binder index, generated statement, manifest, receipt, or package content through the analytics path to the relay or PostHog. Local, preview, and testmode builds cannot reach the production analytics project.

A consent grant is bound to the current Cookie Notice, legal-policy manifest, and release. A stale grant causes the site to re-prompt before optional analytics can resume. Revocation removes the signed server consent authority. This policy does not state a PostHog provider-retention duration; AttestLayer will publish a duration only after the exact production-project retention setting is versioned and verified.

Billing records

For a later valid order, the contractual retention target for paid Fit Check and order metadata, purchase intents, Stripe event references, entitlements, transactional outbox records, resolved operational alerts, provider delivery metadata, and payment, invoice, refund, tax, and accounting records would ordinarily be seven years. This period supports billing, accounting, fraud prevention, service integrity, customer support, and dispute handling. A record may be retained longer where law requires it or a preserved legal hold applies.

Transactional email delivery

The candidate transactional-email contract treats a definitive pre-acceptance rejection as safely retryable. An ambiguous transport result is quarantined for manual reconciliation and is never blindly auto-resent. SendGrid processed or accepted means the provider accepted the message for handling; it does not prove inbox delivery. Only a provider delivered event marks the message delivered. Provider message identifiers, attempt state, delivery outcome, bounce, and complaint metadata follow the paid-order retention period above.

Security logs

The policy target for security and abuse-prevention logs is up to 90 days unless an investigation, dispute, fraud-prevention need, or law requires longer. Actual production coverage and deletion remain evidence gates.

Controlled assurance-room audit metadata

If the access-restricted assurance room is activated after its protected database-role gate passes, its purpose-specific audit record covers grant issuance and revocation, artifact lifecycle, access decisions, completed and interrupted downloads, and expired-event purges. It may include actor identifiers, timestamps, and hashed direct-peer IP and user-agent values. It does not contain customer source files or private package content. This narrowly scoped audit metadata is retained for no more than seven years, except while a documented legal hold requires preservation. It is a separate retention category from the 90-day security and abuse-prevention logs above.

Registry commitments

Registry inclusion is separate and is not currently active for Buyer Review Pack issuance; current Buyer Review Pack generation does not create a new Registry commitment. Historical public commitments, where previously issued, may remain indefinitely. A Registry commitment contains cryptographic hashes and signature material, not the submitted source files or recoverable source content.

Deletion requests

For personal-information requests, email privacy@attestlayer.com. AttestLayer may retain limited information where required for law, accounting, security, fraud prevention, or dispute resolution.