Privacy Policy

Who we are

Ciphora is an early-stage trading-technology project operated from Arizona, United States. For privacy purposes, Ciphora is the controller of personal information submitted through ciphora.ai and the Ciphora Confluence Engine private research beta. Ciphora is not represented here as a corporation, broker, adviser, or other regulated financial institution. The initial application is limited to adults who reside in the United States. Questions and privacy requests can be sent to legal@ciphora.ai.

Information we collect

We collect information you provide directly. If you submit an Early Access application, we collect the fields in the application:

• Name and email address
• Country
• Trading experience and average trades per day
• Whether you use TradingView
• The markets you trade and the instruments or pairs you expect to use
• Whether you are funded with a prop firm and, if so, your funded profitability and the firm(s) you use
• Whether you use paper or simulated trading, how many such accounts you actively use, and, optionally, the platform or provider
• The trading sessions you selected
• The date you applied and your beta status

Your Ciphora account

A Ciphora account is a general product identity. It is not a beta seat and not an entitlement: creating one gives you the account area and nothing that depends on a beta decision. Applying for the beta is a separate step with its own form, and holding an account neither grants beta access nor implies it.

To create an account we collect your name, a username you choose, your email address, your country, and either a password or a link to a sign-in provider you chose. A password is never stored as you typed it: it is kept only as a slow one-way hash under a server-held secret, and no part of this service can read it back. We record whether and when your email address was verified and which route verified it, because an unverified address must not be treated as proven.

We also keep the things the account needs in order to work: your sessions, stored only as hashes so a stored value cannot be replayed as a login; single-use email-verification, password-reset, provider-link confirmation and email-change challenges, likewise stored only as hashes and usable once; a keyed, non-reversible counter used to rate limit sign-in and account creation, which holds no email address, IP address or token; and your preferences, which are your appearance choice and your separate notification choices for roster status, beta releases, security notices, and optional marketing.

In the account area you can add an optional display name and an optional avatar image, which is stored as a private object and streamed only to the signed-in account it belongs to. You can add an optional phone number; it is stored as an encrypted envelope and is never shown back to you in full, and only the region is read by anything that displays your profile. You can answer one onboarding question about what you would like to use Ciphora for, chosen from a fixed list. That answer decides what your workspace offers you first. It is not a permission, not an entitlement and not a beta state, and nothing gates access on it.

You can change your display name, avatar, phone number, purposes, appearance and notification choices at any time in Settings, and you can end a session by signing out. This build has no self-service delete-my-account button, and we would rather say so than let the absence go unmentioned: ask us using the privacy-request process below and we will handle it under that process. When an account record is removed, the records tied to it are removed with it by the database itself rather than by a separate cleanup - provider links, sessions, challenges, preferences, profile, assistant conversations and messages, and assistant memories. Records that exist to evidence something - your consent receipts, and the delivery evidence for account emails - are described under Retention schedule below.

Signing in with Google or Discord

You can create an account or sign in with Google or with Discord where Ciphora has configured that provider. Apple sign-up is deliberately deferred for this launch: it is not offered, and no Apple button is drawn. These providers are identity providers that process your sign-in on their own terms. They are not Ciphora partners, and displaying their marks says only that you may sign in with them.

From a completed provider sign-in Ciphora reads the provider's own permanent identifier for your account, the email address the provider reports, and whether the provider states that the address is verified. Nothing else is requested and no other provider data is read. Ciphora stores the provider name, that permanent identifier, the email address recorded at the moment you linked, and whether the provider claimed it verified. The link cannot be edited afterwards, and the provider identifier is what identifies you on a later sign-in.

An email address is never enough to join an existing account. A provider sign-in that reports an address already held by an account does not sign you in to it and does not merge anything; linking an additional sign-in method happens only from inside Settings, in a session you already hold, and only for an address the provider states is verified. If the provider does not state the address verified, the account is created unverified and you complete the ordinary email verification instead.

Ciphora sends the consent choices you made on its own page - the terms and privacy acceptances, your country and your marketing choice - through the sign-in as signed values, so a provider round trip cannot produce consent you did not give. No Ciphora data is sent to the provider beyond what completing a sign-in requires, and a provider link is never used for advertising, analytics or profiling.

Account emails and what delivery evidence means

Account email - address verification, password reset, the security notice after a reset completes, and beta review notices - is prepared as a sealed encrypted envelope in our database. There is no plain recipient address, subject, body or token column: the envelope is opened only by the scheduled worker that hands the message to the provider, and it is erased the moment the provider accepts it.

Alongside the envelope we keep a separate delivery record that outlives it. It holds no recipient, subject, body or provider payload - only which template it was for, how many attempts were made, the provider's own message identifier once there is one, a closed error category when something went wrong, and the state the message reached.

ACCEPTANCE IS NOT DELIVERY, and this policy will not blur the two. A record that says the provider accepted the message means the provider agreed to try and returned an identifier. Only an authenticated notification from the provider can move that record to delivered, bounced, complained, suppressed or failed, and nothing in this application may write delivered from its own reasoning. Ciphora does not enable open or click tracking on account email.

The Ciphora assistant, your transcript, and your memory

Signed in, you can ask the Ciphora assistant a question. Your questions and the answers you were shown are stored as a conversation transcript scoped to your account. A message is written once and is never edited afterwards, because a transcript is evidence of what was actually said. You can start a new conversation and archive one you are finished with, and archiving is final rather than a toggle. Erasing your account erases the transcript with it.

Separately, you can ask the assistant to remember something - for example which instrument and timeframe you trade. Durable memory records only what you wrote, in your own words. There is no route by which the assistant can decide to keep something about you on its own: the stored provenance has exactly one permitted value, meaning you stated it, and anything else is refused by the database. You can list, correct and delete your memories at any time, and deleting one removes it.

