Built to be defensible, by the team filing it on the record.

Data handling.

By default, we do not persist the scenario content you submit. Council runs are stateless. Your input flows through a Vercel function, fans out to four reasoning roles + Chairman synthesis, and the response is returned to your browser. The scenario text and the model output are not stored on our servers unless you have explicitly opted in. Operational logs (described below) capture only non-content metadata such as request timing and error states.

On the live demo there is a checkbox labeled “Help improve the Council”. Off by default. Checked, it stores the scenario and the response in our learning corpus to inform prompt iteration. Unchecked, your scenario content is not stored. The choice persists in your browser's local storage so a returning visitor doesn't re-decide.

Separately, a firm signed into its archive can choose Save to archiveon an individual record. That is the only action that stores a record's content, it is per-record and deliberate, and the Council is designed to work without client identifiers: you remove any client-identifying detail before submitting, and obvious identifiers we detect are rejected as a backstop, not a guarantee. The firm owns the record and keeps its own downloaded copy; the Teranode archive is a retrievable convenience copy, not the firm's system of record. Full detail under “Filed records” on /privacy.

We never store your IP address, your name, your email, your client's name, or any cross-site cookie. The session id is generated in your browser and is local to that browser. Clearing browser storage breaks the link.

See: /privacy for the long-form disclosure that aligns with this section line by line.

Security posture.

Defenses layered into the application, verifiable by inspecting the live site:

• Per-IP rate limits on every paid endpoint: 10/min on /api/meeting/analyze, 30/min on /api/meeting/suggest-followup and /api/transcribe. Caps cost-DoS exposure.
• Cookie-gated admin surfaces with a separate password from any investor-shared surface. Comparison is timing-safe.
• API response projection. The public API response shape is defined explicitly. Internal council metadata (model policy version, role-by-role intermediates, freshness flags, override reasons) never gets bundled to the client.
• Re-verifiable content fingerprint. The printable decision record computes a SHA-256 hash in your browser over its JSON form, shown on the artifact. Anyone can recompute it and confirm it matches. It is a fingerprint you can re-verify, not a tamper-proof seal: the hash is unsigned and unanchored, so an editor who changes a field simply recomputes a matching hash.
• No secrets in the client bundle. Council role prompts, the Chairman's synthesis prompt, the model policy file, and the process-score formula are imported only by the server-side route handler. The browser never sees them.
• HTTPS everywhere, HSTS enforced (verifiable in the live response headers). A content-security policy is not yet configured; it is on the hardening roadmap.

Subprocessors.

We do not run our own model infrastructure or our own data centers. Every subprocessor below is named so an enterprise compliance team can review them independently.

None of these vendors train on submitted data under their default API tiers. We do not have direct contracts with the model providers. They are reached through OpenRouter, which is itself a transparent routing layer.

Regulatory posture.

Teranode is built FROM compliance constraints, not retrofitted into them. The product exists because regulators are moving on a visible timeline and advisory firms need an AI supervision answer that works under audit pressure.

• FINRA Notice 24-09 on AI tools in advisory workflows is the operating context. Our decision record is specifically the artifact that enables an advisor to document AI-assisted reasoning under that guidance.
• The SEC's 2026 Examination Priorities (released 2025-11-17) name adviser use of AI as a focus area, and the SEC applies its existing Marketing Rule (206(4)-1), books-and-records rule (204-2), and the adviser fiduciary duty to AI-assisted recommendations. The decision record is built to be the kind of documented basis those rules call for.
• The EU AI Act imposes logging and technical-documentation duties on high-risk AI in finance (credit scoring and insurance pricing), with compliance timelines still settling. We treat it as a signal of the documentation direction, not a rule that binds US advisers.

Founder Dan Zimon, Series 7, Series 66, and insurance licensed; fourteen years across institutional finance. Career: Zimmer Lucas Capital(associate, 2012–2014); ex-Millennium(research analyst and trader, 2014–2023); ex-MS Discovery(Portfolio Manager, 2023–2025). When questions are SEC- or FINRA-specific, we route to outside counsel rather than improvising in-house.

What Teranode is not.

The product surface is narrow on purpose. We deliberately do not do the following:

