Privacy Policy

Last updated: 2026-08-06

Effective: 2026-08-31

Day Trader additions effective: 2026-08-06

This Privacy Policy explains what information Slatemark (formerly traider; “we”, “us”) collects when you use the Service, how we use it, who we share it with, and the choices you have. It is part of and incorporated into our Terms of Service.

1. Information we collect

We collect only the information we need to operate the Service:

Account information. Your email address, authentication tokens, and (optionally) a display name. We use Stytch as our identity provider; Stytch may collect additional metadata as described in its own privacy policy.
Subscription and billing information. We do not store your payment-card numbers. Stripe processes payments on our behalf and provides us with a customer identifier, the plan you are on, and high-level subscription events (created, renewed, cancelled, payment failed). Your payment details are stored by Stripe under its own privacy policy. If you begin signup from a link carrying bounded source or campaign labels, we may store those labels with your subscription row until account deletion to measure how accounts first found Slatemark. A share-receipt referral identifier is not copied to that row; only the receipt campaign class is retained there.
Brokerage connection credentials. If you link a brokerage account, we store the per-user connection credential SnapTrade (our brokerage-connection provider) issues to us, which we use to read your Account Data on your behalf. It is not a brokerage-issued credential, and we never receive your brokerage password. It is encrypted at rest with a per-environment AWS KMS key and is scoped to your user identifier; no other user can access it.
Brokerage Account Data. When you link a brokerage account and authorize it, we read your Account Data (balances, positions, orders, and transaction history) and store the portion needed to power the account, order, and transaction tools and to build your trade journal and Strategy Scorecard: an encrypted record of your fills and the journal entries derived from those fills. In addition to finalized fills and journal entries, we temporarily store provisional execution records (including symbol, side, quantity, price, and opaque identifiers) to safely reconcile delayed brokerage activity. Unresolved provisional records are retained for a maximum of 120 days. We limit what we collect, use, and retain to what is reasonably necessary to provide those features, and we keep this core financial data only for as long as the brokerage link is active. We never use your Account Data for advertising, marketing, or cross-selling, and we never sell it. Unlinking a brokerage connection deletes the Brokerage Account Data derived from that connection. The separate operational records needed to synchronize and protect this flow are described as Derived Operational Metadata below.
Derived Operational Metadata. We store limited, user-linked records about how your account and requested features operate. This metadata is personal information, but it is separate from core Brokerage Account Data even when it is produced by or associated with a brokerage connection. Brokerage-related records include broker- and connection-scoped synchronization state, service-use records for brokerage-import and holdings milestones and broker-created journal activity, and bounded metadata about holdings reads. Synchronization state records the last successful poll and accepted manual-sync times, whether the initial backfill completed, whether brokerage activity was observed, the attempt sequence and random ordering token used to keep overlapping reads in order, and the time the state last changed. Service-use records can include a broker-derived journal-entry identifier, which can encode an account reference, symbol, and activity reference; an opaque connection identifier; source type; connection provider; and connection generation. They can also record whether a first fill or holdings result was observed, whether a broker-created journal entry was tagged or annotated, or whether its written-reason prompt was dismissed. Holdings-read metadata records the source and schema version, the oldest last-successful holdings synchronization time SnapTrade reports across the accounts in a complete result, whether the read succeeded, whether the result was complete, and the number of positions. It contains no account identifier, symbol or contract, quantity, price, cost basis, or P&L. We also store per-user markers and event rows for selected onboarding, setup, subscription, journal, sharing, and Strategy Scorecard activity so we can measure feature use, avoid repeating completed steps or dismissed prompts, and improve the Service. These records can include a timestamp and bounded details such as the AI client, analyst type, credential type, plan, tool, provider, skill, or workflow step involved, and include a row for each Strategy Scorecard view or export. Account-linked one-time milestone, current-choice, and durable-dismissal markers have no automatic expiry and may remain until account deletion. Append-only event rows are assigned a 90-day expiration and then deleted asynchronously by the storage service. Brokerage-derived metadata is created only behind the same authorization and live-link fences as Brokerage Account Data, is used only to operate brokerage ingestion and the requested journal and Strategy Scorecard features, and follows the narrower unlink and retention rules in section 6. Calling these records operational metadata does not make them anonymous, aggregate, or exempt from those deletion rules.
Account Data consent record. When you link a brokerage account, we record your explicit authorization to read your Account Data (balances, positions, orders, and transaction history), to store only the limited portion described above, and to share the relevant data with the AI client and model provider you connect. The record holds the version of the authorization you accepted and the time you accepted it. We keep this record for as long as you have at least one brokerage connection; removing your last connection withdraws the authorization and deletes the record.
Day Trader risk-acknowledgement history. If you choose to activate the optional Day Trader skill, Slatemark records every version of the risk acknowledgement you accept. Each append-only entry contains your opaque account identifier, the time you accepted it, the acknowledgement version, the applicable skill version, and the version/hash of the purpose-specific Day Trader Account Data authorization accepted at the same time. A later acceptance does not replace an earlier entry. The history does not contain your brokerage positions or the output produced by your AI provider. Slatemark uses it only to document the warnings and authorization presented and accepted and to enforce the current activation gate.
Optional Day Trader use of Brokerage Account Data. If you choose to activate the optional Day Trader skill, you may direct Slatemark to pass relevant current Account Data, which can include balances, positions, orders, and transaction history, to the AI client and designated third-party AI provider you choose. They use that data to apply the cleared Day Trader methodology to your current positions and account circumstances and return intraday and 0DTE analysis. This is a separate purpose from the read-only account, order, and transaction tools, trade journal, and Strategy Scorecard. Before Slatemark makes Account Data available for this purpose, Slatemark presents a just-in-time disclosure and requires you to affirmatively accept the current Day Trader Account Data authorization. Declining that authorization prevents official Day Trader activation and download. Generic broker tools remain governed by your standing Account Data authorization and do not identify which client- side skill initiated a call. After a skill file has been downloaded or edited, disconnecting your brokerage is the enforceable way to stop future Account Data access through Slatemark.
Vendor API keys. If you provide API keys for third-party data vendors (FRED, Finnhub, etc.), we encrypt them at rest with a KMS key pinned to your user identifier and the credential name. We use these keys solely to make the calls you initiate through the Service.
Your journal and profile. Trade journal entries, account-profile blocks, notes, tags, and any other content you author through the Service. If you preview a journal CSV, we read the uploaded file only to build that preview and do not retain the raw file. If you confirm an import, we store the normalized trade fields you selected as your journal content, together with bounded import metadata such as the batch identifier, source-row number, normalized-row hash, schema version, and import time. A retryable batch contains only those normalized selected rows, never the uploaded file. They are available for retry until the batch finishes or for up to seven days. At that point the Service stops reading or using the retry payload and queues its deletion through the storage-expiry process, which can finish asynchronously. We similarly make the metadata-only batch result unavailable after 90 days and exclude rolling allowance events after approximately 30 days. We keep exact-deduplication hashes under the general account-retention rule so retries cannot overwrite a record or count an accepted row twice; if you close your account we delete those hashes with the rest of your personal data.
Share receipts and referral attribution. If you choose to publish a share receipt, we store only the exact privacy-filtered public projection shown in the preview, a one-way hash of the capability token, its expiry and revocation state, a view count, an opaque referral identifier, and a boolean recording whether the sender was affiliated with Slatemark when they published it. The projection can contain a question and result generated from one listed user-owned journal fact, fact-specific scalar units, and a listed factual outcome, together with its source category and freshness, or threshold-permitted neutral historical scorecard metrics from user-authored records. For a workflow receipt, you confirm that the original response came from your external AI client and that you approved the structured facts; Slatemark generates only the receipt's fixed wording. Provider-derived market facts are not available in the cleared V1. The projection excludes brokerage Account Data, symbols, display names, account and brokerage identity, position size, dollar profit or loss, thesis, notes, rule text, and the name of any journal tag used to filter a scorecard. It identifies the selected source category. If the sender is an employee, founder, or investor, the public page states that the sender is affiliated with Slatemark. Anyone with the public link can view the approved projection until it expires or is revoked. We record metadata-only stages for prompt display, preview, publication, revocation, and anonymous rate limiting. Receipt rate counters use expiring one-way keyed digests rather than storing a raw network address in the counter. A live opaque referral identifier is reduced to a one-way, deterministic pseudonymous key before any recipient marker, event, subscription, or metric log is written. We use that key only to measure receipt view, sign-up, first Free activation, and Free-to-Plus conversion stages. Those events contain no recipient email, prompt, trade, or receipt content.
Suggested briefing updates. The AI client you connect can record a proposed change to your analyst briefing (for example, that an account is your retirement account, or your risk capacity) for you to review. A proposal can draw on your journal and, if you have linked a brokerage, on the Account Data we read from it. We store these proposals as encrypted per-user rows and only until you act on them or a short expiry passes. We use them solely to show you the suggestion on your Profile page, where you approve it (which applies it to your briefing) or dismiss it; nothing changes your briefing until you approve. We do not use them for advertising, marketing, cross-selling, or any secondary purpose, and we never sell them. Approving or dismissing a proposal, its expiry, or removing your last brokerage connection removes it.
Catalyst calendar. If you switch on the catalyst calendar, we store the ticker symbols on your watchlist, your calendar settings and reminder lead times, and the dated entries it delivers. If you create a subscription feed, we store a one-way hash of its link plus a short opening fragment so you can tell which link is active; we cannot reproduce the full link after we show it to you once. If you also switch on the holdings tier, the entries are derived from your Account Data and can name the symbols you hold, your option expirations and their strikes, the date a tax lot was acquired and the date it reaches one year and one day of holding, the date you realized a loss and the date its wash-sale window closes, whether a repurchase inside that window is recorded in another of your linked accounts, and an opaque identifier for the account an entry came from. They never carry your account values: no position values, no cost basis, no gains or losses, no share quantities, no balances, and never the name of your brokerage. Public market figures, such as an option strike, an approximate implied price range, or a consensus earnings estimate, are not about your account and can appear. The subscription link is a bearer link: anyone who has it can read the feed until you regenerate it or switch the feed off. Section 4 describes what that means for the calendar application you choose.
Google Calendar connection. If you connect Google Calendar, Google gives us a refresh credential limited to creating and managing calendars Slatemark itself creates. We encrypt that credential at rest with AWS KMS, bound to your user identifier and this integration, and store the identifier of the separate Slatemark calendar, the exact permission scope, and connection timestamps. We also store the version of the Google-delivery authorization you affirmatively accept when you connect. We use the credential only to create, update, and delete that dedicated calendar and the dated entries and reminder choices described above. The Google copy uses a stable opaque event identifier but omits the raw event identifier and any brokerage account identifier it contains. It does not permit us to read or change your other calendars. If a connection attempt does not finish, we may briefly retain its encrypted OAuth credential solely to retry revocation, whether it failed before a separate calendar was created or after we removed one. No reminders are delivered through that retained credential, and the dashboard provides a control to finish cleanup. Google receives and stores the entries we write at your direction. Sections 4 and 6 describe that user-directed delivery and what happens when you disconnect it.
Weekly Slate email. If you subscribe to the Weekly Slate, we store the email address on your account at the time you subscribe, the date you subscribed, a record of the authorization you gave, a marker of the week last sent so we do not send it twice, and, if you unsubscribe, the date you did. The email is computed from your own records and contains your realized profit and loss, your position sizing, how long you held winners against losers, your trade count against your own trailing average, re-entries you made shortly after a loss, positions you opened without a recorded stop, the symbols involved, and the names of your own rules. If you have also switched on the catalyst calendar, it carries a preview of your week ahead drawn from the calendar entries, which can name the same holdings-derived entries described above. We do not use a tracking pixel, and we do not record whether you opened it.
Connected applications. Records of the OAuth clients you mint to connect AI clients to the Service. We never see the client secrets after the moment of issuance.
Pre-account waitlist information. If you join a coming-soon AI-client waitlist, the marker and its event row include the email address you provide and the AI client you are waiting for. The submission is stored under a pseudonymous key derived from the normalized email address and is not automatically linked to an account you later create. The marker is assigned an automatic expiration 18 months after the first submission; its event row is assigned a 90-day expiration. DynamoDB deletes expired rows asynchronously. Because an account-id purge cannot discover the separate waitlist partition, account deletion also uses a separate email lookup for the account's primary email and any other waitlist address you identify. You can request this deletion without having an account, and a future waitlist submission creates a new record.
Operational logs and aggregate metrics. Request timestamps, source network addresses, error and latency data, and bounded event records necessary to operate, secure, and improve the Service. An event record can include your opaque user identifier and the feature, client, provider, plan, or tool involved. CloudWatch copies of operational logs are retained for one month. The hosted Service also writes size-rotated local diagnostic files on each running compute task's ephemeral storage; those files can remain for the life of that task and are destroyed when its storage is replaced. These source network addresses and opaque identifiers are personal information. The logs are used only to operate, secure, and improve the Service. A transient log used exclusively for security or integrity may be withheld from access or deletion to the extent permitted by law; this exception does not apply to the user-linked product-use records described as Derived Operational Metadata above. We may retain aggregated, de-identified metrics for longer.
Policy-update notice records. When a material policy update requires an email notice, we retain the recipient address, campaign and document version, send time, provider message identifier, and delivery, bounce, or complaint status for four years. We use these records only to document required notice and investigate delivery failures. Policy notices use no open- or click-tracking beacon.
Cookies. We use a session cookie to keep you signed in, CSRF tokens to protect form submissions, a short-lived HttpOnly state cookie while you connect Google Calendar, a First-Party Analytics Cookie for signup attribution that is HttpOnly, expires after ten minutes, and carries bounded acquisition-source and campaign labels from ordinary first-party signup links, and a separate first-party HttpOnly receipt-referral attribution cookie. The receipt cookie also expires after ten minutes and contains only the opaque referral identifier and receipt campaign class; it is used solely to attribute the resulting signup to its sender. We do not use third-party tracking cookies or advertising cookies.