WHAT CROSSES THE PROVIDER BOUNDARY, exactly. When you ask a question, our server sends Anthropic two things and nothing else: the question you just typed, and a bounded set of candidate passages from Ciphora's reviewed, public knowledge base. It does not send your account, your name, your email address, your conversation history, your memories, your trading records or any figure you have entered. Your memories are used only inside our own server, to widen which public passages are offered as candidates for that one question.

Anthropic's reply is not shown to you. The model is asked to choose passage identifiers, never to write prose; our server accepts only identifiers from the set it supplied and then assembles the answer from those exact reviewed passages, or returns a fixed reviewed sentence saying it has no answer. That is a deliberate ceiling on what the assistant can say.

The assistant performs no action on your behalf. It cannot change your account, your beta application, your subscriptions, your connections or anything else, and it cannot place, modify or cancel a trade. Asking it to change something produces an answer about how to do that yourself, never the change. Please do not put a password, an account number, an API key or a payment detail in a question; the assistant does not need them, and a question that looks like a secret is refused before it is stored or sent.

Capital Reference, connections and trading records

Capital Reference performs a real position-size calculation from figures you type in: your capital, the share of it you are willing to risk, your stop distance in points, and the instrument whose tick size and tick value the calculation uses. It returns your risk amount, the stop measured in whole ticks, the risk of one contract, the whole number of contracts that fits, and the risk used and left over. Each calculation is stored against your account with the figures it used, the instrument-definition version, and when it was computed, so a past result can be explained rather than merely asserted.

The calculation depends on no market data at all. A historical price view is offered as context only, and its provider path - Databento historical CME data - is currently UNAVAILABLE: the deployment holds no entitlement for that dataset, billable calls are disabled by a reviewed constant in the source, and a reviewed acquisition contract does not exist. Nothing substitutes a fixture, a sample or a stale cached series for provider data. When the provider cannot be asked, the view reports that it is unavailable, and your calculation is unaffected because the arithmetic never used a price.

You can add a connection to describe where your records come from and import them yourself. Ciphora reads no broker or exchange account on your behalf and holds no execution capability: a connection can, at most, describe a read-only or import-only relationship, and none of them can place an order. From an import we store the import batch and its digest, the execution events it contained, the trades derived from them, and a reconciliation that states whether the two agree. A source that is simulated - a TradingView Pine log, for example - stays labelled simulated everywhere it appears and is never presented as verified fill history. You can also write journal entries, which are your own text.

These records are personal information about you. They are stored in the same Neon database described below, they are never sold, never used for advertising, and never used to compute or market trader profitability. Erasing your account erases them.

Research & Launch List

Where the Research & Launch List is enabled, joining it sends your email address, the one market or platform preference you select, a fixed consent-version identifier, and a dedicated list-form membership to Kit. Kit's form-membership time records when the request was accepted. If your current browser session began with valid source or UTM parameters, the request may also include a bounded source value and the five standard UTM values: source, medium, campaign, content, and term. Those values must use a conservative token format and are discarded when malformed, repeated, or oversized. Ciphora does not send the landing page query string, a full referrer URL, form contents other than the fields just named, or a Ciphora user identifier.

The list is for useful Ciphora research, product education, launch information, and launch access. It is separate from the Early Access application and the playbook-delivery form. Joining does not create a beta application, grant beta access, create a customer account, or prove that an email reached an inbox. You can unsubscribe at any time using Kit's email controls. Ciphora does not store the list contact record in Neon; Kit is the contact and consent system of record for this list.

To keep first-touch attribution across same-tab navigation, the site stores one versioned object in session storage containing only a sanitized source path and the five UTM tokens described above. It never contains your email, name, a user or device identifier, a query string, a fragment, a full referrer, or free text. Session storage is scoped to the current browser tab and normally ends when that tab or window closes, although a browser's session-restore feature may preserve it; clearing this site's data removes it. This functional attribution storage is separate from optional Google Analytics and exists even when analytics is declined.

Google Analytics remains disabled on the Research & Launch List form page. If you previously allowed analytics, an informational page may send one of two allowlisted CTA events before navigation: research-list or beta-application click, together with a fixed page-location label. Those events contain no email, form answer, URL, query, UTM value, link text, or user identifier. Successful list membership is measured in Kit, not by a browser submission event.

Beta review and access provisioning

A beta application submitted from an account is reviewed by a person. Ciphora records the submission, the review deadline it was given, the decision and when it was made, the role that made it, and a short decision reason. Automatic admission was removed: nothing seats you, invites you or advances your status without that decision.

Four facts about your beta standing are kept separate, because they genuinely succeed and fail independently and conflating them is how someone is told they have access they do not have. The DECISION is whether a person approved the application. The PRODUCT PERMISSION is whether your account actually holds beta access, which is a separate act after an approval. PROVISIONING is TradingView access. DELIVERY is whether the notice about any of this reached you, which is tracked as described under Account emails above.

If you receive beta access, Ciphora may collect your TradingView username and access status to provision or revoke invite-only access to the Ciphora Confluence Engine publication on TradingView. TradingView offers no supported customer-access interface for an invite-only publication, so a Ciphora administrator grants access by hand against the exact username you gave. A queued provisioning state means the request is in an operator's work queue; it does not mean an invitation has been sent. You can correct the username yourself until a decision puts it in front of an operator, after which it is locked because someone may already have typed it. Accepting a beta invitation on this website records your acknowledgments and choices but does not itself grant TradingView access.

If you participate in the beta, Ciphora also processes information you choose to submit through beta feedback forms, including build and research-model versions, instrument, timeframe, session, regime, browser and device environment, dashboard mode and orientation, reproduction steps, product feedback, periodic reviews, and the text fields on those forms. The forms do not accept file uploads. A bug report may include an optional screenshot link or reference; do not use it to share account balances, account identifiers, credentials, or other sensitive financial details.

