How we handle what you type into the Council.

The default: we don't persist your scenario content.

When you run the demo, your input is sent to our Vercel function, forwarded to OpenRouter (which routes to Anthropic / OpenAI / Google / xAI depending on the role), and the response is returned to your browser. By default, the scenario text and model output are not persisted on our servers. The decision record lives in your browser; if you copy a share link, the record is encoded in the URL itself, not in a database. Operational logs (described in the next section) capture only non-content metadata.

The data path, end to end.

For a vendor review, here is the full path a scenario travels, in order. Nothing content-bearing travels outside the hops on this page.

1. You type (or dictate) a scenario in your browser.
2. Your browser sends it over TLS to a Vercel serverless function.
3. The function forwards it to OpenRouter, pinned to a non-PRC provider allowlist, which routes each role's call to its pinned model vendor (Anthropic / OpenAI / Google / xAI). The same allowlist is enforced on every OpenRouter path that carries user input, including the single-model baseline and plan-document extraction.
4. The vendors return role outputs; the chairman synthesis comes back through the same function to your browser.
5. By default, nothing content-bearing is written to any store. A content-free telemetry row (tier, duration, structural flags) is recorded.
6. Two opt-in exceptions, each described in its own section below: a record you explicitly file to your firm's archive, and a scenario you explicitly donate via “Help improve the Council.”

One input makes an extra hop before this path begins: dictated audio goes to Groq for transcription, described in its own section below. Sub-processors on this path: Vercel (hosting), OpenRouter (routing), the model vendors above, Groq (voice only), Neon (database for the opt-in stores and telemetry). Encryption, incident response, the DPA approach, and SOC 2 status (planned, not yet engaged) are stated plainly on /security; the full sub-processor table with purpose of processing is on /trust.

Filed records: you choose this, one record at a time.

The default above does not change. Separately, after a run you can choose Save to archiveon an individual record. This is a deliberate, per-record action, distinct from the “Help improve the Council” checkbox and distinct from copying a share link. If you never use it, nothing in this section applies to you.

When you file a record, we store the decision record itself: the scenario text, the decision, the process score, risks, the preserved dissent, the timestamp, and the firm you filed it under. We store it so your firm can pull up its own records later.

The Council is designed to work without client identifiers: it reasons over attributes (age, assets, goals, time horizon), never identity. You are responsible for removing all client-identifying detail before you submit, including narrative descriptions that could identify a client. As a backstop, obvious identifiers we detect (names, account numbers, SSNs, addresses, phone numbers, emails, dates of birth) are rejected rather than stored, but no automated screen is reliable, and it is not a substitute for your review.

Filed records are visible only to members of the firm that filed them. No firm can see another firm's records. Any member of your firm can remove any of your firm's records, and removal takes it out of retrieval. You can also email founders@teranode.ai to remove a record, or every record for your firm.

Your firm owns the record. The copy you download when you file it is yours, kept in your own system; the Teranode archive is a convenience copy for retrieval. We run on managed Postgres with point-in-time recovery, but we do not offer a retention guarantee at this stage, and you should not rely on Teranode as your only copy of any record. Each record carries a SHA-256 content fingerprint you can re-verify, not a tamper-proof seal.

The opt-in: “Help improve the Council.”

On the demo page there is a checkbox, off by default, labeled “Help improve the Council.” If you check it, we store the following for the run that follows:

• The scenario text you typed (or transcribed from voice)
• Any structured inputs you entered, meaning the client-profile attributes (such as age, assets, goals, time horizon) and the constraints, as you entered them
• The Council's response (final answer, recommended action, process score, risks, dissent, per-role outputs)
• Which feedback button you clicked, if any
• An anonymous, browser-generated session id
• Run timestamps and duration

We never store your IP address, your name, your email, your client's name, or any cookie that identifies you across sites. The session id is generated in your browser and tied only to that browser's storage. Clearing browser storage breaks the link.

Our team reviews these scenarios to improve the Council's prompts, the synthesis logic, and the model selection per role. We treat them as confidential research material. They are not shared, sold, or used for advertising.