We do not sell your information, and we do not share it with advertisers.

2. How we use your information

We use the information we collect to:

Operate the Service, authenticate you, and provide the features you request.
Process tool calls you initiate from your connected AI client, including proxying authenticated requests to third-party data vendors on your behalf.
Manage your subscription, process payments, and provide receipts.
At your direction, publish the exact share-receipt projection you approve, measure its metadata-only referral stages, and measure the bounded source and campaign through which an account first reached signup.
Communicate with you about your account, the Service, and changes to these policies, and, if you subscribe to it, send you the Weekly Slate summary of your own records.
Monitor, secure, and improve the Service, including diagnosing errors, detecting abuse, and measuring onboarding and feature use.
Comply with legal obligations and enforce our Terms.

We do not use your journal entries, account profile, or trading data to train any machine-learning model.

We use the Account Data we read from a linked brokerage only to provide the features you requested (the account, order, and transaction tools and your journal and Strategy Scorecard), to operate synchronization, to measure whether brokerage ingestion and those requested features are working and used, and to pass the relevant portion to the AI client and model provider you connect at your request. We do not use your Account Data for advertising, marketing, cross-selling other products, or any secondary purpose, and we do not sell it.

When you affirmatively opt in to the optional Day Trader Account Data purpose, Slatemark uses and shares only the Account Data reasonably necessary to render the cleared methodology through the AI client and designated third-party AI provider you choose. Slatemark does not use that data for advertising, marketing, cross-selling, or any other secondary purpose, and Slatemark does not sell it.