When you accept a beta invitation, we issue a secure, HttpOnly session cookie to your browser. It lets the onboarding page and feedback forms recognize you as an accepted tester. The session expires automatically and can be revoked when you sign out or when Ciphora revokes access. It grants no other permissions.

How beta evidence is separated

Ciphora keeps three evidence categories distinguishable: automatic platform telemetry, information a participant reports, and research records that Ciphora has reviewed and marked as validated. A participant's description, weekly response, or submitted outcome is not represented as independently validated model performance.

Automatic telemetry records only events the configured website or an explicitly enabled TradingView alert can actually transmit. It does not prove that a chart was viewed, a signal was acted on, or a trade was taken. Completed research-trade records include their source, build, research-model version, export-schema version, and validation state. Aggregated performance figures shown in private dashboards must identify their sample and provenance and exclude pending, rejected, or synthetic records.

Risk and dashboard research prefers percentages, states, R multiples, and remaining-buffer measures over exact account histories. Do not submit passwords, broker credentials, account numbers, payment information, private API keys, authentication tokens, or exact balances through beta research or feedback fields.

Beta telemetry (required for participation)

Marketing consent and telemetry participation are separate. Declining marketing does not affect your application or beta eligibility. Operational telemetry is required for this research beta. If you do not accept this participation condition, you cannot accept an invitation or participate. Telemetry begins only after your acknowledgment is recorded and while your beta participation remains active. Each participant receives a unique, revocable telemetry token that is sent in the request body and never in the URL.

For each alert event, Ciphora collects an event ID, event type, research build ID, instrument, five-minute timeframe, and server receipt time. It may also collect a session label, direction category, Confidence alignment category, alert condition label, and a limited set of non-sensitive diagnostics, such as alert latency and chart resolution. Instrument values are limited to beta candidates. Clearly labeled synthetic test events are marked as tests and excluded from research counts.

Telemetry never includes broker or exchange credentials, brokerage account identifiers, account balances, positions, profit or loss, personal notes, or free-form sensitive trading data. The server enforces a strict schema and rejects payloads containing those fields. That sentence describes the telemetry channel and nothing else. It is not a claim that Ciphora never holds figures of that kind, because the separate account-rule features described under Account condition information you enter, below, do collect account-condition figures that you type in yourself. Those figures reach us through a different endpoint, under a different and separately versioned consent, and are kept under a different retention rule. Telemetry and account-condition figures are never merged into a single record. Ciphora does not use telemetry to compute, infer, store, or market trader profitability, success rates, or funded-account performance. Operational telemetry is not evidence of a trading edge.

Ciphora processes telemetry only to evaluate beta reliability, installation success, alert delivery, usability, and research validity. Telemetry is not used for advertising or sold.

Where it lives: telemetry, feedback, and beta application records are stored in a Postgres database operated by Neon (our database hosting provider), which processes the data on our behalf under its own security and privacy commitments. Vercel hosts the application that receives telemetry, and Kit (ConvertKit) processes email data as described elsewhere in this policy.

Retention, revocation, and deletion: telemetry and feedback are deleted or de-identified within 24 months after the earlier of the end of your participation and the end of the beta, subject to the shorter periods and limited exceptions in the Retention schedule below. Because operational telemetry is a condition of participation rather than an optional extra, asking Ciphora to revoke your telemetry token ends your participation in the research beta. It is not a way to remain in the beta with collection switched off. Revocation stops further collection immediately. You can request access to or deletion of your stored telemetry and feedback by emailing the contact address above; applicable requests are handled under the process described below.

Telemetry is sent over HTTPS to https://ciphora.ai/api/beta/telemetry. The revocable token is sent in the request body, never in the URL, and stored only as a cryptographic hash. Payloads are validated, size limited, rate limited, and deduplicated. No security measure is absolute. Beta software and infrastructure can fail, so do not send any data beyond what the alert template defines.

Account condition information you enter

Some beta features can use figures describing the condition of your own paper or simulated trading account. This is a separate, optional collection with its own consent text and its own version identifier. It is not covered by the application acknowledgments or by the operational telemetry condition above, and agreeing to it is never a condition of applying or of participating in the beta. These features sit behind an explicit opt-in feature state that is off unless Ciphora deliberately turns it on. While that state is off, none of the collection described in this section happens at all. While it is on, collection still begins only for a participant who has separately consented, and it stops for that participant as soon as they withdraw.

You type every figure yourself. Ciphora does not connect to a broker, an exchange, or a prop firm, and no account is synchronized on your behalf. The figures you enter are exactly nine, and the form accepts nothing else: your current account equity including unrealized profit and loss; the maximum-loss-limit floor your platform displays; the highest end-of-day balance your platform records, which is optional; your profit or loss for the current day; the total money at risk from your open positions to their protective stops, which is optional but required whenever any contract is open; the position cap your platform displays for the account right now; how many contracts you currently have open; how many losing trades you have taken in a row; and how many trades you have taken today.

There is no field anywhere in this collection for an account name or label, an account number, a per-trade risk percentage, or a maximum-loss, daily-loss or trade limit of your own choosing, and an unrecognized field is rejected rather than stored. Earlier versions of this policy described some of those as collected. They were not collected then and are not collected now; this section was corrected and the policy version was moved so the correction is on the record rather than made silently.

Separately from those figures, you make three choices from lists Ciphora fixes: your evaluation stage, chosen from Ciphora's supported stages rather than written in free text; whether your contract counts are minis or micros; and whether the optional daily loss limit applies to you. The amount of that daily loss limit is set by Ciphora, not by you.

