What this platform holds about you

Every provider returns more than four fields. Google sends a profile picture, given and family names and a hosted domain; LinkedIn a locale and a picture; Microsoft a user principal name and group memberships. None of them is read, stored or forwarded. The code takes an identifier, an address, a display name and a verification flag, and lets the remainder of the response go out of scope.

An account row, holding a display name, the plan tier and the trial dates. A seat row, holding your email address, your display name, your role, a preferences object and the time you were last seen. An identity row, linking that provider and its identifier for you to that seat. Signing in again updates the last-seen stamp and the address your provider currently reports; it creates nothing new.

When a genuinely new account is created, its name is taken from the display name your provider returned — or, when the provider returned none, from your email address. That is the one field on the account record that can carry a person's identity, and it is worth knowing it is there.

When a provider states that the address it gave has not been verified, the sign-in stops there. The transaction that would have created your account is rolled back, no row survives it and no session is created. A provider that says nothing either way is not treated as a refusal — silence is not a denial, and the sign-in proceeds without that check.

Operator access is granted from a list held in the deployment's own configuration and matched against your address. No claim inside a provider's token can grant it, and none is read for that purpose.

The sign-in exchange returns tokens that would let this platform act at your provider afterwards. None is stored: what survives the handshake is the identifier, the address and the display name described above. Two consequences, and the second is the kind this page exists to state rather than omit. Signing out ends the session recorded here and needs nothing from your provider. But the console has no control that detaches a provider from your seat — the link is removed only when the account itself is deleted, which section 08 describes. Ending the platform's access at your end is done in your provider's own account settings, where the permission was granted.

The list name, the symbols in it, any note you type against a symbol, up to eight short tags per symbol, and the columns you chose to display. The note is free text and the console never inspects it.

The filter itself is three fields: a horizon, a signal class and a minimum confidence. Symbols, sectors and free text cannot be part of a screen, because those three are the only fields the specification accepts. Stored alongside it: when the screen last ran, the data date it ran against, how many names it returned, and whether you put it on a schedule.

The name, the template family and version, and your own parameter overrides. A database trigger writes a full snapshot of that definition every time it changes, so the version history is kept as well as the current state.

The request is stored as you sent it, under its own key, including a list of symbols when the client sends one. Beside it sits a frozen copy of the strategy as it stood when the run was queued, the run's status and timings, and what it was charged.

The rule: its name, what it watches — a symbol, a sector, a watchlist, a book or a saved screen — the condition, and the channel. Each time it fires, a delivery row is appended with the payload, and for a price, prediction or screen rule that payload names the securities that matched. The delivery log is append-only: once written, a row's contents cannot be edited.

The address you gave and a signing secret generated here, plus the outcome of the last attempt. HTTPS is required by the database itself, not only by the code that calls it.

A ledger row records the account, one of five fixed action names, how many assets were involved as a count, the breadth, span and depth multipliers, the cost, and the balance afterwards. It names no security whatsoever, and it names no person: the row is attributed to the account, and although columns exist for a user and a request identifier, nothing writes them. The parameters absent from the ledger are present on the strategy run, which is linked to you — the two are separate records and must not be read as one.

One row per sign-in: a random session identifier, the seat, your email address as the token's subject, which provider you used, when it was issued and when it expires, when it was last active, and a deliberately coarse device fingerprint. What that fingerprint is not is the subject of the next section.

Theme, whether the console's sidebar is collapsed, and the language of the public site. The route accepts exactly those three keys and rejects a fourth with an error rather than dropping it silently.

Identity is delegated. The only credential this console checks is the operator break-glass login of section 01, whose username and password live in the deployment's configuration and in no table. There is no password column in any table and no hashing routine anywhere in the console; a check that runs on every build reads the migrations and fails if such a column appears.

No payment processor is connected to this console. No card number, bank detail or billing address is requested, entered, stored or forwarded, because there is nothing here to enter one into.

The session record holds a network prefix rather than an address: an IPv4 address is stored with its final part zeroed, an IPv6 address as its first three groups. The truncation happens before the value is written, and an address the parser cannot read is stored as nothing rather than as a guess. The public contact form does read a caller's address in order to rate-limit itself, but that value lives in the running process's memory for an hour and is written to no database, no log and no message.