Caching of public data. To improve performance and to respect the rate limits of upstream data providers, we may temporarily cache responses from non-commercial, public-data sources (such as FRED, the U.S. SEC, EIA, CFTC, and U.S. Treasury data) and from the publicly available, delayed market data that powers the quote, price-history, and option-chain tools. Because these responses are public and identical for everyone, your query parameters for those sources may be used to serve a cached result to another user who runs the same query. Responses from commercial data vendors that you access with your own API key are never pooled or cached across users; they are used only to answer your own requests.

3. Who we share information with

We share information only with the third parties we use to operate or administer the Service:

Stytch: identity and authentication.
Stripe: payment processing and subscription management.
Amazon Web Services: hosting, compute, storage, encryption (KMS), and email delivery. When we send you the Weekly Slate, the delivery service receives the full contents of that message, including the figures and symbols it contains, in order to route it to your inbox. It processes the message to deliver it and for no other purpose.
Slack: when the optional operator signup notification is enabled, it receives the new account's opaque internal user identifier and a bounded campaign label. It does not receive the account's email address, acquisition-source label, or share-receipt referral identifier.
SnapTrade: brokerage connectivity. When you connect a brokerage account, you authenticate with your brokerage inside SnapTrade's portal, and your brokerage Account Data (balances, positions, orders, transaction history) flows to us through SnapTrade. We never see your brokerage password. Disconnecting a connection removes it, asks SnapTrade to delete its copy, and deletes the Account Data derived from that connection, including every holdings-derived calendar entry the connection contributed to. If another connection still supports the same future event, the next catalyst refresh can create that entry again using only data from the remaining connections.
Anthropic, Yahoo Finance, FRED, U.S. SEC, Massive, Finnhub, EIA, CFTC, FINRA, and other data vendors: when you initiate a request that requires their API, we forward only the information needed to fulfill that request (typically a ticker symbol, a date range, or an authenticated API key you provided). We do not forward your journal contents or unrelated data.