Alongside your figures and choices we store the rule envelope they were evaluated against, because a result cannot be explained or reproduced without it. Every part of that envelope is fixed by Ciphora and cannot be supplied or overridden by you: the account currency; the maximum loss limit; the daily loss limit amount used when the election applies; the internal rule profile actually applied, or a marker recording that no verified profile exists for the stage you asked for; the dated version identifier of that rule profile; and the versions of the account-rule consent and of the policies you accepted. We also record bookkeeping that the server owns rather than you: an identifier for the record, the time the server captured it, the time we received it, and the fixed time at which the record stops being usable. You cannot supply, backdate, postdate, or extend any of those times, and a submission that tries to set one is rejected.

Ciphora never asks for and must never be given a broker or exchange password, an API key or secret, an account number, payment-card details, or any permission to place, modify, or cancel an order. Screenshots are not collected. A record of your account condition is a structured, timestamped set of the figures you typed and nothing more.

These records are stored in the same Neon database described below, alongside a record of which consent version you accepted and when, and are retained under the Retention schedule below. You may withdraw this consent at any time using the withdrawal control in the beta area or by emailing us. Withdrawal takes effect immediately, and from that moment no new account-condition record is accepted from you, every record you had already submitted stops being usable as an input, no further result is produced for you, and the rule profile your figures were evaluated under is retired.

Withdrawal is not an instant erasure, and we would rather say so than imply otherwise. The records you already submitted, the results already produced from them, and the record of what you consented to and when all remain stored after you withdraw. They are simply no longer used. They are removed when the applicable period in the Retention schedule below expires, or sooner if you make a deletion request we can grant. The consent record itself is kept for its full period, because it is the evidence of both the consent and its withdrawal.

Output produced from these figures reports whether a signal met the account rules that applied to your stage and election at one moment in time. Each result is itself kept as a record, so that a past result can be explained and reproduced rather than merely asserted. A stored result holds the outcome, the full ordered list of reasons that produced it, the account-condition band it was produced under, the identifiers of the signal, the account-condition record and the rule profile it used, and the time it was produced. These records are linked to your participant record. They are personal information about you, not anonymous statistics, and they are retained under the Retention schedule below.

A result is decision-support only. It is not financial advice, not an instruction to trade, not a prediction, and not a probability of winning. It can be delayed, out of date, unavailable, or wrong, and your trading decisions remain your own. In the current build these features are also not operational: the sizing and selectivity policies they would need are deliberately absent, so the software cannot return an approval or a position size at all, and every result it can reach is a rejection, a not-evaluated outcome, or an error.

Optional public-site analytics and what we do not collect

This website does not set advertising or marketing trackers. We do not sell personal information, and we do not buy data about you from third parties.

Where Cloudflare Web Analytics is enabled for a deployment, this site is served through Cloudflare and the Web Analytics beacon is loaded on it. Whether the beacon is enabled on any particular deployment is a deployment configuration setting, and this policy does not assert it as verified. When it is enabled, Cloudflare Web Analytics measures aggregate site use and performance, including visits, page views, referring sites, country, device type, browser, operating system, page path, page-load timing, and Core Web Vitals. Cloudflare states that Web Analytics does not use cookies or local storage for analytics and does not fingerprint or track individual visitors over time. Cloudflare Web Analytics does not log query strings. Cloudflare processes the beacon data as our infrastructure and analytics provider.

Where Google Analytics 4 is configured, Ciphora offers a separate analytics choice on informational public pages. The Google tag is not requested unless you select Allow analytics. It remains disabled on application, Research & Launch List, contact, login, account, participant workspace, beta, playbook, and Director routes even after that choice. Account routes are the pages where you create an account, sign in, verify an address, reset a password and complete onboarding; the participant workspace is everything under your signed-in dashboard. The implementation sends a page path without its query string or fragment and a referrer reduced to an origin or same-site path. It does not send form contents, assistant questions, application identifiers, account-condition figures, trading records, UTM values from the functional attribution object, or a Ciphora user identifier. Advertising storage, advertising user data, ad personalization, Google signals, and ad personalization signals remain disabled.

If you allow Google Analytics, Google may set first-party analytics cookies such as _ga and _ga_* and process a randomly generated browser identifier, public page views, approximate location, device and browser information, language, timestamps, and basic interaction or performance information. Google Analytics 4 uses an IP address at collection time to derive location and route the request, but Google states that GA4 does not log or store the IP address. Google processes this information as our optional analytics provider. The property must use the two-month user and event data-retention setting before this feature is activated; Google explains that this setting does not govern every aggregated standard report.

Your choice is stored in this browser as a small local-storage preference. You can reopen Analytics preferences in the footer, change your choice, and decline future analytics at any time. Declining disables the tag and attempts to remove accessible _ga cookies from this site. It does not retract information already received by Google; you may use the privacy-request process below for an applicable request.

We do not require or ask you to provide broker credentials, broker API keys, exchange credentials, account passwords, account balances, or private trading records through the Early Access form or the Knowledge Assistant. Please do not submit them there. The single place Ciphora accepts figures about your account is the separate, separately consented account-condition form described above, and even there it never accepts a credential, an account number, or a payment detail of any kind.

Playbook request and functional browser storage (not analytics)

Where new playbook requests are enabled, the homepage may offer a free downloadable playbook after a short delay, and the direct playbook route shows the same email-request choice to a visitor who has not completed it in that browser. When requests are disabled, neither surface collects an email and the request endpoint refuses the submission before reading its body or contacting Kit. If you affirmatively submit your email while requests are enabled, Kit receives the email address and a dedicated playbook-delivery form membership needed to send the requested guide. That delivery form is separate from the Early Access application and from product marketing. A playbook request does not enroll you in product marketing or send a product-marketing form request. Closing the offer or declining to submit an email has no effect on general site access or beta eligibility, but the site does not present or link the playbook web version or PDF before Kit has synchronously confirmed the dedicated delivery-form membership. That confirmation means Kit accepted the membership request; whether the message reaches an inbox depends on Kit's configured incentive email, the recipient mailbox, and delivery conditions. After confirmation, Ciphora sets a seven-day, strictly necessary, HttpOnly access-receipt cookie scoped to the /playbook path. It contains only a version, expiry, random nonce, and server signature, never your email, and is used only to recognize the completed request when you open the semantic playbook page. Disabling new requests does not revoke a still-valid receipt. The PDF link delivered through Kit remains usable across browsers or devices; the receipt is a browser-access convenience, not an account, identity proof, or claim that the guide is confidential or private.