The User-Agent header is parsed once into three coarse words — a browser, an operating system, a device class — and the header itself is discarded. Any of the three that is not recognised stays empty rather than being filled with a guess.

There is a column on the session record for the country a sign-in came from, and nothing writes it. No geo-location source exists anywhere in the platform, so that column is empty on every row and the platform cannot say where you are.

There is no table of what you looked up. The screener is a read-only query, the research routes are reads, and no route records which symbol was requested. The two exceptions are real and should not be glossed over: a SAVED screen keeps when it last ran and how many names it returned, and an alert keeps what it checked and which symbols matched. Ad-hoc research leaves nothing behind; saved objects do.

Two tables exist to record operator actions — one of them shaped to hold a full IP address and a raw browser string — and nothing in the console writes a row to either. That is why the two absences above can be stated without qualification: no full address and no raw browser string is stored anywhere in the platform today. It is also a control this platform does not yet have, which is the less comfortable half of the same fact, and you should hear it here rather than work it out later.

The analytics tag and its consent banner are imported by the public site's layout and by nothing else. The reason is written into the code: a console URL names the security a signed-in client is researching, and that must not reach an analytics provider.

The analytical database holds market, fundamental and macroeconomic data. No user row, no identifier and no record of anything a person did is ever written to it. When you run work through the platform's research services, the console signs the call with a fixed service identity — your identity, your address and your session do not cross that boundary.

Google, LinkedIn or Microsoft, according to your choice. Each learns that you signed in to this platform, and sees your own address and browser as a matter of making the request. Nothing about your research, watchlists or portfolios is ever sent to them, and the exchange that completes the sign-in runs on the server, so they do not observe what you do afterwards.

All platform email is sent through Google's SMTP service. That covers alert emails to your own address — which carry the rule's name, what it watches, and the payload, including the symbols that matched — messages sent through the public contact form, and reports an operator sends to a client. The connection is encrypted; Google, as the operator of that service, necessarily handles the messages in transit and in the mailboxes at both ends.

Consent-gated exactly as section 04 describes, structurally absent from the signed-in console, and absent altogether when the deployment has set no measurement id.

This is the one that most needs saying. When you open a symbol in the console, the server asks Yahoo's public endpoints for that ticker's current quote, its recent headlines and, where available, analyst consensus and the next earnings date. The request is made by the server, so Yahoo sees the platform's own address and a fixed browser string rather than yours, and no cookie, session or account identifier travels with it — Yahoo cannot attribute the lookup to a person. What does cross is the ticker. A claim that nothing about your research ever leaves the platform would therefore be false, and this page does not make it.

The booking dialog embeds a Google appointment page. Closed, the frame does not exist and Google is not contacted at all. Opened, whatever you type into that calendar goes to Google rather than to this site, which cannot read inside it. Google's embed script is deliberately refused, so none of their code runs on this origin.

If you point an alert at a webhook, the alert payload goes to the address you gave — including the symbols that matched. It is signed so the receiver can verify it came from here, the destination must be HTTPS, addresses that resolve inside a private network are refused, and redirects are not followed. Your identity and your address are not in the body. What happens to it after that is between you and that endpoint.

Three downloads leave with you: your data as JSON, the credit ledger as CSV, and a strategy document. The strategy document embeds the exporting user's email address in its provenance block, so sharing that file discloses your address to whoever receives it.

No advertising network, no data broker, no customer-relationship tool, no session-replay recorder, no error-tracking service, no marketing pixel. The public pages load no third-party script other than the analytics tag described above, and the site's typeface is served from this origin rather than fetched from Google on each visit.

Its databases run on Google Cloud as well, reached over a private network rather than the public internet. The research warehouse and the transactional database are not exposed to the internet at all.

Every request to the console is logged by the hosting platform with the caller's address, the full URL including any query string, the browser string, the referrer, the response status and the latency. That log belongs to Google Cloud Logging and is written by the infrastructure, not by this application — which writes a single warning about a malformed analytics id and nothing at all in its data routes.