Each of these providers has its own privacy practices and contractual commitments to us. We do not authorize them to use your information for purposes other than providing services to us.

We may also disclose information when required by law, court order, or other governmental request; to protect the safety, rights, or property of users, us, or the public; or in connection with a merger, acquisition, or sale of assets, subject to confidentiality.

If you publish a share receipt, you direct us to make its exact approved public projection available to anyone who has the capability link. Search crawlers are instructed not to index receipt pages, but a recipient can copy or redistribute what they can view. Revoke the link if you no longer want Slatemark to serve the projection.

4. User-directed integrations

Optional features can send your own information to a service you choose rather than to a provider we engage. When you switch one on, you are directing us to deliver your data to a tool you control. The provider of that tool is not our sub-processor: we do not engage it, we do not instruct it, and we hold no contract with it covering your data. Its own terms and privacy policy govern what it does with what it receives.

The AI client and designated third-party AI provider you choose. If you opt in to the optional Day Trader Account Data purpose, you direct Slatemark to make the disclosed Account Data available through your chosen AI client to its model provider so that provider can render the cleared methodology. Slatemark does not operate that model or store its response. The provider's own terms and privacy policy govern what it does with the data it receives.
The calendar application you choose. If you connect Google Calendar, you direct us to send your catalyst entries and reminder choices to Google through its calendar API. Google stores them in a separate calendar Slatemark creates and manages under the narrow permission described in section 1. If instead you create a subscription feed for Apple Calendar, Outlook, or another application that reads calendar subscriptions, that application fetches the feed from us over the public internet on its own schedule and stores what it fetches. The subscription link carries no password: anyone who has it can read the feed. Treat it as a secret, and regenerate it if you think someone else has seen it.
The provider that operates your mailbox. When we send an account or policy notice, or if you subscribe to the Weekly Slate, we send it to the relevant address and your mailbox provider receives and stores it under its own terms.

