Paridity Security Whitepaper¶

Verified data. Trusted outcomes.

CDC-Aware Reconciliation Platform

Prepared for: General distribution Version: v0.1 · Date: 2026-10-29

Executive summary¶

Most vendor-risk reviews start with the same question: where does our data go, and who can touch it. For Paridity, the answer today is structural, not procedural: it doesn't go anywhere, and no one at Paridity can touch it. In Paridity's current shipping architecture, the entire platform - API, UI, workflow orchestration, all workers, and the PostgreSQL evidence store - is deployed inside the customer's own cloud account/VPC via a Helm chart and Terraform modules the customer controls. Paridity, the vendor, operates no infrastructure that holds or processes customer data, and has no network path to a customer's credentials, schema, object names, or evidence values. This removes an entire category of vendor risk that a hosted SaaS reconciliation tool cannot: there is no Paridity-operated environment holding customer data to breach, and no cross-customer blast radius from a shared multi-tenant service, because none exists in this deployment model. The one Paridity-operated service an installation talks to is the licence service, run by Evil Genius MindWorks LLC (EGMW), the company that makes Paridity, and hosted on Railway (the Data-Flow Disclosure names EGMW's sub-processors). It receives licence data only: the licence key, a machine id derived from a random installation id, the activation id, the product name, the platform and CPU architecture, and the request's source address - never customer data. In releases that enforce the licence (every release after v1.4.0), an installation that cannot reach it runs normally for 7 days, then a paid licence runs proof-only (counts and hash totals, no field-level diffs, and no new configuration brought into service) until it can; runs are never stopped.

On top of that architectural position, Paridity layers conventional defense-in-depth: OIDC/JWT-based authentication with role-based access control, PostgreSQL row-level security scoped to tenant as a database-layer backstop, a secrets-adapter model that never stores a credential in Paridity's own tables, a chained masking model that governs whether sensitive diff values are stored or displayed at all, and an append-only, cryptographically hash-chained evidence trail built for SOX/ICFR-grade audit. This paper documents what is implemented today and is explicit about what remains roadmap - per Paridity's own accuracy and honesty standard, an unverified claim is not stated as fact.

Problem¶

Enterprises evaluating a reconciliation platform to prove that data from their operational systems of record - SAP, Oracle, DB2, and other databases, plus SaaS and file sources - lands correctly in analytical targets (Snowflake, Databricks, BigQuery, Redshift, ADLS) are, by definition, evaluating a tool that will sit next to systems of record and produce evidence that may be relied on for SOX/ICFR controls. Extending that kind of access to a new vendor is itself a risk decision. Conventional SaaS reconciliation and data-observability tools typically require exporting database credentials, schema/object metadata, and often the underlying data values, to a vendor-hosted environment - expanding the customer's external attack surface, creating a new compliance-review burden at every renewal, and making the customer's audit evidence dependent on a third party's own security posture and uptime.

A vendor-risk team's standard questions - where does data live, who can access it, what happens in a vendor breach, is there a certification behind these claims - are exactly the questions this document answers directly, without inflating what is built versus what is planned.

Approach / architecture¶

Deployment & data-residency architecture¶

Today's shipping architecture. The full Paridity stack deploys inside the customer's own cloud account/VPC:

FastAPI control plane, React/Vite UI, Temporal orchestrator, and all six Temporal workers (scheduler, readiness, SQL, diff, evidence, notification)
A single PostgreSQL instance holding the configuration, run-state, and evidence schemas

Deployment is via an in-repo Helm chart covering the full stack (API, UI, Temporal, workers, preflight/migrate jobs, autoscaling, ingress) and Terraform reference modules for AWS, Azure, and GCP provisioning the cluster, a managed Postgres instance with backups/PITR, the customer's own secret backend, and an egress-locked network. Node egress is deny-by-default on all three clouds and reaches cloud services over private paths rather than the internet - AWS via PrivateLink VPC endpoints, GCP via Private Google Access, Azure via NSG service-tag rules - with only the operator's declared endpoints permitted outbound. This egress lockdown is verified live on all three clouds, by a from-empty deployment plus a probe confirming that a non-declared destination is refused outbound. Paridity operates no part of this infrastructure - there is no Paridity-hosted control plane, no Paridity-visible copy of customer data, and no Paridity credential store in this model. This is today's shipping architecture: the packaging is delivered and continuously validated in CI.

The one outbound path to Paridity: the licence check. The API pods and the scheduler worker call the EGMW licence service over HTTPS (port 443; default https://license.evilgenius.io, set by LICENCE_SERVER_URL; http:// is refused outside development and test) to activate and deactivate a licence and, in releases that enforce the licence, to refresh a signed licence token once a day. The request bodies carry only the licence key, the machine id, the activation id, the product name, and the platform and architecture - never an object, schema, or column name, a credential, an evidence value, or a tenant or user identity. The installation verifies the returned token offline against public keys built into the release image; the keys are a release constant, not a runtime setting, file, or database value. Because the licence service has a stable name but not a stable IP address, an egress-locked deployment routes the call through the customer's HTTPS egress proxy (the client honours HTTPS_PROXY and accepts a custom CA for a TLS-inspecting proxy); neither the Helm chart nor the Terraform modules open this path by default. Without it, the installation runs normally for 7 days on the token it holds, then a paid licence runs proof-only until a refresh succeeds - never a halt. An air-gapped installation cannot be activated today: the product reads a staff-issued offline activation code, but the licence service cannot yet issue one for Paridity. The Data-Flow Disclosure §3 gives the full detail.

Notification egress. Alerts and tickets go only to the destinations a platform admin configures on a notification channel (setting or changing a channel's credential or destination needs platform_admin). Every send is checked before the credential leaves the process: HTTP channels must use https, redirects are not followed, the destination's resolved addresses must not be private, loopback, link-local (including the cloud metadata endpoint 169.254.169.254), CGNAT, multicast or unspecified, and the address actually connected to is checked again before any response is read (for SMTP, before the password is sent). For internal systems (an SMTP relay, Jira Data Center, an on-premises ServiceNow) a platform admin can add an exact host and port to the tenant's private destination allowlist. An entry permits only addresses in 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10 or fc00::/7 for that host and port, only for that tenant's notification channels; the https, no-redirect and connected-address checks still apply, and the connection must land on an address the name resolved to when it was checked. Loopback, link-local and the AWS / Alibaba metadata addresses can never be allowlisted: such an entry is refused when it is added and such an address is refused at send time. Every allowlist change is audited. The Data-Flow Disclosure §4 describes the providers.

This whitepaper describes the shipping, customer-hosted architecture. A hosted deployment option is on our internal roadmap with no committed date; if it ships, the same hard invariant already governs its design - credentials, object/schema/column names, and evidence field values never leave the customer VPC and never reach Paridity-operated infrastructure - and that invariant is enforced as a review gate on all new work today.

Controls / details¶

Access control¶

Authentication. All user-facing API endpoints require an OIDC/JWT bearer token. Token validation enforces RS256/ES256 signature algorithms only (no alg=none), and verifies audience, issuer, and expiry before a request is authenticated. Audiences are applied per path: SCIM provisioning endpoints require their own dedicated audience and the /mcp agent surface another, so a user token cannot drive SCIM or /mcp and a SCIM or agent token cannot reach user endpoints.
Development bypass is production-guarded. A development-only authentication bypass exists for local use; the platform refuses to honor it outside a development/test environment, and it only short-circuits when no credentials are supplied at all - if a real bearer token or API key is present, it is validated normally, so RBAC still applies.
RBAC. Four roles form a strict hierarchy: platform_admin > operator > analyst > auditor. Role checks are enforced in the API layer only - never inside workers or services. Access is further scoped through grants that bind a principal to specific resources (e.g. a business domain), not just a role.
Single sign-on. Interactive browser SSO is available over SAML 2.0 (Okta and Microsoft Entra ID both live-verified) and, since v1.4.0, over OIDC: a server-side authorization-code flow with PKCE, where the API holds the client secret through the customer's secrets backend and accepts an ID token signed only with RS256, PS256, or ES256. OIDC sign-in is live-verified with Microsoft Entra ID; Okta OIDC sign-in is not yet live-tested. Both sign-in paths end in the same session step. SCIM user/group provisioning automates onboarding/offboarding. Separately, OIDC bearer tokens from a registered per-tenant issuer are validated for API and service-account access. Admin-sensitive actions (e.g. bypassing readiness on run creation) require platform_admin and are recorded in the tamper-evident audit log.
Tenant isolation. Every tenant-scoped table carries a tenant_id column, and every application query filters by it. As a defense-in-depth backstop below the application layer, PostgreSQL row-level security (RLS) is live in the production schema: 30+ tenant-scoped tables each carry a policy restricting visibility to the current tenant, and an unset session context fails closed to zero rows rather than failing open. Stated honestly: the application's database role currently retains a bypass on RLS, so RLS is today a backstop against a missing tenant predicate rather than the sole enforcement mechanism; binding the owner role with FORCE ROW LEVEL SECURITY is intentionally deferred until every application call-site is confirmed to set the tenant context. Primary tenant isolation today is the application-layer tenant_id predicate on every query; RLS is the layered backstop.

Secrets management¶

Paridity never stores customer credentials in its own database. A system's connection reference is always a URI pointer, never a secret, e.g. aws-secrets://..., azure-keyvault://..., gcp-secretmanager://..., infisical://.... A secrets client resolves the pointer to the actual credential at runtime by dispatching to the customer's own configured backend:

AWS Secrets Manager
Azure Key Vault
GCP Secret Manager
Infisical (self-hosted, MIT-licensed)
HashiCorp Vault - supported as an optional adapter for existing Vault customers only, never a default or required component.

In multi-tenant deployment configurations, each backend enforces per-tenant access scoping at the IAM/policy layer (e.g. AWS Secrets Manager resource-tag conditions, Azure Key Vault tenant-prefixed secret names, GCP Secret Manager IAM conditions on label match, Infisical per-tenant projects), so one tenant's application identity cannot resolve another tenant's secret. Because Paridity is single-tenant per deployment, this per-tenant secret scoping is inherent to the deployment model itself - each customer's Paridity instance only ever holds a pointer to that customer's own secret backend, in that customer's own cloud account.

Data protection¶

Evidence masking is an AND/OR-chained policy, not a single toggle. store_raw_diff_values - whether a mismatched field's actual before/after values are persisted at all - is an AND-chain across the tenant default, the mapping config, and the field config: any layer set to FALSE suppresses storage entirely and the row is written with NULL values and a masked flag. mask_in_ui - whether a field is masked on display even when raw values are stored - is a per-field control: set it TRUE on a field and display is masked (a tenant-wide display-mask policy is not currently offered). Evidence retrieval endpoints apply this masking at query time; a masked field never returns raw values regardless of caller role.
Evidence is append-only and tamper-evident. Evidence tables are never updated or deleted outside the retention purge function and two narrowly-scoped lifecycle exceptions (anomaly acknowledgment state; the single pending→generated evidence-bundle fill). Core evidence values are immutable once written. Evidence bundles are built once and sealed with a detached signature over the bundle manifest - which commits to every file's SHA-256 - plus a previous-bundle-hash linking each bundle to the prior one per mapping: a chain an auditor can walk independently, offline, with the shipped fail-closed verifier. The signing key is the customer's choice. A cloud-KMS key (AWS KMS, Azure Key Vault, or GCP KMS) or a local ECDSA key signs asymmetrically, so a third party verifies with the public key alone - no customer secret is disclosed and no platform access is needed; the private key never leaves the KMS. A customer-held HMAC key remains available. The bundle embeds the public key as a convenience and records its SHA-256 fingerprint in the manifest, but the assurance path is a key or fingerprint obtained out of band from the customer's own KMS - an attacker who rebuilds a bundle can embed their own key, so the embedded copy is never treated as proof by itself. A bundle whose signing key cannot be resolved ships unsigned, and the offline verifier refuses to report it verified.
Encryption in transit / at rest. Ingress terminates TLS for the UI/API; the pre-production security checklist requires Postgres connections to use TLS (sslmode=require or stricter) and managed-Postgres storage encryption, with a customer-managed key (CMK) as an available option. Stated honestly: these are deployment-configuration requirements verified at install time via the checklist, not properties Paridity's application code enforces unilaterally - because Paridity deploys into the customer's own cloud account, the customer's own cloud provider (KMS, TLS termination, managed-Postgres encryption) is the actual enforcement point, configured per the Terraform/Helm defaults and the pre-production checklist.
Encrypted source/target columns. Where a source or target column is itself encrypted (e.g. Oracle TDE, Snowflake native encryption), a per-field decryption expression is injected into the connector's generated SQL at query time only; decryption keys are resolved through the customer's secret backend, and Paridity never persists a decrypted value outside the normal evidence-masking rules above.
Object-name masking is per-surface, and we name the difference rather than let a reviewer find it. A tenant setting replaces table, schema, and column names with opaque <OBJECT:sha256[:8]> tokens - but it delivers a different guarantee on each of the two surfaces that can carry a name outward. On AI prompts Paridity itself routes to a model provider, the masking is absolute: masking is deny-by-default, so a string survives unmasked only if it is on a curated safe list, sits in fixed instructional text, or is mechanically provable as a non-name (an existing token, UUID, pure number, ISO-8601 timestamp, or phase/attempt id). A pattern miss over-masks; it cannot leak. On the /mcp agent surface it is best-effort: only values under a defined list of object-name fields are tokenized, and any other field carrying a name is returned in clear text.
Why the MCP behaviour is deliberate, and the residual risk it leaves. /mcp is an authenticated customer API at parity with REST, not a Paridity-routed prompt path: the customer's own agent authenticates with the customer's own credentials against a model the customer chose, so the customer is the disclosing party. Deny-by-default masking would defeat the surface's purpose - triage requires naming which column drifted, not merely that one did. The residual risk we state explicitly: same authorization is not the same disclosure surface. A person reading a table name on a Paridity screen does not thereby place it in an LLM context window, a provider's request logs, or a retention window; an MCP client does, automatically, on every call. The permission check is identical to REST; the practical egress is not. In short: on /mcp it is your agent, your credentials, your disclosure - a single setting deliberately governs both surfaces, because a dedicated MCP toggle would present a best-effort mechanism as a guarantee a reviewer could rely on. Compensating controls, each enforced in code rather than by convention: the surface is off by default (with a 403 when disabled) and, in production, the API refuses to start with AI enabled unless a tenant has explicitly opted in; per-tool RBAC uses the same permission strings as the equivalent REST routes; tenant scope always comes from the authenticated principal, never a tool argument; the catalog is read-only, with arbitrary SQL, shell, secret retrieval, file access, and direct database modification permanently excluded; every dispatched tool call is audited; and a per-principal, per-tool rate limit sheds abuse before dispatch. /mcp is classified data-plane and runs entirely inside the customer's own environment, like the rest of the platform. The control that closes the gap is the customer's: govern which MCP clients and which models may hold Paridity credentials, exactly as you would govern REST API keys.

Supply-chain / OSS posture¶

Every dependency in the technology stack is MIT, Apache 2.0, or a comparably permissive license (e.g. the PostgreSQL License) - no GPL, AGPL, or SSPL component is used anywhere in the platform. Two components are deliberately excluded from default use for licensing reasons rather than adopted and then carved around: HashiCorp Vault (BSL 1.1) is optional-only, never a default or required dependency; Confluent Platform components (Schema Registry, ksqlDB, REST Proxy) are excluded in favor of Apache Kafka core only, because the Confluent Community License bars competing SaaS offerings. Every release additionally publishes a machine-generated SPDX SBOM per container image, generated from the published image digests, and signs every released image and the Helm chart with keyless signing (Sigstore) so a customer can verify provenance before mirroring the images into their own registry (most recently verified on the v1.4.0 release, 2026-10-28). Every code change is gated in CI by dependency-vulnerability audits (Python and production JavaScript), Semgrep static analysis, a full-history secret scan (Gitleaks), and a configuration scan (Trivy); release images are additionally Trivy-scanned for fixable HIGH/CRITICAL vulnerabilities before they are pushed, and the latest release's images are re-scanned weekly. A dedicated supply-chain posture document is available for third-party-risk review.

Proof / evidence¶

Paridity's core correctness claim - the thing a security/audit reviewer should actually trust the product on - is deterministic, not AI-assisted or heuristic. A run establishes correctness through aligned time windows, an aggregate dataset fingerprint (hash_total) as a fast pass/fail proof gate, per-row fingerprints (row_hash) to isolate exactly which rows differ, and column-level output (field_diff) as the actual reconciliation evidence. Hash implementations are verified byte-for-byte against a reference engine on every supported database, and an accuracy issue is never closed until a live test vector confirms the fix. Every run's config is fingerprinted (config_checksum) and written to an append-only config audit before the proof phase begins, so an auditor can confirm the policy in force during a run independent of its outcome.

The proof gate's threat model is scoped explicitly. The hash_total aggregate defends against non-adversarial divergence - replication defects, corruption, drift - with a quantified collision probability (about one in ten quintillion per comparison). It is not designed to resist a construction-aware insider who can write the datasets being compared: a 64-bit SQL-pushable aggregate is adversarially weak by construction, and adversarially secure alternatives cannot be computed inside the customer's own engines, which is the property the proof's verifiability rests on. That insider case is covered by compensating controls, not by the aggregate: the customer's own database access controls and change auditing, Paridity's append-only evidence, the hash-chained and checkpoint-signed audit log, signed offline-verifiable evidence bundles, and RBAC separation. The full threat-model statement is given in Paridity's accuracy proof documentation.

Note: AI in Paridity assists triage and explanation only - it never determines whether data matches. Correctness is always established by the deterministic hash_total / row_hash / field_diff pipeline above, never by a model's judgment.

Limitations & roadmap honesty¶

Capability	Status	Notes
Customer-hosted deployment - customer data never leaves customer VPC	Verified	Helm + Terraform; the full stack deploys in the customer VPC, delivered and CI-gated. The one outbound call to Paridity is the licence check, which carries licence data only (next row).
Licence check to the EGMW licence service	Supported	Activation, deactivation, and (in releases after v1.4.0) a daily token refresh over HTTPS 443; licence data only. 7 days of normal running without it, then proof-only for a paid licence, never a halt. Egress-locked deployments need an HTTPS egress proxy for it; neither the chart nor the Terraform modules open the path by default. Offline (air-gapped) activation is not yet available from the licence service.
OIDC/JWT authentication, RBAC, scoped grants	Verified	Enforced in the API authentication layer.
SSO - Okta (SAML)	Verified	Live-verified.
SSO - Microsoft Entra ID (SAML)	Verified	Live-verified, including SCIM provisioning.
SSO - OIDC sign-in (authorization code + PKCE)	Verified (Entra); Supported (other providers)	Live-verified with Microsoft Entra ID before v1.4.0; Okta OIDC sign-in not yet live-tested.
SCIM user/group provisioning	Verified	Create / update / deprovision live-verified against Microsoft Entra.
Tenant isolation - application-layer `tenant_id` predicate	Verified	Enforced on every query.
Tenant isolation - PostgreSQL RLS (defense-in-depth)	Supported	Live in the production schema; `FORCE ROW LEVEL SECURITY` intentionally deferred pending a call-site audit (the app role currently retains an RLS bypass).
Secrets never stored by Paridity; pluggable backends	Verified	The connection reference is a URI pointer only, resolved at runtime against the customer's own secret backend.
Evidence masking (`store_raw_diff_values` AND-chain; `mask_in_ui` per-field display mask)	Verified	Enforced at config-resolution and query time. A tenant-wide display-mask policy is not currently offered - masking display is a per-field control.
Object-name masking - AI prompt path	Verified (absolute)	Deny-by-default; a pattern miss over-masks and cannot leak.
Object-name masking - `/mcp` agent surface	Best-effort by design - stated, not implied	Allowlisted object-name fields are tokenized; other fields carrying a name are returned in clear text, at REST parity. Deliberate - the customer's agent and model are the disclosing party. Bounded by the controls in "Data protection" above; do not represent it as absolute.
Append-only, hash-chained evidence bundles	Verified	Per-file SHA-256 manifest + detached signature over the shipped bytes + previous-bundle chain; verifiable offline with the shipped fail-closed tool. Asymmetric signing (AWS KMS, Azure Key Vault, GCP KMS, or a local ECDSA key) lets a third party verify with the public key alone - no customer secret; a customer-held HMAC key remains available. An unsigned or tampered bundle never reports as verified.
Evidence-bundle retention with a built-in purge schedule	Supported	`bundle_retention_days` resolves per tenant with a platform floor; a built-in `RetentionPurgeWorkflow` runs on a default-on schedule, dry-run first, and writes an audit row for every deletion - including the object store's own answer per object. Cadence and thresholds are deployment configuration.
Legal hold - freeze evidence from retention purge	Supported	An approval-gated hold placed on a tenant, mapping, or bundle causes the purge to skip and audit the skip. Placing and releasing a hold each require the `evidence.legal_hold` permission and are written to `cfg.audit_log`.
Period bundles in customer-owned, write-once object storage	Verified	Optional per-tenant tier: the signed container is written to the customer's own S3, Azure Blob, or GCS bucket and the platform database keeps no bytes - only the object URI, size, SHA-256, and the store's receipt. Where the store confirms immutability (S3 Object Lock, Azure immutability policy, GCS retention), the bundle is attested as anchored; an unprotected store is never attested as one.
TLS in transit / encryption at rest	Supported	Enforced via deployment configuration (Terraform/Helm defaults + pre-production checklist), not unilaterally by application code - see "Data protection" above.
OSS license posture (no GPL/AGPL/SSPL)	Verified	Permissive-only by binding engineering rule.
Machine-generated SBOM + signed release artifacts	Verified	SPDX SBOM per image + keyless (Sigstore) image and chart signatures, published every release.
SOC 2 / ISO 27001 certification	None held, none planned	No certification exists, and no SOC 2 or ISO 27001 audit is planned now or in the immediate future. These attest a service organization's controls over the customer data it hosts or processes. Paridity is software the customer runs in its own environment; EGMW does not host it and does not process customer data, so the controls that matter for the deployment are the customer's own, under the customer's own certifications and audits.
Proof gate vs. adversarial dataset tampering	Out of scope by design - stated, not implied	The `hash_total` proof targets replication faults/corruption (quantified collision bound); a construction-aware insider writing compensating rows into the compared datasets defeats any SQL-pushable 64-bit aggregate. Covered by compensating controls - see "Proof / evidence" above.
Independent penetration test	Not performed, none scheduled	No third-party penetration test has been performed and none is scheduled. What runs is automated, on every code change: Semgrep static analysis, dependency vulnerability audits, a full-history Gitleaks secret scan, and a Trivy configuration scan; release images are Trivy-scanned before release and re-scanned weekly. A dynamic scan (DAST) runs weekly in CI: OWASP ZAP against a throwaway stack built from the current code - a passive baseline scan of the production UI image, and an authenticated, active scan of the API driven by the API's own OpenAPI document. The job fails on any finding in a FAIL-level class (injection, cross-site scripting, path traversal, XML external entities, remote code execution, server-file disclosure, open redirect, and the security headers already in place) and when the API scan cannot be shown to have run authenticated. This is automated scanning, not a penetration test: it does not chain findings, test business logic or tenant isolation, or test a real deployment's ingress, TLS or identity provider. The customer may test its own deployment, which runs in its own environment (Acceptable Use Policy §6.1).
Internal security review	Performed 2026-10-30 to 2026-11-01 (internal, not third-party)	An internal, AI-assisted code review of the Paridity source (#3357), carried out by EGMW with an AI model in four passes from 2026-10-30 to 2026-11-01. No outside party took part. Scope: tenant isolation and authorization; authentication (bearer tokens, SAML, OIDC, SCIM, API keys); generated SQL; licensing; secrets and logging. Every item in scope was read line by line and either demonstrated as a finding, ruled out with a recorded counter-check, or pinned by a test. A finding required a test, committed to the repository, that failed against the code before the fix. Five findings: three high (#3365, #3369, #3398), one medium (#3383), one low (#3384); all five were fixed by 2026-11-01. This is a secure-development control, not a penetration test and not a third-party assessment: it reviewed source code and a development stack, did not test a customer deployment's ingress, TLS or identity provider, and did not exercise exploit chains against live credentials. The review record (method, coverage, findings, hypotheses not demonstrated, ruled-out items with their counter-checks, follow-ups) is retained by EGMW and available on request.
Formal security program / incident-response plan	Not in place	EGMW is a small business with no formal, documented security program or incident-response plan today. Contractual incident terms are in the agreement.
Disaster recovery (backup/PITR, restore playbook)	Supported	RPO/RTO targets and restore procedures are documented per deployment tier. The restore-validation drill is automated in Paridity's CI on a quarterly schedule against its reference environment; it has executed once to date (2026-08-17, a manual dispatch), and the first scheduled run is 2026-11-01. RTO at realistic evidence volume is not yet measured.

Further information¶

Trust Center - the index to Paridity's security and compliance materials.
Supply-chain & OSS posture - full dependency/license inventory, SBOM, and signing verification steps.
Accuracy proof & verification guide - the deterministic correctness record behind the hash_total / row_hash / field_diff claims, with steps to reproduce them yourself.
Additional architecture and control documentation (deployment model, tenant isolation, disaster recovery, the pre-production security checklist) is available to reviewers on request through your Paridity account contact.