Skip to main content

Privacy architecture

Privacy architecture v1.0 — effective 2026-05-05

How the platform handles private deal data: a client-side execution model in which the platform's servers never see your private inputs, intermediate values, or derived outputs. This page is the customer-facing surface of that architectural commitment, and the basis for the audit-under-NDA pathway described below.

For what the Platform collects, who processes it, and how long it is kept, see the Privacy Policy.

The architectural commitment

Hybrid V1 commits to the following architectural model for private-data handling:

  1. Browser-side execution. All computations on customer-supplied private inputs run in the customer's browser via Pyodide/WASM. The validated formula library compiles to WebAssembly and executes locally. The platform's servers do not see private inputs, intermediate computation values, or output values derived from private inputs.
  2. Browser-side persistence. When the customer opts in to persist a deal across sessions, the persistence target is the customer's browser localStorage. The platform's servers do not store private-deal state.
  3. Browser-side export. When the customer exports a workspace, the export target is a file the browser delivers to the customer's local filesystem. The platform's servers do not retain copies of exports.
  4. Server-side telemetry — strictly bounded. The platform's servers may receive the following telemetry from private-data sessions: (a) page-view events with no payload (e.g., "user opened private-deal page" — no deal identifier, no input values); (b) feature-usage events with no payload (e.g., "user clicked Generate LBO" — no deal context); (c) error events with stack traces only, with all input values redacted. No deal identifier, no input values, no output values, no derived metrics flow server-side under any circumstances.
  5. No analytics cookies on private-data pages. Third-party analytics (Google Analytics, Mixpanel, Segment, etc.) are forbidden on every page that handles private data. First-party telemetry per (4) is permitted, scoped strictly to operational metrics.
  6. No third-party script execution on private-data pages. All JavaScript on private-data pages is first-party and source-controlled. CDN-loaded libraries are pinned to specific versions and SRI-hash-validated. Pyodide is loaded same-origin from the platform's own static hosting (self-hosted under the platform domain and SRI-hash-validated), not the public Pyodide CDN, to avoid any third-party access pattern.
  7. Public-data and private-data isolation in the browser. Public-data network requests (USAspending, EDGAR, etc.) are made exclusively from public-data pages. Private-data pages do not make any network requests beyond loading the application bundle and Pyodide; in particular, private-data pages do not call the platform's public-data endpoints with any payload that could correlate to a private deal.
  8. Methodology version stamping with immutability. Every output produced from private inputs carries the methodology version stamp of the formula library that produced it. The customer can always reproduce a historical output by re-running the same inputs through the same methodology version. Methodology versions are immutable; once published, they are never edited.

What this rules out, explicitly

  • Server-side processing of customer inputs.
  • Server-side caching of customer-derived values.
  • Server-side logging of customer inputs or outputs.
  • Server-side aggregation of private-data signals across customers.
  • Cross-customer data analytics of any kind on private inputs.
  • "Anonymized" exports of private-data signals that could be re-identifying.
  • Third-party analytics that could correlate session activity to a customer identity.
  • Surfacing one customer's private data to another customer in any form.
  • Using customer private data to train shared platform models.
  • Using customer private data to enrich the platform's master dataset.
  • Any "we noticed you've been looking at..." prompts based on private-data activity.

What this permits, explicitly

  • Aggregated, anonymized usage signals at the population level (e.g., "47% of sessions use the LBO surface" — no per-customer identification).
  • Customer relationship metadata (billing, support, login frequency) — the company's own data about the commercial relationship, not the customer's analytical work product.
  • Customer-volunteered feedback for product improvement.
  • Per-tenant agent operations producing per-tenant outputs for that customer alone (V2+; V1 has no agents touching private data).
  • Track Record entries for public-target calls (public by design; not customer-derived).

The customer audit pathway

The privacy architecture is documented here as a customer-facing surface. Institutional buyers can request an audit under NDA; the audit reviews:

  • The page-by-page network call inventory for every private-data surface, demonstrating no private payloads transit to the server.
  • The Pyodide/WASM execution model demonstrating in-browser-only computation.
  • The localStorage schema demonstrating browser-only persistence.
  • The export schema demonstrating customer-controlled data egress.
  • The error-handling code paths demonstrating input redaction in error reports.
  • The third-party script policy and SRI-hash validation demonstrating no third-party access patterns.