You stay in control of each. You can disconnect Google Calendar, regenerate or switch off the calendar subscription link, and unsubscribe from the Weekly Slate at any time from your dashboard.

5. How we protect your information

All vendor credentials, brokerage connection credentials, and Google Calendar OAuth credentials are encrypted at rest with AWS KMS. Encryption-context fields pin a row to your user identifier and, where applicable, the credential or integration name, so a misrouted decrypt request fails.
Brokerage connection credentials are scoped per user. No shared key, no cross-tenant access.
Authentication is enforced at the request boundary; tool calls and dashboard actions both require a valid session bound to your user identifier.
Data is hosted on AWS in the United States.
We follow the principle of least privilege internally: production data access is limited to operators with a specific operational need.

No system is perfectly secure. If we learn of a breach that affects your information, we will notify you and the relevant authorities as required by law.

6. Data retention

We retain your data for as long as your account is active. If you delete your account, we delete the personal data associated with your account and the content you authored within a reasonable timeframe, except where we are required by law to retain a record (for example, Stripe billing records) or where a limited security or operational record is expressly described below. We may retain aggregated, de-identified operational metrics for longer periods.

Derived Operational Metadata markers that record a one-time milestone, a current choice, or a dismissed prompt may be kept until account deletion so completed steps and durable choices remain effective. Append-only event rows are assigned a 90-day expiration and then deleted asynchronously by the storage service. These rows are separate from operational logs, whose CloudWatch and task-local copies follow the distinct retention periods stated in section 1. A pre-account AI-client waitlist marker is stored separately under a pseudonymous key derived from the normalized email address and receives an automatic expiration 18 months after its first submission; the associated event row expires after 90 days. Expired rows are deleted asynchronously by the storage service. The waitlist partition is not automatically associated with an account created later, so account deletion uses a separate email-based lookup for the primary email on the account and any additional waitlist address you identify. You can also request deletion without an account. A later submission after expiry or deletion creates a new record. Source-attributed metadata derived from Brokerage Account Data can be deleted earlier when its source connection is removed, as described below.

