# Sphinixx Server Infrastructure Assurance Overview

**Document class:** External assurance / due-diligence summary  
**Disclosure level:** Non-secret. Does not disclose source code, credentials, private keys, exploit details, proprietary algorithms, internal hostnames, or infrastructure secrets.  
**Last reviewed:** 12 September 2026

## Purpose

This document describes the security and operational boundaries of the Sphinixx content server at a level suitable for customers, auditors, insurers, payment-provider reviews, counsel, and other legitimate due-diligence requests.

It deliberately describes **controls, ownership, data flows, and trust boundaries** rather than implementation details. Source code and other trade-secret material are maintained separately and are not required to understand the controls described here.

This document cannot prevent a court, regulator, or other competent authority from lawfully compelling production of additional material. If disclosure is legally required, Sphinixx should use counsel-led procedures to preserve confidentiality and request appropriate protective treatment for trade secrets.

## System Boundary

The server provides these high-level functions:

- user authentication and server-side sessions;
- room and realtime connectivity for engine clients and constrained web clients;
- creator/content publishing services;
- platform integrations;
- payment orchestration through external payment service providers;
- administrative and operational telemetry;
- persistent application data in PostgreSQL;
- transient/session/cache data in Redis;
- asynchronous background tasks where required.

The server does **not** require disclosure of engine implementation, rendering internals, proprietary format algorithms, or source-level architecture in order to explain these functions.

## Trust Zones

### Public client zone

Includes engine clients, approved browser/WebGL clients, and public REST/WebSocket entry points.

Controls expected at this boundary include:

- authenticated sessions where required;
- protocol/version validation;
- capability and room admission checks;
- request size and rate limits;
- origin/CORS policy;
- bounded realtime queues;
- idle connection expiry and heartbeat handling;
- server-authoritative validation before state mutation.

### Application zone

Application services enforce business rules and isolate concerns such as authentication, rooms, publishing, payments, administration, and platform integrations.

The design objective is that no external client receives direct database, Redis, payment-provider, or host-management access.

### Data zone

PostgreSQL is the primary durable application store. Redis is used for transient/session/cache/realtime coordination where appropriate.

Access is restricted to server-side components. Database credentials are deployment secrets and are not stored in client applications or assurance documentation.

### External provider zone

Third-party services such as payment processors and content-platform APIs are accessed through narrowly scoped server-side integrations.

Provider credentials remain server-side and are not written to public logs or client-facing payloads.

## Realtime and Room Resilience

Realtime connections are treated as recoverable transports rather than the sole source of truth.

Operational goals include:

- engine simulation can continue locally during temporary network failure;
- clients may reconnect without requiring a complete application restart;
- stale sockets expire after configured inactivity;
- heartbeat/lease failures cause reconnection rather than silent dead sessions;
- WebGL/browser inputs are constrained and categorised before state mutation;
- engine-originated state has priority over lower-trust viewer/control input;
- noisy inputs such as pointer movement should be coalesced rather than persisted per frame;
- queues are bounded so a slow consumer cannot create unbounded memory growth.

## Payment Boundary

Sphinixx payment orchestration supports external payment service providers. Current provider architecture is designed for Stripe and PayPal.

The server is designed so that:

- raw card numbers, CVV/CVC values, card magnetic-stripe data, and PIN data are not accepted into Sphinixx application APIs;
- payment credentials are collected by the payment provider's approved client/hosted flow;
- Sphinixx stores internal transaction identifiers, provider references, amount, currency, status, refund state, and limited non-sensitive metadata;
- payment-provider webhooks are verified before state changes are accepted;
- webhook event identifiers are recorded to make repeated delivery idempotent;
- provider calls are outside the realtime room/simulation hot path;
- provider secrets are deployment configuration, not source-controlled application data.

See `docs/payment_compliance_and_provider_controls.md`.

## Observability and Security Records

Operational telemetry should be structured around events rather than unconstrained log dumping.

Security/audit records may contain:

- UTC timestamp;
- category and outcome;
- request/correlation identifier;
- actor/client class;
- internal room/session/transaction reference where needed;
- coarse operational metrics;
- sanitised error classifications.

They should not contain:

- passwords;
- session tokens;
- OAuth access or refresh tokens;
- payment-provider secret keys;
- webhook secrets;
- SSH private keys;
- card/CVV data;
- seed phrases or private crypto keys;
- arbitrary request bodies unless explicitly required and reviewed.

## Portability and Deployment

The service is container-oriented and separates application code from environment configuration and persistent volumes. A small deployment may run on a single host, while database, cache, workers, and gateways can be separated later without changing public application contracts.

Portability does not imply that every deployment has identical security properties. Production configuration, TLS termination, network policy, secret storage, backup policy, database hardening, and host access remain deployment responsibilities.

## Trade-Secret Boundary

External assurance documentation should normally be sufficient to explain:

- what data is processed;
- which parties receive it;
- which security controls are present;
- how incidents are recorded;
- how payment and identity providers are isolated;
- how retention and deletion are governed;
- how privileged access is controlled.

It should normally **not** include:

- source code;
- exact proprietary algorithms;
- private repository history;
- private keys or credentials;
- security bypass procedures;
- exploit reproduction details;
- complete network topology including sensitive addresses;
- internal red-team payloads or defensive detection signatures where disclosure would materially weaken security.

Where a legitimate investigation requires more detail, disclose the least-sensitive evidence capable of answering the question first, while preserving required evidence and following applicable legal obligations.

## Assurance Limits

This document describes design and repository controls. It is not a certification, penetration-test report, legal opinion, PCI Attestation of Compliance, FCA authorisation, or guarantee against compromise.