Compliance
What the architecture makes structural, what remains procedural, and what is missing.
Some compliance objectives are satisfied by how a system is shaped; others need an organisational programme on top. This page separates the two, and says plainly where the gaps are.
Structural
Own-infrastructure deployment turns several objectives from procedural commitments into architectural facts:
| Objective | Why it becomes structural |
|---|---|
| Data residency | Data never leaves your chosen server, region or cloud account. Residency is inherent, not a configuration toggle |
| Data minimisation | The vendor processes only what it needs to operate and bill, and retains no content |
| Processor scope | Because content stays with you, the vendor's role is narrowly scoped — which simplifies the data-processing agreement |
| Encryption in transit and at rest | Tunnel plus mutual TLS in transit; disk plus box-held key at rest, with keys the vendor does not hold |
| Auditability | Every privileged action logged, credential-free |
Control mapping
| Criterion | Posture | Notes |
|---|---|---|
| Security | Strong | Encryption, tenant isolation, RBAC, audit, gateway |
| Confidentiality | Strong | Encryption at rest and in transit, perimeter, sovereignty |
| Availability | Partial | Health probes and orchestration in place; formal SLO and disaster-recovery documentation outstanding |
| Processing integrity | Partial | Idempotency, audit and reconciliation in place; formal documentation partial |
| Privacy | Partial | Selective erasure not built |
Gaps, stated plainly
Do not build a compliance programme around these until they land.
- No SOC 2 Type 2 attestation. The control mapping exists and the controls are real. The audit is an organisational programme that has not been completed. SOC 2 is not something code can produce.
- No HIPAA BAA.
- No selective right-to-erasure. Whole-tenant purge exists; per-record erasure does not. This is the most commonly requested missing control, and the honest answer is that it is on the roadmap.
- No formal DR/RPO/RTO documentation or published backup-restore evidence.
- Backup and restore for a memory box is not built. For an own-infrastructure deployment, backup is currently your responsibility. This matters and is called out here rather than buried.
Subprocessors
Model inference, email delivery, payments and cloud infrastructure involve third parties. Request the current subprocessor list through your account contact — it is maintained as a controlled document rather than published here, so that it cannot drift out of date on a docs page.
In bring-your-own-model mode, inference does not touch a Chordian subprocessor: content reaches only the provider you already have a relationship with.
Claim guardrails
For anyone writing about Chordian externally:
| Claim | Permitted for |
|---|---|
| "Data never leaves your infrastructure" | Own-server and own-cloud deployments only |
| "Air-gapped install" | Own-infrastructure, validated |
| "Air-gapped processing" | Own-infrastructure in bring-your-own or in-box model mode only |
| "Encrypted at rest and in transit" | All tiers |
| "Tenant isolation enforced on every query" | All tiers |
| "SOC 2 certified" | Nobody. Not yet true |
| "GDPR right to erasure supported" | Nobody. Not yet built |