Day Trader risk-acknowledgement history has no automatic expiration and is retained for the life of your account, including after a plan downgrade, persona change, or disconnection of your brokerage. A downgrade or persona change blocks official Day Trader access; disconnecting your brokerage stops future Account Data access through Slatemark. None of those events erases the historical warnings or authorizations you accepted. The dashboard does not provide a self-service control to withdraw or delete an individual acknowledgement entry. If you delete your account, Slatemark deletes the active risk-acknowledgement history within a reasonable timeframe. Copies may remain in encrypted, access-restricted disaster-recovery backups until the applicable recovery window expires. Slatemark does not use backup copies for ordinary product operations, and any data restored for disaster recovery remains subject to the account-deletion request.

Brokerage Account Data is held to a tighter limit. Brokerage-derived Operational Metadata follows the same authorization and live-link boundary without becoming part of the core financial-data category. The bounded holdings-read metadata and synchronization state described in section 1, the record of your fills, the journal entries derived from those fills, and the metadata derived from brokerage imports, holdings, or broker-created journal activity are retained only while a brokerage link is active. When you unlink a brokerage connection, we delete the Brokerage Account Data, connection-scoped synchronization state, and current source-attributed metadata attributable to it. A broker-wide manual-sync throttle record remains while another connection is active and is deleted when the last connection is removed. A successful final-link cleanup also deletes older broker-derived metadata that predate connection attribution when their brokerage provider remains identifiable. Closing your account deletes all of those records along with your stored brokerage connection credentials. A failed deletion remains pending for retry rather than being treated as complete. The journal entries you author yourself and Derived Operational Metadata tied only to your own content are kept under the general retention rule above. After account closure, we retain one secret-free brokerage lifecycle control row without automatic expiry. It contains your pseudonymous opaque user identifier, a random revision, and an open-or-severing state, but no brokerage credential or Brokerage Account Data. We use it solely as a security and integrity record to prevent an older or in-flight brokerage connection from recreating deleted data.

A share receipt expires after thirty days by default and can never remain available for more than 180 days. Revocation immediately makes the capability link unavailable, and account deletion removes the stored projection, token hash, counters, raw opaque referral identifier, and its sender lookup. Deterministic referral stage keys are pseudonymous personal data, not de-identified data. Account-linked marker and event rows that contain those keys are removed on account deletion; operational logs containing them follow the CloudWatch and local diagnostic retention periods described in section 1. Only aggregated, de-identified operational metrics may be retained longer under the general rule above.

Policy-update notice records described in section 1 are retained for four years, including after account deletion when necessary, solely as evidence that required notice was sent and to document delivery failures. They are deleted after that compliance-retention period.

Bounded non-receipt signup source and campaign labels stored on the subscription row follow the general account-retention rule and are deleted when the account is deleted. The attribution cookie expires after ten minutes and is deleted when the sign-in callback consumes it. On initial signup, the callback copies the bounded labels into the new subscription row.