Analytics is kept out of the console precisely so a URL naming a security cannot reach an analytics provider. The same URL still appears in the infrastructure request log for the request that served it. Both statements are true, and stating only the first would be misleading.

Nothing in this codebase configures logging, a retention setting or a log sink, so what applies is the hosting platform's own default. Naming a number here would be inventing one.

Webhook deliveries are refused unless the destination is HTTPS, enforced by the database as well as by the code. Outbound mail uses TLS. Beyond that: the connections between the console and its databases run inside a private network and nothing in this codebase configures transport encryption on them, and nothing here supports a claim about encryption at rest. So none is made.

A session row outlives the session itself so that “a new device signed in last Tuesday” stays visible after that session ends. Thirty days past expiry, it is deleted. Three qualifications, because each of them matters: the sweep is not a scheduled job — it runs when somebody opens the sessions list; it is budgeted to once an hour per running process; and a session you revoke is removed 30 days after it would have expired, not 30 days after you revoked it.

Watchlists, saved screens, saved strategies and their version history, strategy runs, alert rules, alert deliveries, alert evaluations, webhook configuration, account and seat records, identity links, and the credit ledger. No cleanup job, no scheduled task and no expiry applies to any of them. They remain until somebody removes them.

The alert delivery log, the credit ledger and the strategy version history are append-only, enforced by the database rather than by convention. A delivery row can have its status advanced and nothing else. That is deliberate — a receipt you can rewrite is not a receipt — and its cost is that those three records cannot be selectively cleaned. Only the credit ledger is protected against deletion as well; the other two are removed with the alert rule or the saved strategy they hang off, which is what section 08 describes.

The trial end date governs what your account may do. Nothing is removed when it passes and nothing about your data changes; the entitlement is simply recomputed on the next request.

When retention rules exist for the tables above, this section will say what they are. Until then it says this.

One link streams every row the console holds for you as a JSON file: your seat record, your linked identities, watchlists and their members, saved screens, saved strategies, strategy runs, alert rules, alert deliveries, and your account's credit ledger. It is built so new columns cannot silently fall out of it, and a section that fails to read says so inside the file rather than appearing as an empty list. There is no job to queue and nothing is emailed.

Six things are absent, and naming them is the point of this paragraph: your session records, including their device fingerprints and network prefixes; the version history of your saved strategies; the current evaluation state of each alert rule; your webhook configuration; the billing account record; and the account row itself, with its tier and trial dates. Portfolio books are excluded deliberately and the file says so. The rest is a gap in the export rather than a decision, and it is listed here so the download is not read as more complete than it is.

A watchlist, a symbol within one, a saved screen, a saved strategy, an alert rule and your webhook configuration are each removed by the console when you ask it to — permanently, at once, with nothing queued. The removal reaches what hangs off them: deleting a saved strategy takes its version history with it, and deleting an alert rule takes its delivery log.

There is no automated route for it today: no self-service button, no operator control and no script. Ask through the contact form and an operator removes the records by hand. Every table that hangs off your seat cascades from that deletion, so removing it removes the watchlists, screens, strategies, runs, alert rules, sessions and identity links attached to it. The console's Profile screen says exactly this and deliberately shows no delete button, because a control that appeared to delete an account and did not would be the worst thing on that screen.

The credit ledger belongs to the account rather than to your seat, and it is protected against deletion as well as against editing — the database refuses to remove a ledger row at all, so an account-level deletion cannot take it out without that protection being lifted first. Section 07 explains why it is written that way. What survives is a list of how much work an account did and what it cost: no security is named in it and, as section 02 says, no person is either.

A deletion run by hand has no queue anybody measures, and a deadline nobody can keep is worse than none. What is promised is that you are told when it is done. If a self-service control is built, this is the paragraph that will describe it.

Removing this platform's permission at your identity provider is done in that provider's own account settings, not from this console — see section 01. Deleting your account here removes what this platform holds; it does not reach into Google, LinkedIn or Microsoft to withdraw a consent you granted there.