Separately from any analytics choice, the playbook offer uses two functional, PII-free markers in this browser's local storage. Closing the homepage offer before a confirmed request stores a numeric dismissal time so the homepage does not show that offer again for 30 days. After 30 days the marker no longer suppresses the offer, but local storage does not delete it automatically; the stored value remains until you clear this site's data or a later dismissal overwrites it. Completing a confirmed request through either request form stores the word true so the homepage does not show the offer again in that browser. This completion marker has no automatic expiry and remains until you clear this site's local storage. Neither marker contains your email address or any other direct identifier. The markers stay in your browser; they are not sent to Kit, Google Analytics, or Ciphora's server, and they are not used for analytics, advertising, profiling, access control, or proof of delivery. The completion marker is separate from the seven-day HttpOnly access-receipt cookie: it suppresses the homepage offer but does not grant playbook access.

Abuse prevention for public email requests (required, not optional)

The playbook and Research & Launch List request endpoints are public and unauthenticated, so they are protected against automated abuse by a shared, durable rate limit. This protection is required to use that endpoint for either form. It is not part of the optional analytics choice described above, you cannot decline it and still submit the form, and declining analytics does not affect it. Ciphora relies on its legitimate interest in keeping each public endpoint available and resistant to automated abuse.

When you submit either form, Ciphora applies a keyed one-way hash (HMAC) to your IP address using a secret held only on our servers and a different fixed domain for each form, and stores the resulting value in the same Neon/Postgres database described below, together with a fixed ten-minute window start and expiry and a small attempt count. The separate domains prevent one form's record or quota from being reused for the other. Your raw IP address is not written to this record, and Ciphora does not store or log it in the application's own logs or storage. That statement is about what Ciphora controls: our infrastructure providers, described under Service providers, receive and handle IP addresses as part of delivering and protecting the site, under their own policies. No email address, no message content, and no name, account, device or other direct identifier is stored in this abuse-prevention record. The stored value is the only identifying field it has.

That value is a pseudonymous identifier rather than anonymous data, and we describe it that way deliberately. It cannot be read back to produce an IP address, but someone holding the server secret could test a candidate IP address by hashing it and comparing the result, so it remains information relating to you for as long as it is stored and it is treated as personal information under this policy. It is used only to enforce the rate limit. It is never used for marketing, analytics, profiling, or any decision about you, and it is never combined with your email address or with an application record.

The ten-minute expiry is a logical window, not a deletion time. A submission after the window expires starts a fresh window rather than adding to the old one, so someone who keeps submitting can keep a record present indefinitely. An expired record is not removed at the moment it expires: it remains in the database until the next successful run of a routine daily cleanup, which deletes expired records in bounded batches. That cleanup reports how much it removed and, separately, two different conditions: whether it reached its per-run limit (it did its work and stopped at the limit, so some expired records may remain until the next run) and whether it failed (the run is applied as a single unit, so a failure removes nothing at all and the records it would have cleared are still there). Both are visible to us for monitoring, and either means some expired records may still remain until a later run clears them.

Payments

Payment-card data is not collected because no payment flow is enabled and Ciphora Confluence Engine is not currently for sale. There is no purchase flow, no subscription, no cancellation flow and no refund flow in this build. No payment processor is currently active for Ciphora. Nothing in your account is a paid plan. Before any paid access is enabled, this policy will be updated to name the approved payment provider and to describe exactly what data it processes, and the paid terms themselves will be published before paid access opens rather than after.

How we use your information

• To review Early Access applications and manage beta access
• To send administrative messages about applications or beta access and, only when you separately consent, marketing messages
• To respond when you contact us
• To operate, secure, and improve our services

Lawful bases and required information

Where the GDPR, UK GDPR, or a similar law applies, Ciphora relies on the following bases: steps you ask us to take when you apply or contact us; performance of the Terms of Service after you accept an invitation; legitimate interests in operating, securing, evaluating, and improving a small research beta, including required operational telemetry; consent for optional marketing and optional Google Analytics; and legal obligations when records must be preserved or disclosed by law. Ciphora does not use consent where another basis is more appropriate. The playbook request rate limit described above is one of those cases: it rests on legitimate interests in keeping a public endpoint available and resistant to automated abuse, not on consent, and it is therefore required rather than optional.

Fields marked required on the application are needed to review the application and administer a possible beta invitation. If you do not provide them, the application cannot be reviewed. Marketing consent and provider names identified as optional are not required. Declining optional marketing does not prevent application review or beta eligibility. Telemetry is not required to apply, but it is a condition of accepting an invitation and participating in the research beta.

Ciphora does not ask for special-category information, government identifiers, account credentials, or payment-card data anywhere in its services. The application, the Knowledge Assistant, the feedback forms, and support messages do not ask for account balances or other financial figures either, and you should not include them there. Figures describing the condition of your own paper or simulated account are collected only through the separate opt-in form described above, under its own separately versioned consent, and are processed on the basis of that consent.

Service providers that process data

