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 / DeepSeek 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 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)
• The Council's response (final answer, recommended action, confidence, 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.aiat 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.

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 / FINRA Battle-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 FINRA-examiner verification ran, and its verdict (pass / gap)
• Which chairman prompt version was used (v3, v4) 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 confidence or risk values that could indicate the substance of the recommendation; 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.

• Vercelhosts 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 DeepSeek 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 Insightsfor 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 its recommendation.

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.