Home / Trust

Trust, security & data handling

The CISO & counsel view of Veriqa.

A factual account of how Veriqa is built, where data lives, how it is protected, and what is — and is not — yet attested. Written for security buyers, defense counterparties and institutional investors. Honest about stage, evidence-first, no marketing fluff.

01 · Hosting & data residency

Two providers, named regions, a small surface area.

Veriqa runs on a deliberately small infrastructure footprint: Vercel for the marketing site and the application's static delivery, Supabase for the API runtime, database and authentication. Both providers operate in the United States and the European Union; the active deployment region is selected per customer at onboarding.

Web & SPA — Vercel

The marketing site (quantum-nexus.dev) and the product console (app.quantum-nexus.dev) are served as static assets from Vercel's edge. Request logs and edge function invocations live in the Vercel platform.

API & database — Supabase

The Veriqa API (api.quantum-nexus.dev), the managed Postgres database and the magic-link authentication service all run on Supabase. Customer reports, account records and the audit trail live here.

Region selection

EU and US regions are available. The default for new tenants is EU; US is available on request. Region is set per project at provisioning and is not silently relocated.

Region commitments are infrastructure-level facts about where data is stored and processed, not a regulatory certification of data residency.

02 · Encryption

Encrypted in transit, encrypted at rest, honest about key custody.

All connections to the marketing site, the application and the API are TLS 1.2 or higher. Data at rest is encrypted using the cloud-provider-managed key management services that sit underneath Supabase and Vercel.

In transit. HTTPS is enforced site-wide; HTTP requests are redirected. TLS 1.2+ with modern cipher suites is required end-to-end. Database connections between the API and Postgres require TLS. The sign-in mailbox and outbound transactional email run over TLS.

At rest. The Postgres database, file storage and platform logs are encrypted at rest with provider-managed keys (AES-256). Backups inherit the same encryption.

Key management. Encryption keys are managed by the underlying cloud KMS services that Supabase and Vercel use. We do not hold the keys ourselves, and we do not yet offer customer-managed keys (CMK / BYOK). If a deal requires CMK, please ask before signing — we will be direct about whether and when we can support it.

At a glance

  • In transit: TLS 1.2+ everywhere
  • At rest: AES-256, provider-managed
  • Keys: cloud KMS via Supabase / Vercel
  • Customer-managed keys: not yet offered
  • Backups: encrypted, region-resident
03 · Access controls

Authentication you can audit today; enterprise SSO on the roadmap.

The product runs on passwordless magic-link email authentication and a role-based authorization model. We are early-stage and intentionally have not shipped SSO/SAML or SCIM yet — both are on the roadmap and we will not market them before they exist.

Today

Magic-link sign-in

One-time email links via Supabase Auth. No passwords are stored. Sign-in tokens are single-use and are not written to application logs. Sessions are bearer JWTs held in browser sessionStorage.

Available now
Today

Role-based access

Two roles are enforced in the API: user (creates and views their own reports) and reviewer (approves draft reports through the workflow gate). Authorization is checked per request; per-user scoping is enforced at the database layer.

Available now
Roadmap

SSO / SAML

Enterprise SSO (SAML 2.0 and OIDC) via the identity providers your security team already runs. Targeted as part of the enterprise tier; please ask if you need a committed date before signing.

roadmap
Roadmap

SCIM provisioning

Automated user lifecycle (joiners / movers / leavers) via SCIM 2.0, scoped to the enterprise tier. Not shipped yet; do not assume it is available in the current product.

roadmap
04 · Data retention & deletion

A default, a deletion path, an SLA we will stand behind.

Retention is described in the privacy policy; this is the operational summary. Account data and reports are retained while your account is active. Technical and access logs are retained for up to 90 days for security and debugging, then deleted or aggregated.

Default retention

Up to 90 days for technical and access logs. Account records and reports are retained while the account is active and for a limited period after closure, unless deletion is requested sooner.

Deletion on request

You can request account and report deletion at any time by writing to hello@quantum-nexus.dev. We may need to verify your identity before acting.

Our SLA

Verified deletion requests are completed within 30 days, subject to narrowly-scoped legal-retention exceptions which we will name in writing.

05 · Sub-processors

The full list, in one table.

Every external processor that touches customer data, what it is used for, and where it operates. Web fonts are self-hosted on our own origin — no third-party font CDN — so font loading does not disclose visitor IPs or request metadata.

We will give written notice via this page (and the changelog) before adding a new sub-processor that materially changes the data flow.

06 · Logging & audit trail

Enough to investigate, not more than we need.

We log the events required to operate the service safely, debug it, and prove that the reviewer gate ran. We do not log content that we do not need, and we do not log sign-in tokens.

What we log. Each API request is stamped with a request ID, the authenticated user ID, the route, the response status, latency, and the IP at the edge. Each report carries the rules-engine version and the schema version it was produced against. Reviewer approvals are logged against the exact report version that was approved, with a timestamp and the reviewer's identifier.