The complete list of providers that process data for Ciphora is this one, and each is named here with the single role it actually performs. Vercel hosts the website. Cloudflare protects and serves requests that are proxied through it. Neon operates the Postgres database. Resend delivers transactional email. Kit (ConvertKit) holds the email lists and the applicant contact record. Anthropic answers assistant passage-selection requests. Google and Discord are identity providers for the sign-in methods you may choose, and Google is additionally the optional analytics provider and the Director owner's identity provider. Databento is named only so its absence is explicit: it is the historical market-data provider a future Capital Reference view would use, Ciphora holds no entitlement for the dataset that view needs, and no request is made to it. TradingView hosts the invite-only publication the beta runs on and is where an administrator grants access by hand. None of these is a Ciphora partner, and naming or displaying one is a statement about a role, not a relationship.

If you use the public Knowledge Assistant on the homepage or Help Center, or the assistant inside your signed-in workspace, your question and a limited set of reviewed public knowledge-base passages may be sent to Anthropic, our AI provider. Those passages may include text, article titles, links, and stable passage identifiers. Data is sent only when the assistant is enabled, Anthropic is configured, and our server attempts a provider request. Anthropic's model selects which reviewed passages are relevant. If those conditions are not met, the assistant returns a reviewed no-answer message.

Anthropic's output is not shown directly. Our server accepts only passage identifiers from the set it supplied, then builds the displayed answer from the exact reviewed passages or returns a fixed, reviewed no-answer message. Do not include personal, account, or trading information in assistant questions. The assistant does not need that information.

Administrative beta delivery emails - a beta invitation, the onboarding message sent after your TradingView access has been verified, and required beta build-update notices - are delivered by Resend (Plus Five Five, Inc.), our transactional email provider, which processes them on our behalf. For these messages Resend receives the recipient email address, the first name used in the greeting, and the message content; for an invitation email that content includes the one-time invitation code, which can be used once, expires, and is never placed in a link. Resend returns signed delivery notifications for these messages (for example delivered, bounced, or a spam complaint), which our server verifies cryptographically before recording them to administer delivery. Ciphora does not enable Resend's open or click tracking, and does not send marketing email through Resend. Until Resend accepts an invitation message, the one-time code is stored in our database only in encrypted form, and it is erased from the delivery record once the message is accepted or the delivery attempt ends without sending.

Account email - address verification, password reset, the security notice after a reset, and beta review notices - travels the same transactional path, and Resend receives the same three things for it: the recipient address, the greeting name, and the message content. The sealed envelope described under Account emails above is opened only at the moment the message is handed over, and is erased as soon as the provider accepts it.

Our website infrastructure providers process requests to serve the site and protect it. Vercel (hosting and request handling) receives standard request data such as IP address, user agent, and requested URL as part of serving the site. When a request is proxied through Cloudflare, Cloudflare processes network and security metadata (such as IP address, user agent, and requested URL) under its own services and policies. We do not make claims here about these providers' internal retention or training practices beyond what their own policies state.

If you affirmatively allow optional public-site analytics and the Google Analytics measurement identifier is configured, Google processes the limited analytics information described above. Ciphora does not enable Google advertising storage, Google signals, ad personalization, or advertising user data through this implementation.

Director owner sign-in with Google

Ciphora Director is the private administration console that Ciphora's single owner uses to review Early Access applications and operate the beta. Where the managed sign-in is configured, the owner signs in to Director with a Google Account that belongs to the ciphora.ai Google Workspace. This section describes only that sign-in. Applicants, beta participants, and visitors to the public website never sign in with Google, are never asked to connect a Google Account, and are not affected by this section except as described under Purpose below.

What is requested. The sign-in uses Google's OpenID Connect flow with the scope openid email and nothing else. It does not request profile, contacts, Gmail, Calendar, Drive, or any other Google API scope, does not request offline access, and receives no refresh token. It asks Google to include two additional claims in the signed identity token, the authentication method references (amr) and the authentication time (auth_time), and asks Google to show its own login screen rather than reuse a silent browser session. Google decides whether to supply those claims; asking for them is not treated as receiving them.

What is accessed and how it is used. From the signed identity token Google returns at sign-in, Ciphora reads the account's stable subject identifier, email address and its verified flag, hosted domain, authentication method references, and authentication time. Ciphora uses them for one purpose: to confirm that the person signing in is the configured owner and that Google attests the sign-in used multi-factor authentication. The sign-in is refused unless the email address is verified and equals the configured owner address, the hosted domain is ciphora.ai, the subject identifier equals the owner account identifier pinned in the deployment's configuration, and the authentication method references literally include mfa. A refused sign-in creates no session, and Ciphora's application code records only a fixed diagnostic reason in its server log, never an email address, account identifier, claim, or token.

Purpose. A verified Google sign-in identifies the owner to Director. The multi-factor evidence additionally gates one surface that holds applicant personal information: the owner's ability to read the Early Access applicant list held in Kit, which contains applicant names, email addresses, and four application fields described elsewhere in this policy. That list is fetched with Ciphora's own Kit credentials; no Google data is sent to Kit. Google data is not used for advertising, analytics, profiling, model training, or any purpose other than authenticating the owner and gating that access.

Storage. Ciphora runs no account database for this sign-in. The validated claims are held only inside an encrypted session cookie in the owner's browser, together with a non-secret revocation value. Each session cookie expires twelve hours after it is issued or refreshed; continued use of Director may result in a refreshed cookie, so an active session is not limited to twelve hours in total. Ciphora's application code does not write Google tokens or Google claims to its database, to Kit, to Resend, to Anthropic, to analytics, or to its own logs. The session endpoint exposes to the owner's browser the owner's email address, role, non-secret revocation values, and a yes-or-no verification flag; it never exposes the subject identifier, the authentication claims, or any token. The owner's configured email address, which is the same address the Google Account carries, is recorded as the acting administrator in Director audit records, and a keyed, non-reversible pseudonym of that address identifies the owner's Director workspace record. Those records describe the owner's own administrative actions and follow the retention schedule below.

