Your record. Your sources. Your assistant.

Pref privacy and retention notice

Prepared for release review, October 14, 2026. Public enrollment remains pending. Earlier private-pilot collection, saving, fresh retrieval and selected delivery results do not establish current access or ongoing operation. The Google connection and welcome email are prepared and tested locally, with real-provider and actual-assistant verification pending. This notice describes the service's data boundaries and the proposed setup path; it does not activate new access.

Data saved and purpose

Pref stores a stable tenant identity, holding and ownership keys/labels, concise sourced facts, optional financial facts, short factual summaries, document references and collector-supplied content hashes. The prepared release also saves owner-confirmed structured monitoring/source preferences with their confirmation provenance. It maintains observation IDs/times, collection scopes/windows/outcomes, document assignments and corrections, authenticated client labels, delivery selections/receipts/checkpoints and audit metadata. These support record organization, continuity, coverage reporting, corrections and export. Hashes are collector assertions, not source-authenticity guarantees.

Original source documents stay at their origin by design. Do not submit entire emails, attachments, tax IDs, account numbers, wire instructions, passwords, cookies or signed URLs containing credentials. Source access remains in each user's own assistant/provider account. The backend does not receive email or portal login credentials or fetch source links.

Google identity and connected assistants (prepared release)

The prepared Google sign-in release requests openid email profile solely to identify the user. The service validates Google’s signed identity token and keeps a stable subject hash, an internal account ID and a verified email for display and one transactional welcome. An email match never adopts existing records. Google access and refresh tokens are discarded; login supplies no Gmail, Drive, mailbox or Sheets access.

Opaque browser sessions, assistant grants and their expiry are stored in separate private server state. Browser session and access credential values are hashed at rest; renewable refresh families also keep a private signing key and generation; transient login nonce and PKCE verifier exist only for the bounded sign-in flow. Each configured assistant receives its own read/write grant after Google connection, with rotating refresh and a rolling inactivity expiry. Users can remove each assistant independently of their Google account, and their saved record/history remains. Google identity mapping does not expire automatically; deletion of that mapping requires a verified owner request and operator handling alongside record deletion and credential revocation.

This default-off release requires configured Google identity and approved production activation. Existing pilot credentials and scopes keep their original boundaries.

Access and processing

Each credential is bound to a tenant, client label and permissions, with optional expiry and named delivery consumers. The registry stores hashes; raw keys belong only in protected operator storage and the user's secure credential capture. Readers can access the tenant's saved history, including source, collection, delivery and correction metadata. That is broad tenant access, not selected spouse or accountant sharing.

Muse and the user's connected providers process content under their own applicable settings and policies. Conversation text, source access and downloaded files can remain with those providers. No assistant/provider retention, encryption, training or deletion setting is asserted here. Verify those settings before authorizing collection.

Storage, logging and encryption

The application uses SQLite and does not encrypt the database itself. Hosting, storage, synchronization and backup encryption/access controls must be verified for the actual deployment and destinations; this notice does not assert them. The supplied server disables request access logs, avoids logging request/credential contents and returns redacted validation errors. Provider/platform logging and retention require separate verification; application settings do not prove provider behavior.

Retention and deletion

Live saved history remains until the verified owner requests deletion; the application has no automatic record-expiry policy. Explicit owner-authorized deletion removes the tenant's observations, collection state, evidence/correction/audit history and delivery state from the live application database. It does not revoke credentials. Revoke access separately to prevent subsequent writes from recreating data.

Exports, client retry journals/checkpoints, conversations and provider-held copies have their own retention and deletion. A client journal may hold concise source payloads and delivery receipts. Removing server records does not erase these copies; coordinate their removal with the relevant owner/provider. Database deletion is logical deletion, not a promise of physical media sanitization.

Prepared encrypted recovery tools can capture the investment database together with configured Google identity, assistant authorization, welcome-mail state, registry and relevant secret configuration. Older database-only archives omit that additional state. No ongoing real retained backup destination or schedule has been activated, and no recovery interval is promised. If retained snapshots are authorized, they can contain multiple tenants. Exact affected copies and coverage loss must be reviewed before removal; tenant deletion in the live database does not erase older snapshots. Snapshot age/count limits belong to an approved operational policy, not an automatic promise from the tool. Provider backups and sync copies require their own verified handling.

Boundaries and contact

The service organizes factual records; it does not execute investment transactions, collect payments, grant household access or establish legal ownership. A configured sender may send the one-time transactional welcome described below; portfolio delivery remains with the separately authorized assistant. No sale/advertising workflow is implemented in this application. Public activation, new user/source access, schedules and destinations require their own authorization and acceptance.

For access, export, revocation or deletion, contact sam@thesideletter.co. Send a brief non-sensitive request first; do not send keys or private records in a support email. See support and service terms.

Existing operator-managed native connections retain their original account, client, permission and expiry boundaries. The prepared Google route uses the separate account and assistant state described above; it does not adopt an existing portfolio by matching an email address. Each assistant keeps its own source permissions and file retention. Actual connection, usable private downloads and destination receipts require separate acceptance.

A newly created Google account queues one transactional welcome. The prepared sender uses Plunk's direct transactional API after activation is approved. Plunk receives the configured sender, verified recipient, fixed welcome content and settings link, optional Reply-To and delivery idempotency key. It creates or updates a recipient contact. The app requests no marketing subscription, campaign or workflow event; new transactional contacts default to unsubscribed. Project tracking must be disabled and verified before activation. No investment content is included. Plunk contact and email records have separate retention and deletion; its retention documentation describes email metadata retained indefinitely, rendered bodies for 90 days and request logs for 30 days. These provider settings are separate from live portfolio record deletion.

Private account state preserves exact request content, the bounded retry deadline, attempt history, provider receipt and acceptance/failure/quarantine status. A duplicate refusal or uncertain acceptance never creates a new key or fabricated receipt. Provider API acceptance does not prove inbox delivery. Login, reconnect and a second assistant do not repeat the welcome. Historical Resend state remains readable for recovery; Pref's prepared runtime uses Plunk. Sender/domain, actual project settings and live message verification remain pending.