How your data actually moves through this platform

What persists, and what doesn't

The product's core value is remembering your portfolio, notes, and research — that data is intentionally persisted. Everything that flows through the AI reasoning layer is deliberately not.

Persistent memory & retrieval

Notes you save aren't just stored as flat text you have to search by exact keyword. Each one is also embedded by a compact, local, open-weight model — no external embedding service is called to do this; the vectors are generated on our own servers — and matched by meaning using standard vector search inside our existing database. Verified If a note hasn't been embedded yet, or that lookup fails for any reason, we fall back to full-text search rather than returning nothing.

Notes can also be linked to the market instruments they discuss — a commodity, a stock, a rate — matched automatically against a maintained list of known assets, and correctable by you afterward if the match is wrong. That link is a reference to a public asset identifier, never a stored copy of price data. Verified To be precise about what this is: it's graph-like retrieval built on ordinary relational and vector-search primitives, not a dedicated graph database — we'd rather describe it accurately than oversell the architecture.

The inference layer

When you ask Nexus Guru a question, we assemble a snapshot of whatever's on your screen at that moment — position values, note context, research summaries — and send only that snapshot, not your full account history, to a vendor-hosted inference provider running an open-weight model. Verified The snapshot and the response are held in memory for the duration of that single request and discarded afterward; our servers never write it to a database or log file.

On the provider side: per that provider's data policy, API inputs and outputs are never used to train models, and we have Zero Data Retention configured on our account — the provider does not log or retain inputs or outputs at all, not even the temporary reliability/abuse-monitoring logs it would otherwise keep for a limited period. Vendor-asserted That configuration lives in the vendor's own console, not in our code — real, but not something we can prove from outside that relationship.

Data minimization in the research cache

Company research reports are cached to avoid re-running expensive lookups. The cache key is an HMAC-SHA256 digest of the normalized company name — the raw company identifier itself never appears in the key store. Full reports cache for 24 hours; partial/low-confidence reports for 1 hour, after which they're re-fetched fresh. Our social-intelligence feed (news/sentiment tracking) is stricter still: it holds nothing on disk at all — extracted company mentions live only in process memory for the duration of that request cycle.

Database access model

Our database (managed Postgres) runs with Row Level Security enabled on every table — a user's query for their own data is filtered by the database engine itself, based on their authenticated identity, independent of whether the application code above it happens to include the right filter. Verified Operational and usage-tracking tables carry no public policies at all — they're reachable only through a service-role credential that lives exclusively in server-side environment variables and is never shipped to the browser. A leaked client-side key does not grant access to these tables; there simply isn't a policy that permits it.

One thing worth stating plainly: on a managed Postgres platform, row-level policy alone isn't always sufficient, since the platform can grant baseline privileges to application roles independently of policy. We don't assume a policy is correctly locked down — we check actual role privileges directly against the database with introspection queries after every change to this layer. Verified

Market-data isolation

Live prices and rates come from public, unauthenticated market-data and economic-data sources — the same public figures regardless of who's asking, with no credential tied to your account. Verified The code that fetches and caches this data has no path into user identity, authentication, or the database client that reads your notes — a structural property of how the code is organized, not a rule that depends on every future change respecting it. The cache in front of it is keyed by instrument and time window, never by user. Verified

The two features that intentionally bring notes and market data into the same view — grounded Guru answers and the related-notes panel on market screens — join them by reference, not by value, and only for the duration of one request. A note links to an asset identifier, never to a copy of that asset's price; the live figure is always fetched fresh at read time, and no table anywhere stores the two merged. Verified To be precise about the boundary: this is a data-architecture separation, not a network one — both kinds of request are handled by the same application, not by physically separate infrastructure.

Usage controls

Nexus Guru enforces per-user hourly and daily message caps, checked atomically against the database before each request reaches the inference provider — so a runaway script or compromised session can't silently rack up unbounded usage against your account. Limits are configurable per deployment.

Sub-processors

Categories of third-party services this platform actually calls, and what each one sees. We name exact vendors in a real diligence packet — this page describes them by role rather than by brand.