Sharing and processing. Ciphora does not sell Google sign-in data, does not share it with or transfer it to any third party for that party's purposes, and does not use it for advertising. Two providers necessarily process it: Google, as the identity provider, under its own privacy policy; and Vercel, which hosts ciphora.ai and therefore handles the sign-in requests, including the callback request that carries Google's one-time authorization code, together with standard request data such as IP address, user agent, and requested URL, under Vercel's own logging and retention practices. Ciphora's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Retention and control. Access ends when the owner signs out, when the deployment's revocation value is changed, which invalidates every previously issued session cookie the next time it is presented, or when a session cookie reaches its twelve-hour expiry without being refreshed. Removing any part of the configured owner binding closes the multi-factor gate immediately for every session. The owner can also remove Ciphora's access from the Google Account's third-party access settings at any time. Because the only account involved is Ciphora's own owner account, the rights described under Your rights apply to the owner in the same way as to anyone else.

Where your information lives

Application data accepted by the service is stored in a Postgres database operated by Neon on our behalf. Only the contact, application-administration, policy-version, and marketing-choice fields needed for email operations are synchronized to Kit (ConvertKit). A separate homepage playbook request sends only the submitted email address and dedicated playbook-delivery form membership to Kit; it does not create a beta application or enroll the visitor in product marketing. A Research & Launch List request sends the fields described in that section to its own Kit form and does not store the contact record in Neon. Detailed trading-profile answers remain in the Neon database and are not copied to Kit; the one-time invitation code is never sent to Kit. The Neon database also stores beta telemetry, feedback, invitation and consent records, delivery records for administrative beta emails, related audit history, and the public-email-request abuse-prevention records described above (a purpose-separated pseudonymous keyed value, a window, and an attempt count, with no contact data and no raw IP address). Administrative beta delivery emails are processed by Resend (Plus Five Five, Inc.) as described under Service providers that process data. Kit, Neon, and Resend process this data as service providers. Vercel hosts our website.

Account data lives in the same Neon database: the account record and its verification provenance, the password hash, provider sign-in links, sessions, single-use challenges, the keyed abuse counters, preferences, the profile with its optional encrypted phone number, the beta review and its separate permission and provisioning states, account-email envelopes and their delivery evidence, assistant conversations and messages, assistant memories, and the connections, imports, execution records, derived trades, reconciliations, journal entries and Capital Reference results described above. The avatar image is stored as a private object outside the database. None of this is synchronized to Kit: Kit receives the contact and eight administration fields for an application, the playbook-delivery membership, and the Research & Launch List fields, and nothing else.

International transfers and geographic limits

The initial private beta application is currently limited to adults who reside in the United States. The server rejects an application that identifies another country before creating an application record or an email-platform delivery job. Website availability in another country does not mean beta access is offered or approved there.

Ciphora and several service providers named above operate in the United States. Public website requests and provider operations may be processed in the United States or another country where a provider operates, and privacy protections and government-access rules may differ from those in your country.

Ciphora will not open applications or invitations in another country until the controller identity, provider contracts, transfer safeguards, local representatives where required, and applicable product, privacy, marketing, consumer, accessibility, and financial-services rules have been reviewed for that jurisdiction. Where European or United Kingdom transfer rules apply, a lawful transfer mechanism and related safeguards must be implemented before accepting an application.

Email choices

Marketing emails include an unsubscribe link. Unsubscribing stops future marketing but does not withdraw an Early Access application or prevent administrative emails needed to review and manage an application you submitted, such as a receipt, status message, or beta invitation. Submitting an application does not guarantee delivery of an administrative email. To withdraw an application, email us.

Your rights

You may ask us to access, correct, export, delete, or restrict personal information we hold about you by emailing legal@ciphora.ai. You may also withdraw consent at any time for processing based on that consent and, where applicable, request data portability. We handle valid requests under applicable law, normally without charge, and may verify your identity before acting. If a legal exception limits your request, we will explain why.

These rights vary by location and by the lawful basis used. Ciphora extends the request process above to all applicants and beta participants even when a particular local law does not require every listed right.

Your right to object

Where processing relies on legitimate interests, you may object by emailing legal@ciphora.ai and explaining the processing you want stopped. You may object to direct marketing at any time without giving a reason by using the unsubscribe link or contacting us. Ciphora will stop direct marketing after an effective objection, while retaining only the minimum suppression record needed to honor it.

Complaints and supervisory authorities

You may contact legal@ciphora.ai so we can investigate. You do not have to contact Ciphora before using a complaint right available to you. If European data-protection law applies, you may complain directly to the supervisory authority where you live or work, or where you believe an infringement occurred. United Kingdom residents may complain to the Information Commissioner's Office. California residents may contact the California Privacy Protection Agency where the CCPA applies. These options do not limit any other remedy available under law.

No solely automated significant decisions

Ciphora does not use solely automated processing to make a decision that produces a legal or similarly significant effect. Application screening may organize submitted information, but a Ciphora administrator reviews every beta invitation decision, and that decision is recorded as a decision by a person. The assistant selects reviewed public passages and does not decide beta eligibility, trading access, employment, credit, insurance, or any other significant matter. Capital Reference performs arithmetic on figures you typed and returns the result to you; it decides nothing about you.

The account-rule features described above do apply automated rules to figures you enter and do produce an automated result. That result is decision-support returned to you and nothing else. It does not place a trade, does not decide your access to Ciphora or to any third party, and does not affect your beta eligibility, your credit, your employment, your insurance, or any other significant matter. Beta eligibility and account-rule output are separate throughout: an account-rule result is never an input to an invitation decision, and an invitation decision is never an input to an account-rule result. Whatever words a result uses to describe its own outcome refer only to the comparison between the figures you entered and the rules you configured, and carry no meaning outside it. You may disregard any result entirely, and you may withdraw the consent that enables these features at any time.