You can email founders@teranode.ai at any time to request deletion of any scenario tied to your session id. Include the session id (visible in your browser's DevTools under localStorage.teranode_session_id) and we will remove the matching rows.

Voice transcription.

If you click the microphone, your browser records audio (90 seconds max), uploads it to our function, which forwards it to Groq for transcription via Whisper. Per Groq's policy, the audio is not retained after processing. The transcript is returned to your browser; whether the transcript is then run through the Council follows the same rules as typed input above.

Uploaded plan documents.

If you use “Bring a plan” to upload a plan-summary PDF or image, the file is sent to our server and forwarded to a vision model (Google Gemini 2.5 Pro, fallback Anthropic Claude Opus 4.8, via OpenRouter) that reads only the printed summary figures (on-track %, median ending value, downside value, retirement age). We do not store the file. It is held in memory only for the extraction request and discarded when the response returns; there is no database row or stored copy. The document is not added to the Council's reasoning; only the figures you confirm are used. Per the providers' API terms it is not used for training and is subject only to a short abuse-review window. Because the extraction model reads the full document image, redact client names, account numbers, and other identifiers before uploading.

Operational logs (always on).

Independent of the opt-in, we always log operational information to the Vercel function log:

• An anonymous session id
• Which event happened (run started, run finished, feedback clicked) and when
• Which role-and-model combinations succeeded or failed
• Run duration in milliseconds

We do not log your scenario text or the model's output in the operational stream. These logs exist to keep the demo running and to debug failures, not to study what visitors type.

Anonymous structural telemetry (always on, public on the reliability graph).

On every Council run (whether you opted into capture or not) we record one row of structural metadata about the computation. This row feeds the live counters and statistics on the public reliability graph. The reliability graph is intentionally a live, breathing artifact of the system's activity.

Each row contains only:

• The depth tier you selected (Quick / Standard / Exam-Tested)
• The mode (fast / deep)
• The advisory domain you selected from the structured-input dropdown, if any (retirement, portfolio, tax, estate, risk, general). If you didn't fill in structured inputs, this field is null.
• How long the run took (milliseconds)
• The count of role calls that failed (e.g., one model returned an error and fell back)
• Whether the cross-examination round was triggered, and if so, whether the chairman revised the decision after engaging the dissent
• Whether the SEC-RIA-examiner verification ran, and its verdict (pass / gap)
• Which chairman prompt version was used and which model-policy version was active

Each row contains none of: the scenario text you typed; your transcript; your client profile fields; the Council's output text; the decision; the dissent; any process-score or risk values that could indicate the substance of the decision; your IP address; your name; your email; or anything that could be linked back to you as an individual.

This is structural usage metadata about the computation, not content data about you. We log it because the reliability graph is a public-facing artifact of the Council's reliability discipline, and a graph that only counts opt-in runs would systematically understate what the system has actually done. Counting deliberations is the same shape as counting page-views: it tells the reader how active the system is, without ever revealing what any individual visitor was thinking about.

Third parties.

• Vercel hosts the site and the API. Vercel sees your IP address and request paths. That's standard for any web host. We use it for rate limiting (per-IP) and nothing else.
• OpenRouter routes Council role calls to the underlying model providers. They see the prompt for each role call. Per their terms, they do not train on data and may retain logs briefly for debugging.
• Anthropic, OpenAI, Google, and xAI answer individual role calls via the OpenRouter API. By default their API tier does not train on submitted data; each maintains its own short retention window for abuse review. The active routing set shifts when our role-pin policy upgrades; this page is regenerated from model-policy.json on every build so the disclosure here always matches the routing the code does.
• Groq handles voice transcription only, and only when you click the microphone.

We use Vercel Web Analytics and Vercel Speed Insights for aggregate page-view counts, route-level latency, and Core Web Vitals. Both run cookieless and capture no personal identifiers: no IP-to-user mapping, no cross-site tracking, no advertising fingerprint. Per Vercel's privacy notice, raw events are retained for up to 30 days for aggregation; aggregate metrics persist for the lifetime of the project.

We use no other analytics vendor: no Google Analytics, no Plausible, no Mixpanel, no PostHog. We have no advertising tracking. We do not embed third-party widgets, fonts (other than Google Fonts served via Next.js), or pixels.

For advisors testing real client scenarios.

If you are using the demo with anything resembling a real client's identifying details, we recommend redacting names, account numbers, and any other identifiers before submitting, both as a precaution against the third-party retention windows above, and as standard practice when introducing a new tool to your workflow before contracts are in place. The Council doesn't need identifiers to produce the decision record.

Changes to this notice.

If we change how data is handled, we will update this page and mark the change with a new dated section below. The current text is the contract today.