What we do not log. Magic-link tokens are not written to application logs. We do not record raw payment-card data (Veriqa does not collect it). Optional error tracking, when enabled, runs with PII scrubbing on and does not receive report content.

Retention. Technical and access logs are retained for up to 90 days, then deleted or aggregated. The reviewer audit trail is retained with the report.

Customer access. The audit trail for your own reports — versions, approvals, exports — is available on request. Write to hello@quantum-nexus.dev.

Logged per report

  • Request ID for cross-service correlation
  • Rules-engine version the report was produced against
  • Schema version the report validates to
  • Reviewer approval with timestamp and identifier
  • Export events with format and time
07 · Methodology integrity

Pinned versions. Reviewer-gated. Immutable after approval.

A trustworthy verdict depends on knowing exactly what rules were applied and exactly when they were applied. Veriqa is built so a report can be reconstructed and audited line by line, long after it ships.

  • Versioned engine. Every report is pinned to the rules-engine version that produced it. The version is stamped on the report and recorded in the audit trail.
  • Versioned schema. Every report validates against a published JSON Schema and carries the schema version, so the structure is reconstructable years later.
  • Immutable after approval. Once a reviewer approves a report, that version is frozen. Any change creates a new version with its own approval and audit record.
  • Transparent scoring. Scoring is a rule-based heuristic over text features — not a sentiment score and not a statistically validated model. We do not market it as one.
  • Verdict discipline. Public verdict vocabulary is Proceed / Monitor / Require further diligence. A Proceed verdict is blocked in software while any core advantage claim is needs-baseline.
  • Change record. Material changes to the engine, the schema, or the methodology are recorded in the changelog.
08 · Independence & conflict-of-interest

No stake in the verdict.

The value of a neutral referee disappears the moment it has its own bet to defend. Veriqa is built so its only product is a defensible decision — not a position in the company being graded.

No equity in graded companies

Quantum Nexus does not take equity, warrants, options, or revenue-share in companies whose claims or programs Veriqa grades. Acceptance of any such instrument is policy-prohibited.

No quantum hardware

We do not design, operate or sell quantum hardware, simulators or chemistry stacks. We have no modality to defend, which is the point.

Reviewer disclosure

If a reviewer has a prior personal, financial or employment relationship with a graded company, the report is reassigned to a different reviewer before approval. The disclosure is logged.

09 · Responsible disclosure

If you found something, please tell us.

We welcome good-faith security research and will work with you to investigate and fix issues quickly. Report findings to security@quantum-nexus.dev. A PGP key is available on request.

Scope. The marketing site (quantum-nexus.dev), the product console (app.quantum-nexus.dev), and the public API (api.quantum-nexus.dev) are in scope.

Out of scope. Sub-processor infrastructure (Vercel, Supabase, Anthropic), denial-of-service testing, social engineering of our staff or customers, and physical attacks.

Safe harbor. We will not pursue legal action against researchers acting in good faith, who avoid privacy violations, destruction of data, and degradation of service, who only interact with accounts they own or have explicit permission to test, and who give us a reasonable window to fix the issue before any public disclosure.

What to include. A clear description of the issue, the affected endpoint or surface, reproduction steps, and any logs or screenshots that help us triage. We will acknowledge receipt within two business days.

In scope

  • quantum-nexus.dev — marketing site
  • app.quantum-nexus.dev — product console
  • api.quantum-nexus.dev — public API

Contact

  • security@quantum-nexus.dev
  • PGP key available on request
10 · Compliance posture

What we have. What we do not. No "in progress" theatre.

A growing number of security questionnaires ask for attestations we are too early to honestly claim. We would rather be useful than impressive, so the table below is exactly what is true today.

Not yet attested. We are early-stage and shipping; please ask if you need a specific control mapped before signing. We will respond directly — yes, no, or "here is the compensating control" — rather than promising an attestation we have not earned.
11 · Status & uptime

One status page. Honest about its stage.

A live operational view of the marketing site, the application and the API. The current implementation is a static page; an automated, hosted status page is on the roadmap.

Where to look

The current status surface lives at /status. It is the canonical place we will post incidents and maintenance windows.

Today: static

The page is updated manually when we know about an incident. It does not yet poll components automatically; treat the absence of an incident as "no known issue", not "verified green".

Roadmap: hosted

A hosted status page with automated component checks and an email/RSS subscribe is on the roadmap. We will note the cut-over here when it ships.

12 · Last reviewed

This page is dated, and the dating means something.

Trust statements that are not dated are not trustworthy. This page is reviewed on a regular cadence and on any material change to the platform, the sub-processor list, or our compliance posture.

Last reviewed: 2026-06-08. Security-relevant changes are recorded in the changelog. To verify a specific assertion on this page or request supporting detail, write to security@quantum-nexus.dev.

Bring the questionnaire. We will answer it directly.

If your security or procurement team has a vendor assessment, a DPIA, or a specific control to map, send it. We respond with what is true today, what is on the roadmap, and where we will not pretend.