teranodeTrust

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

Decision records have to survive a compliance review. The system producing them does too. This page is what an enterprise compliance officer or institutional investor looks for first. Plain language. Every claim aligns with code shipped to production today.

01

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, nothing is stored. The choice persists in your browser's local storage so a returning visitor doesn't re-decide.

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.

02

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.
  • Cryptographic record fingerprint. Every shared decision record has a SHA-256 hash computed over its canonical JSON form. Tampering with any field of the record changes the hash.
  • No secrets in the client bundle.Council role prompts, the Chairman's synthesis prompt, the model policy file, and the confidence formula are imported only by the server-side route handler. The browser never sees them.
  • HTTPS everywhere, HSTS enforced, CSP via Vercel defaults.
03

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.

VendorRoleData they seeRegion
VercelHosting + serverless functionsIP, request paths, function logsiad1 (US East)
OpenRouterAI model routingRole prompts (which contain your input)US-based
Anthropic / OpenAI / Google / DeepSeekUnderlying reasoning models, accessed via OpenRouterThe role prompt assigned to themGlobally distributed (vendor-managed)
GroqVoice transcription (Whisper)Audio file (when the mic is used)US-based
NeonPostgres for opt-in capture (when configured)Captured scenarios + outputs (opt-in only)iad1 (US East)

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.

04

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.
  • SEC Predictive Data Analytics rule(proposed) applies if and when finalized. Our preserved-dissent attribution is consistent with the rule's expected disclosure requirements.
  • EU AI Act, high-risk classification for decision-support systems takes effect August 2026. The architecture (multi-role adversarial reasoning + preserved dissent + tamper-evident audit artifact) was designed to satisfy high-risk system documentation expectations.

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). A forthcoming independent advisory practice (registration pending) will be the client gate for Teranode. When questions are SEC- or FINRA-specific, we route to outside counsel rather than improvising in-house.

05

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 cryptographic hash on each record is a tamper-evidence fingerprint, not an on-chain anchor. We are deliberately separate from agent-payment products.
06

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 cryptographic-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.

07

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:

RoleModelVendorStatus
Riskclaude-opus-4.7Anthropicdefended
Buildergpt-5.4OpenAIdefended
Strategistgemini-3.1-pro-previewGoogleupgraded
Contrariandeepseek-r1DeepSeekupgraded
Chairmanclaude-opus-4.7Anthropicemergency-pin

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.

08

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.

09

Contact.

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