When you unlink one connection, we delete every holdings-derived catalyst calendar entry attributable to it, including an entry also supported by another connection. We also delete any older holdings-derived entry that cannot be attributed to a specific connection. If a remaining connection still supports the same future event, the next catalyst refresh can create that entry again using only data from the remaining connections.

When you disconnect Google Calendar, we first ask Google to delete the separate calendar and revoke the grant, then delete the encrypted OAuth credential and connection record we hold. If Google has already revoked the grant, we delete the unusable local credential, but we may no longer have permission to delete the remote calendar; you can remove it from Google directly. A temporary Google failure leaves the encrypted credential in place only so the disconnect can be retried rather than reporting a deletion that did not happen. A failed connection attempt can retain a non-delivery OAuth credential when immediate revocation cannot be confirmed, including before a separate calendar id exists. After an orphan calendar is removed while a different live link exists, we may also retain its credential because revoking it could revoke that live Google authorization. The dashboard identifies these states and lets you finish cleanup; explicit cleanup and account closure revoke every retained grant before deleting those credentials. Account closure follows the same remote-first process while a grant remains usable.

Additional limited exceptions apply to those caps. We state them rather than leave the rule absolute:

Calendar entries that have already happened. While at least one calendar delivery method is on, a dated entry stays in the catalyst calendar for 90 days after its date, so the calendar reads as a record of what happened and not only as a forecast, and is then deleted. Disconnecting Google Calendar or switching off the subscription feed stops that delivery method immediately. When the last delivery method is off, the entries already stored by Slatemark are deleted at the same time. Your calendar settings, such as your watchlist and reminder choices, are your own configuration and are kept so you can switch the calendar back on later; you can ask us to delete those too at any time using the contact address below.
Email suppression. If you unsubscribe from the Weekly Slate, we keep your email address and the date you unsubscribed on a suppression list for as long as we operate the Service. We keep it so that we can honor your unsubscribe, and federal law requires us to keep such a record. We do not use it for any other purpose.

You can request deletion of your data by contacting support@slatemark.ai.

7. Your rights

You can:

Access the account, subscription, journal, profile, and configuration data available through your dashboard.
Update or correct your account information at any time.
Request access to the other personal data we hold about you, including user-linked Derived Operational Metadata such as service-use markers and telemetry (see contact below). These operational records are included in an access response even though they are generally outside the portability export for data you provided to the Service.
Delete your account and the personal data associated with it.
Request deletion of other personal data, including a pre-account AI-client waitlist marker that is not linked to a later account.
Opt out of non-essential communications.

You may decline the optional Day Trader Account Data authorization, which prevents official Day Trader activation and download. Generic broker tools remain governed by your standing Account Data authorization because those calls do not identify the client-side skill that initiated them. Slatemark cannot distinguish an official downloaded skill from an edited copy; disconnecting your brokerage is the enforceable way to stop future Account Data access through Slatemark. The append-only acknowledgement history documents past acceptances and cannot be selectively erased through a dashboard control while your account remains open. You may still exercise applicable access or deletion rights through the contact method below, and deleting your account removes the active history as described in section 6.

Residents of California may have additional rights under the California Consumer Privacy Act (CCPA). To exercise any applicable right, contact support@slatemark.ai. We do not sell personal information and have not sold personal information in the prior twelve months.

8. Children

The Service is intended for users 18 and older. We do not knowingly collect personal information from anyone under 18. If you believe a minor has provided us with personal information, contact support@slatemark.ai and we will delete it.

9. International users

The Service is currently offered only to residents of the United States and is hosted in the United States. If you access the Service from elsewhere, you do so at your own risk and are responsible for compliance with local laws.

10. Changes to this policy

We may update this Privacy Policy from time to time. When we make material changes we will update the “Last updated” date above and, where appropriate, notify you by email or an in-product banner. Your continued use of the Service after the effective date constitutes acceptance of the updated policy.

11. Contact

Questions, data-access requests, and other privacy-related inquiries can be sent to support@slatemark.ai.