• Not investment advice. Decision records are an artifact for use within an advisor's existing supervised process. Teranode is software infrastructure and owes no fiduciary duty to the advisor's clients; the advisor remains the responsible party for any client-facing recommendation.
• Not custody, not money transmission. We hold no client assets, broker no trades, and route no payments.
• Not a substitute for advisor judgment. The Council is a structured second opinion, not an autonomous decision-maker.
• Not training on customer data. Captured scenarios under the opt-in flow are used to refine our prompts and our internal eval set, not fine-tune underlying models.
• No blockchain, no token, no payment rail. The SHA-256 fingerprint on the printable record is a content fingerprint, not an on-chain anchor, and not a tamper-proof seal. Signing or externally anchoring that hash (the step that would let a reader detect a later edit) is on the roadmap, not a property we claim today. We are deliberately separate from agent-payment products.

Code visibility.

Our repository is private at pre-seed. This is standard IP protection for a company in this stage and is not a posture we intend to keep forever. We plan to open the council architecture, the role prompts, and the schema definitions post-funding so buyers can independently verify what we say we do.

What is already public, today:

• The architecture is rendered as a hand-coded SVG at /brand/council-architecture.svg.
• A working sample of the artifact lives at /design/record, including the real, re-verifiable SHA-256 content-fingerprint computation.
• The customer-facing archive UI is mocked at /design/archive.
• The schema for a decision record is published in the artifact footer of every record. Six fields, deterministic shape.

Compliance officers can request the role prompts and the model-policy file under NDA before contracting.

Validation methodology.

Council quality depends on which frontier model we route to each role and which prompts each role uses. Both choices are decisions, not defaults. Both need evidence.

We run an in-product eval scaffold at /admin/eval that supports head-to-head A/B comparison. Two modes:

• Compare models. Vary one role's model; hold the other four roles and the chairman's prompt constant. Run the same scenario through both variants.
• Compare prompts. For the chairman role specifically, run the four reasoners ONCE per scenario and feed identical anonymized outputs to two prompt versions of the chairman in parallel. Isolates the prompt change as the only systematic difference.

Every comparison persists to a Postgres table for trend analysis. The system supports founder judgment and (post- funding) design-partner and outcome-signal judgment, growing into the reliability graph that informs routing decisions.

Current state of the model-pin policy, all five roles backed by eval evidence:

4distinct vendors across five roles. We route to the best frontier model per role, regardless of provider. Pin upgrades ship when the eval wins decisively; pin defends ship when quality is tied or when an architectural concern (e.g., duplicating an existing pin) overrides a quality win. Operational overrides (like the chairman's emergency pin shift) ship when a vendor's production reliability degrades a live demo and an eval-tied alternative is available.

Methodology and per-scenario comparison records are documented in the repository under eval-results/. Available under NDA before contracting.

Deep-dive: /methodology for decision rules, the live eval counter, and per-pin detail.

Reliability.

Uptime is hosted on Vercel's production edge. We have no published SLA at pre-seed and do not commit to one until we have paying customers. Operational telemetry (function-level latency, error rates, role-and-model failures) is logged to Vercel and reviewed daily.

If the demo is unreachable, email founders@teranode.ai and we'll respond within an hour during US business hours.

Continuity & key-person.

A reasonable diligence question for any pre-seed vendor: what happens to your records if Teranode is unavailable, acquired, or gone? The answer is built into the record format. A signed decision record is self-contained. The durable copy is the one-page document your adviser saves or prints, and a shared record is encoded directly in its URL, with no account, login, or Teranode backend required to open it. A record you have saved keeps working whether or not Teranode does.

Teranode is a small team, so key-person risk is real and we do not hide it. The mitigation is structural, not a promise: by default we do not hold your records at all (see Data handling above), and the records that exist are yours and readable without us, so your books and records do not sit behind our continued operation. Keep your own copy of any record you need to retain, in your firm's system of record.

Contact.

For due diligence questions, security review requests, vendor questionnaires, or anything else this page didn't answer:

• Email: founders@teranode.ai
• Telegram: @teranode_ai
• Privacy-specific deletion requests: founders@teranode.ai (include your browser's anonymous teranode_session_id)