Retention schedule

Applications that are declined or withdrawn are deleted or de-identified within 12 months after the final decision or withdrawal. Applications that remain pending and are never invited are deleted or de-identified within 12 months after the most recent submission or applicant-initiated update. Records for accepted participants, including consent receipts, access history, administrative email delivery records, feedback, operational telemetry, and any account-condition figures and the results produced from them, are deleted or de-identified within 24 months after the earlier of the end of participation and the end of the beta. Separately from that outer limit, an individual account-condition record stops being usable as an input a fixed ten minutes after the moment you captured it. That expiry ends the record's use immediately, but it is not by itself a deletion: the expired record, and any result produced from it, stay stored until the 24-month rule above or a granted deletion request removes them. Support and privacy-request records are retained for up to 24 months after resolution. Playbook-delivery form contact data is kept only while needed to fulfill and document the requested delivery, resolve delivery or privacy issues, and honor a valid legal requirement; it is reviewed periodically and removed when no longer needed. Research & Launch List contact and preference data is kept in Kit while you remain subscribed or while a minimal suppression record is needed after unsubscribe, subject to a valid legal requirement. The public-email-request abuse-prevention record described above holds no contact data and follows its own schedule: its ten-minute window is a logical expiry rather than a deletion, a later submission starts a fresh window instead of extending the old one (so continued activity can keep a record present), and an expired record stays until the next successful run of the bounded daily cleanup removes it. That cleanup is monitored and reports a per-run limit (records may remain until the next run) or a failure (the run is applied as a single unit, so nothing is removed and the records remain), either of which means some expired records may remain until a later run. Optional marketing contact data is kept until you unsubscribe or withdraw consent. Afterward, Ciphora may retain a minimal suppression record to prevent future marketing.

Account records follow the account. While your account exists, Ciphora keeps it and the records tied to it: your identity and verification provenance, provider links, preferences, profile, assistant transcript and memories, beta review state, and imported trading records and Capital Reference results. There is no automatic expiry for an account that stays open, and there is no self-service deletion control in this build; a granted deletion request removes the account record, and the records above are removed with it by the database itself, because each is bound to the account rather than merely referencing it. Three kinds of record are treated differently and deliberately: consent receipts, which are the evidence of what you accepted and when, and are kept for their own period below; account-email delivery evidence, which holds no recipient, subject or body and is kept to administer and document delivery; and the beta application and its lifecycle records, which follow the application periods above rather than the account. Sessions and single-use challenges expire on their own and are removed as they do. The keyed abuse counters hold no contact data and follow the same bounded cleanup as the public-request records described above.

A shorter period applies when information is no longer needed or a valid deletion request is granted. A longer period applies only when reasonably necessary for security, fraud prevention, legal obligations, or establishing, exercising, or defending legal claims. Infrastructure and security logs controlled by service providers follow each provider's documented schedule. De-identified research records may be retained only when they can no longer reasonably be linked to a person.

Children and age eligibility

The beta application and beta are intended only for adults who are at least 18 and legally able to accept the Terms. Ciphora does not knowingly accept beta applications from anyone under 18. If you believe a minor submitted personal information, contact legal@ciphora.ai so the record can be investigated and deleted where required.

Cookies and consent controls

The public website does not use advertising cookies. Where Cloudflare Web Analytics is enabled for a deployment, it is described above as a cookie-free aggregate analytics service. Google Analytics is optional and remains unloaded until you select Allow analytics; that choice is stored in local storage and can be changed through Analytics preferences, which is reachable from the footer of the public pages and from the compact legal row on the account and workspace pages. If allowed, Google Analytics may set the first-party analytics cookies described above. The Research & Launch List attribution object uses the PII-free session storage described above and remains separate from analytics consent. The playbook offer also uses the two PII-free functional local-storage markers described above; they are separate from optional analytics and from the access-receipt cookie. A confirmed playbook request sets the seven-day, strictly necessary, HttpOnly, PII-free access-receipt cookie described above, scoped to the /playbook path. Accepted beta participants also receive a strictly necessary, secure session cookie for onboarding and feedback.

Signing in to a Ciphora account sets a strictly necessary, host-only, secure, HttpOnly session cookie. It sets no expiry, so it lasts until you close the browser or sign out, and it is not a remember-me. It carries an opaque token whose stored form is a hash, so the stored value cannot be replayed, and the session it names can be revoked on its own or by changing the account's revocation number. Starting a sign-in with Google or Discord sets short-lived, strictly necessary cookies that carry the state of that one attempt and are cleared when it finishes. These are required to sign in. None of them is analytics, none can be declined while still signing in, and declining analytics does not affect them.

Changes to this policy

If this policy changes in a way that materially affects an applicant or participant, we will update the effective date above and provide any administrative notice required by law through the contact channel associated with the application or beta account. This notice does not depend on marketing consent. If applicable law requires consent to a change, we will request it before the change takes effect.

A publication that only adds or corrects a description of how Ciphora processes its own owner accounts, such as the Director owner sign-in section, updates the published date above but does not change the effective date or the applicant and participant consent version, and does not ask anyone to acknowledge the policy again.

When the change IS material, as this revision is, the version above moves and existing people are asked to accept the republished documents. Nothing is taken away while you decide. If you hold a Ciphora account, your account, your sign-in methods, your settings, your assistant transcript and memory, your records and your current session all stay exactly as they are, and the acceptance is recorded as a new, additional receipt rather than by editing or replacing the receipt you already have. If you have a beta application, the same is true of it: its identity-verified renewal path records a fresh receipt against the current versions and the application keeps its data and its place. Your separate marketing choice is never re-collected by this and is never bundled into it, and your separately versioned account-rule consent for Risk Intelligence is untouched by it.